# Engagement Metrics: Measure How a Variant Affects a Page
Source: https://docs.abconvert.io/analytics/engagement-metrics
Understand whether a variant makes a page or template more engaging: how often visitors click through, how often they bounce, and how long they actively stay.
Engagement metrics show whether a variant keeps visitors interested. You see it in days, long before you have enough sales to call a winner. An engaging page is one where the visitor clicks through to another page, doesn't bounce, and stays longer. ABConvert measures this on the pages your test changed, so it complements your [traffic and conversion metrics](/analytics/metrics), which cover the whole funnel.
## When to use it
* **Landing-page redirect tests.** Run a [URL redirect test](/experiments/url-redirect-test) between two landing pages and see which one keeps visitors clicking through instead of bouncing.
* **Template and theme tests.** When a [template test](/experiments/template-test) changes a product or collection layout, check whether the new layout earns more scroll, more clicks, and longer active time.
* **Visual editor changes.** After a [visual editor test](/experiments/visual-editor-test) rearranges a page, confirm the change helped engagement on exactly the pages it touched.
* **Guarding against side effects.** When a price test changes what shoppers see, check that browsing engagement on the tested product pages didn't drop.
## When NOT to use it
* **Measuring revenue or conversion lift.** Engagement tells you whether visitors stayed and clicked, not whether they bought. Use [traffic and conversion metrics](/analytics/metrics) instead.
* **Reconciling against GA4.** These are measured per page and won't line up with GA4's session numbers. See the FAQ for why.
* **Tests with no page or template target.** Shipping, payment, and checkout tests don't change a specific page, so an engagement number for the whole store mixes the test in with everything else and tells you nothing. Judge those on conversion and revenue instead.
## The three metrics
Each metric is measured per page view, then totaled for the page or template in scope.
| Metric | What it means |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Click-Through Rate | How often visitors click through to another page on your store, as a share of page views. Higher is usually better. |
| Bounce Rate | Share of page views with no engagement. A view counts as engaged if the visitor scrolled, clicked through, or stayed active for over 10 seconds. Lower is usually better. |
| Avg Time on Page | Average active time visitors spend on the page, not counting time the tab sits in the background. Longer usually means more interest. |
The breakdown table also shows two supporting counts:
* **Page views** are how many times visitors in this test loaded a page inside the scope you picked. The three rates above are all measured out of this number, so a small page-view count means the rates are still noisy.
* **Clicks** are how many times visitors clicked through to another page on your store.
**Example.** Your redirect test sends visitors to Landing B. Control bounces 62%, Variant B bounces 48%, and Variant B also lifts click-through from 22% to 31% and keeps visitors longer on average: three signals pointing the same way. Click the **Destination** tab to see where click-throughs went.
## How scope works
Scope is the set of pages you want this test judged on. It matters because if you measure the whole store, the few pages your test changed get drowned out by all the pages it didn't, and a real improvement can vanish into the average.
The scope button reads **Storewide**, or a count like **3 pages** or **2 templates**. Click it to view the pages in scope, or to open the **Edit scope** modal. (A template is the shared layout behind a group of pages, like the layout every product page uses.)
Try it: open a redirect test's Engagement section and click the scope button.
![Engagement section of the Analytics dashboard with a 4 pages scope button, showing Click-Through Rate, Bounce Rate, and Avg Time on Page cards that each compare Control and Variant A]()
### Default scope per test type
When a test launches, ABConvert seeds a default scope from what the test actually changes, so engagement points at the right pages from day one.
| Test type | Default scope |
| ----------------------------------------------------- | ------------------------------------------------------------------------------ |
| [Price test](/experiments/price-test) | The tested products' product pages (`/products/{handle}`, exact match) |
| [URL redirect test](/experiments/url-redirect-test) | Each rule's trigger and destination URLs, using that rule's own match type |
| [Template test](/experiments/template-test) | The templates assigned to control and variants, matched as templates |
| [Visual editor test](/experiments/visual-editor-test) | The page URLs each modification targets, matched as a pattern (glob supported) |
| Shipping, offer, theme, checkout tests | Storewide (these don't target specific pages) |
For the storewide-by-default types you can still narrow scope by hand. A **Reset to default** action restores the launch-derived default at any time.
### Edit the scope
Open the **Edit scope** modal and pick a mode:
* **Storewide** measures every page.
* **By URL** takes one or more URL rules. Each rule has a match type: **Exactly matches**, **Starts with**, or **Contains**. (Visual editor tests, which support glob URLs, also offer **Matches pattern**.)
* **By template** lets you pick templates, so engagement rolls up by template instead of by URL.
Rules seeded from the test's launch default are tagged **from test**, so you can tell them from ones you added by hand.
![Edit scope modal in By URL mode, with a match-type dropdown set to Exactly matches and a field to search pages or paste a URL, listing four URL rules with Contains, Starts with, and Exactly matches badges, each tagged from test, plus Reset to default, Cancel, and Apply]()
### Break engagement down
Breakdown tabs read the metrics across a dimension:
* **All** totals the whole scope.
* **Page** lists one row per URL (URL scope only).
* **Template** lists one row per template (template scope only).
* **Destination** shows where click-throughs went (available whenever your scope is narrower than the whole store).
* **Country**, **Device Type**, and **Traffic Source** split by audience.
* **Custom** combines two dimensions, for example page by destination.
![Engagement breakdown table for a template-scoped test, with tabs for All, Template, Destination, Country, Device Type, Traffic Source, and Custom, and columns for CTR, Bounce, Avg time, Page views, and Clicks per test group]()
A click-through counts whenever a visitor moves to another page on your store, by a link, a button, or submitting a form, not just tracked link clicks. Going to another website doesn't count.
## Common mistakes
* **Benchmarking against GA4.** GA4 measures engagement per session with proxies; ABConvert measures it per page directly. The numbers are built differently and won't match. Compare variant against control inside ABConvert.
* **Leaving scope at Storewide on a redirect or template test.** A few changed pages get diluted by every untouched page, and the lift disappears. Use the launch-derived default, or scope by URL or template to the pages the test changes.
* **Expecting data for anonymous visitors.** Engagement is only collected after a visitor is assigned to a test, so unassigned traffic never appears.
* **Comparing Click-Through Rate across different scopes.** A rate measured over product pages and a rate measured storewide aren't the same denominator. Keep the scope fixed when you compare.
## FAQ
A visitor moving to another page on your store, by a link, a button, or submitting a form, not just tracked link clicks. Going to another website doesn't count.
When the visitor scrolled, clicked through, or stayed active for over 10 seconds. A view with none of those counts as a bounce.
Click-Through Rate is onward navigations divided by page views. Bounce Rate is 1 minus engaged page views divided by page views. Avg Time on Page is the average active (foreground) time per page view, including the last page a visitor saw.
No. It counts only active, in-focus time. Time the tab sits in the background is excluded. The exit page is included in the average.
They are not meant to. ABConvert measures engagement per page at page grain; GA4 measures it per session with proxies. Use ABConvert's numbers to compare variant against control, not to reconcile with GA4. See [GA4 integration](/configuration/ga4-integration).
ABConvert seeds it from what the test changes at launch. Edit it any time; **Reset to default** restores the seeded scope. See [How scope works](#how-scope-works).
Yes. In the Edit scope modal choose **By template** and pick your templates. The breakdown then shows a **Template** tab with one row per template.
With a non-storewide scope, open the **Destination** breakdown tab. It lists where click-throughs went, so you can read flows like homepage to a specific product page.
For how to read whether a difference is real rather than noise, see [statistical significance](/analytics/statistical-significance) and the [Analytics overview](/analytics/overview).
# How to Interpret Analytics Results and Choose a Next Action
Source: https://docs.abconvert.io/analytics/interpret-results
Learn how to read an ABConvert analytics dashboard, choose one primary metric, check guardrails, and decide what to do next.
Use this tutorial when you need to turn one Analytics dashboard into a clear decision: ship the variant, keep running the Experiment, or revise the Experiment.
## If you remember only four things
* Pick exactly **one primary metric** before the Experiment starts.
* Use guardrail metrics to catch side effects, not to create a second primary winner rule.
* Check visitor count, run time, and traffic split before you decide.
* Do not ship if guardrails show a business risk that matters.
## Start by choosing one primary metric
Your primary metric is the one number that decides whether the Experiment worked. Choose it before the Experiment starts.
| Your goal | Choose one primary metric |
| ---------------------------------------- | ------------------------------------------------- |
| Increase purchase likelihood | **Conversion Rate** |
| Increase user spending in a single order | **Average Order Value** |
| Increase value per visitor | **Revenue per Visitor** or **Profit per Visitor** |
For metric definitions, see [Analytics metrics](/analytics/metrics), [Traffic and conversion metrics](/analytics/metrics-traffic-conversion), and [Revenue and profit metrics](/analytics/metrics-revenue-profit).
## Choose guardrails after the primary metric
Guardrails are the checks that stop you from shipping a harmful variant. Pick them from the business goal and the risk you expect.
Use two or three guardrails. They do not need to beat control. They need to stay healthy enough for the decision to make business sense.
* If the goal is more purchases and the primary metric is **Conversion Rate**, guardrails may include **Revenue per Visitor** or **Profit per Visitor**. This checks that more purchases are not coming from lower-value or lower-margin orders.
* If the goal is higher order value and the primary metric is **Average Order Value**, guardrails may include **Conversion Rate** and **Profit per Visitor**. A higher threshold or bundle can raise order value while reducing purchase likelihood or profit per visitor.
## Check whether you have enough data to decide
Review the sample before you choose the next action.
| Check | What to look for | What to do if it looks wrong |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Visitor count | Each variant has enough visitors for your store's normal purchase volume. As a rough starting point, wait until each variant has at least 100 converted orders when the primary metric depends on purchases. Small effects or high-risk decisions need more data. | Keep running until each variant has more exposure and enough converted orders. |
| Run time | The Experiment has covered at least one normal business cycle, such as weekdays and a weekend. | Keep running unless the primary metric or a guardrail is moving sharply negative. |
| Traffic split | Visitor share is close to the expected distribution, such as 50/50 or 34/33/33, and matches the observed data well enough to compare variants. | Check the Experiment setup before rollout. Keep running if the split is still settling. |
Running for 1-2 weeks helps include weekday and weekend behavior. High-traffic
stores may reach a useful visitor count sooner. Low-traffic stores often need
more time.
There is no universal visitor number that makes every Experiment ready. Use your store's normal traffic volume as the sanity check.
## What not to do when reading results
* Do not end an Experiment in the first two days only because confidence shows 95%. Early confidence can jump around when the sample is small.
* Do not change the primary metric after the Experiment starts just to make a variant look better.
* Do not ignore guardrails. A variant can win the primary metric and still hurt profit, order value, or purchase likelihood.
## Convert the dashboard into a decision
Use this matrix after you check visitor count, run time, and traffic split.
| Result | What it looks like | Next action |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Winner | One variant leads on the primary metric, guardrails are acceptable, and the expected gain is larger than the work and risk of rollout. | Ship the variant or schedule rollout. Record why the gain is worth the change. |
| Candidate to ship | One variant leads on the primary metric, but guardrails seem risky or the rollout risk is close to the expected gain. | Review the risk, adjust the rollout plan, or revise the variant before shipping. |
| Unclear | The lead is small, the result keeps moving, traffic is imbalanced, or the business impact does not clearly beat rollout cost. | Keep running, segment the result, or stop and test a bigger change. |
Rollout cost includes implementation work, QA, customer support risk, operational changes, and margin or brand tradeoffs.
As a default, do not ship a variant for a tiny projected lift if rollout needs theme edits, checkout QA, pricing policy changes, new support macros, or extra fulfillment work. Ship when the gain is clearly worth those changes for your store.
## Example: Revenue per Visitor winner
The Holiday Pricing Experiment dashboard uses **Revenue per Visitor** as the primary metric.
The Experiment uses a 34/33/33 traffic split across control and two variants. The sample includes 25,540 visitors.
Variant B leads. It is up 13.3% in Revenue per Visitor versus control. The estimated monthly revenue uplift is 6,420. The estimated monthly profit uplift is 2,775.
Profit is positive, with 13.05% estimated profit uplift. Variant B is a winner when the run time is long enough for your store and the gains beat normal rollout cost.
## Example: Conversion rate winner but profit loser
Suppose your primary metric is **Conversion Rate** because you want more visitors to purchase.
Variant A increases Conversion Rate by 8%, but **Profit per Visitor** drops by 12%. The variant used a larger discount, so more visitors bought, but each visitor produced less profit.
This is a candidate to ship only if the profit risk is acceptable. In most stores, a better next Experiment would use a smaller discount, a higher free-shipping threshold, or a bundle offer that protects margin.
# Analytics Metrics: How ABConvert Groups and Calculates Them
Source: https://docs.abconvert.io/analytics/metrics
See how Analytics v2 groups metrics in ABConvert and jump to detailed guides for traffic, conversion, revenue, profit, and discount metrics.
ABConvert Analytics v2 groups metrics by role so you can evaluate each test from multiple angles: traffic quality, conversion behavior, business impact, and discount cost.
## How are metrics grouped in Analytics v2?
| Group | Includes |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Traffic | Visitors, Sessions |
| Funnel | Product Viewed, Added to Cart, Reached Checkout, Contact Submitted, Address Submitted, Shipping Submitted, Payment Submitted, Completed Checkout |
| Conversion | Conversion Rate (Visitors), Conversion Rate (Sessions), Add to Cart Rate, Reached Checkout Rate |
| Abandonment | Cart Abandonment Rate, Checkout Abandonment Rate, Shipping Step Drop-off Rate |
| Revenue / Profit | Orders, Average Order Value (AOV), Revenue per Visitor (RPV), Profit per Visitor (PPV) |
| Discount | Discounted Order Rate, Average Discount Value, Revenue Discount Percentage, Profit Discount Percentage |
| Engagement | Click-Through Rate, Bounce Rate, Avg Time on Page |
## Where should you start?
Learn how visitor and session counts are derived, how funnel steps map to Shopify events, and how conversion and abandonment rates are calculated.
Understand ecommerce impact metrics such as Orders, AOV, RPV, and PPV, and how COGS settings affect profit accuracy.
See how product, order, and shipping discounts roll up into discount KPIs, and why they are critical for offer tests.
See whether a variant makes a page or template more engaging: click-through, bounce, and active time on the page.
## How are these metrics calculated?
All metric formulas in these pages match ABConvert's Analytics v2 metric definitions in the app code.
If you want to choose one primary metric and decide what to do next, see [How to interpret Analytics results](/analytics/interpret-results).
If you want to interpret p-values, confidence intervals, and probabilities alongside these metrics, see [Statistical significance](/analytics/statistical-significance).
# Discount Metrics in Analytics v2
Source: https://docs.abconvert.io/analytics/metrics-discount
Understand where discount values come from in ABConvert Analytics v2 and how to use discount metrics to evaluate offer test impact.
Discount metrics quantify how much margin your variant gives away. They are essential for offer tests where discount behavior is the main lever.
## Where do discount values come from?
ABConvert calculates total discounts from Shopify order data using discount allocations.
For each order, discount value is aggregated from:
* **Product discount value** from line-item discount allocations.
* **Order discount value** that Shopify allocates across line items.
* **Shipping discount value** from shipping-line discount allocations.
In Analytics v2, these roll up into `total_discounts`, which powers all discount KPIs.
## What do discount metrics mean?
| Metric | Definition | Formula |
| --------------------------- | --------------------------------------- | --------------------------------------- |
| Discounted Order Rate | Share of orders that used any discount. | `Discounted Orders / Orders × 100` |
| Average Discount Value | Average discount amount per order. | `Total Discounts / Orders` |
| Revenue Discount Percentage | Total discounts as a share of revenue. | `Total Discounts / Total Revenue × 100` |
| Profit Discount Percentage | Total discounts as a share of profit. | `Total Discounts / Total Profit × 100` |
## Why are these metrics critical for offer tests?
In offer tests, conversion or revenue lift is only half the story. You also need to measure discount cost.
Use these metrics together to decide whether a variant is truly better:
* Use **Discounted Order Rate** to see how broadly the offer is being used.
* Use **Average Discount Value** to see the typical cost per order.
* Use **Revenue Discount Percentage** and **Profit Discount Percentage** to quantify margin impact.
# Revenue and Profit Metrics in Analytics v2
Source: https://docs.abconvert.io/analytics/metrics-revenue-profit
Learn how ABConvert calculates revenue and profit metrics in Analytics v2 and how to use them for ecommerce decisions.
Revenue and profit metrics show whether a variant is good for your business, not just good for click-through or checkout progression.
## Why do revenue and profit metrics matter in ecommerce?
Conversion lift alone can be misleading. A variant can increase conversion rate while lowering basket value or margin. Revenue and profit metrics help you answer the questions that matter most:
* Are you earning more money per visitor?
* Are you earning more profit per visitor after costs?
* Are larger order values driving the result, or only higher order counts?
## What do revenue and profit metrics mean?
| Metric | Definition | Formula |
| ------------------------- | ------------------------------------------------------- | -------------------------- |
| Orders | Distinct completed orders attributed to the experiment. | `COUNT(DISTINCT order_id)` |
| Average Order Value (AOV) | Average revenue per order. | `Total Revenue / Orders` |
| Revenue per Visitor (RPV) | Average revenue generated per visitor. | `Total Revenue / Visitors` |
| Profit per Visitor (PPV) | Average profit generated per visitor. | `Total Profit / Visitors` |
## How is profit calculated?
ABConvert computes order-level profit as:
`Revenue - Product Cost - Shipping Cost - Transaction Fee`
These values come from your COGS settings (product costs, shipping cost per order, and transaction fee rules).
If you want accurate PPV and other profit metrics, configure COGS before analyzing winners. See [COGS settings](/configuration/settings#cogs-settings).
# Traffic and Conversion Metrics in Analytics v2
Source: https://docs.abconvert.io/analytics/metrics-traffic-conversion
Understand how ABConvert derives visitor and session metrics, maps funnel steps to Shopify standard events, and calculates conversion and abandonment rates.
Traffic and conversion metrics tell you whether a variant improves shopper behavior through the funnel, not just final orders.
## How are visitors and sessions derived in ABConvert?
ABConvert computes traffic metrics from experiment-attributed event data:
* **Visitors** = distinct `visitor_id` values in experiment events.
* **Sessions** = distinct `session_id` values in experiment events.
A visitor can create multiple sessions, so Sessions is usually higher than Visitors.
## Which Shopify events power funnel tracking?
ABConvert's funnel steps map to Shopify Web Pixels standard events. See Shopify's full event reference at [Shopify Web Pixels standard events](https://shopify.dev/docs/api/web-pixels-api/standard-events).
| Funnel step in ABConvert | Shopify standard event |
| ------------------------ | ---------------------------------- |
| Product Viewed | `product_viewed` |
| Added to Cart | `product_added_to_cart` |
| Reached Checkout | `checkout_started` |
| Contact Submitted | `checkout_contact_info_submitted` |
| Address Submitted | `checkout_address_info_submitted` |
| Shipping Submitted | `checkout_shipping_info_submitted` |
| Payment Submitted | `payment_info_submitted` |
| Completed Checkout | `checkout_completed` |
**Client-side vs. server-side tracking:** Funnel-step metrics on this page are derived from experiment-attributed events, including Shopify Web Pixel events such as `checkout_started` and `checkout_completed`. Browser-side events can occasionally be blocked or dropped by ad blockers, privacy features, or network interruptions, so middle-funnel steps may be slightly underreported.
Order-backed metrics come from confirmed Shopify order data, which reaches ABConvert server-to-server and is not affected by the visitor's browser environment. As a result, order-backed metrics such as conversion rate, average order value, and revenue per visitor are less affected by missed browser-side events.
## What do traffic, conversion, and abandonment metrics mean?
| Metric | Definition | Formula |
| --------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Visitors | Distinct visitors attributed to the experiment. | `COUNT(DISTINCT visitor_id)` |
| Sessions | Distinct sessions attributed to the experiment. | `COUNT(DISTINCT session_id)` |
| Product Viewed | Sessions where a product view event occurred. | `COUNT(DISTINCT session_id where event_type = product_viewed)` |
| Added to Cart | Sessions where an add-to-cart event occurred. | `COUNT(DISTINCT session_id where event_type = product_added_to_cart)` |
| Reached Checkout | Sessions where checkout started. | `COUNT(DISTINCT session_id where event_type = checkout_started)` |
| Contact Submitted | Sessions where contact info was submitted. | `COUNT(DISTINCT session_id where event_type = checkout_contact_info_submitted)` |
| Address Submitted | Sessions where address info was submitted. | `COUNT(DISTINCT session_id where event_type = checkout_address_info_submitted)` |
| Shipping Submitted | Sessions where shipping info was submitted. | `COUNT(DISTINCT session_id where event_type = checkout_shipping_info_submitted)` |
| Payment Submitted | Sessions where payment info was submitted. | `COUNT(DISTINCT session_id where event_type = payment_info_submitted)` |
| Completed Checkout | Sessions where checkout completed. | `COUNT(DISTINCT session_id where event_type = checkout_completed)` |
| Conversion Rate (Visitors) | Share of visitors with at least one completed order. | `Visitors with orders / Visitors × 100` |
| Conversion Rate (Sessions) | Share of sessions with at least one completed order. | `Sessions with orders / Sessions × 100` |
| Add to Cart Rate | Share of sessions that reached add to cart. | `Added to Cart / Sessions × 100` |
| Reached Checkout Rate | Share of sessions that reached checkout start. | `Reached Checkout / Sessions × 100` |
| Cart Abandonment Rate | Share of add-to-cart sessions that did not reach checkout. | `(1 - (Reached Checkout / Added to Cart)) × 100` |
| Checkout Abandonment Rate | Share of checkout-started sessions that did not complete checkout. | `(1 - (Completed Checkout / Reached Checkout)) × 100` |
| Shipping Step Drop-off Rate | Share of sessions that dropped between address and shipping submission. | `(1 - (Shipping Submitted / Address Submitted)) × 100` |
Funnel display is customizable in Analytics v2. Sessions stays as the baseline, and you can choose up to five additional steps in the funnel card. See [Custom funnel steps](/analytics/overview#custom-funnel-steps).
# Analytics Overview: Understanding Your A/B Test Results
Source: https://docs.abconvert.io/analytics/overview
Learn how ABConvert tracks your store's conversion funnel and how to use the analytics dashboard to interpret experiment results.
The analytics dashboard is where you see whether your experiments are working. Every time a visitor loads a page, adds something to their cart, reaches checkout, or completes checkout, ABConvert records that event and attributes it to the correct test group. You can review these results at any time as snapshots refresh throughout the day.
## Accessing your analytics
To view analytics for an experiment, go to the experiment table on your ABConvert homepage and open the analytics page for that experiment. From there you can see a breakdown of results for each test group, filter the data by date range or visitor segment, and track statistical confidence over time.
![ABConvert experiment table showing test rows and where to open analytics for a specific experiment]()
![Analytics v2 overview page showing date filter, comparison selector, performance summary, and chart area]()
To turn this dashboard into a decision, see [How to interpret Analytics results](/analytics/interpret-results).
## What does the conversion funnel track?
ABConvert tracks the purchase journey for every experiment. By default, most experiments show a standard 4-step funnel:
A distinct session in your experiment. Sessions is always the top of the funnel and serves as the 100% baseline for all conversion rate calculations.
The visitor adds the product to their cart. This is the first indicator of purchase intent.
The visitor reaches the checkout page. This shows they moved past browsing and are actively considering buying.
The visitor completes a purchase. This is the final conversion event and triggers all revenue metrics.
Every stage is tracked per test group, so you can compare how each variant performs at each point in the funnel — not just at the order level.
### Custom funnel steps
In Analytics v2, you can customize the funnel stages to track more granular events like *Shipping Information Submitted* or *Payment Submitted*. This lets you identify exactly where visitors drop off in your specific flow.
With custom funnel steps, Sessions remains fixed as the baseline, and you can select up to **5 additional stages** from the available tracked events to display in the Conversion Funnel card.
To configure your funnel:
1. Navigate to the **Conversion Funnel** card on your analytics dashboard.
2. Click the **Customize** icon in the top right of the card.
3. Select up to **5 custom steps** from the available event types in addition to Sessions.
4. Click **Apply Changes**.
![Customize funnel dialog showing selected stages for Added to Cart, Reached Checkout, and Completed Checkout, along with controls to reorder stages, add another stage, reset to default, or apply changes]()
**Session-based configuration:** Funnel customization is currently session-based. Your changes only affect your current browser view and reset to the default on page refresh. Other team members see the default funnel unless they customize it themselves.
## Which revenue and discount metrics can I review?
Analytics also includes revenue and discount metrics so you can evaluate business impact alongside conversion results.
* **Revenue and profit metrics** show order value, revenue per visitor, and profit per visitor. See [Revenue and profit metrics](/analytics/metrics-revenue-profit).
* **Discount metrics** show how much discount cost contributes to each variant's result. See [Discount metrics](/analytics/metrics-discount).
## What can I see in the breakdown table?
The **Breakdown** table lets you review the metrics you care about across test groups and dimensions. Use **Metrics** to choose which values to compare, such as visitors, conversion rate, orders, or average order value. Then select a dimension to see how variant performance changes across an audience or traffic segment.
### How do I add dimensions to the breakdown table?
Select **Country**, **Device Type**, **Visitor Type**, or **Traffic Source** to group the table results by one preset dimension.
![Breakdown table with tabs for All, Country, Device Type, Visitor Type, Traffic Source, and Custom above variant results]()
To combine two dimensions in the same table:
Click **Custom** in the **Breakdown** table.
Select the first level used to group results, such as **Landing Page**.
Optionally select a nested level, such as **Visitor Type**, to compare segments within each primary group.
Click **Apply** to update the table. Use the swap button to reverse the primary and secondary order when needed.
![Custom Breakdown controls with Landing Page as the primary dimension and Visitor Type as the secondary dimension above nested variant results]()
## Filtering your results
You can narrow your data to focus on specific audiences or time windows. The following filters are available on the experiment analytics page:
Set a start and end date to focus on a specific period. Useful for isolating the impact of a promotion or seasonal change.
Filter by one or more countries to see how a variant performs in specific markets.
Choose between **Desktop**, **Mobile**, or **All** to compare behavior across device types.
Filter by **New visitors** (visitors whose first recorded visit happened after the experiment started) or **Returning visitors** (visitors who had already visited before the experiment started) to understand how each segment responds to your test.
Visitor type is not determined by Shopify's session cookie. ABConvert determines visitor type using each visitor's first-seen timestamp and the experiment start time:
If the first-seen timestamp is after the experiment start time, the visitor is counted as new.
If the first-seen timestamp is before the experiment start time, the visitor is counted as returning.
To segment this data correctly, enable the visitor label script in your theme settings before the experiment starts and keep it enabled. Visitors tracked only after the script is enabled may otherwise be treated as new by default.
## How quickly does analytics update?
Analytics data is typically refreshed within about 1 hour.
If you want to confirm whether new data is available, click the **Refresh** button in the analytics page.
![Analytics page toolbar with the Refresh button next to the date range filter and last updated timestamp]()
# Product Groups: Analyze Test Results by Product
Source: https://docs.abconvert.io/analytics/product-groups
Bring a product-level view to your test: filter the Analytics dashboard to a set of products and see how each one responded.
A product group is a named, reusable set of products you can apply as a filter on a test's Analytics dashboard.
A test verdict tells you which variant won overall. A product group lets you read the same test through your products: how your hero collection responded, which products drove the lift, whether the win was broad or concentrated in a few items. Build a group from a Shopify collection, a tag, a product type, or a hand-picked list, then reuse it on any test in your store.
## When to use it
* **Storewide tests.** See whether a [theme](/experiments/theme-test) or [template](/experiments/template-test) test helped your hero collection, not just the whole store.
* **Price tests across many products.** Filter to the tested products, then open the per-product breakdown to see which products drove the lift.
* **A recurring focus set.** Build a "Best sellers" group once and apply it to every test.
## How it works
The test still splits visitors randomly between control and variants. A product group only filters which sessions and which products in each order count toward the dashboard numbers.
1. Apply a group on a test's Analytics dashboard.
2. A session counts when the visitor viewed a group product; each step (product view, add to cart, checkout, purchase) counts when it involved a group product.
3. Revenue and profit count only the group's products in each order, never the whole order.
4. Collection, tag, and product type groups stay in sync as your catalog changes in Shopify.
5. A **Product** tab appears in the breakdown table with per-product rows.
The test splits visitors randomly, not products, and visitors choose what they view, so per-product results are noisier than the test-level verdict. Read them as signals of where the lift came from.
## Setup
Price tests come with a built-in group of the tested products, marked **In this test** in the Filters modal. No setup needed.
### Create a group
1. In ABConvert, open [**Settings**](/configuration/settings) and find the **Product Groups** card.
2. Click **Manage Product Groups**, then **Create group**.
3. Pick a source: **Specific products**, **Collection**, **Tag**, or **Product type**. The last three update automatically with your catalog; Specific products is a fixed list.
4. Name the group and save it.
![Product groups page listing groups with their source badge and product count]()
![Create group form with the Collection source selected and a product preview below]()
You can also create a group without leaving the dashboard: the Filters modal has an **Add group** button.
### Apply it on the Analytics dashboard
1. Open the test's Analytics dashboard and click the **Filters** icon.
2. Under **Product group**, pick a group. **All products** means no filter; a price test also shows its built-in group marked **In this test** here.
3. Click **Apply**. A **Filtered to:** pill shows the active group, and the selection is saved per test.
![Filters modal showing the Product group picker with All products, an In this test group, and a collection group]()
![Analytics dashboard header with the Filtered to pill naming the active product group]()
### Break results down per product
While a group is applied, a **Product** tab appears in the breakdown table next to Country and Device Type. Each row is one product in the group, so you can compare control and variants product by product.
![Breakdown table with the Product tab selected, showing one row per product in the group]()
*Try it: open any running test's Analytics dashboard, click the **Filters** icon, and apply a group. The **Filtered to:** pill and the **Product** tab appear immediately.*
## Common mistakes
* **Expecting a group to change who sees the test.** It never does. Groups are an analytics filter; targeting and product selection live in the test setup.
* **Comparing filtered revenue with the test total.** Only group products in qualifying sessions count, so filtered numbers won't add up to the total. Compare filtered numbers with each other.
* **Looking for the Product tab without a group applied.** The per-product breakdown only appears while a group is applied.
* **Hesitating to edit or delete a group.** Your test data isn't affected. If you delete a group a dashboard is filtered to, open **Filters** on that test and pick another group or **All products**.
## FAQ
No. Randomization, targeting, and traffic split are untouched. A group only filters which sessions and order line items count toward the dashboard numbers.
Price tests (and offer tests that target specific products) automatically get a built-in group of exactly the tested products. It only appears in that test's Filters modal and isn't listed on the Product Groups page.
Groups built from a collection, tag, or product type stay in sync automatically. There's nothing to rebuild.
Only sessions that viewed a group product count, and revenue is counted per product: an order with one group product and three others contributes only that one line's revenue.
Yes. Groups are store-level: define one in Settings and apply it on any test's Analytics dashboard.
Per-product comparisons aren't randomized the way the test itself is, because visitors choose which products they view. Expect more noise than the test-level verdict and weigh them accordingly. See [Statistical Significance](/analytics/statistical-significance).
# Statistical Significance in A/B Testing Explained
Source: https://docs.abconvert.io/analytics/statistical-significance
Learn how to read statistical significance in Analytics v2, including p-values, confidence intervals, and Bayesian win probabilities.
This page helps you answer one practical question: "How strong is the evidence for this result?"
Before you read the statistics, choose the metric that best matches the Test goal. See [How to interpret Analytics results](/analytics/interpret-results) for the full decision workflow.
Analytics v2 gives you two statistical views of the same Test:
* **Frequentist analysis** for clear pass/fail decision support.
* **Bayesian analysis** for early directional guidance when traffic is still low.
Use both together when you review the selected metric.
## Key facts
* A p-value shows the strength of evidence that the observed difference is unlikely to be random noise.
* A confidence interval shows uncertainty around the estimated impact.
* Prob. Beat Control and Prob. Be Best estimate how likely a variant is to beat control or be best for the selected metric.
* More visitors, conversions or orders, and run time make results more stable.
## Frequentist analysis: clear decision support
Frequentist analysis is useful when you need structured evidence for go or no-go decisions.
In Analytics v2, this view is represented mainly by **p-value** and **confidence interval**.
### How to read p-value
A p-value describes how surprising the observed result would be if there were no real difference between variants.
Lower p-values are stronger evidence that the observed difference is unlikely to be random noise under the test assumptions.
| P-value | What it means |
| ----------- | -------------------------------------------------------------------------------------------- |
| > 0.10 | Weak evidence. Usually too early or no clear difference. |
| 0.05 - 0.10 | Borderline. Keep running the Test. |
| \< 0.05 | Statistically significant. Strong evidence against no difference under the test assumptions. |
| \< 0.01 | Very strong evidence. |
A p-value below 0.05 does not mean there is a 95% chance your variant is
better. It means the observed gap is unlikely to be random noise.
### How to read confidence intervals
Confidence intervals show a likely range for the true impact, based on the data and method.
A narrow range means a more stable estimate. A wide range means more uncertainty. A range that includes both good and bad outcomes means the result is still mixed.
For example, if Revenue per Visitor is 2.40 and the interval is \[1.10, 3.70], the true value could reasonably fall anywhere in that range.
![Statistical significance table comparing Control and Variant A with uplift percentages and value ranges for each group]()
## Bayesian analysis: early directional guidance
Bayesian analysis is useful when you do not have enough traffic for a strong frequentist result yet.
It helps you understand which variant is leading right now and how stable that lead looks.
* **Prob. Beat Control**: the model-estimated chance that a variant is better than control for the selected metric.
* **Prob. Be Best**: the model-estimated chance that a variant is best among all variants in the Test.
These probabilities can change as more data arrives. Read them for the selected metric and model shown in the dashboard.
![Performance overview chart on the Win chance tab showing Variant A probability trend for Conversion Rate over several dates]()
Do not decide based on one snapshot. Look for a consistent pattern across
multiple refreshes.
## How to use frequentist and Bayesian results together
ABConvert shows both statistical systems. Read them in this order:
Check **Prob. Beat Control** and **Prob. Be Best**. If they are unstable or
keep flipping, keep running the Test.
Before final rollout, verify that p-value is below 0.05 and confidence
intervals are not too wide.
Make sure uplift is meaningful for your store, not just statistically
detectable.
Launch the winning variant when Bayesian trend and frequentist evidence both
support the same direction.
Run your Test for at least one full business cycle before making a final
decision. For most stores, that means around 1-2 weeks so weekday and weekend
behavior are both included. You still need enough visitors, conversions or
orders, and balanced traffic.
## What to do when results are inconclusive
Sometimes the result is still unclear after several days. That is normal.
If the statistical result is still mixed, do this:
* Keep the current winner (usually control) while you collect more data.
* Extend the run window and review again after more traffic arrives.
* Check segments such as country, device type, or visitor type to find hidden differences.
* If signals stay flat, treat it as "no meaningful difference" and test a bigger idea next.
Inconclusive results are still useful. They tell you your current variant is not strong enough to justify a rollout yet.
# Changelog
Source: https://docs.abconvert.io/changelog/overview
Recent updates, improvements, and fixes shipped to ABConvert.
Stay up to date with what's new in ABConvert. Entries are grouped by week, with new features first, followed by improvements and bug fixes.
## Updates
* **Affiliate portal tier and status guides.** The affiliate portal now surfaces guides that explain each tier and referral status inline, so partners can see what earns each commission rate and what each status means without leaving the page.
* **Affiliate commission rate overrides prioritized.** Custom per-affiliate commission rates now take precedence over the default rule-based rate, so negotiated overrides are honored on every commission calculation.
* **Faster shipping test setup.** Wizard delivery-profile lookups now roll up into a single backend call, carrier service zone setup batches to one call per delivery profile, and zone loading is parallelized and scoped per location group — shipping test creation is noticeably faster on stores with complex delivery rules. See [Shipping test](/experiments/shipping-test).
* **More reliable assignment tracking.** Assignment and exposure events on the storefront are now sent via `sendBeacon`, so exposure data holds up even when a shopper closes the tab immediately after landing. See [Metrics](/analytics/metrics).
* **Google Ads ROI pipeline live.** The Google Ads ROI cronjob is now activated in production with a 30-day backfill, so paid-ads ROI numbers reflect real Google Ads spend and attribution end to end. See [GA4 integration](/configuration/ga4-integration).
## Bug fixes
* **Storefront script no longer crashes on delayed dict.** The v2 storefront script now waits for a delayed shop dictionary to arrive instead of throwing, eliminating a class of visitor-facing script errors on slow initial loads.
* **Tutorial tab back button restored.** Clicking Back from the create-test screen now returns you to the Tutorial tab you launched from, instead of dropping you on the experiments list. See [Onboarding](/onboarding).
* **Shipping test config fits Shopify's Function limit.** Shipping test delivery-customization configs are now kept under Shopify's 10 KB Function payload cap, so large shipping tests no longer fail to save or deploy. See [Shipping test](/experiments/shipping-test).
* **Analytics demo tour fixed.** The Analytics V2 demo walkthrough no longer stalls on missing steps, and the Back button now works throughout the tour. See [Analytics overview](/analytics/overview).
* **Duplicate churn claims prevented.** Fixed a case where a single Shopify subscription churn could be recorded more than once, so lifecycle events and billing state now match one-to-one.
* **Recovered churn events in subscription writer.** Subscription churn events that were previously being suppressed are now written through, so subscription analytics reflect actual cancellations. See [Pricing plans](/configuration/pricing-plans).
* **Shipping and offer mapper regressions fixed.** Zone rates and widget variables are now lifted correctly when hydrating shipping and offer tests from storage, so drafts and edits load with the values you saved. See [Shipping test](/experiments/shipping-test) and [Offer test](/experiments/offer-test).
## New features
* **Autopilot (beta).** A new Autopilot experience ships as a ranked inbox of deterministic recommendations — shipping, price, and offer opportunities scored, filtered, and promoted directly into real draft experiments. Includes conflict guards (same-type active or recently-run tests suppress cards), a price margin floor, per-shop kill switch, and a beta UX pass. See [Experiments overview](/experiments/overview).
* **Claude custom connector via OAuth.** The MCP server now runs an OAuth 2.1 (Authorization Code + PKCE) authorization server, so you can connect ABConvert as a Claude custom connector from Claude.ai web, desktop, and mobile. Generate a Client ID and Secret in Settings and paste them into Claude's "Add custom connector" dialog. See [Claude connector](/mcp/claude-connector) and [MCP overview](/mcp/overview).
* **Combined test preview widget.** Combined tests now render as a single entry in the storefront preview widget with a group switcher; each stacked modification appears as a collapsible section using its own type-specific preview panel. See [Experiments overview](/experiments/overview).
* **Per-group review for combined tests.** The combined-test wizard's Review step is now organized as per-group cards that show exactly which modifications each group of visitors sees and with what value (price deltas per market, shipping rate + threshold, redirect target, template/theme name, offer title, visual editor change counts, checkout blocks).
* **Combined-test analytics settings and restricted active edit.** Combined tests get a dedicated Analytics Test Settings tab rendered as per-group cards, and editing a running combined test now opens a restricted edit page — name, hypothesis, and traffic split are editable while modifications stay read-only, matching every other v5 test type.
* **Add-to-cart and Reached Checkout in Analytics V2.** The Analytics V2 Performance overview dropdown and Statistical significance table now support Add-to-cart Rate and Reached Checkout Rate as selectable comparison metrics, with daily time series and full frequentist/Bayesian rollups. See [Metrics](/analytics/metrics) and [Interpret results](/analytics/interpret-results).
* **Merchant-controlled notification email.** A new Notification email setting on the Help tab is now the single destination for ABConvert product, lifecycle, and support notifications, replacing the behavior where the address could be silently overwritten by the Shopify store email on sync. See [Settings](/configuration/settings).
* **Affiliate portal Terms of Service acceptance.** New and migrated affiliates must now explicitly accept the ABConvert Terms of Service during signup or activation (clickwrap consent), with acceptance metadata recorded on the affiliate record.
* **Affiliate payout approval workflow.** Adds an internal payout approval flow and richer payout details (stable payout ID, commission IDs, per-commission summaries) so the internal dashboard can review and approve payouts without inferring membership.
* **Redesigned onboarding flow.** The onboarding survey has been rebuilt against the approved Built for Shopify redesign: each question now states why it's asked, the recommendation is folded in as step 5 of 5, backgrounds are admin-aligned, and errors surface only after blur or submit. Accessibility and contrast fixes ship in a follow-up (labeled radio groups, alert-role errors, focus moves to the first invalid control). See [Onboarding](/onboarding).
* **Homepage theme app embed status.** The homepage now shows a compact status row for your theme app embed connection in both enabled and disabled states, so the embed state is always visible even when no test is running.
* **First-landing tutorial banner.** After completing onboarding, new merchants get a dismissible homepage banner pointing to the tutorial tab — capped at one emission per shop and one banner per app load.
## Updates
* **Serialized experiment lifecycle.** Every experiment lifecycle mutation now runs under a per-shop distributed lock, so concurrent start, end, and delete requests can no longer interleave Shopify writes with a failed request's cleanup and leave an experiment Active with no storefront config.
* **Faster combined-test edits.** New tracing on the unified experiment endpoint measured combined-test edit latency dropping from \~10.2s to \~4.2s in production traces.
* **Faster, more reliable price test activation.** Added performance monitoring to the price test activation path so we can catch slowdowns on large catalogs and keep price test launches snappy as your store grows. No action needed on your side. See [Price test](/experiments/price-test).
* **Recovered order attribution tightened for Offer and Checkout tests.** Order-derived analytics now only count recovered orders for Offer and Checkout-family tests when the Shopify order itself carries matching attribution evidence, so recovered totals reflect the final order state rather than earlier checkout context.
* **Status badge retoning.** Red is now reserved for errors, failures, destructive actions, and hard blocks. Setup-incomplete states move to Attention, Paused and risky/advisory states move to Warning, and factual states move to neutral or subdued — including a fix so the order usage bar only turns red on a real hard cap. Draft and Paused also now render distinct tones (grey vs. orange) across every status renderer.
* **Form validation gated on blur or submit.** Validation errors no longer render on pristine fields or while you're typing on current test surfaces (order tag modal, market price, advanced conditions, target URL). Errors appear on blur or submit attempt, and clear as soon as the value becomes valid.
* **Nav highlighting on Settings and Billing sub-pages.** Settings sub-pages (COGS, Product groups, Exclusion groups) and Billing sub-pages (Extend trial, Custom plan) now live under their parent routes so the app nav highlights the correct top-level item. Old paths redirect automatically. See [Settings](/configuration/settings) and [Pricing plans](/configuration/pricing-plans).
* **Connection banners now render inside the page.** Script and theme status banners now render inside each page below the title instead of floating above it, restoring correct reading order for screen readers and matching Polaris conventions.
* **Affiliate portal preview UI revamp.** The affiliate portal preview (overview, referrals, commissions, payouts, reports) is aligned with the Partner Portal reference design. Payouts are ordered newest-first with collapsible included-commission lists and clearer partner-facing status copy.
* \*\*Affiliate minimum payout raised to $500.** The default affiliate payout threshold moves from $50 to \$500 across the backend eligibility flow, internal payout creation, and portal UI. Persisted overrides still apply.
* **Affiliate commissions use net revenue.** Affiliate commission calculation now uses net revenue instead of gross, and referrals convert to paid commissions once eligibility is met (with automatic cancellation for uninstalled referrals).
* **Announcement editor upgrades.** Announcements now support a Retire operation (immediately stops rendering, reversible on re-publish), a Retired status, 16:9 media on grid cards and hero images, publish-time ordering (newest first, drafts last), multi-segment audiences with an append-only fanout log, and an optional version label in the grid modal footer.
* **Homepage announcement banner without layout shift.** The announcement banner decision now piggybacks on the shop-settings payload the home page already loads, eliminating the second async hop that caused a visible layout shift on load.
* **Pricing plan and FAQ docs refresh.** The [Pricing plans](/configuration/pricing-plans) page has been updated with revised monthly fees, included experiment orders, overage rates, new test types in the plan matrix (multi-market price test, checkout UI extension test), new support tiers, and clearer explanations of order limits and overage.
## Bug fixes
* **Embedded app "refused to connect" on back button.** Fixed a case where clicking the browser back button inside the Shopify admin could leave the embedded app dead because the iframe reloaded without shop parameters. The admin now correctly frames the app in that state, and the catch-all route no longer returns a hard 500.
* **Welcome Back banner trap.** Fixed a churned-resubscribe case where shops with a stale Shopify subscription ID could be pinned on the "You're on the new ABConvert" migration banner with no way to reach plan selection. Eligibility is now derived from an active Shopify subscription rather than a stored field. See [Pricing plans](/configuration/pricing-plans).
* **Visual Editor market language and geo redirects.** Fixed a Shopify Markets issue where the storefront proxy returned English-US pages for stores that geo-redirect from US IPs. The proxy now forces the resolved market via the country query param (re-applied on every redirect hop), so previews render in the URL's market language. See [Visual editor test](/experiments/visual-editor-test).
* **Notification banner cap.** Dismissing an announcement banner no longer chains straight into the next unseen banner in the same app load — the queued row keeps its turn on the next load.
* **Affiliate portal payout profile save.** Saving PayPal payout email or details on the affiliate portal no longer fails when the affiliate has a legacy negative outstanding commission value. Payout profile updates now scope to the payout fields only.
* **Storefront error reporting scoped.** Uncaught storefront errors are no longer reported to browser error tracking unless they come from ABConvert scripts, so unrelated third-party errors stop crowding out signal.
* **Uninstall webhook deduplicated.** Fixed a case where the Shopify uninstall event could trigger multiple times for a single uninstall.
* **Reporting reliability.** BigQuery transfer lookups now fail closed on errors, experiment performance rollups tolerate wide float metrics, the BigQuery monitor freshness query is fixed, and paid-ads attribution sync now fails cleanly when the GA4 daily export table is missing. See [GA4 integration](/configuration/ga4-integration).
## New features
* **Combined test creation flow.** The combined-test experiment type now has an end-to-end creation flow, so you can stack multiple modifications into a single test from a guided wizard. See [Experiments overview](/experiments/overview).
* **Affiliate partner dashboard.** Partners in the affiliate program can now sign in to a dedicated dashboard to view attributed shops, referrals, commissions, and payouts, backed by scoped partner report APIs.
* **In-app feature announcements.** A new announcement surface delivers targeted product updates inside the app, with audiences resolvable from Customer.io segments so the right cohort sees the right message.
* **Launch and revert previewed experiments via MCP.** Ask Claire and other MCP clients can now activate a previewed experiment and revert it back to draft through the MCP server, closing out the preview-to-launch loop end to end. See [MCP tools](/mcp/tools).
## Updates
* **Faster analytics dashboards.** Analytics V2 now computes overall and date-range metrics eagerly and defers demographic breakdowns to on-demand loading, so the main dashboard renders faster and breakdowns still resolve when you open them. See [Analytics overview](/analytics/overview).
* **Product-scoped cart abandonment.** Analytics V2 now shows a dedicated cart-abandonment metric under product scope and hides checkout and shipping abandonment where they don't apply, so product-scoped funnels reflect what actually happened. See [Metrics](/analytics/metrics).
* **Historical results readable from V1 snapshots.** Experiment results now read from V1 analytics snapshots, so older experiments render consistent numbers alongside newer runs on the results page. See [Interpret results](/analytics/interpret-results).
* **GA4 attribution for paid-ads installs.** A new GA4 attribution pipeline captures install source for paid-ads campaigns, feeding cleaner acquisition data into reporting. See [GA4 integration](/configuration/ga4-integration).
* **Affiliate outstanding vs. payable separated.** Affiliate ledgers now distinguish outstanding commissions from balances that are actually payable, so partners and finance see clearer figures on each side of the payout cycle.
* **Historical affiliate data imported from Mantle.** Prior affiliate commissions and payouts have been backfilled from Mantle so partner reports reflect full history from day one.
## Bug fixes
* **Announcements wait for onboarding.** Announcements no longer surface until a shop has completed plan selection and the onboarding survey, so new stores aren't interrupted mid-setup.
* **Billing sync ignores 401s.** The billing sync job now skips Shopify 401 Unauthorized responses per shop, matching how 402 and 403 are already handled, so a single unauthorized store no longer noises up the run. See [Pricing plans](/configuration/pricing-plans).
* **Cleaner engagement counts during redirect tests.** Engagement events are now suppressed on forced redirect trigger pages, so redirect-test destinations get accurate engagement numbers without duplicated hops. See [Engagement metrics](/analytics/engagement-metrics) and [URL redirect test](/experiments/url-redirect-test).
* **Storefront script crash fixes.** Added null guards, a stale-percentage fallback, and safer fetch response handling in the browser script to eliminate several ABConvert V1 crash reports on live storefronts.
* **Affiliate portal now ships in the app image.** The affiliate portal is now built into the deployed app image so the partner dashboard loads reliably in production.
## New features
* **Combined tests (early access).** A new combined-test experiment type lets you stack multiple modifications — price, offer, checkout, and more — in a single test, with a wizard that walks you through each modification in an accordion step and shared analytics across the bundle. See [Experiments overview](/experiments/overview).
* **Affiliate program MVP.** The affiliate portal now resolves `mref` attribution from GA4, tracks referral installs in a partner ledger, and calculates commissions per rule so partners can see attributed shops and earnings. Identity tokens and the referral ledger schema are also live.
* **MCP tools for offer and checkout tests.** Ask Claire and other MCP clients can now create, edit, and inspect offer tests and checkout tests through the MCP server. See [MCP tools](/mcp/tools).
* **MCP reliability and security hardening.** The MCP server picks up phase 1 of its maturity work: improved error handling and retries, structured logging and metrics for every tool call, and tightened auth and input validation. See [MCP overview](/mcp/overview) and [MCP security](/mcp/security).
* **Redesigned checkout placement card.** The checkout test editor's placement card has been redesigned for clearer hierarchy, and resting placement pins now pulse to cue that they're hoverable. See [Checkout test](/experiments/checkout-test).
* **Experiment ID in the action menu.** The public experiment ID has moved into the experiment row's action menu as a Copy ID action, so it's available when you need it without crowding the table. See [Experiments overview](/experiments/overview).
## Updates
* **V3 access state synced to growth tools.** When a shop gains V3 access, that state is now pushed to Intercom, Customer.io, and PostHog so lifecycle messaging and analytics reflect the right cohort immediately. See [Pricing plans](/configuration/pricing-plans).
* **Engagement scope persisted with match-type awareness.** Engagement page scope now persists per experiment and respects match-type rules (exact, prefix, contains) when resolving which pages count, so breakdowns stay consistent across sessions. See [Engagement metrics](/analytics/engagement-metrics).
* **Analytics V2 demo at full feature parity.** The Analytics V2 demo walkthrough now mirrors the live dashboard, including engagement metrics, product-group scoping, and the updated filters panel. See [Analytics overview](/analytics/overview).
* **Customer.io charge rejection event.** A Customer.io event now fires when a Shopify charge is rejected, so dunning and recovery messages can be wired up to the right trigger.
* **Cleaner theme test connect step.** The redundant connect-themes banner has been removed from the theme test variants step, since each variant card already shows its own connection badge and action. See [Theme test](/experiments/theme-test).
* **Checkout placement limits are clearer.** Checkout placement options that already hold three blocks are now disabled in the picker instead of overflowing into the next slot. See [Checkout test](/experiments/checkout-test).
* **Single-product upsell layout choice respected.** Single-product upsell tiles now follow the vertical or horizontal layout you pick in the editor, with aligned quantity and add-button controls. See [Checkout test](/experiments/checkout-test).
* **Trimmed checkout block configuration.** Benefit and trust-badge blocks no longer show unused divider controls, image link URLs render as clickable anchors, and duplicate max-image copy has been removed. See [Checkout test](/experiments/checkout-test).
## Bug fixes
* **Open theme editor unblocked during theme connect.** Clicking Open theme editor during the theme test connect flow now works as expected instead of being suppressed by the connect modal. See [Theme test](/experiments/theme-test).
* **V5 price test percentages from metadata.** V5 price tests now resolve variant percentages from the experiment metadata, fixing cases where the displayed percentages didn't match the configured test. See [Price test](/experiments/price-test).
* **Single-string URL redirect cart attribute.** URL redirect tests now handle the cart attribute when Shopify returns it as a single string rather than an array, so attribution holds for those redirects. See [URL redirect test](/experiments/url-redirect-test).
* **Engagement breakdown freshness.** Engagement breakdown rows now honor the 1-hour freshness window used by the rest of the dashboard, so cached and live numbers line up. See [Engagement metrics](/analytics/engagement-metrics).
* **Create-test badge and experiment table header stabilized.** The Create test badge and the experiment table header no longer shift or flicker on load. See [Experiments overview](/experiments/overview).
* **Migration modal gated on V3 access.** Step 1 of the legacy V2 → V3 migration modal now gates on real V3 access state instead of the migration timestamp, so the checklist reflects what's actually enabled. See [Pricing plans](/configuration/pricing-plans).
* **Shared theme test snippets preserved.** Closing one theme test no longer strips snippets that another active theme test still depends on. See [Theme test](/experiments/theme-test).
* **Save to preview stays clickable on error.** The checkout test editor's Save to preview button no longer locks up after a save error, and its banner text size now matches the rest of the editor. See [Checkout test](/experiments/checkout-test).
* **Non-placeable Inside delivery slot removed.** The checkout placement picker no longer lists the "Inside delivery" slot, which couldn't actually host a modification. See [Checkout test](/experiments/checkout-test).
* **Mobile-only placement note in checkout editor.** Placements that only render on mobile now surface a note in the editor so you don't expect them on desktop preview. See [Checkout test](/experiments/checkout-test).
* **Checkout editor scrolling restored.** Long checkout test configurations now scroll inside the editor again. See [Checkout test](/experiments/checkout-test).
* **Checkout preview parity for buttons and icons.** Buttons and icons in the checkout test preview now render with the same sizing and spacing as live checkout. See [Checkout test](/experiments/checkout-test).
* **Control group pricing initialization.** Price tests now initialize the control group with complete variant pricing data, fixing draft saves where some variants were missing prices. See [Price test](/experiments/price-test).
* **Visual editor proxy geo redirects.** The visual editor proxy now follows Shopify geo redirects correctly, so previews in markets that geo-redirect resolve to the right storefront. See [Visual editor test](/experiments/visual-editor-test).
* **Reliable staying-time delivery.** Time-on-page is now sent via an unload-safe beacon, so engagement numbers capture the last page view even when shoppers close the tab quickly. See [Engagement metrics](/analytics/engagement-metrics).
* **Quieter storefront error reporting.** Storefront error reporting now scopes capture to ABConvert scripts and disables session tracking, so unrelated third-party errors no longer crowd out signal.
* **Cross-origin iframe queue error fixed.** A cross-origin SecurityError in the embedded admin iframe queue has been resolved, so iframe-backed views load reliably.
* **Shopify API request resilience.** Verify-request, screenshot capture, and BigQuery sync now retry transient Shopify and pipeline errors instead of failing the job, reducing background error noise.
* **GA4 retry noise suppressed for unconfigured shops.** GA4 impression retries no longer exhaust and log errors for shops that haven't configured GA4. See [GA4 integration](/configuration/ga4-integration).
* **Affiliate sync supports deployed Mongo env.** Affiliate sync now reads connection settings from the deployed Mongo environment, so production syncs run reliably.
* **Revenue snapshot rejection non-fatal.** A Customer.io rejection during the revenue snapshot job is now treated as a warning instead of failing the run.
* **Visual editor preview saves recover after errors.** A failed Save to preview now leaves the visual editor button enabled and shows an error toast so you can retry. See [Visual editor test](/experiments/visual-editor-test).
* **Contextual save bar stays hidden during preview saves.** The Shopify contextual save bar no longer briefly appears when you click Save to preview in the visual editor. See [Visual editor test](/experiments/visual-editor-test).
## New features
* **Engagement metrics in V2 Analytics.** The V2 analytics dashboard has a new Engagement section with click-through rate, bounce rate, and average time on page, plus a breakdown table that slices by page or template. Engagement isn't shown for checkout, shipping, or payment tests. See [Analytics overview](/analytics/overview).
* **Page-scope control for analytics.** Each test type now seeds a sensible default page scope at launch (URL redirect destinations, template names, visual editor target pages, price test product handles), and you can override the scope per experiment from the analytics dashboard. See [Analytics overview](/analytics/overview).
* **Checkout test edit page.** Checkout tests now have a dedicated edit page reachable from the Edit row action, so you can update a live checkout test without going through the draft path. See [Checkout test](/experiments/checkout-test).
* **Checkout test settings tab in analytics.** The analytics dashboard for checkout tests now has a read-only Test settings card that groups each variant's modifications by app block (Checkout functions, ABConvert checkout block, Cart control block) with a collapsible row per modification. See [Checkout test](/experiments/checkout-test).
* **Checkout test tutorial flow.** New stores get a guided checkout test walkthrough that takes you through the editor, placement, and analytics dashboard using mock data, so you can learn the flow before launching a real test. See [Checkout test](/experiments/checkout-test).
* **Win-back offer for churned legacy shops.** Churned shops that previously held a legacy V2 plan can come back on their old plan name at their old price, with full V3 feature access and no V3 overage. The offer surfaces on the welcome-back page after the grace period ends, and as a Reactivate banner on the homepage while a cancelled plan is still inside its paid grace period. See [Pricing plans](/configuration/pricing-plans).
* **Legacy V3 access for grandfathered shops.** Active legacy-plan shops can now opt in to V3 features without changing their subscription. A confirmation modal walks you through enabling the app embed, polls embed status in the background, runs the test migration, and lands you on a success state. See [Pricing plans](/configuration/pricing-plans).
* **Redesigned pricing page.** The in-app pricing page has been rebuilt to match the new design: a store-orders slider and testing-intensity picker drive a per-plan cost estimate, the recommended plan is highlighted, and an explainer plus FAQ walk you through how billing works. No price or tier changes. See [Pricing plans](/configuration/pricing-plans).
* **Experiment ID in admin UI.** Experiments now display their public ID in the admin UI so support can identify a specific test at a glance.
## Updates
* **Consolidated legacy V2 → V3 migration modal.** The standalone migration page and separate confirm step have been replaced by a single reopenable modal that walks both the migration and theme reconnect steps on one screen, with inline actions and in-modal app-embed polling. See [Pricing plans](/configuration/pricing-plans).
* **Polished migration flow on mobile.** The legacy billing entry, migration checklist, and variant-theme reconnect now stack cleanly on mobile, and the global variant-theme banner is suppressed on the migration page so it no longer stacks on the checklist. See [Pricing plans](/configuration/pricing-plans).
* **Measure by moved into Filters.** The analytics dashboard's Measure by control now lives inside the Filters panel alongside Product group and Outlier filter, all collapsible with one-line summaries when closed. A "Filtered to" pill surfaces a non-default basis. See [Analytics overview](/analytics/overview).
* **Clearer product-group filter copy.** The product-group filter in V2 analytics has clearer event-grain wording and links directly to the product groups documentation. See [Product groups](/analytics/product-groups).
* **Cleaner pricing CTA hierarchy.** Only the recommended plan's CTA uses the primary button style, so the recommended choice stands out from the other plan cards. See [Pricing plans](/configuration/pricing-plans).
* **Updated pricing slider copy.** The pricing slider and overage copy have been refined to talk about experiment order count, matching the underlying billing model. See [Pricing plans](/configuration/pricing-plans).
* **Frontend uses experiment order count for usage.** The usage cap and overage display on the billing page now read from the cleaned-up experiment order count contract, so the numbers you see match what's billed. See [Pricing plans](/configuration/pricing-plans).
* **Legacy price test method settings removed.** Old, unused price test method settings have been removed from the price test configuration to simplify the form. See [Price test](/experiments/price-test).
* **Polaris Badge for original-price tag.** The original-price tag on price test cards now uses Shopify Polaris Badge styling for visual consistency, and the plans CTA copy has been relabeled.
## Bug fixes
* **Exposure events with multiple experiment IDs.** Exposure and funnel events that carry an `experimentIds` array now resolve the correct shop, instead of being rejected with a missing-shop error and silently dropped. See [Analytics overview](/analytics/overview).
* **V5 analytics group name mismatch.** Fixed a V5 analytics issue where group-name mismatches and missing variants caused rows to disappear from the dashboard. See [Analytics overview](/analytics/overview).
* **Price test draft preserves empty original price.** Saving a price test draft with no test price set no longer falls back to the original variant price, so empty fields stay empty in the draft. See [Price test](/experiments/price-test).
* **Cart Transform instruction limit for multi-market stores.** Compressed the per-variant price metafield payload so stores selling into many markets no longer trip the Cart Transform instruction limit. See [Price test](/experiments/price-test).
* **Visual editor proxy locale.** The visual editor proxy now resolves locale from the URL instead of cached state, so localized previews match the locale you're viewing. See [Visual editor test](/experiments/visual-editor-test).
* **Index page no longer jumps to top.** Fixed an unexpected scroll-to-top on the index page that interrupted navigation.
* **Win-back V3 access tied to active subscription.** Legacy V3 access from the win-back flow is now granted only after the subscription webhook reports ACTIVE, so opening or declining the confirmation page no longer grants access without payment. See [Pricing plans](/configuration/pricing-plans).
* **Win-back page renders reliably.** The welcome-back offer now renders straight from the churned-resub offer response, so churned legacy shops no longer briefly see the standard pricing grid before the offer loads. See [Pricing plans](/configuration/pricing-plans).
* **Billing sync skips churned stores.** The billing sync job now skips churned stores, eliminating noisy sync errors for shops that have already left. See [Pricing plans](/configuration/pricing-plans).
* **Customer.io install status.** Fixed the Customer.io install status flag so it correctly reflects fresh installs.
## New features
* **Multiple redirect rules per URL redirect test.** URL redirect tests now support multiple redirect rules in a single experiment, so you can route different source paths to different variants without splitting them across separate tests. See [URL redirect test](/experiments/url-redirect-test).
* **Consolidated checkout test editor.** The checkout test editor now shows one card per modification with drag-to-set placement, so you can reorder and place blocks without leaving the canvas. See [Checkout test](/experiments/checkout-test).
* **Product-group scope selector in V2 Analytics.** The V2 analytics dashboard now has a scope selector that filters metrics down to a specific product group, so you can read results for the exact set of products you care about. See [Product groups](/analytics/product-groups).
* **Product-group breakdown rows in V2 snapshots.** Scheduled V2 snapshots now include per-product-group breakdown rows alongside experiment-level numbers, so emailed digests reflect the same scoping you use on the dashboard. See [Product groups](/analytics/product-groups).
* **Auto-grouping for price and product-scoped offer tests.** New price tests and product-scoped offer tests now bootstrap their own product group automatically from the products you select, so the test, its analytics, and any follow-up experiments stay in sync without manual setup. See [Product groups](/analytics/product-groups).
* **Affiliate referrals list and commission rates.** The affiliate portal now shows a list of crawled referral installs alongside the commission rate that applies to each, so partners can see which stores were attributed and what they'll earn.
* **Clickable Ask Claire sample questions.** Sample questions in Ask Claire are now clickable shortcuts, so you can launch a question into the assistant in one tap instead of retyping it. See [FAQ](/help/faq).
## Updates
* **Refreshed affiliate portal design.** The affiliate portal has been re-skinned to match ABConvert's brand guidelines, with updated colors, typography, and component styling across every page.
* **Cleaner checkout test placement.** Checkout test placements are now grouped by merchant block in the picker, making it easier to find the right slot when a theme exposes several blocks in the same area. Block IDs also persist a per-experiment suffix so renamed or duplicated tests don't collide. See [Checkout test](/experiments/checkout-test).
* **Polished checkout preview panel.** The checkout test preview panel has clearer copy and a simplified modification configuration, removing options that didn't apply to the block you were editing. See [Checkout test](/experiments/checkout-test).
* **Outlier filter applied to product-group metrics.** The V2 outlier filter now also applies to product-group metrics, so per-group numbers use the same trimmed-order treatment as experiment-level metrics. See [Metrics](/analytics/metrics).
* **Order-count-based overage on V3 billing.** V3 billing overage is now calculated from experiment order count, so usage charges line up with the orders your experiments actually influenced. See [Pricing plans](/configuration/pricing-plans).
* **Upsell tile preview matches checkout.** Offer test upsell tiles now render in the editor with the same layout as the checkout storefront, so what you see while editing matches what shoppers see. See [Offer test](/experiments/offer-test).
* **Better support ticket follow-ups.** In-app support tickets now identify the merchant on the outbound email so replies thread correctly, and the success banner uses a clearer in-banner action instead of a small dismiss control. See [FAQ](/help/faq).
## Bug fixes
* **Billing page now shows current plan price.** Fixed a bug where the Billing page could show a stale or default plan price instead of the price you're actually paying. See [Pricing plans](/configuration/pricing-plans).
* **Stale visual editor metafield cleanup.** Closing the last active visual editor test now clears its theme metafield, so storefronts no longer carry leftover variant data after a test ends. See [Visual editor test](/experiments/visual-editor-test).
* **Connection banner no longer flashes.** The "connect your storefront" banner no longer flashes against a stale app-embed status while the live status loads, so first-run navigation feels steadier. See [Installation](/installation).
* **Cart control editor parity.** Cart control offer tests now render the same stepper behavior in the editor preview as on the storefront, and a race that could double-fire the live stepper has been fixed. See [Offer test](/experiments/offer-test).
* **Compose checkout editor reopens after discard.** Discarding changes in the checkout test compose editor now reliably reopens the editor in its prior state, instead of leaving you on a blank canvas. See [Checkout test](/experiments/checkout-test).
* **Path conditions reject empty strings.** Audience targeting path conditions now reject empty-string values at validation time, preventing rules that would silently match every URL. See [Audience targeting](/experiments/audience-targeting).
* **Frozen product scope filtering.** Analytics filters for frozen product scopes now strip the Shopify GID prefix before querying, so product-scoped breakdowns return the rows you expect. See [Metrics](/analytics/metrics).
* **Analytics start time preserved on background updates.** Experiment updates that don't trigger a sync now preserve the original start time, preventing gaps in analytics for long-running tests. See [Analytics overview](/analytics/overview).
* **Original error reported on tag retries.** When tag updates exhaust their retries, ABConvert now surfaces the original error instead of a generic retry-exhausted message, making real failures easier to debug.
## New features
* **Product groups in Settings.** A new account-level Product Groups entity lets you create, rename, edit, and delete reusable groups of products. Groups can be defined manually or sourced from a Shopify collection, tag, or product type. Use them to scope experiments and analytics to a consistent set of products across launches. See [Settings](/configuration/settings).
* **Product-grained metrics in V2 Analytics.** The V2 analytics query layer now surfaces eight product-level metrics — including product sessions, add-to-cart rate, reached-checkout rate, conversion rate, revenue per visitor, profit per visitor, AOV, and average units per order — so you can break results down by product or product group inside a single experiment. See [Metrics](/analytics/metrics).
* **Tailored retention offers in the exit flow.** When you start to cancel, the exit flow now resolves a primary best-fit retention offer plus up to two alternatives based on the cancellation reason you selected and your current plan, trial, and billing interval. Eligible offers include retention discounts, downgrades, trial extensions, or a direct support handoff. See [Pricing plans](/configuration/pricing-plans).
* **Pricing-aware retention discounts.** Cancellers on V2 pricing now see a retention offer that routes them to a discounted V3 plan, with a confirmation step and a clear warning when an active subscription discount is already in place. The applied discount takes effect immediately on migration, not at the next billing cycle. See [Pricing plans](/configuration/pricing-plans).
* **Active retention discount on the billing page.** The Billing page now shows the active retention discount alongside your current plan, and exit-flow returns deep-link back to Billing so you can confirm what was applied. See [Pricing plans](/configuration/pricing-plans).
* **Refreshed statistical significance table.** The Analytics V2 statistical significance table now includes a dedicated p-value column and cleaner confidence interval formatting, making it easier to read at a glance which variants have hit significance. See [Statistical significance](/analytics/statistical-significance).
* **GA4 impression tracking rolled out to V3.** GA4 impression tracking is now live for all V3 and V2-UI stores, so impressions flow through to your GA4 property without extra setup. See [GA4 integration](/configuration/ga4-integration).
* **In-app support requests.** The Help page now opens tickets through a guided form that routes directly to the support team, replacing the previous email-only flow. See [FAQ](/help/faq).
## Updates
* **Smarter theme-connect banner.** The "connect your theme" banner now only appears where it's actionable — on the homepage when you have an active experiment, or on an analytics dashboard when that specific test depends on a theme connection. It's also hidden until you've selected a plan, so new installs see a cleaner first run. See [Theme test](/experiments/theme-test).
* **Cancellation feedback persisted end-to-end.** Cancellation reasons and follow-up details captured in the exit flow are now persisted to the uninstall record and instrumented as a funnel, so the team can act on the feedback you leave. See [Pricing plans](/configuration/pricing-plans).
* **Exit-flow copy and confirmations polished.** Step 1 copy now matches Shopify's deferred-cancellation timing, the confirmation step calls out live-subscription discounts before you proceed, and assorted UX rough edges have been smoothed out.
## Bug fixes
* **URL redirect exposure path matching.** Fixed an edge case where URL redirect tests could mis-match the exposure path on certain storefront URL patterns, causing exposure events to be dropped. See [URL redirect test](/experiments/url-redirect-test).
* **URL redirect preview group switching.** Switching between groups while previewing a URL redirect test now clears the redirect marker, so the next page evaluates the freshly selected group instead of falling through to a plain reload. See [URL redirect test](/experiments/url-redirect-test).
* **Price test decimal display.** Removed a leftover flag that could suppress decimals in price test V2 storefront prices, ensuring prices render with the store's normal precision. See [Price test](/experiments/price-test).
* **Retention discount timing for migrations.** Fixed two related issues so that retention discounts applied during a V2→V3 migration are marked as live for the current cycle and are reflected immediately on the Billing page, rather than appearing only after the next renewal.
* **Billing sync error visibility.** Removed swallowed errors from the billing sync's network calls, so genuine failures are now surfaced instead of silently retried.
## New features
* **"Measure by" control in V2 Analytics.** URL redirect and template tests now have a Measure by toggle in the analytics toolbar that switches the denominator between visitors who actually saw the variant (exposure) and everyone assigned. Exposure is the new default for these test types, giving you a more accurate read on impact. See [Analytics overview](/analytics/overview).
* **Exposure-based snapshots by default.** Scheduled analytics snapshots for exposure-enabled tests now compute on the exposure basis automatically, so dashboards and emailed digests line up with the new Measure by default.
* **Cancellation value reminder.** When you start to cancel your plan from Billing or Settings, ABConvert now shows a value reminder modal with one-click shortcuts to test types you haven't tried yet, so it's easier to spin up a new experiment instead of churning. See [Pricing plans](/configuration/pricing-plans).
* **Cancellation reason collection.** If you proceed past the value reminder, a follow-up step asks why you're cancelling with a multi-select list and an optional details field. Feedback is stored alongside the uninstall record so support can follow up.
## Updates
* **More resilient exposure tracking.** Template, theme, and URL redirect tests now replay exposure events on each in-session page load, recovering data that would previously be lost if the initial landing-page request was dropped. No setup required.
* **Integer-only traffic splits in the unified flow.** Traffic allocation across experiment groups is now enforced as whole-number percentages on both new launches and v5 edits, eliminating rounding drift that could push group totals over 100%.
* **Uninstall feedback in customer.io.** When a store uninstalls ABConvert, the captured reason and free-text details are now forwarded to customer.io and persisted, so retention workflows can use real reasons instead of a single generic event.
## New features
* **Custom events dashboard.** A new Custom Events management page lets you view, enable, disable, and create scroll-based custom events with a 3-step wizard. Rules are now backed by a single source of truth, with server-derived rule IDs that stay stable for the lifetime of the event.
* **Offer test discounts are live.** The offer test type's discount engine is now fully enabled in production on V3 plans, so you can launch offer tests with volume and threshold discount tiers end-to-end. See [Offer test](/experiments/offer-test).
* **Checkout test preview widget panel.** The floating storefront preview widget now includes a dedicated panel for checkout tests, showing per-variant block details alongside other test types. See [Checkout test](/experiments/checkout-test).
* **In-editor variant picker for checkout tests.** Each checkout content block now renders a live preview for the selected variant directly in the editor, with a dropdown to switch variants without leaving the block. A new global variant selector keeps every block on the page in sync so you can preview an entire checkout variant in one click.
* **Collapsible preview header in the checkout editor.** Each block's preview chrome (avatar, badge, Block ID, variant select) can now be collapsed to a thin summary row so you can see the checkout canvas the way customers will. See [Checkout test](/experiments/checkout-test).
* **Group share in the analytics info bar.** When an experiment belongs to a mutual exclusion group, the analytics top bar now shows the group's traffic allocation alongside the existing traffic split, so you can see at a glance how much of total traffic the experiment is eligible for. See [Analytics overview](/analytics/overview).
* **Experiment history records namespace updates.** Adding or removing an experiment from a mutual exclusion group is now captured in the experiment history timeline, so you can audit exactly when group membership changed. See [Settings](/configuration/settings).
* **Exposure tracking groundwork.** Template, theme, and URL-redirect experiments now emit a standardized exposure event after assignment, laying the foundation for more accurate cross-channel reporting in upcoming analytics releases.
## Updates
* **Mutual exclusion groups renamed to exclusion groups.** "Experiment group" has been renamed to "exclusion group" across the UI for clearer language. Copy, hints, and empty states throughout the mutual exclusion flow have been polished, and exclusion groups now cap at 5 experiments to keep traffic math predictable. See [Settings](/configuration/settings).
* **Automatic Block IDs in checkout tests.** Block IDs in the checkout test editor are now derived automatically from the placement you pick, so you no longer need to type or manage them. The placement-confirmed checkbox now persists across wizard remounts, and the Copy button uses a Shopify toast instead of a transient label. See [Checkout test](/experiments/checkout-test).
* **Checkout content block preview parity.** The trust badge content block now hides multi-item display options (layout, divider) when only one badge is configured, matching what visitors see on the storefront.
* **Improved offer test validation.** The offer wizard now surfaces inline errors next to the field that needs attention instead of generic submission failures, and edited control offers can be removed from the wizard. The shipping rate picker is now grouped by profile and zone with clearer validation when a rate becomes invalid. See [Offer test](/experiments/offer-test).
* **Decluttered offer storefront components.** The storefront component editor has been simplified: the "Pill" shape option is now labeled "Floating badge," and unused configuration has been trimmed for a cleaner setup flow.
* **Price test product limit warning.** The price test product selector now flags when you exceed the supported product limit, so you can adjust the selection before launch. See [Price test](/experiments/price-test).
* **Theme connection warning on variants.** Theme tests now warn you when a variant theme isn't connected to ABConvert, so you can fix the connection before launching instead of seeing missing assignments after the fact. See [Theme test](/experiments/theme-test).
* **Market-aware price test view links.** Product preview links on non-primary market tabs in price tests now include the market's country code, so the preview opens in the correct market context.
* **Custom event contract simplified.** Scroll-based custom event rules now use a single depth value and a stable `scroll:{ruleId}` event name, making rules easier to read and reference.
* **Softer migration verify toast.** The migration verification toast has been toned down so it's less disruptive while the script is being checked.
* **Settings script section cleanup.** The Settings page's script connection sections have been tidied up with clearer copy around theme connection state.
## Bug fixes
* **Preview interference between exclusion groups.** Fixed a bug where previewing an experiment in one mutual exclusion group could affect assignment for experiments in a different group.
* **Namespace weight rebalancing.** Fixed two related issues where adding or removing an experiment from a mutual exclusion group could push group percentages over 100% or drop the experiment ID from rebalanced weights.
* **Profit uplift without COGS.** Analytics V2 no longer shows a profit uplift number when COGS isn't configured for the store, removing a misleading zero/negative figure.
* **Lost assignment recovery.** The assignment tracking endpoint now resends on every visit when a previous assignment wasn't recorded, recovering data for sessions that would otherwise be missing. SRM-related dedup windows and resend timestamps have also been tightened so traffic split checks stay accurate.
* **Checkout V2 gating.** The checkout V2 route and UI extension cards are now properly gated so they only appear for stores eligible for Shopify Checkout UI extensions.
* **Cart.js noise from kaching script.** ABConvert's cart change calls now include `kaching_cart_ignore=true`, preventing duplicate events when stores also run the Kaching discount app.
* **Paused experiment billing cap.** Fixed a billing edge case where paused experiments could be counted against your active experiment limit.
* **V5 experiment metadata preservation.** Fixed a regression where saving a V5 experiment could strip metadata from the document; metadata is now preserved through every save.
* **Analytics demo script banner.** The "connect your storefront script" banner no longer appears on the analytics demo page, which doesn't depend on a connected script.
## New features
* **One-click migration to the unified script.** Eligible stores now see a migration banner in the dashboard with a single button that disables the legacy app embeds and enables the unified ABConvert app embed in one flow. New installs skip the banner entirely. See [Installation](/installation).
* **Namespaces (mutual exclusion groups).** You can now create namespace groups from a new settings UI to keep selected experiments from running on the same visitor at the same time. Namespace intent is captured during launch and persists through draft, preview, and active states. See [Settings](/configuration/settings).
* **Checkout test v2.** The checkout test type now supports content blocks, upsell tiles, and a placement checklist in the compose step, powered by a new web-component extension. See [Checkout test](/experiments/checkout-test).
* **Order-level CSV export in V2 Analytics.** Export per-order analytics data (including a profit column with COGS notes) directly from the V2 Analytics dashboard. File names include the experiment prefix and date range for easier archiving. See [Metrics](/analytics/metrics).
* **Customize funnel steps in V2 Analytics.** A new Customize button on the Conversion Funnel card opens a modal where you can reorder, enable, and disable funnel stages with drag-and-drop. The breakdown table now shows dynamic funnel columns that match your configured funnel. See [Metrics](/analytics/metrics).
* **Duplicate experiment as draft.** Any experiment — including archived ones — can now be duplicated as a draft from the row overflow menu in the experiments table.
* **Storefront install script settings.** A new Storefront integration settings panel surfaces the install script state for your theme and helps detect manual install snippets. See [Installation](/installation).
* **Visual editor on V2 plans.** Visual Editor Tests are now available on V2 plans. See [Visual editor test](/experiments/visual-editor-test).
* **Per-day churn metrics.** Revenue snapshots now compute per-day churn metrics for finer-grained retention analysis.
## Improvements
* **Global script connection banner and redesigned Settings page.** A persistent banner flags stores whose storefront script isn't connected, and the Settings page has been reorganized for clarity. The banner is suppressed until you've completed the onboarding survey on fresh installs.
* **Launch guard for script-dependent tests.** Preview and Launch actions on script-dependent test types now route through a shared Connect modal that blocks launch until the script is verified.
* **Theme test variant connection check.** Theme tests now verify each variant theme is reachable before allowing preview or launch, catching unpublished or deleted themes earlier in the flow. See [Theme test](/experiments/theme-test).
* **Refreshed MCP access tokens UI.** Settings → MCP tokens has a redesigned card layout, per-environment URLs, a revoke confirmation step, and per-token setup instructions. See [MCP quickstart](/mcp/quickstart).
* **Branded welcome banner for MCP.** AI assistants connecting via MCP for the first time now receive a branded ABConvert welcome message with onboarding tips. See [MCP overview](/mcp/overview).
* **Cleaner offer test wizard.** Redundant minimum purchase options are hidden, offer type picker arrows are aligned, and edited control offers can be removed via a new row overflow action.
* **Archived experiments tab.** Delete on Active/Paused experiments is now gated, and archived tests live under a dedicated Archived tab. Copy across the experiments table consistently uses "Archive" instead of "Delete."
* **Better metric tooltips and breakdown dropdown.** Metric tooltips now show the full title and description for every metric with a definition. The breakdown metric dropdown uses sentence case and correctly highlights the selected item.
* **GA4 integration restricted to V3 plans.** The GA4 integration is now available only on V3 billing plans. See [GA4 integration](/configuration/ga4-integration) and [Pricing plans](/configuration/pricing-plans).
* **Deprecated PDP content card removed.** The legacy PDP content card no longer appears in the experiment table.
* **Updated migration banner help link.** The migration banner now points to current help content.
## Bug fixes
* **Pricing analytics metrics no longer return Infinity.** Pricing analytics now guards against divide-by-zero so calculated metrics always render as finite numbers.
* **Bulk-action toast on mixed selections.** Removed a confusing toast that fired when bulk actions ran against a mix of eligible and ineligible rows.
* **Billing page "Have questions" button.** Fixed a frontend error when clicking the "Have questions" button on the billing page.
* **Analytics demo page crash.** Fixed a crash that affected every visit to the analytics demo page; mock data now includes the discount and SRM fields the page expects.
* **Visual editor lazy image replacements.** Visual editor edits no longer break when a page lazy-loads images that match a replacement rule.
* **Theme-agnostic swatch price replacement.** Price replacements on color/variant swatches now apply correctly across more themes.
* **Shipping rates returning empty.** Fixed a bug where certain shipping zones returned no rates during shipping tests.
* **Redirect test country lookup.** Country lookup is now scoped to redirect tests that actually need it, reducing wasted requests and improving the reliability of assignment tracking.
* **Duplicate "Reset web pixel" CTA.** Removed a duplicate reset web pixel button from the dashboard.
* **Storewide analytics load failures.** The dashboard now degrades gracefully when storewide analytics requests fail instead of getting stuck.
* **Customize funnel modal polish.** Several UI/UX issues in the Customize Funnel modal are resolved, including dropdown unselection behavior and selected-row styling.
## New features
* **ABConvert MCP server (preview).** A new Model Context Protocol endpoint lets you connect AI assistants and agents directly to your ABConvert data over HTTPS with bearer-token auth. Read, list, and inspect experiments from Claude, Cursor, and other MCP-compatible clients. See [MCP overview](/mcp/overview) and [Quickstart](/mcp/quickstart).
* **Offer test edit page.** You can now edit a live offer test's configuration without recreating it, including discount tiers and targeting.
* **Volume and threshold discount tiers in the offer wizard.** Build offers with quantity-based ("buy 3, save 15%") or spend-based ("spend $100, get $20 off") tiers directly in the offer wizard. Tiers are reflected in both the wizard preview and the storefront widget.
* **Offer test preview.** Preview offer experiments end-to-end before launch — browse mode, password-protected storefronts, and the storefront widget are all supported in the preview flow.
* **Discount metrics in V2 Analytics.** The V2 Analytics dashboard now reports discount usage, discount amount, and discount-adjusted revenue alongside existing experiment metrics. See [Metrics](/analytics/metrics).
* **Offer test surfacing in app UI.** Offer tests now show a dedicated icon in the experiments table and render their configuration in the analytics test settings tab, so it's easy to spot and review them at a glance.
## Improvements
* **"Content Test" renamed to "Visual Editor Test".** The test type is now called Visual Editor Test throughout the app and docs to better match what it does. See [Visual editor test](/experiments/visual-editor-test).
* **Unified back button on create test pages.** All create-test flows now return you to the same place when you cancel, making navigation more predictable.
* **More complete event metrics.** Five additional event-count metrics are now tracked in analytics snapshots, giving you finer-grained visibility into funnel events.
* **Funnel reporting (early access).** Internal funnel data pipeline and reporting APIs are now live, paving the way for a richer funnel report in the analytics dashboard.
## Bug fixes
* **Currency display in V2 Analytics.** Fixed a bug where V2 Analytics could show the wrong currency symbol for stores using a non-USD default. Currency now consistently reflects your store settings.
* **Device targeting for checkout, payment, and delivery customization tests.** Fixed a regression where device targeting (mobile/desktop) was not being applied to checkout UI, payment customization, or delivery customization tests.
* **Filter input crash.** Fixed a crash caused by special characters (`(`, `[`, `*`, etc.) in filter inputs across the dashboard. Filters now handle regex metacharacters safely.
* **Cleaner analytics error handling.** Analytics dashboards no longer treat error responses as valid data, preventing misleading numbers when an upstream request fails.
## New features
* **Offer test (early access).** End-to-end support for amount-off-product and amount-off-order offer experiments has landed, powered by a unified offer lifecycle and discount engine. Reach out to support if you'd like to pilot offer testing on your store.
* **Drop-off metrics in analytics.** Experiment results now include funnel drop-off metrics so you can see exactly where visitors leave between view, cart, checkout, and purchase. See [Metrics](/analytics/metrics).
* **Cost-of-goods warnings on the Impact Dashboard.** When COGS data is missing or stale, the homepage Impact Dashboard now flags it inline so profit lift numbers don't quietly mislead you. See [Analytics overview](/analytics/overview).
* **Grouped metrics in the analytics breakdown.** The breakdown table now clusters related metrics (revenue, conversion, AOV, funnel) into named groups for faster scanning across variants.
* **Auto-launch for pending price tests.** The AI theme compatibility check now auto-launches any price tests that were waiting on theme verification once the check passes — no need to come back and start them by hand. See [Price test](/experiments/price-test).
## Improvements
* **Redesigned create-test page.** The new test creation flow groups test types more clearly and merges the standalone checkout chooser into a single, simpler picker.
* **Faster, lighter storefront script.** Price, theme, template, shipping, visual editor, and URL redirect tests now all run on the unified ABConvert script runtime. Custom-event tracking, visitor labels, and theme cache clearing are folded into the same embed, which means fewer script tags and a smaller storefront footprint.
* **More accurate SRM detection.** Sample-ratio mismatch checks now reset their evaluation window after a traffic split change so a deliberate reallocation no longer trips the alarm.
* **Subscription products blocked from price tests.** Subscription items are now filtered out during price test product selection to prevent unsupported configurations. See [Price test](/experiments/price-test).
* **API hardening.** The V2 experiment APIs received a round of validation and error-handling improvements as part of the new ABConvert MCP server preview. See [API overview](/api-reference/overview).
## Bug fixes
* **Preview widget bucketing.** Fixed a bug where the preview widget could route to the wrong target URL when bucketing visitors into a variant.
* **Feature flags on fresh sessions.** Fixed a race where feature flags could be evaluated before the merchant identity resolved on a brand-new session, occasionally hiding features that should have been available.
* **Annual billing on V3 plans.** Fixed a billing error by blocking annual subscriptions from attaching usage line items, and prevented annual checkout for V3 plans where it isn't supported.
* **Legacy variant cleanup.** Fixed a Shopify GraphQL error caused by empty variant IDs slipping into legacy cleanup runs.
* **Embedded admin authentication.** Fixed a regression where some embedded admin requests using App Bridge session tokens could be rejected as "Invalid token" after the new API token middleware was introduced.
## New features
* **Self-service script removal.** Merchants on no-plan accounts with leftover ABConvert tests can now clean up active tests and remove storefront scripts on their own from a new **Remove Scripts** page — no support ticket required.
* **URL pattern presets in the visual editor.** The "Where should this change appear?" modal now opens with one-click scope presets (Every page, Product pages, Collections, Custom) so you don't have to hand-write glob patterns. Each pattern row shows a plain-English match preview. See [Visual editor test](/experiments/visual-editor-test).
* **Multi-URL targeting for visual editor mutations.** A single visual edit can now apply to multiple Shopify routes — useful when the same product appears at `/products/foo` and `/collections/*/products/foo`. Locale handling is now explicit via globs instead of hidden behavior.
* **Upgrade-to-unlock prompts for starter plans.** When a recommended test type isn't available on your current plan, you'll now see a clear "Upgrade required" badge and an inline upgrade modal instead of running into dead ends mid-flow. See [Pricing plans](/configuration/pricing-plans).
* **Richer experiment table.** The experiments list now surfaces impact metrics directly in the table so you can scan winners and lifts without opening each test. See [Metrics](/analytics/metrics).
* **Cumulative added-revenue and added-profit trends.** Experiment results now display cumulative trends for revenue and profit added by the winning variant, so the upside compounds visibly over the run of a test.
* **Outlier filtering for analytics.** Shop-level settings now let you exclude revenue outliers from order-based metrics using either z-score exclusion or an absolute cap, producing more stable comparisons on stores with occasional large orders. See [Statistical significance](/analytics/statistical-significance).
## Improvements
* **Visual editor error recovery.** The canvas now shows a retry button when a page fails to load, plus a one-click reload next to the URL bar. Timeout messages explain what happened and what to try next.
* **URL redirect product-not-found is now a warning.** A missing product handle is reported as a warning instead of a hard error, so a stale handle no longer blocks you from saving the rest of a redirect test. See [URL redirect test](/experiments/url-redirect-test).
* **Help banner consolidated.** The dashboard's two stacked help cards collapsed into a single, more compact info banner with clearer copy and region-specific availability windows.
* **Cleaner navigation for accounts without a plan.** The sidebar now shows only the relevant entries (Pricing, plus Remove Scripts when applicable), and the brief flicker on dashboard load is gone.
## Bug fixes
* Fixed a crash in **experiment history** caused by HTML error responses being parsed as JSON; the modal now surfaces a clean error message instead of failing silently on Safari.
* Fixed **currency display** in the price test Target Market selector for stores that inherit the default currency from the shop (previously fell back to USD, even on EUR stores).
* Fixed **visual editor mutations leaking across pages** in the canvas — edits made on one product page no longer apply when previewing a different product.
* Fixed the **URL pattern modal** so it scrolls correctly when adding many patterns.
# GA4 Integration: Track Experiments in Google Analytics
Source: https://docs.abconvert.io/configuration/ga4-integration
Connect ABConvert to GA4 to receive experiment impression events and analyze test group performance alongside your other Google Analytics data.
Connecting ABConvert to Google Analytics 4 lets you analyze experiment performance alongside all of the other behavioral data you're already collecting in GA4. Once connected, ABConvert fires a custom event every time a visitor is assigned to an experiment, so you can build reports that segment any GA4 metric — sessions, revenue, engagement — by experiment and variant.
## What gets tracked
When the integration is active, ABConvert sends a `abconvert_experience_impression` event to your GA4 property each time a visitor enters an experiment. The event includes:
| Parameter | Description | Example |
| ------------------------------ | ----------------------------------------------------------------------- | --------------------- |
| `abconvert_experiment_id` | The numeric experiment ID | `1001` |
| `abconvert_experiment_name` | The experiment name | `Homepage price test` |
| `abconvert_group_index` | The assigned test group index | `1` |
| `abconvert_variant_name` | The assigned variant name | `Variant B` |
| `abconvert_exp_variant_string` | Combined experiment + group key in the format `experimentId-groupIndex` | `1001-1` |
| `abconvert_assignment_reason` | Why this assignment happened | `random_split` |
These parameters are available as event parameters in GA4 and can be used to create custom dimensions, apply them to explorations, or build audience segments.
## Setup
In Google Analytics, go to **Admin** → **Data Streams** → select your web data stream. Your Measurement ID appears at the top right of the stream details panel. It follows the format `G-XXXXXXXXXX`.
Click the copy icon next to the Measurement ID or select the full string (including the `G-` prefix).
In ABConvert, go to **Settings** and find the **GA4 Measurement ID** field. Paste your Measurement ID and click **Save**.
Run a live experiment and open **GA4 → Reports → Realtime**. You should see `abconvert_experience_impression` appearing in the event stream within a few minutes of a visitor being assigned to an experiment.
![GA4 Realtime overview showing event count by event name with abconvert_experience_impression listed in the event stream]()
Your Measurement ID must follow the format `G-XXXXXXXXXX` (the letter G followed by a hyphen and alphanumeric characters). ABConvert validates the format when you save — if the field shows an error, double-check that you've copied the full ID from GA4.
## Building reports in GA4
Once the integration is running and impression events are flowing into GA4, you can analyze experiment data in several ways.
**Custom dimensions**
To use ABConvert event parameters in standard GA4 reports, register them as custom dimensions:
1. Go to **Admin** → **Custom definitions** → **Custom dimensions**
2. Click **Create custom dimension**
3. Set the scope to **Event**
4. Set **Event parameter** to one ABConvert parameter (for example `abconvert_experiment_name` or `abconvert_variant_name`)
5. Repeat for other parameters you want to report on
After registering, GA4 will start populating the dimension in reports going forward (historical data won't be backfilled).
![GA4 edit custom dimension dialog showing scope set to Event and event parameter field for an ABConvert parameter]()
**Explorations**
GA4 Explorations give you the most flexibility for analyzing experiment results. To compare variants correctly, create one **user segment** per test group.
In GA4, go to **Explore** and choose **Segment overlap**.
Add a **User segment** with an event condition where event name equals `abconvert_experience_impression`, then filter the same event by:
`abconvert_experiment_id = `
`abconvert_group_index = 0`
Duplicate the control segment and change `abconvert_group_index` to `1`, `2`, or other variant indexes used in your experiment.
Add business metrics like purchases, revenue, or engagement and compare segments side by side.
![GA4 custom segment setup screen with User segment selected as the segment type]()
![GA4 user segment condition builder filtering abconvert_experience_impression by ABConvert experiment and variant fields]()
If you want a single filter field per segment, use `abconvert_exp_variant_string` (for example `1001-0` for control and `1001-1` for Variant 1).
**Funnel exploration**
Build a funnel exploration with steps for page view → add to cart → purchase, then apply variant segments as breakdowns. This lets you see exactly where in the purchase funnel each variant performs differently.
## Things to know
* GA4 impression events are fired client-side by the ABConvert script. If a visitor has an ad blocker or has opted out of tracking, the event may not be sent.
* The integration supplements ABConvert's own analytics — it does not replace them. Use ABConvert's dashboard for statistical significance calculations and conversion metrics; use GA4 for deeper behavioral and cross-channel analysis.
* There is no additional cost in ABConvert or GA4 for enabling this integration. GA4's standard event limits apply.
# Pricing Plans
Source: https://docs.abconvert.io/configuration/pricing-plans
Find the plan that best fits your needs
## ABConvert plans
All plans are order-based pricing, designed to align with your store's performance. Choose a plan based on your monthly order volume, run experiments risk-free with a free trial, and scale as your store grows.
| **Plan** | **Monthly subscription fee** | **Included experiment orders** | **Overage per 1,000 extra experiment orders** |
| :------------ | :--------------------------- | :----------------------------- | :-------------------------------------------- |
| **Starter** | \$99/mo | 1,000 | \$59 |
| **Growth** | \$199/mo | 5,000 | \$39 |
| **Scale** | \$399/mo | 15,000 | \$29 |
| **Pro** | \$599/mo | 30,000 | \$24 |
| **Unlimited** | \$2,499/mo | Unlimited | \$0 |
For all first-time users, all plans include a **14-day free trial**. You can run experiments and evaluate results before committing. (Exception: **Unlimited** plan has no free trial)
## What each plan includes
| | **Starter** | **Growth** | **Scale** | **Pro** | **Unlimited** |
| :-------------------------- | :---------- | :--------- | :-------- | :------ | :------------ |
| **Test Types** | | | | | |
| URL test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Template test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Theme test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Visual editor test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Offer test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Price test | ❌ | ✅ | ✅ | ✅ | ✅ |
| Multi-market price test | ❌ | ❌ | ✅ | ✅ | ✅ |
| Shipping test | ✅\* | ✅\* | ✅\* | ✅\* | ✅\* |
| Payment customization test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Delivery customization test | ✅ | ✅ | ✅ | ✅ | ✅ |
| Checkout UI extension test | ✅\*\* | ✅\*\* | ✅\*\* | ✅\*\* | ✅\*\* |
| **Support** | | | | | |
| 24/7 AI Chat | ✅ | ✅ | ✅ | ✅ | ✅ |
| Email Support | ✅ | ✅ | ✅ | ✅ | ✅ |
| Priority Tech Support | ❌ | ❌ | ✅ | ✅ | ✅ |
| Dedicated Slack Support | ❌ | ❌ | ❌ | ✅ | ✅ |
| Theme Integration Support | ❌ | ❌ | ❌ | ✅ | ✅ |
Some test types require a specific Shopify plan due to technical limitations, regardless of your ABConvert plan:
* Shipping test (\*): Requires Shopify Plus for Carrier Service API
* Checkout UI extension test (\*\*): Requires Shopify Plus
## How order limits and overage work
Each plan includes a number of **experiment orders** per billing cycle. For example, the Growth plan includes 5,000 experiment orders. An experiment order is any order that participated in one of your tests during that billing cycle.
You pay overage only when your **experiment orders** exceed your plan limit. Orders that never enter a test do not create overage charges.
**Key insight:** There is no minimum test duration requirement. The old 7-day rule no longer applies. If an order participated in a test during the billing cycle, it counts toward your billing usage.
You can monitor your experiment orders and overage status anytime from the **Billing** page in the ABConvert dashboard.
## FAQs
**Starter**: New or low-volume stores starting with A/B testing **Growth**: Growing stores running consistent experiments (most popular) **Scale**: High-volume stores optimizing multiple funnels **Pro**: Advanced teams needing deeper support and collaboration **Unlimited**: Enterprise stores running continuous, large-scale testing
For billing, ABConvert counts **experiment orders**, not all store orders.
An order counts when it participates in one of your tests during the billing cycle. If the same order touches multiple tests, ABConvert still counts it only once for billing. Orders that never enter a test do not count toward overage billing.
Overage charges apply when your **experiment orders** exceed your plan limit during the billing cycle.
If your store has high total order volume but only a small number of those orders participated in tests, ABConvert charges based only on experiment orders.
Overage is billed per 1,000 **experiment orders** over your limit, rounded up.
*Example:* You're on the Growth plan (5,000 order limit), and 6,800 orders participated in your tests this month.
* Experiment orders over limit: 1,800
* Billable units: 2 (rounded up from 1.8)
* Overage charge: 2 × $39 = _$78\_
* Total for the month: $199 + $78 = *\$277*
Every plan has a **maximum overage charge** per billing cycle, and you can check your cap on your billing page. Once you hit this cap, no additional overage is charged for the rest of that billing cycle, though new experiments will be paused until the next cycle begins. The cap resets automatically each cycle.
Overage is calculated and charged through Shopify's standard 30-day billing cycle. It appears on the same invoice as your subscription renewal, on the same billing date every 30 days from your activation date.
You can switch your plan anytime by going to **ABConvert > Billing > View plans**. Find the plan that best fits your needs and select **Choose this plan**.
# App Settings: Configure ABConvert for Your Store
Source: https://docs.abconvert.io/configuration/settings
Control how ABConvert runs on your store — from tracking scripts and order tagging to COGS configuration and Google Analytics.
The Settings page is where you control the core behavior of ABConvert across your store. Most settings apply globally to all experiments, so it's worth reviewing them before you launch your first test.
## Theme connection
The ABConvert unified script must be activated in your theme for experiments to run. This app embed loads the tracking and experiment logic on every page of your storefront. You can check connection status or change methods here.
![Connect status]()
### Connect method 1: Theme embed app (recommended)
1. Click **Change method**
2. Choose **Use app embed**
![Use app embed]()
3. Follow the steps to enable in Shopify theme editor and click **Verify status** to check
![Enable app]()
Once enabled, the unified script loads automatically on all pages. You don't need to re-enable it unless you switch to a new theme.
### Connect method 2: Manual installation (for edge cases)
If your theme has a unique pattern or needs special configuration for better performance, you can install the script manually by adding a code snippet to your theme's `theme.liquid` file. This method requires manual management to your theme files, only change to this method when needed.
Manual installation requires editing your theme code manually. If you're not comfortable with Liquid or HTML, contact ABConvert support for assistance.
**Steps for manual installation:**
1. Click **Change method**
2. Choose **Add script to theme code**
![Add script to theme code]()
3. Follow the steps to add scripts to your Shopify theme.liquid file
![Manual connect]()
After finishing, when you update or change your theme, you still need to re-add this snippet to the new theme's `theme.liquid` file.
## WebPixel status
ABConvert uses a Shopify web pixel to track visitor events — page views, add-to-cart, checkout — with high accuracy. The web pixel is required for accurate analytics. Without it, ABConvert cannot collect and show experiment data correctly in analytics dashboard.
If the web pixel is not enabled, please create Webpixel before start a test. If it becomes misconfigured, use the **Reset** option to recreate it.
![WebPixel]()
## Carrier service
Carrier service configuration is required for shipping rate experiments. When a carrier service is registered, ABConvert intercepts Shopify's shipping rate requests and returns the test rates for visitors in the experiment group.
The Settings page shows whether a carrier service is currently configured. You can delete the carrier service from this page if you no longer need shipping tests.
![Carrier service]()
You cannot delete the carrier service while a shipping experiment is running. Stop all active shipping tests first.
## Order tag
ABConvert can automatically tag orders with experiment data, making it easy to segment orders by test group in your Shopify admin or in reports exported from ABConvert.
![Order tags]()
Click **Configure order tags** in Settings to open the tag configuration panel. For each experiment type, you can choose one of three tagging modes:
| Mode | Example tag |
| -------- | ------------------------------------------------------------ |
| No tag | *(no tag added)* |
| Plain | `ABConvert Price Test` |
| Detailed | `ABConvert Price Test: Group 0`, `ABConvert Price Test: 123` |
| Custom | Your own tag text (up to 40 characters) |
Order tags are available for: Price Test, Shipping Test, URL Redirect Test, Template Test, Theme Test, and Checkout Test.
![Order tags configuration]()
Use the Detailed tag mode if you want to filter orders by specific experiment variant in your Shopify admin or third-party reporting tools.
## Price test method
ABConvert evaluates your store during setup and assigns the optimal price test method. Currently, you cannot switch your method on your own, and all stores will be using Shopify function by default.
![Price test method]()
## Order outlier filter
The order outlier filter excludes unusually large orders from your Analytics dashboard, preventing them from skewing your experiment results.
![Outlier filter]()
You can choose from three filtering methods:
| Method | How it works |
| ----------------------------- | --------------------------------------------------------------------------------------- |
| **No filter** | All orders are included in analytics (default) |
| **Maximum revenue per order** | Excludes orders above a specific dollar amount you define |
| **Z-score exclusion** | Excludes orders that are statistical outliers based on standard deviation from the mean |
### Maximum revenue per order
Set a dollar threshold (e.g., \$500). Any order above this amount is excluded from analytics. Use this when you know the upper bound of typical orders for your store.
### Z-score exclusion
Define a threshold between 1 and 5 (typical range: 2 to 4). Higher values keep more orders; lower values exclude more outliers. A threshold of 3 excludes orders more than 3 standard deviations from the mean.
If your store occasionally receives large wholesale or bulk orders that aren't representative of typical customer behavior, use the outlier filter to get clearer experiment results.
## COGS settings
ABConvert uses your COGS (cost of goods sold) data to calculate profit metrics in analytics, including **Profit per Visitor**, **Profit Uplift**, and other profit-based comparisons.
![COGS]()
Click **Manage COGS settings** to configure these fields:
![Configure COGS]()
**Product Costs**
* **Automatic mode**: Sync product costs directly from Shopify. Choose daily sync frequency if your costs change often.
* **Manual mode**: Upload a CSV file with product costs for more control
**Shipping Costs**
* Set your average shipping or fulfillment cost per order
**Transaction Fees**
* Configure payment processing fees as percentage + fixed amount (e.g., 2.9% + \$0.30)
**Tier Costs** (optional)
* Override base product costs by quantity tier for wholesale or bulk order scenarios
* Define cost breaks at different quantity thresholds
If product costs are missing, ABConvert cannot calculate profit metrics correctly. Profit per Visitor and related metrics may show as zero or inaccurate until COGS data is properly configured.
Use Automatic mode with daily sync if your product costs fluctuate frequently. This keeps your profit calculations up to date without manual CSV uploads.
## Product groups
Product groups are reusable sets of products you can apply as a filter on a test's Analytics dashboard. Build one from a collection, tag, product type, or a hand-picked list. Click **Manage Product Groups** to create and edit them. See [Product Groups](/analytics/product-groups) for how to use them in analytics.
## GA4 Measurement ID
Enter your Google Analytics 4 Measurement ID here to connect ABConvert to your GA4 property. When configured, ABConvert fires a custom event in GA4 each time a visitor is assigned to an experiment, letting you analyze experiment data alongside your other GA4 metrics.
See [GA4 Integration](/configuration/ga4-integration) for setup instructions.
## Settings FAQs
Yes. We recommend keeping the ABConvert app embed turned on, even when you are not running tests. It will not affect your store if there are no active tests running, and it keeps your store ready for future tests and helps ABConvert confirm your storefront is connected.
Confirm the ABConvert app embed is enabled on the theme where your tests should run. Modifying a theme will not affect the embed app, but changing to a new theme will require you to enable the ABConvert app embed in the new theme before starting a test.
You can still view existing test data and historical analytics. However, ABConvert will ask you to reconnect before you can preview, launch, or continue tests that need the storefront script.
The app embed is recommended for most stores, but some custom themes may perform better with manual installation. If you notice slower loading or flickering, contact ABConvert support and we can help check whether manual setup is a better fit.
# Audience Targeting: Filter Who Sees Your Experiments
Source: https://docs.abconvert.io/experiments/audience-targeting
Learn how the traffic system works in ABConvert, including traffic allocation, audience targeting, and group assignment rules
Before a visitor ever sees a variant, ABConvert determines exactly who qualifies. To ensure your analytics remain perfectly clean, every visitor goes through a deterministic evaluation flow before they see a final variant.
![ABConvert traffic flow with Exclusion Group before Traffic Allocation]()
When creating a test, you can configure these rules in **Step 2: Audience**.
![Audience step configuration in test setup]()
## Exclusion Group (optional)
If you add an experiment to an **Exclusion Group**, ABConvert ensures each visitor can enter only one experiment in that group. This prevents experiment overlap from contaminating your results.
ABConvert uses a deterministic group-level hash and preconfigured ranges to decide which experiment a visitor can enter. Once assigned, that visitor stays in the same Exclusion Group assignment for consistency.
![ABConvert Exclusion Group configuration where one visitor can only join one experiment in the same exclusion group]()
You can create, edit, and delete Exclusion Groups in **Settings**.
![ABConvert Settings page where merchants can create, edit, and delete exclusion groups]()
## Traffic allocation
When a visitor arrives at your store, ABConvert first decides whether they should enter the test at all. You control this with the **Traffic allocation** percentage (1–100%).
* **100%** — All eligible visitors enter the test (recommended)
* **Lower percentages** — Useful for cautious rollouts or limited inventory
For example, if you set traffic allocation to 50%, half of your visitors will enter the test and half won't. This decision is **sticky** — once a visitor is included or excluded, they stay that way for the duration of the test.
![Traffic allocation control for deciding how many visitors enter the test]()
## Audience filters (optional)
After passing traffic allocation, visitors go through audience filters. These let you narrow down exactly who sees your test. Filters only apply to visitors who haven't been assigned yet.
![Audience filter builder with country, traffic source, device, and visitor type options]()
### Basic filters
* **Countries** — Target specific geographic regions
* **Traffic Sources** — Filter by where visitors came from (paid ads, organic search, social, email, etc.). See *Understanding Traffic Sources* below for full details.
* **Devices** — Target desktop or mobile visitors
* **Visitor Type** — Target new visitors or returning visitors. **Note:** Enable ABConvert Visitor Label in your embedded apps at least 2 weeks before using this filter.
### Advanced filters
You can use **Advanced filters** to expand these options:
* **Referral Domain** — Filter by the referring website domain
* **Landing Page URL** — Target visitors arriving at specific pages
* **URL Parameters (UTM)** — Target visitors with specific UTM parameters
* **Cookie Values** — Target based on existing cookie data
Advanced filters support complex logic, for example: Landing Page URL **starts with** /products **and contains** /A or /B or /C.
![Advanced filter example showing combined landing-page conditions]()
### Understanding traffic sources
ABConvert detects where a visitor came from using two signals on their first page load:
* **Click IDs in the URL** — When someone clicks a paid ad, the ad platform automatically appends a unique ID to the landing URL (e.g. `gclid` for Google Ads, `fbclid` for Facebook Ads, `ttclid` for TikTok Ads). ABConvert reads this to identify paid visitors reliably.
* **Referring page** — When a visitor clicks a link on another site, the browser passes along where they came from. ABConvert uses this to detect organic search, organic social, and referral traffic.
Once detected, the traffic source is saved for the entire session, so navigating to other pages won't change the visitor's classification.
### Channels
Channels group visitors by acquisition type:
* **Paid Search** — Clicked a Google Ads or Bing Ads link (detected by `gclid` or `msclkid` in the URL)
* **Organic Search** — Clicked an organic result from Google, Bing, Yahoo, DuckDuckGo, etc.
* **Paid Social** — Clicked a paid social ad on Facebook, TikTok, Instagram, etc. (detected by `fbclid`, `ttclid`, or `utm_medium=cpc/paid`)
* **Organic Social** — Clicked an organic post on Facebook, Instagram, TikTok, Twitter/X, or YouTube
* **Email** — URL contains `utm_source=email` or `utm_medium=email`
* **SMS** — URL contains `utm_source=sms` or `utm_medium=sms`
* **Affiliate** — URL contains `utm_medium=affiliate`
* **Referral** — Came from another website (not a search engine or social platform)
* **Direct** — No referrer and no UTM params (typed URL, bookmark, or unknown source)
### Platforms
Platforms let you target a specific source within a channel. For example, selecting **Google** captures all Google visitors, both paid (Google Ads) and organic (Google Search).
Available platforms: Google, Facebook, Instagram, TikTok, Twitter/X, YouTube, Bing.
### How filters work together
A visitor must pass **all** enabled filter groups to proceed to group assignment.
**Example configuration:**
* Country: United States OR Canada
* Device: Mobile
* Traffic source: Facebook OR Instagram
**Result:** Only mobile visitors from US/Canada arriving from Facebook or Instagram will enter the test.
## Targeting rules (optional)
Targeting rules let you force-assign specific visitors to a particular group, instead of random assignment. Rules are evaluated in order, the first matching rule wins.
1. **Add a rule**\
Click **+ Add rule** to create a condition
2. **Set conditions**\
Choose from: Country, Traffic Source, Referral Domain, Landing Page, Device, UTM parameter, Cookie
3. **Set the action**\
Choose what happens when the rule matches:
* **Assign to group** — Send matching visitors directly to Control or a Variant
* **Random split** — Pass to the normal random assignment step
* **Exclude** — Remove from the test entirely (not tracked in analytics)
![Targeting rules panel with assign, random split, and exclude actions]()
**Example:** "IF Device is Desktop → Assign to Control"
**Default:** Visitors who don't match any rule are randomly split according to your group percentages.
## Random group assignment
If a visitor passes all filters and doesn't match any targeting rules, they are randomly assigned to a test group based on your split percentages.
ABConvert uses a deterministic hash so the same visitor always lands in the same group across sessions, even if they clear cookies or return days later.
**Example:** For a 50/50 split, visitors with hash 0–49 see Group 0 and hash 50–99 see Group 1.
## Audience targeting FAQs
Even with a 50/50 split, analytics may show 52/48 or similar. This is normal for two reasons:
1. **Smaller sample = more variance**\
Audience filters reduce the visitor pool. With 100,000 visitors you'll see near-perfect 50/50. With 1,000 visitors after filtering, 48/52 is statistically normal.
2. **Short-term randomness**\
Like flipping a coin — you might get 6 heads and 4 tails in a short run. It evens out over time.
**What to do:** Let the test run longer. As sample size grows, the distribution naturally balances.
Each test assigns visitors independently. The same visitor can be in different groups across different tests — this is by design. Each test's assignment is isolated and based on its own experiment ID.
**Example:**
* Price Test A → Visitor in Group 0 (Original)
* Theme Test B → Same visitor in Group 1 (Variant)
* Shipping Test C → Same visitor in Group 2
This is not currently possible. We're planning to launch a test grouping feature that will unlock this use case — stay tuned!
Yes. You can adjust the allocation percentage at any time. However, visitors who were already excluded stay excluded.
**Example:** If you start at 50% and increase to 80%, the extra 30% comes from previously excluded visitors.
Yes, but changes only affect new, unassigned visitors. Visitors already in a group keep their original assignment.
**Best practice:** Test your filters thoroughly before launching to avoid losing attribution data.
They are permanently excluded from the test. They won't see any variant and won't appear in test analytics.
# Checkout test
Source: https://docs.abconvert.io/experiments/checkout-test
A/B test changes to your Shopify checkout to see what lifts orders and revenue.
A checkout test splits your visitors into groups, shows each group a different checkout, and measures which completes more orders. You decide what every group sees, and ABConvert compares the results.
Checkout tests are available on all ABConvert plans. Delivery and Payment modifications work on any Shopify plan. Content, Cart, and Upsell modifications require **Shopify Plus**.
## When to use it
Use a checkout test to prove a change lifts orders or revenue before rolling it out:
* **Raise order value with an upsell.** Show a product recommendation inside checkout and compare average order value against Control.
* **Win more orders with reassurance.** Add trust badges, a guarantee banner, or payment icons, and measure whether more visitors finish.
* **Guide shipping choice.** Rename or reorder shipping options to make a faster option clearer.
* **Streamline payment methods.** Hide, rename, or reorder payment methods and measure the effect on completed checkouts.
## When NOT to use it
Checkout tests change only what visitors see *at checkout*. If your change happens earlier, use the test built for that surface:
* **Testing a product's price?** Use a [price test](/experiments/price-test). Checkout tests don't change the price shoppers pay.
* **Testing a discount or promotion?** Use an [offer test](/experiments/offer-test). A checkout test can rename a payment method but can't discount it.
* **Testing a landing or product page?** Use a [URL redirect test](/experiments/url-redirect-test) or [theme test](/experiments/theme-test). Checkout tests don't touch the pages leading up to checkout.
## What you can change
A checkout test can modify five things. Combine several in one variant, and give each variant its own set.
| Category | What it changes |
| ------------ | -------------------------------------------------------------------------------------------- |
| **Delivery** | Which shipping options shoppers see at checkout and how they're labeled. |
| **Payment** | Which payment methods shoppers see and how they're labeled. |
| **Content** | Adds visual blocks (banners, trust badges, benefits, images) that build confidence. |
| **Cart** | Whether shoppers can edit cart lines at checkout: change variant, quantity, or remove items. |
| **Upsell** | Recommends extra products at checkout so shoppers add them without leaving the page. |
## Set up a checkout test
Choose the **Checkout** type, name the test, set a hypothesis, pick your primary metric, and add the variants to test against Control.
Set the traffic split and targeting rules. See [Audience targeting](/experiments/audience-targeting).
Open the **Compose checkout** editor for a group, click **Add modification**, pick a category, and configure it.
A live preview on the right updates as you build, and the tabs at the top switch which group you're previewing. It's an approximation of your checkout; confirm the real thing on your storefront before launch (see [Preview on your storefront](#preview-on-your-storefront)).
![Compose checkout editor showing a live preview with Added badges on an upsell block and a trust badge]()
Two toggles help while you build:
* **Show diff markers** flags how the group differs from the original checkout page: **Added** and **Modified** blocks get a solid ring, **Hidden** ones a dashed ring.
* **Desktop / Mobile** switches the viewport.
Check the **Mobile** viewport too. Most checkout traffic is on mobile, and the desktop and mobile views can differ, so a block that looks right on one may not on the other.
![Compose checkout preview in the mobile viewport with a collapsed order summary bar]()
Click **Save**. ABConvert shows a card listing the blocks to add in the Shopify checkout editor. See [Add your blocks](#add-your-blocks-in-the-checkout-editor).
Preview every group on your storefront to confirm each renders correctly, then click **Launch test**. See [Preview on your storefront](#preview-on-your-storefront).
## Add your blocks in the checkout editor
Add the listed blocks exactly where ABConvert shows them, or your test won't render.
Content, Cart, and Upsell modifications render through ABConvert blocks you place in Shopify's checkout editor. (Delivery and Payment modifications apply automatically, with no block to add.) After you save, the **Add your blocks** card lists two kinds of block:
* **ABConvert Checkout Block** renders your Content and Upsell modifications. Add one at each placement the card lists.
* **ABConvert Cart Control** renders your Cart modifications. Add one in **Order summary**.
![Add your blocks card with the ABConvert Checkout Block highlighted, its Block ID and Copy ID button, and the editor guide spotlighting where the block renders]()
![Add your blocks card with the ABConvert Cart Control highlighted, its Mark as added toggle, and the editor guide spotlighting the cart lines in Order summary]()
**What a Block ID is.** Each Checkout Block placement has a short code like `before-contact-bpa`. It links a block you add in Shopify's checkout editor back to the modifications you configured for that spot in ABConvert. You paste the Block ID into the block's settings so ABConvert knows what to render there. Each Block ID belongs to exactly one placement.
Click **Open checkout editor** on the card. It opens the editor in a new tab, jumped to the **Apps** tab, so ABConvert stays open beside it.
Click **Add app block**, open **ABConvert Checkout Test**, and add an **ABConvert Checkout Block** at each placement the card lists. Then paste that placement's **Block ID** into the block's **Block ID** field in the checkout editor's settings panel.
Add **ABConvert Cart Control** in the **Order summary** section. It has no Block ID and renders its controls on each cart line automatically.
Click **Save** in the checkout editor (blocks aren't applied until you save), then return to ABConvert and check off each placement on the card.
### Check each group renders in the editor
While you're in the checkout editor, each ABConvert block shows a **Preview** header with its Block ID and a **Variant** dropdown. Switch the dropdown to render each group's content and confirm your blocks land in the right spot. If a group has no modification for a block, it shows a **Block hidden** banner.
![ABConvert Checkout Block Preview header with a Variant dropdown showing Control and Variant A]()
If you change modifications in ABConvert while the checkout editor is open, refresh the editor to load the latest version.
## Preview on your storefront
Before launching, walk the full shopper path to checkout on your real storefront, as any group you choose. This is the standard pre-launch preview for every ABConvert test type. See [Preview before you launch](/experiments/lifecycle#preview-before-you-launch).
1. In the **Preview Test** card on the review step, click **Open**.
2. An **ABConvert Preview** widget appears. Choose the group you want to walk through as.
3. Browse to your cart and checkout. The blocks render the same way a real shopper would see them.
![Storefront homepage with the ABConvert Preview widget showing the checkout test groups Control and Variant A at a 50/50 split]()
Preview is only visible to you. Real shoppers never see the test while it's in Preview.
## Reading your results
Open the [Analytics dashboard](/analytics/overview) to compare Control against each variant. ABConvert tracks the checkout funnel step by step, so you can see where each variant drops off. You can also add [custom funnel steps](/analytics/overview#custom-funnel-steps) to measure stages specific to your checkout.
![Session-based conversion funnel comparing Control and Variant A across sessions, added to cart, reached checkout, submitted payment, and completed checkout]()
| Metric | What it tells you |
| ----------------------- | ------------------------------------------------------------------------------------- |
| **Conversion rate** | Share of visitors who complete the order. The primary signal for most checkout tests. |
| **Order count** | Completed orders credited to each variant. |
| **Revenue** | Total revenue from each variant's completed orders. |
| **Average order value** | Revenue divided by order count, useful for upsell or shipping tests. |
For full definitions and how significance is calculated, see [Metrics](/analytics/metrics).
Checkout tests often reach significance faster than storefront tests, because only high-intent visitors who reach checkout are counted.
## Common mistakes
Launching without adding the blocks in the checkout editor. Your variants render nothing. Complete [Add your blocks](#add-your-blocks-in-the-checkout-editor) first.
* **Pasting a Block ID into the wrong placement.** Block IDs are placement-specific, so a mismatched ID renders the wrong content or nothing.
* **Forgetting the ABConvert Cart Control block.** Cart modifications only appear if the block is added in **Order summary**.
* **Not previewing every variant.** Checking only one group hides a broken placement in another. Preview them all before launching.
## Checkout test FAQs
Almost always because the blocks weren't added in the checkout editor, or a Block ID was pasted into the wrong placement. Follow [Add your blocks](#add-your-blocks-in-the-checkout-editor): add a Checkout Block at each placement, paste the matching Block ID, and add the Cart Control block in **Order summary** if you use Cart modifications.
No. It means the selected variant has no modification for that block, so customers in it won't see the block. Switch the dropdown to another variant to confirm it renders there.
No. Preview sessions bypass your traffic and audience rules and are excluded from analytics.
Yes. Once assigned, a visitor sees the same checkout for the duration of the test.
# Combined Test: Getting Started
Source: https://docs.abconvert.io/experiments/combined-test
A/B test multiple changes together in one experiment so each visitor sees one coherent experience.
## What is a combined test?
A combined test stacks multiple changes, such as a price change and a shipping rate change, into a single experiment with a single traffic split. Each group sees its own version of every change, so each visitor experiences all the changes together as one package.
You can combine any test type: [price](/experiments/price-test), [shipping](/experiments/shipping-test), [offer](/experiments/offer-test), [URL redirect](/experiments/url-redirect-test), [template](/experiments/template-test), [theme](/experiments/theme-test), [visual editor](/experiments/visual-editor-test), and [checkout](/experiments/checkout-test). You can add each test type once. Each change has the same requirements as when you run it as its own test. For example, a shipping change still requires the Shopify Carrier Service API.
## Combined test use cases
* **Price + shipping (total-cost framing):** Increase product prices and lower or remove the shipping fee. The customer pays a similar total either way; you're testing whether "higher price, free shipping" converts better.
* **Shipping + theme (consistent storefront messaging):** Change your shipping rates and pair them with a theme that mentions the new rates in its banners and product pages, so the promise on the page matches the rate at checkout.
* **Price + content:** Raise a product's price and use the visual editor to strengthen the value messaging on the product page, testing whether better positioning supports a higher price point.
A combined test measures all changes as one package. It can't tell you which change drove the result. To measure a change on its own, run it as its own test instead.
## Set up a combined test
In the ABConvert dashboard, click **Create New Test** and select **Combined Test**.
![Combined test card on the test type selection page]()
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add more variants.
Write the hypothesis about the overall strategy. "Customers prefer all-inclusive pricing" beats "raise price by 10% and make shipping free."
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
Click **Add change** and pick a test type. Each change appears as a card in the list. Expand it to walk through the same configuration steps as the standalone test. Each type can be added once.
![Changes step with a price and a shipping change card]()
![Adding a second change from the test type picker]()
Review your full experiment configuration. The review screen summarizes what each group sees across all changes. We recommend using [Preview test](/experiments/lifecycle#preview-before-you-launch) to check the variant on your storefront before launching. When everything looks correct, click **Launch test**.
![Review screen with the per-group summary of all changes]()
## Combined test FAQs
A visitor is assigned to one group on their first visit, and that assignment stays the same on every page and every visit. Each change then applies where its own configuration targets: storewide changes like price and shipping apply everywhere, while page-scoped changes like a visual editor change appear only on the pages they target.
Yes. The same conflict rules apply as for tests running on their own. For example, only one active test can modify a given shipping zone.
While a theme test is running, your combined test can't include changes that conflict with it:
* a theme change
* a visual editor change
* a template change, if a theme in the theme test doesn't have the template you want to test
# Test lifecycle
Source: https://docs.abconvert.io/experiments/lifecycle
The states a test moves through, and the key actions at each one.
A test's state decides what you can do with it. Most tests follow one path: draft → preview → active → closed. While a test is active, you can pause and resume it.
## What each state means
| State | What it means | What you can do |
| ------------ | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Draft** | Configured but not running. Nothing is live and no data is collected. | **Preview** to check it, **Launch** to go live |
| **Preview** | Live on your storefront, visible only to you. Shoppers still see the original. | **Launch** to go live, **Update preview** after edits, **Convert to draft** to stop the preview |
| **Active** | Live for all shoppers. ABConvert assigns visitors and collects data. | **Edit** the name and traffic split, **Pause**, **End** |
| **Paused** | Stopped. Every shopper sees your original storefront again, and your data is kept. | **Resume** to go live again, **End** |
| **Closed** | Finished. Results are final and it cannot be resumed. | **Archive** to hide it, **Duplicate as draft** to copy and adjust |
| **Archived** | Hidden from the default list, with analytics intact. | **Duplicate as draft** to copy and adjust |
## Preview before you launch
Preview shows a variant on your live storefront, scoped to your session only. Real shoppers keep seeing the original, so you can walk the buyer journey and confirm everything looks right before a single visitor enters the test.
Start a new test or open an existing draft, then go to the final review step.
Click **Preview**. ABConvert opens your storefront in a new tab with the variant applied to your session.
![Review step showing a Preview Test card with a Preview button]()
Browse as a shopper would. Visit the affected pages, add to cart, and step through checkout. Confirm the modification displays the way you designed it.
![Storefront in preview mode with the ABConvert preview widget open]()
Switch between variants from the preview widget and confirm each one looks right.
![Preview widget variant switcher toggling between Control and Variant A]()
When everything looks right, click **Launch** to go live. To change something first, edit the test and click **Update preview** to re-check.
Preview before every launch. No two storefronts are identical, so a preview is the best way to confirm your variant looks and works the way you intended on your store.
### What Preview confirms
Preview is your check on what shoppers see:
* **Display.** The modification renders the way you designed it.
* **App conflicts.** No other app overwrites the same part of your storefront (price, shipping, checkout, or theme).
Preview does not verify analytics. Tracking starts only when the test is **Active** and real visitors are assigned, so confirm your numbers in the [Analytics dashboard](/analytics/overview) once data begins arriving.
## Edit a live test
While a test is **Active**, you can change its name, hypothesis, variant names, and traffic split.
You can't change the variant configuration (the price, shipping rate, theme, content, or offer you're testing) or the [audience](/experiments/audience-targeting) while a test is running.
This restriction is deliberate. Changing what you test partway through mixes two setups into one result set, and the numbers stop meaning anything. To test a different change, end this test and start a new one.
## Pause a live test
Pause is your emergency stop. If a live test looks wrong, pause it right away. Common reasons: a display bug, a conflict with another app, or results you don't trust.
When you pause, ABConvert removes the test's changes from your storefront. Every shopper sees your original store again and no new visitors are assigned. The data you've collected so far is kept. **Resume** puts the variant back and starts assigning visitors again.
Pause stops your test from gathering results, so use it to fix problems rather than to take a healthy test offline for a long time.
Paused because the variant isn't behaving the way you expected? Send us your store and the test, and we'll help you find what's overriding it and get it working.
## Duplicate as draft
**Duplicate as draft** copies a test's setup into a new draft so you can adjust it without rebuilding it from scratch. It's available from any test, in any state, and the copy always starts as a fresh draft with no data of its own.
Use it to try a tweaked version of a test: duplicate it, adjust the draft, then launch. It also lets you branch a new idea off an existing test or recover the setup from an archived one.
# Offer Test: Getting Started
Source: https://docs.abconvert.io/experiments/offer-test
Run A/B tests on automatic discounts to measure their impact on revenue, average order value, and conversion.
## What is an offer test?
An offer test lets you experiment with discounts so you can measure how each one affects revenue, average order value, and conversion. See [Offer types](#offer-types) for the discounts you can test.
ABConvert builds every offer as a Shopify [automatic discount](https://help.shopify.com/en/manual/discounts/discount-methods/automatic-discounts) applied through [Shopify Functions](https://shopify.dev/docs/api/functions/latest/discount). Your existing discounts stay untouched, and an offer only applies to the visitors in the group it is set for.
Offer tests are available on all ABConvert plans.
## Offer types
You choose one offer type per group. The same five types are available to every group.
| Offer type | What it does |
| ----------------------- | ------------------------------------------------------------------------------------------- |
| **Amount off products** | Discount specific products, collections, or all products by a percentage or a fixed amount. |
| **Amount off order** | Discount the entire order by a percentage or a fixed amount. |
| **Shipping discount** | Discount shipping for all rates or specific rates. Use 100% for free shipping. |
| **Volume discount** | A tiered discount by quantity. Buy more, save more on matching products. |
| **Threshold discount** | A tiered discount by cart subtotal. Spend more, save more on the order. |
Percentage offers can optionally set a maximum discount amount, which caps the dollar value the percentage can reach. You can also add a minimum requirement to any offer, either a minimum subtotal or a minimum quantity, so the discount applies only once the cart qualifies.
Each type has its own settings, but the editor is the same: a live preview at the top summarizes the offer as you build it, and the **Title** you set is what shoppers see in the cart and checkout. When an offer's scope is set to specific products or collections, you pick them from your catalog.
![Amount off products offer configuration]()
## Offer test use cases
* **Find the discount that pays for itself:** Compare a discount group against a no-offer control to see whether the lift in conversion makes up for the lower margin.
* **Increase average order value:** Test a threshold discount ("spend $75, save $10") to nudge cart size upward.
* **Move more units:** Test a volume discount to encourage multi-unit purchases on the products you want to sell through.
* **Test free shipping:** Compare free shipping against your standard rates to see which drives more completed orders.
* **Compare two offers head to head:** Configure a different offer in each group to learn which promotion your shoppers respond to.
## Set up an offer test
In the ABConvert dashboard, click **Create New Test** and select **Offer**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary metric (Revenue per visitor, Average order value, or Conversion rate). Set the traffic split across your groups, and add more groups if you want to test several offers at once.
Define which visitors enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
For each group, pick an offer type and set its value, scope, and any minimum requirement. The Control group can keep **No offer** to test against the normal price, or you can give it its own offer to compare two promotions directly.
![Offer type picker]()
You can also add an optional [offer message](#storefront-widgets) and set your [discount combinations](#discount-combinations) here. Both are described below.
Review your full configuration, including the visitor flow and the offer set up for each group. We recommend using **Preview test** to confirm the discount applies correctly in your cart and checkout before launching. When everything looks correct, click **Launch test**.
![Previewing an offer test on the storefront]()
When you launch, ABConvert creates one Shopify automatic discount for the test and activates the script that assigns visitors. The status changes to **Active** once setup is complete. See [Lifecycle](/experiments/lifecycle) for what each state means.
## Storefront widgets
You can attach an optional **offer message** to any group to promote the discount on your storefront. To add one, open the offer message component in the offer step and click **Set up**.
The offer message renders as a badge anchored to a page corner, or as a banner. You can set its text, colors, and corner style, and choose whether shoppers can dismiss it. The text supports dynamic tokens such as the discount value, the cart subtotal, and the amount remaining to reach a threshold, so the same message updates as the cart changes.
![Offer message editor]()
Two more storefront components, **Quantity break** and **Progress bar**, are coming soon and appear in the editor as preview-only.
## Discount combinations
ABConvert builds the whole test as one Shopify automatic discount. The **Discount combinations** controls decide whether it stacks with the other product, order, and shipping discounts in your store. Because it is a single discount, these settings apply to the whole test, not group by group.
See Shopify's [discount combinations guide](https://help.shopify.com/en/manual/discounts/discount-combinations) for which discounts can stack.
## How visitors experience an offer test
1. A visitor browses your store. ABConvert evaluates your targeting rules and assigns the visitor to a group. The assignment is sticky, so the visitor stays in the same group on later visits.
2. Shopify applies the discount for the visitor's assigned group at the cart and checkout.
3. The visitor completes checkout. ABConvert credits the order to that group so you can compare performance across groups.
## Reading your results
ABConvert tracks every group across all metrics in the Analytics dashboard, not just the primary metric you chose. For an offer test, read two sides together: how much the offer lifted sales, and how much margin it gave away.
**How much did the offer lift sales?**
| Metric | Description |
| ------------------- | --------------------------------------------------- |
| Revenue per visitor | Total revenue divided by the visitors in the group. |
| Average order value | Revenue divided by completed orders. |
| Conversion rate | Share of visitors who placed an order. |
**What did the offer cost?** The dashboard's **Discount** metric group quantifies the margin you gave away:
| Metric | Description |
| --------------------------- | -------------------------------------------- |
| Discounted Order Rate | Share of orders that used a discount. |
| Average Discount Value | Average discount amount per order. |
| Revenue Discount Percentage | Total discounts as a share of total revenue. |
| Profit Discount Percentage | Total discounts as a share of total profit. |
Compare each group against the Control to decide whether a promotion earns its margin. A group can lift conversion and average order value while still lowering revenue per visitor if the discount is too deep, so weigh the lift against the discount cost. Profit metrics use your COGS configuration. See [Key metrics](/analytics/metrics) for exact formulas and [Analytics](/analytics/overview) for how results reach significance.
## Offer test FAQs
Yes. ABConvert uses sticky bucketing stored in the visitor's browser. Once a visitor is assigned to a group, they continue to see the same offer for the duration of the experiment.
Use **Preview test** to browse your store as a visitor in a specific group, then add items to your cart and start checkout to confirm the discount applies as expected.
ABConvert creates one automatic discount per offer test, named after your test (for example, `ABConvert Offer #1234: Summer free shipping`), listed under **Discounts** in your Shopify admin. ABConvert manages it for you: it activates when you launch and stops applying when you pause or close the test. Do not edit or delete it manually while the test is running.
Only if you allow it, and only when each discount is set to combine with the other's type. Use the [Discount combinations](#discount-combinations) controls to choose what your offer combines with.
Because the whole test is one discount, the setting covers every group. For example, if your control offers free shipping and your variant takes 10% off a product, ABConvert builds a single discount covering both. A shopper in the variant gets the 10% product discount, but because the test's discount also carries shipping, it will not stack with any other shipping discount in your store, even though that shopper sees no shipping offer.
Yes. Each active offer test uses one of Shopify's automatic discount slots. Shopify allows up to 25 active automatic discounts per store at once, shared across ABConvert and any other discounts you run. If you reach that limit, pause or close an older offer test (or another automatic discount) before launching a new one.
No. You can't change a group's offer once the test is live. You can still edit the test name, hypothesis, and traffic split. To test a different offer, close the test and start a new one.
# Experiments Overview: Choose the Right Test Type
Source: https://docs.abconvert.io/experiments/overview
Understand what all ABConvert experiments have in common, then navigate to detailed guides for each of the 9 test types.
Every ABConvert experiment follows the same workflow—create, preview, launch, analyze, close. What changes is **what you're testing**: prices, shipping rates, page templates, images, or checkout elements.
This page explains what all experiments have in common, then helps you navigate to the detailed guide for the test type you want to run.
## What every experiment includes
Regardless of which test type you choose, every ABConvert experiment shares these core components:
### 1. Hypothesis and primary metric
Before you launch, write a clear hypothesis: "Raising the price from 29 to 34 USD will increase revenue per visitor by 15%." Then select your primary metric:
* **Revenue per visitor** — Total revenue divided by total visitors (best for price and offer tests)
* **Conversion rate** — Orders divided by visitors (best for checkout and template tests)
* **Average order value** — Total revenue divided by total orders (best for upsell and bundle tests)
ABConvert tracks all metrics regardless of which you choose as primary. The primary metric determines which variant ABConvert flags as the "winner" when you reach statistical significance. See [Lifecycle](/experiments/lifecycle) for what each state means and how to preview a variant on your storefront before launch.
### 2. Test groups and traffic allocation
Define how many variants you want to test and what percentage of traffic each group receives. Most experiments start with:
* **Control (50%)** — Your current experience
* **Variant (50%)** — The change you're testing
You can add multiple variants (Control, Variant A, Variant B, Variant C) and adjust traffic splits as needed (e.g., 25% each for four groups).
### 3. Audience targeting
Control which visitors enter your experiment using filters:
* **Country** — Restrict experiments to specific markets
* **Device type** — Desktop only, mobile only, or all devices
* **UTM parameters** — Target visitors from specific campaigns, sources, or mediums
* **Visitor type** — New visitors only, returning visitors only, or all
Visitors who don't match your filters see the default experience and are not counted in experiment analytics. See [Audience Targeting](/experiments/audience-targeting) for detailed configuration instructions.
### 4. Preview mode
Before launching, use **Preview** to verify the experiment displays correctly on your storefront. Preview applies the variant to your session only—real shoppers still see the original.
Preview mode lets you:
* Walk through the buyer journey as if you were a customer
* Switch between variants to test each one
* Catch display issues, app conflicts, or tracking gaps before going live
**Always preview before launching.** Catching problems in Preview prevents polluting your experiment data with broken variants. See [Experiment Lifecycle](/experiments/lifecycle) for detailed Preview instructions.
### 5. Statistical significance tracking
ABConvert calculates statistical significance for each variant automatically. The significance indicator shows whether the difference between variants is likely real or just random noise.
Aim for:
* **100-200 conversions per variant** minimum
* **At least 2 weeks** of data to account for day-of-week variation
* **95% confidence level** before making a final decision
See [Statistical Significance](/analytics/statistical-significance) for a deep dive into how ABConvert calculates confidence and when to end an experiment.
## Detailed guides for each test type
Test different price points to maximize revenue per visitor. Supports multi-market pricing for global stores.
Compare shipping rates and delivery labels to reduce checkout abandonment.
Test discount formats—percentage off, dollar off, BOGO, free gifts—to find what drives the most revenue.
Send visitor segments to different landing pages to compare conversion performance.
Compare different Shopify page templates on the same product or collection.
Test an entirely different Shopify theme against your current one without disrupting live traffic.
Modify text, images, buttons, and links on any page using a visual editor—no code required.
Customize and test checkout UI elements, delivery options, and payment method ordering.
Stack multiple changes, like price plus shipping, into one experiment and test them as a single strategy.
## Next steps
See the complete state diagram and learn how to use Preview mode before launching.
Learn how ABConvert tracks conversions, calculates significance, and surfaces insights.
Configure filters to target specific visitor segments with country, device, and UTM rules.
# Price Test: Getting Started
Source: https://docs.abconvert.io/experiments/price-test
A/B test product prices to identify the pricing strategy that drives the best business outcome.
## What is a price test?
A price test allows you to show different product prices to different groups of visitors so you can identify the pricing strategy that drives the best business outcome, whether that is a higher conversion rate, increased average order value, or improved profit margins.
ABConvert uses Shopify Functions to apply price changes dynamically at checkout without duplicating products or modifying your product catalog. Your existing products, variants, inventory, and integrations remain fully intact.
Price tests are available on the **Growth plan** and above.
## Price test use cases
* **Increase profit margins:** Test a higher price point to see whether increased margins offset any potential drop in conversion rate.
* **Increase conversion volume:** Test lower pricing to drive more purchases, customer acquisition, or inventory sell-through.
* **Optimize psychological pricing:** Compare pricing formats like `.99` vs `.00` or round numbers vs discounted-looking prices.
* **Test premium positioning:** Validate whether a higher price improves perceived product value and customer quality.
## Theme review
If you are running a price test for the first time, you will see a modal asking you to request a theme review before launching your experiment. Our team reviews your theme to confirm it is compatible with price tests.
Theme reviews are typically completed within **1–2 business days**.
## Set up a price test
In the ABConvert dashboard, click **Create New Test** and select **Price Test**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add additional variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
Choose the products you want to include in the experiment. You can filter products by collection, product type, vendor, or tags.
![Clean Shot 2026 05 26 At 13 11 19@2x]()
Enter the prices you want to test for each variant directly in the pricing table. You can manually edit prices, use quick fill for bulk updates, or add additional markets for multi-currency pricing.
Multi-market price testing is available on the **Scale plan** and above.
![Clean Shot 2026 05 26 At 13 16 36@2x]()
Price update tips:
* Use **Quick fill** to automatically populate prices in bulk.
* Use **Upload CSV** to update variant prices faster using a CSV file.
Review your full experiment configuration, including the visitor flow and pricing setup. We recommend using **Preview test** to check your prices on the storefront before launching. When everything looks correct, click **Launch test**.
## Analyze results by product
Every price test automatically gets a [product group](/analytics/product-groups) containing its tested products. On the Analytics dashboard, open **Filters** and select the group marked **In this test** to filter results to those products and see a per-product breakdown.
## Price test FAQs
No. ABConvert uses sticky bucketing stored locally in the visitor's browser. Once a visitor is assigned to a variant group, they continue to see the same price for the duration of the experiment.
You can use **Preview test** to navigate your store as if you were assigned to a specific variant group. This allows you to confirm prices display correctly across your product pages, cart, and checkout before visitors see them.
Our team reviews your theme during the theme review process and will let you know if we identify any compatibility issues before launch. Because ABConvert uses Shopify Functions and keeps your original variants intact, price testing is compatible with most third-party apps, inventory management systems, and page builders.
Running price tests while sending traffic from Google Ads or Meta Ads can sometimes cause price mismatch warnings if ad crawlers detect a different storefront price than the price shown in the ad. We recommend either **excluding experiment products from your ad feeds or always routing ad traffic to the control group.**
No. ABConvert price tests are not compatible with subscription products.
No. You cannot update products or pricing after launching the experiment. Make sure all settings are correct before you launch.
# Shipping Test: Getting Started
Source: https://docs.abconvert.io/experiments/shipping-test
A/B test shipping rates and free shipping thresholds to find the strategy that maximizes checkout conversion.
## What is a shipping test?
A shipping test lets you offer different shipping rates, free shipping thresholds, and delivery options to different groups of visitors. This helps you identify the shipping strategy that maximizes conversion rates while protecting your profit margins.
ABConvert uses Shopify's Carrier Service API and Delivery Customization (Shopify Functions) to apply shipping rate changes dynamically at checkout without permanently altering your native Shopify shipping profiles.
Shipping tests require the **Shopify Carrier Service API**. This is available by default on Shopify Advanced and Plus plans, or by request on Annual billing plans. ([Source](https://shopify.dev/changelog/update-carrier-service-api-access-for-stores-on-starter-and-basic-plans))
## Shipping test use cases
* **Optimize free shipping thresholds:** Compare offering free shipping at \$50 vs \$75 to see which drives a higher average order value (AOV) without hurting conversion.
* **Test flat rate shipping:** See if a simplified \$5 flat rate converts better than complex calculated rates.
* **Experiment with premium shipping:** Test offering expedited delivery options to see if customers are willing to pay for faster shipping.
* **Test shipping rate names:** Validate whether naming a rate "Standard Delivery" vs "Insured Tracked Shipping" impacts checkout completion.
## Set up a shipping test
In the ABConvert dashboard, click **Create New Test** and select **Shipping Test**.
**Testing non-default shipping profiles**
ABConvert automatically adds rates to your default shipping profile. To test non-default profiles, follow the steps below to add ABConvert rates to those profiles.
1. In your Shopify admin, go to **Settings** > **Shipping and delivery**
2. Open the shipping profile you want to test
3. In the shipping zone you want to include, click **Add shipping option**
4. Set the rate type to **Carrier or app calculated**
5. Select **ABConvert Shipping**
![Clean Shot 2026 05 26 At 13 34 06@2x]()
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add more variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
Choose which Shopify shipping zones to include in the experiment. The test only applies to checkouts with shipping addresses matching the selected zones.
![Clean Shot 2026 05 26 At 13 38 00@2x]()
Configure shipping rates for each variant group. The **Control** group uses your original shipping settings by default. For each selected shipping zone, you can manage the variant group's rates:
* **Delete rate:** Remove an existing rate from the variant group.
* **Edit rate:** Update the name, description, or price of an existing rate.
* **Add rate:** Add a new shipping rate to the variant group.
![Clean Shot 2026 05 26 At 13 39 03@2x]()
Review your full experiment configuration, including the visitor flow and shipping rate changes. We recommend using **Preview test** to check your changes in the checkout before launching. When everything looks correct, click **Launch test**.
## Shipping test FAQs
No. ABConvert's shipping tests use Shopify Functions (Delivery Customization) to automatically hide your native Shopify rates and replace them with your test rates during checkout. Your original shipping profiles remain intact.
Yes. ABConvert uses sticky bucketing. Once a visitor is assigned to a variant group and a shipping rate is calculated, they will continue to see the same shipping rates for the duration of the experiment.
Yes. You can select specific shipping zones during setup, and you can also explicitly exclude specific countries from your experiment in the audience targeting step.
Yes, you can run multiple shipping tests concurrently. However, you can only have **one active test per shipping zone**. This ensures accurate data tracking and prevents conflicting rates from being shown to the same visitor.
ABConvert can only import and modify your **native Shopify shipping rates**. While our test rates can safely display *alongside* third-party calculated rates at checkout, we cannot directly modify or hide rates generated by other shipping apps or carriers.
# Template Test: Getting Started
Source: https://docs.abconvert.io/experiments/template-test
A/B test Shopify page templates to find the layout that drives the highest conversion rate.
## What is a template test?
A template test lets you assign different Shopify theme templates to different groups of visitors for the same product, collection, or page.
This is the best test type for structural layout changes, reordering Shopify sections, or testing different third-party app block placements — all built natively within the Shopify Theme Editor.
## Template test use cases
* **Test product page layouts:** Compare a traditional two-column product layout against a modern long-form storytelling template.
* **Test section order:** See if moving customer reviews and trust badges higher on the page increases your add-to-cart rate.
* **Test app block placements:** Test whether placing an upsell app above the add-to-cart button performs better than placing it below the product description.
* **Test distinct visual styles:** Test a completely different color scheme, typography, or styling for a specific promotional collection page.
## Set up a template test
Before creating a test in ABConvert, open the **Shopify Theme Editor** for your live theme. Create the alternative templates (e.g., a new product template called `product.variant-b`) and design the layout and sections for your test.
In the ABConvert dashboard, click **Create New Test** and select **Template Test**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add additional variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
Choose the specific product, collection, or page templates you want to test. You can choose from all template types: Homepage, Collections, Products, Pages, Cart, Blogs, Articles, Search.
![Clean Shot 2026 05 26 At 14 20 50@2x]()
Use **Compare variants** to preview and compare each group in desktop or mobile view.
![Clean Shot 2026 05 26 At 14 29 49@2x]()
![Clean Shot 2026 05 26 At 14 34 47@2x]()
Review your full experiment configuration. We recommend using **Preview test** to verify that the correct template variations are loading for each group before launching. When everything looks correct, click **Launch test**.
## Template test FAQs
No. You only need to create a new template within your existing active theme (for example, a new product template called `product.test`). You do not need to publish a completely separate theme.
ABConvert pulls templates from your current **live theme**. Make sure the original template exists in your live theme, not in an unpublished draft theme. If you just created the template, try refreshing the ABConvert app to sync the latest templates from Shopify.
No. ABConvert can only assign templates that exist within your currently active Shopify theme. If you want to test an entirely different theme, run a **Theme Test** instead.
**1. Create your alternate homepage template**
Shopify doesn’t allow you to add multiple homepage templates directly in the Theme Editor, but ABConvert makes it easy.
1. In ABConvert, go to **Create new test > Template test**
2. In the **Create variants** section:
* Set your current homepage template as the **original**
* Click **Create a duplicate** to generate a **variant template**
**2. Edit your alternate homepage template**
Once the variant template is created:
1. Click **Edit in Shopify** next to the variant
2. This opens the template inside Shopify’s **Theme Editor**
3. Make your design changes, then click **Save**
**3. Review and launch**
Review your settings and click **Launch test** to start your homepage test.
Currently, there is no “select template” option for the home page. Due to a Shopify’s constraint, if you end a successful template test on the homepage, you cannot directly apply the winning template.
To apply the winning design manually: open the **Theme Editor**, navigate to the **Home page**, and update the live template to match your winning variant.
**Method 1: Use advanced conditions**
This method is ideal if you’re targeting only a few specific products.
1. Create a new template test
2. Go to **Advanced settings**
3. Select the second radio button: **Yes, only include the conditions below**
4. Add a condition:
* Choose **Page URL**
* Choose **matches exactly**
* Enter the product page relative path, for example `/products/my-cool-product`
5. Repeat for each additional product page you want to include
![Screenshot 2026 05 20 At 16 49 04]()
**Method 2: Duplicate the original template**
If you want to run the test on a large group of products, adding URL conditions one by one is time-consuming. Instead, use Shopify’s template assignment to target entire product groups.
1. In your Shopify theme editor, duplicate your current product template
2. Name it something like **product-template-a**
3. Assign this duplicated template to all the products you want included in the test (for example, all lamp products)
4. In ABConvert, open your test setup and select:
* **Original template**: the duplicated **product-template-a** you just assigned
* **Variant template**: the new template you want to test
In this setup, only products using **product-template-a** will be included in the test.
No. Like a redirect test, a template test keeps your full query string, so ad tracking parameters such as `gclid` and `utm_` reach the destination page and your attribution stays correct. See [Attribution and ad tracking](/experiments/url-redirect-test#attribution-and-ad-tracking) for the details and sources.
# Theme Test: Getting Started
Source: https://docs.abconvert.io/experiments/theme-test
A/B test your entire Shopify theme to identify the design that drives the most revenue and conversions.
## What is a theme test?
A theme test lets you serve a completely different Shopify theme to a subset of your visitors while keeping your current live theme unchanged for everyone else.
This is the best test type for validating a full theme migration, comparing two distinct design directions, or measuring the revenue impact of a major redesign before committing to a full launch.
## Theme test use cases
* **Validate a new theme before launching:** Measure conversion rate, revenue per visitor, and bounce rate on your new theme against your existing one before making it live.
* **Test a complete redesign:** Compare a brand-new theme design against your current theme to quantify the business impact of the visual overhaul.
* **Benchmark theme frameworks:** Test a headless or custom-built theme against a standard Shopify theme to make a data-driven decision on infrastructure.
* **Test major UX changes:** When changes are too broad or deeply structural for a template test, a theme test gives you a clean side-by-side comparison at the theme level.
## Set up a theme test
Before creating a test in ABConvert, go to **Shopify Admin → Online Store → Themes** and add or customize the theme you want to test as a variant. Fully configure and preview it to make sure it is ready. You do not need to publish it — ABConvert will serve it to the variant group while it remains unpublished.
In the ABConvert dashboard, click **Create New Test** and select **Theme Test**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add additional variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
For the Control group, your currently published (live) theme is assigned automatically. For the Variant group, select the unpublished theme you prepared in Step 1 from the dropdown menu.
![Clean Shot 2026 05 26 At 14 39 17@2x]()
Use **Compare variants** to preview and compare each group in desktop or mobile view.
![Clean Shot 2026 05 26 At 14 46 11@2x]()
![Clean Shot 2026 05 26 At 14 43 31@2x]()
Review your full experiment configuration. We recommend using **Preview test** to verify that the correct theme is loading for each group before launching. When everything looks correct, click **Launch test**.
## Theme test FAQs
No. ABConvert serves the variant theme to assigned visitors using Shopify's built-in theme preview system, so your live store continues to display your current published theme. The variant theme can remain unpublished in your theme library for the entire duration of the test.
A template test swaps individual page templates (e.g., a product template) within your single published theme, best for testing layout changes or section reordering. A theme test swaps the entire theme, making it the right choice when your changes span many page types or involve a complete design overhaul.
Yes, as long as the theme exists in your Shopify theme library (published or unpublished), ABConvert can assign it to a variant group. Make sure the theme is saved to your library before setting up the test.
**Reason: Compatibility issues**
Theme tests split user traffic between your current live theme and the test theme to compare their performance. However, other tests are incompatible with the test theme, making it impossible to run them simultaneously with a theme test.
**What if other tests are active?**
You won’t be able to proceed with creating a theme test. When choosing test types, you can see a “ongoing test” badge next to the theme test option.
ABConvert does not edit your cart drawer directly. Instead, you test cart drawers by comparing **two Shopify themes**, each with a different cart drawer setup.
* **Theme A** uses cart drawer version A
* **Theme B** uses cart drawer version B
ABConvert splits traffic between the two themes and tracks performance.
**Steps to test your cart drawer with a theme test**
1. **Duplicate your theme** in Online store > Themes
2. **Edit the cart drawer** in your duplicated theme (add free-gift blocks, adjust upsells, etc.)
3. **Create a theme test** in ABConvert
4. **Split traffic** between your current theme and the new cart drawer setup
Yes. If you’re running a **Theme Test**, you’re free to edit the theme just like you normally would inside Shopify. Any changes you make (e.g., layout tweaks, styling updates, content edits) will apply directly to the version being tested.
**Will it affect my test?**
No, your test will continue to run as expected. ABConvert’s Theme Test simply directs visitors to different theme versions; it does **not** create copies or freeze versions. This means:
* Changes you make are live immediately on that theme
* There’s no need to pause or restart your test
* The experience remains seamless for your visitors
If you make **major structural changes**, we recommend starting a new test. This keeps your test data clean, since the testing environment is no longer consistent with when the test began.
On the theme test edit page, you can update the following:
1. Test info (name, hypothesis)
2. Traffic distribution
**What you cannot change:**
The theme itself. If you need to test another theme, you’ll need to **create a new test**.
**Best practice**: Treat each theme as its own experiment. This keeps results accurate and easy to compare.
Yes, you can achieve this using our theme tests.
Set up two themes — one with the app enabled and one without — and run a split test between them to compare performance.
No. Like a redirect test, a theme test keeps your full query string, so ad tracking parameters such as `gclid` and `utm_` reach the destination page and your attribution stays correct. See [Attribution and ad tracking](/experiments/url-redirect-test#attribution-and-ad-tracking) for the details and sources.
# URL Redirect Test: Getting Started
Source: https://docs.abconvert.io/experiments/url-redirect-test
A/B test different landing pages to identify the page design that drives the highest conversion rate.
## What is a URL redirect test?
A URL redirect test automatically sends a percentage of your visitors to an alternative URL when they land on your original page. This is the most flexible test type for comparing major structural changes or completely different landing page designs.
## URL redirect test use cases
* **Test entirely new landing pages:** Compare a long-form sales page against a short, feature-focused landing page.
* **Test promotional offers:** Send visitors to different pages featuring unique discounts or bundles to see which offer drives the highest revenue.
* **Test localized content:** Redirect visitors to different subfolders (e.g., `/products/item` vs `/uk/products/item`) to test region-specific messaging.
## Set up a URL redirect test
In the ABConvert dashboard, click **Create New Test** and select **URL Redirect Test**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add additional variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
Define the starting page for the experiment and where each visitor group will be redirected.
* **Control:** stays on the original page
* **Variant(s):** redirected to the specified destination
![Clean Shot 2026 05 26 At 13 50 37@2x]()
ABConvert **automatically suggests** pages from your store as you type. You can also use the matching options below to control how URLs are matched:
* **Exactly matches**: Only triggers on the exact URL
* **Starts with**: Triggers if the URL starts with the pattern
* **Contains**: Triggers if the URL contains the pattern
Review your full experiment configuration, including the visitor flow and redirect settings. We recommend using **Preview test** to check that the redirect is working as expected before launching. When everything looks correct, click **Launch test**.
## URL redirect test FAQs
The short answer is: URL Redirect Tests will **NOT** violate ads policy as long as you meet the platform’s requirements. In this question, we will go through the current ads policy and address potential concerns (Nov 1, 2024).
**Google Ads Policy**
Google’s [Destination requirements](https://support.google.com/adspolicy/answer/6368661?sjid=5642879325978226616-NA#672) mentions a principle called “Destination Mismatch“. You might be concerned with violating this specific ads policy when choosing to run an URL Redirect test. This will NOT be the case as long as the [display URL](https://support.google.com/google-ads/answer/2616010?sjid=12299956676139922965-NA) on your ads is the same as the final URL. Therefore, make sure you are **using the same domain in your ads and the redirected URL** to meet this requirement.
Refer to Google’s example for more details:
Display URLs give people an idea of where they'll arrive after they click an ad. The landing page that you define with a final URL tends to be more specific. For example, if your display URL is [www.example.com](http://www.example.com), your final URL might be example.com/sweaters.
**Facebook Ads Policy**
In Facebook’s “[About Meta’s Unacceptable Business Practices advertising policy](https://www.facebook.com/business/help/2895682587380674?id=434838534925385)”, it is only mentioned that your ad’s landing page should be functioning properly and the content is relevant to your ad. Therefore, URL Redirect Tests will **NOT** cause a problem with your Facebook ads. While Facebook does not have a clear requirement for URL destination, refer to [About destination links in your ad](https://www.facebook.com/business/help/152143699744690) to learn more about Facebook’s definitions:
The display URL allows you to show a shortened link instead of your full website URL to make it easier for viewers to recognize the website. The link goes to the same domain as your website URL.
According to the above, you can also double check if you have the same display URL on your ad as the final URL to be on the safe side.
No. ABConvert URL redirect tests only work within your primary Shopify store domain. Redirecting to external domains or subdomains (e.g., `mystore.uk.shopify.com`) is not supported because we cannot track sessions or conversions across domains. If you want to test localized pages, use subfolders (e.g., `mystore.com/uk/`) instead.
The most common reason a URL redirect test fails to trigger is an incorrect trigger condition setup. If you are targeting a specific page, make sure to use "**Exactly matches**" instead of "Contains".
## Attribution and ad tracking
A redirect test changes the URL a visitor lands on, so a common worry is whether it breaks paid ad attribution. It does not, because the redirect keeps your ad tracking parameters intact.
No. The redirect keeps your full query string, so the tracking parameters on the original ad link reach the destination page.
Google Ads attributes a click from the URL, not from the referring site. Auto-tagging adds a [Google Click Identifier (`gclid`) to the ad URL, which maps the ad click to a row in your report](https://developers.google.com/google-ads/api/docs/reporting/valuetrack-mapping). GA4 captures the full page URL, which [defaults to `document.location`](https://developers.google.com/analytics/devguides/collection/ga4/reference/config) and so includes the `gclid` along with any `utm_` campaign tags. Because the redirect preserves the query string, those values arrive on the destination page intact, so the ad click stays tied to your campaign.
All of them. The redirect carries over your existing query string, including `utm_source`, `utm_medium`, `utm_campaign`, the Google Ads click ID (`gclid`) and its `gbraid`/`wbraid` variants, and the Facebook click ID (`fbclid`). It only appends ABConvert's own markers on top, so nothing is stripped from the destination URL that your analytics and ad tools read.
# Visual Editor Test: Getting Started
Source: https://docs.abconvert.io/experiments/visual-editor-test
A/B test storefront content like headlines, images, and buttons to improve conversion rate without touching theme code.
## What is a visual editor test?
A visual editor test allows you to create A/B tests directly on your Shopify storefront without touching theme code. Using the built-in visual editor, you can modify text, images, buttons, links, and page elements for different visitor groups.
This helps you validate design and messaging changes before permanently updating your store. Visual editor tests are ideal for testing conversion-focused improvements quickly while keeping your original theme intact.
## Visual editor test use cases
* **Test homepage headlines:** Compare different messaging to improve conversion rate.
* **Experiment with CTA buttons:** Test button text, links, or placement.
* **Validate product page layouts:** Hide or reorder sections to improve engagement.
* **Test promotional banners or images:** Compare creative assets during campaigns or seasonal promotions.
## Set up a visual editor test
In the ABConvert dashboard, click **Create New Test** and select **Visual Editor Test**.
Enter a descriptive name for your experiment, write a clear hypothesis, and select your primary success metric. By default, traffic is split evenly between the Control and Variant groups. You can adjust the traffic allocation or add additional variants.
Define which visitors should enter the experiment using audience targeting and traffic allocation rules. Read more in the [Audience targeting](/experiments/audience-targeting) guide.
In Step 3 of the setup wizard, click the **Edit** button with the pencil icon to open the visual editor.
![Clean Shot 2026 05 26 At 14 47 53@2x]()
Update your variant in the visual editor, see the section Using the visual editor for more detailed guide.
Review your full experiment configuration, including the visitor flow and visual changes. We recommend using **Preview test** to check your changes on the storefront before launching. When everything looks correct, click **Launch test**.
## Using the visual editor
### The top bar
At the top of the editor, you will see several controls. From left to right:
1. **Variant switcher:** Switch between the **Control** and different variant groups
2. **URL bar:** Type a URL to navigate to another page within your store
3. **Select element button:** Turn this on to activate **Select mode**
* When enabled, you can click elements and edit them
* When disabled, you can browse your store normally
4. **Device switcher:** Preview your store on desktop, tablet, or mobile screen sizes
5. **Save button:** Click **Save** to keep your changes
![Clean Shot 2026 05 26 At 14 58 39@2x]()
### Edit elements in select mode
When **Select mode** is active:
* Move your cursor over the page
* Elements will be outlined as you hover
* Click an element to select it
![Clean Shot 2026 05 26 At 15 00 21@2x]()
After selecting an element, **right-click** to see editing options:
* **Edit**: Depending on the element type, you can:
* Edit text: Update the text in the input field, then click Save
* Change link: Enter a new URL for buttons or linked text
* Change image: Choose an image from your library, upload a new one, or paste an image URL
* **Move up** or **move down**
* Reorder the element within the same hierarchy level
* For example, move a product card to the first position in a grid
Note: You can only reorder elements within the same parent container
* **Hide element**
* Hide the selected element from the page without deleting it in Shopify
* **Select parent**
* Quickly jump to the parent container if you need to edit a larger section
![Clean Shot 2026 05 26 At 15 01 33@2x]()
### The right-side panel
When an element is selected, the right panel gives you more controls.
* **Properties**:
* View the element tree structure
* Note: You can see up to three levels above the selected element
* **Edit options**: You will see the same editing options here, this is useful if you prefer using the side panel instead of right-clicking
* Edit text
* Change link
* Change image
* **Custom code**
* Click **Add code** to insert custom **CSS** or **JavaScript**
* This applies at the **site level,** not just one page. Use this for advanced customizations
* **Changes**
* This section shows all edits made in each variant group
* Click the **trash icon** to remove a specific change
![Clean Shot 2026 05 26 At 15 19 52@2x]()
For each change, you can click the **edit icon** to get more control over where the change appears in your store.
![Clean Shot 2026 05 26 At 15 14 47@2x]()
## Visual editor test FAQs
No. The visual editor is designed for non-technical Shopify merchants. Most changes can be made directly through the editor interface without touching code.
Yes. You can preview your storefront on desktop, tablet, and mobile devices while building your experiment.
No. Your original Shopify theme files remain unchanged.
Yes. You can add custom CSS or JavaScript using the Custom code section in the right-side panel.
Yes. The Changes panel shows all edits made in the current variant. You can remove individual changes at any time before launch.
The visual editor works with most standard Shopify themes. However, there are a few things to keep in mind:
* **Dynamically rendered elements** (e.g., content loaded via JavaScript after page load) may not be selectable or editable.
* **Third-party app elements** may have limited editability depending on how they are rendered.
# Frequently Asked Questions — ABConvert
Source: https://docs.abconvert.io/help/faq
Answers to the most common questions about ABConvert: how experiments work, plan requirements, traffic splitting, order attribution, and multi-market testing.
ABConvert is built for Shopify merchants who want to make data-driven decisions about pricing, content, shipping, and more. This page answers the questions that come up most often. If you don't find what you're looking for here, reach out to support — contact details are at the bottom of this page.
ABConvert is a Shopify app that lets you run A/B experiments on your store — testing different prices, themes, templates, shipping options, checkout layouts, and URL redirects — and measures which variant converts better.
When a visitor lands on your store, ABConvert assigns them to a test group using a seeded random algorithm. That assignment is stored in the visitor's browser (via localStorage) and in their cart attributes, so they see a consistent experience throughout their session. As they browse, add to cart, check out, and purchase, ABConvert tracks each step using a Shopify web pixel. Your analytics dashboard then shows conversion rates, revenue, and statistical results for each group.
Experiments run directly on your live store. No redirects to separate domains, no iframes — just a lightweight script that modifies what the visitor sees.
ABConvert works on all Shopify plans, but some experiment types require specific Shopify subscriptions:
* Shipping test: Requires Shopify Grow+ for Carrier Service API
* Checkout UI test: Require**s** Shopify Plus
ABConvert is compatible with most Shopify themes, including Online Store 2.0 themes and legacy themes. The app uses an embed app in your theme that targets standard Shopify DOM elements (product forms, price selectors, variant inputs).
If you're on a theme with heavy customizations and find the test not loading well on your theme, contact support.
Currently, ABConvert does not support Shopify headless stores.
When you create an experiment, you define test groups and assign a percentage of traffic to each. For example, you might send 50% of visitors to the control group and 50% to a variant, or split traffic three ways at 33%/33%/34%.
Each visitor is assigned to a group using a seeded random hash. The seed is derived from a visitor identifier so that the same visitor consistently lands in the same group throughout their session — and on return visits, as long as their localStorage hasn't been cleared.
You can also restrict which visitors enter the experiment using filters. Visitors who don't match your filters see the default experience and are not counted in experiment analytics.
Yes. ABConvert supports concurrent experiments. Each experiment tracks its own visitors, conversions, and revenue independently.
There are a few things to keep in mind when running experiments simultaneously:
* If two experiments target the same product, a visitor may be assigned to both. Each experiment maintains its own assignment independently.
* You cannot run more than 1 active test on the same product in price test, or on the same shipping profile in shipping test.
* Running many experiments at once will divide your traffic, which means each individual experiment collects data more slowly. Fewer daily visitors per group means it takes longer to reach statistical significance.
There is no universal answer — it depends on your traffic volume and the size of the effect you're trying to detect. As a practical guideline:
* Run experiments for **at least two full weeks** to account for day-of-week variation in shopper behavior.
* Aim for a minimum of **100–200 conversions per group** before drawing conclusions. With fewer conversions, results are unlikely to be statistically reliable.
* Avoid stopping an experiment the moment you see a positive result. Early "wins" often revert as more data comes in — a pattern called "peeking."
If your store has low traffic, a test that would take weeks to complete may not be worth running. In that case, focus on larger, more impactful changes where even a small sample can show a meaningful difference.
ABConvert does not create separate URLs or pages for test variants, so there is no risk of duplicate content penalties from running experiments.
For price tests, the price change is applied to the visitor's session only — search engine crawlers see your original prices. For theme and template tests, crawlers typically receive the default variant since they do not execute JavaScript in the same way a browser does.
ABConvert adds one lightweight script to your storefront. It loads alongside your theme and your other apps, and runs only the logic needed to assign each shopper to their test group and show them the right variant.
The speed impact of any single app is small and hard to measure on its own. Most Shopify stores run many apps at once — analytics, reviews, upsells, chat widgets — and they all share the same page. When a page feels slow, it's usually the combined weight of everything loading together, which makes it hard to point to one app as the cause.
That's why we recommend you preview every test before you launch it. Preview shows your variant on your live storefront, scoped to your own session, so you can walk through your store exactly as a shopper would and confirm pages look right and load the way you expect — before a single real visitor enters the test.
Preview before every launch. See [Preview before you launch](/experiments/lifecycle#preview-before-you-launch) for the full walkthrough.
ABConvert uses two complementary methods to attribute orders to experiments:
1. **Web pixel** — A Shopify web pixel tracks `page_viewed`, `product_added_to_cart`, `checkout_started`, and `checkout_completed` events in real time. The pixel reads the visitor's experiment assignment from cart attributes and sends conversion events to ABConvert's analytics backend.
2. **Cart attributes** — When a visitor is assigned to an experiment group, ABConvert writes a `groupInfo` attribute to their Shopify cart. This attribute follows the cart through the entire checkout flow, which is how orders are connected to the correct experiment and test group even when a visitor completes checkout in a different browser session.
Both methods work together. If the web pixel fires successfully at checkout completion, the order is recorded via the pixel. The cart attributes provide a fallback and are used for order webhook processing.
If your analytics show 0 views or conversions, the web pixel may not be installed correctly. Go to **Settings** in ABConvert and check the web pixel status. You may need to reinstall it.
Yes. ABConvert supports audience filtering at the experiment level, so you can limit which visitors are included in an experiment.
Visitors who do not meet your filter criteria are excluded from the experiment and see the default experience. They are not counted in your experiment's analytics.
For multi-market stores using Shopify Markets, you can also configure per-country price variants in a price test, so each market sees prices in their local currency.
**When you pause an experiment:**
ABConvert removes the active Shopify resources (scripts, metafields, extensions) that power the experiment. Visitors who were mid-session and had been assigned to a test group will revert to seeing the default experience — they are no longer in the experiment. All data collected up to the pause point is preserved, and you can resume the experiment later.
**When you end an experiment:**
Ending an experiment permanently closes it. ABConvert cleans up all Shopify resources, including duplicated variants for V1 price tests. Any visitor mid-session at the moment you end the experiment will revert to the default experience immediately. The experiment data is preserved for analysis, but the experiment cannot be restarted — you would need to create a new one.
**What about orders placed mid-transition?**
Orders placed in the brief window during a pause or end operation may not be attributed to the correct experiment group. This is an inherent limitation of the async nature of Shopify API operations. For best results, avoid pausing or ending experiments during peak traffic hours.
Yes, with some nuances depending on the experiment type.
For price tests, ABConvert supports multi-market pricing for **Scale+ plan**. When you create a price test, you can configure test prices per country and currency, stored in a market price map. When a visitor lands on your store, ABConvert detects their country from Shopify's market context and applies the correct localized price for their test group.
For other experiment types (theme, template, content, checkout, URL redirect, shipping), the experiment applies to all visitors regardless of market by default. You can use country filters to restrict an experiment to specific markets if needed.
# Troubleshooting Common ABConvert Issues
Source: https://docs.abconvert.io/help/troubleshooting
Step-by-step guides for the most common problems when running and analyzing your experiments
## Analytics showing 0 views or conversions
Your experiment is running but the analytics dashboard shows no data, or data stopped recording partway through.
Go to your analytics page and select the **Test Settings** tab. In the **Test Details** section, look for a green healthy label indicating the test is running properly.
![Screenshot 2026 04 28 At 17 09 06]( "Screenshot 2026 04 28 At 17 09 06")
Analytics data processes with a delay. Our system caches data to maintain fast dashboard performance, so new events can take up to 10–15 minutes to appear. If you just launched your experiment, wait at least 1–2 hours for meaningful traffic before checking results.
Analytics only populate when real visitors interact with your experiment. Confirm that:
* Your store is receiving traffic to the experiment page
* Your audience targeting rules are configured correctly
Open your store in an incognito or private window to bypass Shopify's cache. Trigger a page view or add an item to your cart, then click **Refresh** on your dashboard to see updated data.
***
## Test variant not showing on live store
The active test variant is failing to display for visitors on the live storefront.
Go to your analytics page and select the **Test Settings** tab. In the **Test Details** section, look for a green healthy label indicating the test is running properly.
![Screenshot 2026 04 28 At 17 09 06]( "Screenshot 2026 04 28 At 17 09 06")
With a 50/50 traffic split, you may randomly see the original page. Instead of guessing, use the preview links in your ABConvert dashboard's **Test Settings** tab. These links bypass the traffic split and force the variant to load, letting you confirm it's working.
Once you visit your store, our system assigns you to a variant and keeps showing you that version. To properly QA your test, always use a fresh incognito window so previous assignments don't interfere.
Use **Preview Mode** before going live
We recommend testing your variant in preview mode before launching the test live. This ensures everything works as expected without affecting real traffic.
![Image 1]()
***
## Price not updating correctly in the store
Visitors are seeing the original price instead of the test price, or prices are displaying incorrectly across different pages or after adding items to the cart.
Go to your analytics page and select the **Test Settings** tab. In the **Test Details** section, look for a green healthy label indicating the test is running properly.
![Screenshot 2026 04 28 At 17 09 06]( "Screenshot 2026 04 28 At 17 09 06")
Open the experiment and verify that the product you're testing is listed under the experiment's products. If it isn't, the script won't update prices on that product's page.
When you first start a price test, our team reviews your theme to ensure compatibility with our price tests. If you've recently updated your theme, this may prevent prices from updating correctly. Contact support to request a new theme review.
***
## Shipping rates are not showing correctly in checkout
Visitors are seeing the original shipping rates instead of the expected test rates, or shipping costs are displaying incorrectly during the checkout process.
To enable shipping tests, add ABConvert shipping rates to your target zones.
1. Go to **Shipping and delivery settings** > **General profile**
2. Select your zone, click **Add shipping option**
3. Choose **Carrier or app calculated**, select **ABConvert**, and click **Done**.
![Screenshot 2026 04 29 At 10 43 16]( "Screenshot 2026 04 29 At 10 43 16")
Verify the **ABConvert Shipping V2** app embed is enabled in your live theme before running shipping tests. This embed is required for the shipping script to calculate and display test rates correctly.
![Screenshot 2026 04 29 At 10 47 42]( "Screenshot 2026 04 29 At 10 47 42")
Shipping tests are zone-aware and only display test rates for visitors in your targeted shipping zone. If you're testing from a different location, use a VPN to match your target zone during QA to see accurate test rates.
If shipping rates calculate incorrectly when **discount codes are applied at checkout**, it's because our script cannot run on Shopify's checkout page due to platform limitations. Manually entered discount codes won't be recognized by our shipping script.
![Image]( "Image")
To fix this, **apply discounts automatically before checkout** using Shopify's automatic discount settings. This ensures the shipping script calculates rates correctly with discounts included.
If you work through the steps above and still can't resolve the issue, contact support based on your plan:
* **Starter plan** — self-serve documentation
* **Growth plan** — email support (response within 24–48 hours)
* **Scale plan** — priority email + live chat (response within 12–24 hours)
* **Pro and Unlimited plans** — dedicated Slack channel and scheduled calls
# ABConvert: Shopify A/B Testing Built for Revenue Growth
Source: https://docs.abconvert.io/introduction
A/B test prices, shipping, checkout, and content on Shopify. Make data-driven decisions with full-funnel analytics and statistical confidence.
Should you raise your price from \$29 to \$34? Would free shipping actually increase revenue or eat your margins? Which checkout upsell drives the most incremental revenue?
High-growth Shopify Plus brands don't guess—they test. ABConvert is the revenue optimization platform built specifically for Shopify merchants who need to make data-driven pricing, checkout, and merchandising decisions at scale.
**ABConvert combines AI-powered experimentation with native Shopify capabilities to help you optimize every revenue touchpoint**—from dynamic pricing and shipping strategies to checkout customizations and product merchandising. Run sophisticated experiments without developers, get AI-driven insights within hours, and scale your testing program as you grow from \$1M to \$100M+ ARR.
## What you can test
ABConvert supports **8 experiment types**, covering the parts of your store that matter most to conversion and revenue. Each test type follows the same workflow—you just change what you're testing.
Use when you want to optimize pricing strategy, test premium positioning, or validate whether a price increase will hurt conversions.
Use when you're unsure whether "free shipping" outperforms "flat-rate shipping," or want to test expedited delivery options.
Use when you want to find the discount format that drives the most purchases while preserving profitability.
Use when you're running paid ads and want to optimize landing page performance, or testing different homepage layouts.
Use when you have multiple page templates and want to know which design drives more purchases.
Use when you're considering a theme redesign and want to validate it increases conversions before fully committing.
Use when you want to test product images, headlines, CTAs, or page copy without generating duplicates.
Use when you want to test checkout upsells, trust badges, or different payment method ordering.
***
## How ABConvert works
ABConvert is built natively on Shopify's platform-—works best with your Shopify store and no complicated integration needed.
### The experiment flow
When a visitor lands on your store, ABConvert assigns them to a test group using a seeded random algorithm. The assignment is stored in their browser and cart attributes, ensuring they see a consistent experience throughout their session.
ABConvert checks each experiment's traffic allocation and audience filter, and delivers the corresponding variant of the assigned group—a different price, product image, shipping rate, or page template.
As the visitor browses, adds to cart, reaches checkout, and completes their purchase, ABConvert tracks every step using a Shopify web pixel.
Your analytics dashboard updates in real-time with conversion rates, revenue metrics, and breakdown dimnsions for each test group. When you have a winner, apply it to your store and end the experiment.
### What makes ABConvert different
**1. Native Shopify integration**
ABConvert uses Shopify Functions for price and shipping tests, web pixels for tracking, and app embeds for content modifications. This means:
* No duplicate products cluttering your catalog (for price tests on Growth plan and above)
* No external scripts slowing your page load
* Full compatibility with Shopify's checkout, cart, and discount systems
* Seamless integration with Shopify Markets for multi-currency pricing
**2. No developer required**
Install from the Shopify App Store like any other app. No theme code edits, no Liquid modifications, no custom checkout scripts. The app automatically installs tracking and experiment infrastructure when you activate it.
**3. Full-funnel analytics**
ABConvert doesn't just track clicks or page views—it tracks the complete purchase journey from product view through order completion. You see exactly where each variant wins or loses: add-to-cart rate, checkout initiation, checkout completion, revenue per visitor, and statistical significance.
**4. Accurate attribution**
Visitor assignments persist across sessions using localStorage and cart attributes. If a visitor abandons their cart and returns three days later to complete the purchase, ABConvert still attributes the order to the correct test group.
***
## Start testing in 15 minutes
Install ABConvert, complete survey, and launch your first experiment right away.
See detailed guides for all 8 test types.
Learn how ABConvert tracks conversions, calculates statistical significance, and surfaces insights.
# Connect ABConvert as a Claude.ai custom connector
Source: https://docs.abconvert.io/mcp/claude-connector
Generate OAuth credentials and add ABConvert to Claude.ai web, desktop, or mobile.
Claude.ai custom connectors authenticate with OAuth, so you paste a Client ID and Secret instead of a token header.
Available where the **Claude / MCP Access** settings appear. Requires the MCP surface to be enabled for your store — see [Overview](/mcp/overview).
## When to use it
* You use **Claude.ai on the web, desktop, or mobile** and want to drive ABConvert from chat.
* You want ABConvert to appear as a first-class connector with a consent screen, not a pasted header.
* You manage one store per set of credentials and want to revoke access per connector.
## When NOT to use it
* You use **Claude Code** or **Codex CLI** — those accept a token directly. Use the [Quickstart](/mcp/quickstart) and pass your `abc_` token as a header (`--header` in Claude Code, `bearer_token_env_var` in Codex). The Claude.ai / Claude Desktop connector UI is the only surface that needs OAuth.
## How it works
You generate an OAuth client bound to your store. When you add the connector, Claude discovers ABConvert's authorization server, opens a consent screen, and receives an access token scoped to your store. The token is the same `abc_` token used elsewhere, so revoking it in Settings cuts access immediately.
1. You generate a Client ID and Secret in ABConvert.
2. You paste the MCP URL and credentials into Claude.
3. Claude runs the OAuth flow (Authorization Code with PKCE) and shows a consent screen.
4. You approve; Claude stores the token and lists the ABConvert tools.
## Setup
In your Shopify admin, open ABConvert and go to **Settings → Claude / MCP Access**. In the **Claude connector credentials** card, click **Generate credentials** and give it a name (for example, "Claude — Acme store").
You'll see three values: the **Remote MCP server URL**, the **OAuth Client ID**, and the **OAuth Client Secret**. Copy all three now — the secret is shown once.
Treat the Client Secret like a password. Anyone who has it can obtain an access token for your store. Don't paste it into shared chats or commit it to a repo.
In Claude, go to **Settings → Connectors → Add custom connector**.
* **Name**: `ABConvert`
* **Remote MCP server URL**: `https://mcp.abconvert.io/mcp`
Expand **Advanced settings** and paste:
* **OAuth Client ID**: the `abcmcp_live_…` value
* **OAuth Client Secret**: the secret you copied
Click **Add**.
Claude opens a consent page showing which store it's connecting to. Confirm the store domain is yours and click **Approve**. Claude finishes the connection and lists the ABConvert tools.
Ask Claude to work with your tests:
> "List my active ABConvert experiments and summarize the results of the top one."
## Common mistakes
* **Pasting a token into the Client ID field.** The connector fields are an OAuth *client* identity, not the `abc_` access token. Generate credentials from the **Claude connector credentials** card, not the **Access tokens** card.
* **Approving a consent screen for the wrong store.** The consent page names the store the credentials belong to. If it isn't yours, cancel and regenerate credentials from the correct store's admin.
* **Losing the secret.** It's shown once. If you didn't copy it, revoke the connector and generate a new one.
* **Expecting Claude Code to use these fields.** Claude Code and Codex use a token header instead — see the [Quickstart](/mcp/quickstart).
## FAQ
Open **Settings → Claude / MCP Access**, find the connector in the list, and revoke it. Any access token issued through it stops working immediately.
Access tokens are long-lived and stay valid until you revoke the connector. Revoke from Settings to cut access.
Yes. Generate a separate set of credentials from each store's admin and add each as its own connector in Claude.
Not yet — Codex's OAuth requires Dynamic Client Registration, which this connector doesn't offer. Connect Codex with a token instead (`bearer_token_env_var` in `config.toml`). See the [Quickstart](/mcp/quickstart).
# Drive ABConvert from Claude with MCP
Source: https://docs.abconvert.io/mcp/overview
Run A/B tests by talking to Claude in plain English. ABConvert's Model Context Protocol (MCP) integration lets Claude Desktop, Claude Code, and other AI assistants create, launch, analyze, and end experiments without leaving the chat.
The MCP integration is in **beta**. Reach out to support to opt in.
ABConvert exposes a Model Context Protocol (MCP) server that turns Claude (or any MCP-aware AI assistant) into a working interface for your A/B testing program. Instead of opening the dashboard, picking a test type, filling out a wizard, and clicking through five screens to launch — you describe what you want in plain language and Claude does the rest.
## What you can do
```
You: Test 10% off the snowboards collection for US mobile visitors
Claude: I'll set this up. Hypothesis: "10% discount lifts revenue per visitor among
US mobile shoppers", goal: revenue per visitor, 50/50 split, 100% traffic,
audience: US visitors on mobile. I'll save it as a draft so you can review.
Tweak any of these or say "create it" to proceed.
You: create it
Claude: Draft created. Want me to launch now or generate a preview link first?
```
That's a real session. Claude resolves "the snowboards collection" to the right Shopify GID, picks sensible defaults, asks for confirmation, and creates the test on your store.
## Why use it
For tests you've run before, going from idea to draft is one paragraph instead of clicking through six screens.
Ask Claude "how is my hoodie price test doing" — get the metrics, the breakdown by device, the cross-test comparison. No dashboard navigation.
Anyone on your team with the ABConvert MCP token can drive tests from their preferred AI assistant. Same surface across Claude Desktop, Claude Code, OpenClaw, Fin.
All the power of an API without writing any code yourself — Claude does the API calls, you supervise.
## When NOT to use it
MCP is great for:
* **Repeating tests** you've run before with small variations ("same as last week but for the Hydrogen instead of Oxygen")
* **Querying analytics** without context-switching to the dashboard
* **Bulk lifecycle work** (pause five tests, end three others, start a draft) in one chat
The wizard is still the right tool for:
* **First-time test design** where you want visual guidance and live previews of what the variant will look like
* **Complex audience targeting setups** that benefit from the visual filter builder
* **Visual editor tests** (DOM mutations) — those need a real click-to-record interface; MCP doesn't help here
## What's supported
Create, preview, launch, end. Resolve products by name. Apply percentage or fixed-amount changes.
Modify rates, hide rates, add new rates per zone. Auto-preserves untouched rates.
Compare two themes by GID. Resolve theme names from Claude.
Test alternate Liquid templates per type (product, index, collection, page).
Send traffic to different landing pages. Resolve URLs from natural language.
Build discount variants — product, order, shipping, volume, or threshold — against a no-offer control.
Hide, rename, or reorder delivery and payment methods, or add checkout UI blocks. Plus-only.
Query results, breakdowns by device/country, cross-test comparison.
Visual editor tests aren't yet exposed via MCP — use the wizard for those.
## How it works
You mint an API token from ABConvert's settings. You paste it into your AI assistant's MCP config. Your AI assistant then talks to `https://mcp.abconvert.io/mcp` over HTTPS using that token. The MCP server validates the token, scopes everything to your shop, and forwards the work to ABConvert's backend — the same backend the wizard uses.
MCP is currently available on the **Growth plan** and above. [Pricing →](/configuration/pricing-plans)
## Next steps
Step-by-step setup for Claude Desktop and Claude Code.
The full list of operations Claude can perform on your behalf.
# Connect Claude to ABConvert in 5 minutes
Source: https://docs.abconvert.io/mcp/quickstart
Connect your AI assistant — OAuth connector credentials for Claude Desktop and Claude.ai, an API token for Claude Code and other clients — and run your first test prompt in five minutes.
By the end of this guide you'll have your AI assistant connected to ABConvert and a real draft test created from a single prompt.
Using **Claude Desktop or Claude.ai**? Skip this step — they connect with OAuth connector credentials you'll generate in step 2. The token below is for Claude Code and other header-based clients.
Open ABConvert in your Shopify admin. Go to **Settings → Claude / MCP Access** and click **Generate token**.
Give the token a name that identifies which app will use it (e.g. "Claude Code" or "Jeff's laptop") — when you revoke a token later, the name is how you'll know which one to kill without disrupting other integrations.
Copy the token. It starts with `abc_` and you can only view it once — paste it somewhere safe immediately.
Treat the token like a password. Anyone who has it can create, modify, and delete tests on your store. Don't paste it in shared chats or commit it to a repo.
Pick the assistant you use:
Claude Desktop connects through a custom connector with OAuth — no config file, no token header. The same flow works on Claude.ai web and mobile.
1. In ABConvert, go to **Settings → Claude / MCP Access**. In the **Claude connector credentials** card, click **Generate credentials** and give it a name. Copy all three values — the client secret is shown once.
![The Generate connector credentials modal showing the remote MCP server URL, an OAuth client ID, and an OAuth client secret, each with a copy button.]()
2. In Claude, go to **Settings → Connectors → Add custom connector**. Name it `ABConvert` and paste the **Remote MCP server URL** (`https://mcp.abconvert.io/mcp`).
3. Expand **Advanced settings**, paste the **OAuth Client ID** and **OAuth Client Secret**, and click **Add**.
4. Approve the consent screen. Check that the store domain it names is yours.
Claude lists the ABConvert tools as soon as the connector is added — no restart needed.
See [Claude.ai connector](/mcp/claude-connector) for common mistakes and how to revoke access.
Run one command:
```sh theme={null}
claude mcp add --transport http abconvert https://mcp.abconvert.io/mcp \
--header "Authorization: Bearer abc_your_token_here"
```
That's it. The next chat session will have the ABConvert tools available.
Verify it's connected:
```sh theme={null}
claude mcp list
# Should show: abconvert (http) — Connected
```
Most MCP-aware clients accept an HTTP transport URL plus an Authorization header. Use:
* **URL:** `https://mcp.abconvert.io/mcp`
* **Header:** `Authorization: Bearer abc_your_token_here`
Refer to your client's MCP setup docs for the exact config format.
Open a new chat and type:
> "Use the ABConvert ping tool"
You should see Claude call `ping` and respond with `{ ok: true }`. If you see a 401, your credential is wrong or revoked — re-mint the token (or regenerate connector credentials and re-add the connector) and try again. If you see "MCP is not enabled for this shop," ask ABConvert support to flip the `enable-mcp` feature flag for you.
Try one of these:
> "Test 10% off my best-selling product"
> "Test free shipping over \$50 for US visitors"
> "How is my snowboard price test doing?"
> "Send 50% of /products/old-hoodie traffic to /products/new-hoodie"
Claude will ask for a hypothesis, primary metric, and traffic split before creating anything. Once you confirm, the test lands in your dashboard as a **draft** — you can review, then launch from the dashboard or by saying "launch it" in the chat.
Tests default to draft for safety. To skip the draft step, say something explicit like "launch it immediately" or "go live now" in your prompt.
## You're done
That's the full setup. Everything else is just exploration — see [What you can do](/mcp/tools) for the full surface.
## Token management
* **One token per app.** Mint a separate token for Claude Code, OpenClaw, and every other header-based client. When you replace your laptop or stop using one tool, you can revoke just that token without breaking the others.
* **Connector credentials are separate.** Claude Desktop and Claude.ai authenticate with OAuth connector credentials, not tokens. Revoke them from the same **Settings → Claude / MCP Access** page.
* **Revoke at any time.** Settings → Claude / MCP Access → Revoke. Takes effect within seconds — the next call from that token returns 401.
* **Tokens are shop-scoped.** A token you mint for Shop A cannot be used to access Shop B, even if the same person owns both.
See [Security & token management](/mcp/security) for the full guide.
# Security & token management
Source: https://docs.abconvert.io/mcp/security
How tokens work, how to manage them safely, and what's protected by default.
## Token model
A token is a single-shop, single-purpose credential. It looks like `abc_1lRrF_CdEOYbg6xCP6FFoiFnOcp05s8E`.
Mint a separate token for each integration: Claude Code, your team's automation, etc. Revoking one doesn't break the others. (Claude Desktop and Claude.ai use [connector credentials](/mcp/claude-connector) instead, managed from the same page.)
A token you mint for Shop A can never access Shop B's data — even if you own both.
Tokens stay valid until you revoke them. There's no automatic rotation. We may add expiration in a future update.
Settings → Claude / MCP Access → Revoke. Takes effect within one request — the next call from that token returns 401.
## Treat tokens like passwords
If someone has your token, they can do anything you can do via MCP — create tests, modify rates, end experiments. The same goes for a [connector client secret](/mcp/claude-connector): treat both like passwords.
**Don't:**
* Paste tokens in shared Slack channels, GitHub issues, or screenshots
* Commit tokens to a repo (even a private one)
* Email tokens in plaintext
* Store tokens in a shared 1Password vault unless your team genuinely needs shared access
**Do:**
* Mint a personal token for each team member, not a shared one
* Name tokens descriptively ("Claude Code — Jeff", not "token1")
* Revoke tokens you stop using immediately
* Set a recurring reminder to audit your token list quarterly
## What protects you by default
Even if a token leaks, several layers limit blast radius:
**1. Per-shop feature flag.** MCP is opt-in per shop. If your shop has the flag off, even a valid token can't do anything.
**2. Rate limit.** 200 requests per minute per token, server-enforced. A leaked token can't be used to hammer the API or run an unbounded loop.
**3. Token kill switch.** Revoke from Settings → Claude / MCP Access. Effective within one request. Don't wait — the moment you suspect a token is compromised, kill it.
**4. Resource overlap protection.** Even with a leaked token, an attacker can't launch a price test on a product that already has an active price test running. Same for shipping zones, themes, templates, and redirect URLs.
**5. Backend audit trail.** Every API call is logged with the token ID, timestamp, and outcome. Contact support if you need to investigate suspicious activity.
## Auditing token usage
Today, the in-app audit view is read-only and shows:
* Token name + when it was created
* Last successful use timestamp
* Whether it's currently active or revoked
A more granular activity log (which tools were called, when, by which client) is on the roadmap. If you need it sooner, contact support — we can pull logs server-side on request.
## When to rotate
Rotate (revoke + mint a new one) when:
* A team member leaves
* You change laptops
* You suspect any leakage (committed to git by accident, pasted in a public chat, lost a device)
* Quarterly as part of a routine audit — minimal effort, maximum hygiene
## What's NOT covered yet
These are on the roadmap:
* **OAuth for every client.** Claude.ai and Claude Desktop already connect through an [OAuth custom connector](/mcp/claude-connector). Other clients still require a manually pasted token; broader OAuth support (e.g. Dynamic Client Registration for Codex) is on the roadmap.
* **Per-token scopes.** Today, every token has full access. Future tokens will let you create read-only or scope-limited tokens for safer sharing.
* **Per-IP allowlist.** Lock a token to specific IP ranges (e.g. your office) for extra defense.
If any of these would change your decision to use MCP, let support know — that's how we prioritize.
## Reporting a suspected leak
If you think a token has been compromised:
1. **Revoke it immediately** — Settings → Claude / MCP Access → Revoke. Don't wait.
2. **Check the audit timestamps** — was the token used recently from somewhere unexpected?
3. **Email [security@abconvert.io](mailto:security@abconvert.io)** with the token's name and approximate compromise window. We'll pull server-side logs and confirm whether anything unusual happened.
The fastest mitigation is always step 1. Don't delay revocation while you investigate.
# What Claude can do for you
Source: https://docs.abconvert.io/mcp/tools
Every operation Claude can perform on your behalf, grouped by intent. You don't need to memorize tool names — Claude picks them based on what you ask.
Claude has access to 30 ABConvert tools. You don't call them by name — you describe what you want in natural language, and Claude picks the right one (or chains several together). This page lists what's possible so you know what to ask for.
## Discover & resolve
These tools translate names you'd say in English into the IDs that ABConvert needs internally. You almost never trigger these directly — Claude calls them automatically when you mention a product, page, theme, etc.
| What you say | What Claude does |
| -------------------------------- | --------------------------------------------------------------- |
| "the snowboards collection" | `list_shop_collections` → resolves to `/collections/snowboards` |
| "the cotton hoodie" | `list_shop_products` → finds the right product GID |
| "my sale page" | `list_shop_pages` → resolves to `/pages/sale` |
| "the Refresh theme" | `list_shop_themes` → finds the theme by name |
| "the alternate product template" | `list_shop_templates` → lists available Liquid templates |
| "my US shipping zone" | `list_shipping_profiles` → returns zone IDs and current rates |
You'll see Claude make these calls in passing. They never modify anything; they're read-only lookups against your Shopify catalog.
## Create a test
Seven test types supported. Each one asks for a hypothesis, primary metric, and traffic split before creating anything.
> "Test 10% off the Oxygen snowboard for US mobile visitors"
> "Compare $39.99 vs $44.99 on the cotton hoodie, 50/50 split"
> "Run a price test on all snowboards — minus 15% — but cap traffic at 50% of visitors"
Claude resolves products by name, picks sensible defaults, asks you to confirm, and creates a draft. Variants can be percentage changes, fixed-amount changes, or absolute prices. [Price test details →](/experiments/price-test)
> "Test free shipping over \$50 for US visitors"
> "Bump my Express shipping rate from $9.99 to $14.99 in the US zone, 50/50 split"
> "Test removing the Standard shipping option in the Canada zone — see what happens to AOV"
Modifies, hides, or adds rates per zone. Untouched rates are auto-preserved (you don't need to enumerate every existing rate). [Shipping test details →](/experiments/shipping-test)
> "A/B test my Dawn theme vs the Refresh theme, 50/50"
> "Test the new theme I just uploaded against the live one"
Claude resolves theme names. Path-condition routing (testing only on certain URLs) isn't yet exposed via MCP — use the wizard for that. [Theme test details →](/experiments/theme-test)
> "Test the alternate product template I created"
> "Compare two product page layouts: the default and the 'minimal' template"
Picks alternate Liquid templates by name. Available for any template type (product, index, collection, page, blog, article, cart, search). [Template test details →](/experiments/template-test)
> "Send 50% of /products/old-hoodie traffic to /products/new-hoodie"
> "Test a redirect from /sale to /pages/black-friday for US mobile visitors"
Pure URL composition — Claude resolves friendly names ("the sale page", "snowboards collection") to real paths. Supports exact match, regex, contains, starts-with. [URL redirect test details →](/experiments/url-redirect-test)
> "Test 15% off the whole order against no discount, 50/50"
> "Compare free shipping over $50 vs a flat $10 off on all snowboards"
> "Test a volume discount — buy 2 get 10% off — on the cotton hoodie"
Builds discount variants against a no-offer control: percentage or fixed amount off products, the order, or shipping, plus volume and threshold tiers. Claude resolves products and collections by name. [Offer test details →](/experiments/offer-test)
> "Rename my 'Test rate 1' delivery option to 'Standard Shipping' at checkout"
> "Hide the slowest delivery method for US orders over \$100"
> "Reorder payment methods so Shop Pay shows first"
Plus-only. Hides, renames, or reorders delivery and payment methods, or adds checkout UI blocks, against an unchanged-checkout control. [Checkout test details →](/experiments/checkout-test)
## Lifecycle: launch, preview, pause, resume, end
Once a test exists (whether you created it via MCP or in the wizard), you can drive it from chat:
| What you say | What happens |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Launch the Oxygen test" | Goes to Active and real traffic starts flowing — from a Draft, or straight from a Preview once you're happy with it. |
| "Preview it first" | Goes to Preview status; Claude returns a URL you can open in your browser to QA the variant before launching. Share with the team if you want a second pair of eyes. When you're ready, "launch it" goes live; "put it back to draft" reopens it for edits. |
| "Put it back to draft" | Pulls a previewed test back to Draft so you can change its setup before launching. |
| "Pause the snowboard test" | Stops assigning new visitors. Existing data preserved. |
| "Resume it" | Goes back to Active. |
| "End the test, the variant won" | Closes it permanently. Data stays for analysis; new visitors stop being assigned. |
| "Clone the Oxygen test" | Duplicates it as a new draft you can tweak before launching. |
| "Update the hypothesis to ..." | Patches metadata on a draft (name, description, hypothesis, primary metric). |
Deleting a test isn't available from chat — the API token can't delete. To remove a draft, end it (if it ever launched) or delete it from the dashboard. Active tests must be ended first either way.
## Analytics: query results
You don't need to open the dashboard to check on tests:
| What you say | What Claude returns |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| "How is my Oxygen price test doing?" | Per-variant metrics: views, conversions, AOV, RPV, p-value, confidence interval |
| "Show me the breakdown by device" | Same metrics, broken out by mobile / desktop / tablet |
| "Compare the Oxygen and Hydrogen tests" | Side-by-side comparison of both tests' winners and lifts |
| "Which variant is winning?" | Plain-language summary with statistical-significance call-out |
| "Is the snowboards test statistically significant yet?" | Yes/no answer based on the current sample size |
| "Which tests are ready to act on?" | Active tests that have cleared significance and run long enough to call |
| "When did we launch this? Why is it paused?" | The test's lifecycle history — created, launched, paused, resumed, ended, with timestamps |
Available breakdown dimensions: date, device, country, traffic channel, traffic platform, visitor type, landing page, referral domain, and each UTM parameter (source, medium, campaign, term, content). Page-experience tests add page URL, template, and click destination. Pass up to two at once (e.g. device × country).
## What's NOT supported (yet)
Still wizard-only:
* **Visual editor tests** (DOM mutations like text/image/link changes) — Claude can't see your storefront the way the visual editor's click-to-record can.
* **Path-condition routing on theme tests** (testing only on certain URLs) — create the test in chat, then add path conditions in the wizard.
We'll add these as merchant demand drives priority. If you want a specific one prioritized, let support know.
## What's NOT supported, period
Some operations are intentionally not exposed:
* **Billing/plan changes** — these go through Shopify, not the API.
* **Shop-level settings** that aren't experiment-scoped (CSS, theme injection points, etc.) — wizard only.
* **Deleting tests** — the API token can't delete. End a running test from chat; remove drafts from the dashboard.
# MCP troubleshooting
Source: https://docs.abconvert.io/mcp/troubleshooting
Common errors and how to fix them.
## "Invalid token" / 401 Unauthorized
**Cause:** The token in your MCP client config is wrong, expired, or revoked.
**Fix:**
1. Open ABConvert → Settings → Claude / MCP Access.
2. Confirm the token (or connector) you're using is still listed and not marked as revoked.
3. If it's revoked or missing, mint a new one and update your MCP client config. For Claude Desktop / Claude.ai, generate new connector credentials and re-add the [custom connector](/mcp/claude-connector).
If your client reads a config file (Claude Code and most CLI clients), fully quit and re-open the app after updating it. Just closing the window doesn't reload the config.
## "MCP is not enabled for this shop" / 403 Forbidden
**Cause:** Your shop doesn't have the `enable-mcp` feature flag turned on.
**Fix:** Contact ABConvert support and ask to enable MCP for your shop. Tell them which shop domain you're on. Same-day turnaround in most cases.
MCP is rolling out gradually during beta. The flag is off by default; we turn it on per shop as we confirm everything works for your specific configuration.
## "Rate limit exceeded" / 429
**Cause:** You've made more than 200 requests in the last minute on the same token.
**Fix:** Wait a minute. The limit resets each minute. The response includes a `Retry-After` header that tells your AI assistant exactly how long to wait — most clients respect it automatically.
If you legitimately need a higher limit (e.g. a production integration making heavy use), contact support to discuss. The default works for normal interactive Claude usage; runaway loops are the only thing that should hit 429.
## "Service temporarily unavailable" / 503
**Cause:** ABConvert has temporarily disabled MCP HTTP transport (typically during a deploy or incident).
**Fix:** Check the [status page](https://status.abconvert.io) and wait. Stdio-based connections (mostly internal/dev) are unaffected. The disable is usually transient — under 5 minutes.
## Tools don't appear in Claude
**Symptoms:** Claude doesn't show ABConvert tools when you start a new chat, even though setup looked successful.
**Fix:**
Go to **Settings → Connectors** and confirm ABConvert is listed and enabled. If it shows an error, remove it, generate fresh credentials in ABConvert, and re-add it — see [Claude.ai connector](/mcp/claude-connector).
JSON syntax errors silently disable an entire MCP server config. Run the JSON file through a validator (e.g. `jq . path/to/config.json`) — it should print without errors. Then fully quit and re-open the app; just closing the window doesn't reload MCP servers.
In a new chat, ask: "What ABConvert tools do you have?" Claude should list them. If it says "I don't have access to any ABConvert tools," the MCP connection failed silently.
Open a terminal and run:
```sh theme={null}
curl -X POST https://mcp.abconvert.io/mcp \
-H "Authorization: Bearer abc_your_token_here" \
-H "Accept: application/json, text/event-stream" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
```
If this returns a list of tools, your token is fine — the issue is your assistant's config. If it returns 401 or 403, see the sections above.
## Claude creates the test on the wrong product
**Cause:** The product name was ambiguous — Claude picked the wrong match from your catalog.
**Fix:** Be more specific in your prompt. Instead of "test 10% off the snowboard," say "test 10% off **The Collection Snowboard: Oxygen**." Or paste the product GID directly if you know it.
If the wrong product still gets created, leave that draft and just recreate the test correctly — nothing has happened on the live store yet, so an unlaunched draft is harmless. Deleting isn't available from chat (the API token can't delete); remove the stray draft from the dashboard when convenient.
## Claude doesn't ask for confirmation before creating
**Symptoms:** You said "test 10% off Oxygen" and Claude went straight to creating without asking about hypothesis, goal, or audience.
**Cause:** Either (a) your prompt already specified all the relevant fields ("test 10% off Oxygen for US mobile, hypothesis: discount lifts RPV, goal: revenue per visitor, 50/50 split, save as draft" — Claude has everything it needs and skips confirmation), or (b) you said something like "just create it" / "use defaults" earlier in the conversation.
**Fix:** If you want the confirmation step, ask specifically: "Before creating, confirm the hypothesis, goal, traffic, and audience with me." Or open a fresh chat — Claude treats each new conversation independently.
## "Already in active test" error on launch
**Cause:** You're trying to launch a test that overlaps with an already-running one — same product (price tests), same zone (shipping), same theme (theme tests), or same trigger URL (redirects). ABConvert blocks this to prevent two tests from fighting each other.
**Fix:** Either end the conflicting test first, or pick a different resource for this one. The error message includes the conflicting experiment ID.
## "I can't see your storefront"
**Cause:** You asked Claude to do a visual editor test (text/image/link change) — those need a click-to-record interface that MCP doesn't provide.
**Fix:** Use the visual editor in the wizard for those. [Visual editor docs →](/experiments/visual-editor-test)
## Still stuck?
* **Live chat** in the ABConvert dashboard, bottom-right corner. Mention you're using MCP and paste any error messages.
* **Email** [support@abconvert.io](mailto:support@abconvert.io) — same humans on the other end.
* **Status page** at [status.abconvert.io](https://status.abconvert.io) for incidents that affect everyone.
# Onboarding ABConvert
Source: https://docs.abconvert.io/onboarding
Install ABConvert, walk through tutorials, and launch your first A/B test
## Installation
Open the [ABConvert on the Shopify App Store](https://apps.shopify.com/a-b-convert-price-a-b-test). Click **Install** and review the permissions ABConvert needs to run experiments.
![Install]()
Shopify will show you an authorization screen listing the permissions ABConvert needs: access to products, orders, and theme files. Approve to continue, and you'll be redirected directly into the ABConvert dashboard inside your Shopify admin.
ABConvert requires these permissions to deploy experiments and track results. See [Terms of service](https://www.abconvert.io/terms-of-service) for complete details on what the app accesses and why.
After installation, ABConvert opens an onboarding survey. Answer a few questions about your store and testing goals—this helps ABConvert recommend the right experiment type for your situation.
![Onboarding survey]()
Based on your answers, ABConvert will suggest a test type and offer to walk you through creating your first experiment in guided mode, or let you explore the dashboard independently.
After finishing the survey, you have three options:
* **Tutorial mode** — Risk-free practice with mock data (recommended for first-timers)
* **Guided mode** — Create a real test with step-by-step help
* **Explore independently** — Dive in and create tests on your own
See the next section for details on tutorial and guided modes.
***
## Interactive tutorial and guided mode
ABConvert offers two interactive learning modes to help you create your first experiment with confidence. Both provide step-by-step coaching with contextual tooltips explaining each field, but they differ in how your work is saved.
![Tutorial guided]()
### Tutorial mode (risk-free practice)
This is a practice environment that uses pre-filled mock products and sample data. You experience the complete test creation workflow without affecting your actual store.
**Use when:**
* You're new to A/B testing and want to explore without risk
* You want to understand the workflow before committing real products
* You're evaluating ABConvert and want to see how test creation works
**How to access tutorial mode:**
**For new users after onboarding:**
1. Choose **"Take a guided tour first"** when prompted
2. Select a test type to begin the tutorial
![Take a guided tour]()
**For all users anytime:**
1. Navigate to **ABConvert dashboard → Get Started tab**
2. Click **"Start interactive tutorial"**
3. Select the test type you want to practice
![Start tutorial]()
### Guided mode (real test creation with help)
This is step-by-step coaching while creating an actual experiment using your real store products and data. Everything you configure saves immediately and can be launched.
**Use when:**
* You're ready to create a real test but want guidance through the process
* You want contextual help explaining each configuration field
* You've completed the tutorial and are ready to launch your first experiment
**How to access guided mode:**
**For new users after onboarding:**
1. Choose **"Create my first test"** when prompted after the survey
2. Follow the guided flow to create your first experiment
![Create guided test]()
**For all users during test creation:**
1. Start creating any new experiment
2. Click the **"Guided tour"** button in the test creation interface
3. Follow the step-by-step coaching through each configuration section
![Start tutorial]()