⌘Ctrlk
Mutual exclusion is the concept of ensuring that a single visitor isn't assigned to multiple experiments that could interfere with each other. Understanding how AB Genius handles this is important for maintaining clean test results.
AB Genius assigns visitors to each experiment independently. If you have three experiments running, a single visitor could be assigned to a group in all three.
This is fine when the experiments target different elements — for example, a price test on Product A, a content test on the homepage, and a page split test on a landing page. These experiments don't interact with each other, so there's no conflict.
Conflicts arise when two experiments modify the same thing:
Two price tests on the same product. Both experiments will try to set a price for the same product. The second assignment may overwrite the first, producing unreliable data for both tests.
Two content tests modifying the same element on the same page. If both experiments target the same headline, the second modification may overwrite the first.
A page split test and a content/price test on the same page. If a visitor is redirected by the page split test, they leave the original page entirely — so the content or price test on that original page never applies. But if they're in the control group of the split test (staying on the original page), both experiments could apply.
AB Genius does not currently enforce automatic mutual exclusion between experiments. This means it's your responsibility to ensure you don't run conflicting experiments simultaneously.
Practical rules to follow:
One price test per product at a time.
One content test per element per page at a time.
Don't run content or price tests on the control page of an active page split test unless you understand the interaction.
If in doubt, run experiments sequentially rather than in parallel.
If you need to run two experiments on the same page for different audiences, you can use audience targeting to create non-overlapping segments:
Experiment A targets mobile visitors only.
Experiment B targets desktop visitors only.
Since the targeting criteria don't overlap, no single visitor can be in both experiments. This is a manual form of mutual exclusion.
Keep a simple record of which experiments are running on which pages and products. Before launching a new experiment, check for overlap. This takes 30 seconds and prevents weeks of corrupted data.
Use this checklist before launching any experiment. It covers all three test types and will catch the most common setup issues.
Instead of manually starting an experiment, you can schedule it to launch automatically. This is useful when you want to coordinate test launches with campaign launches, promotions, or team availability.
Scheduling is available on the Pro plan only. Free plan experiments must be started manually.
Schedule launches for the start of the day. If your store gets most of its traffic during business hours, scheduling an experiment to start at midnight means you capture a full day of data from day one.
Coordinate with ad campaigns. If you're launching a new ad campaign and want to test the landing page, schedule the experiment to start at the same time as the campaign.
Don't forget to complete QA before the scheduled time. Once the experiment auto-starts, it's live. Run through the QA Checklist well before the scheduled launch.
Sometimes you need to pause an experiment — maybe you're running a flash sale and don't want it to interfere with test results, or you've spotted an issue that needs fixing before the test continues.
No new visitor assignments. Visitors arriving on the page will see the original store experience — as if no experiment exists.
Existing data is preserved. All visitor assignments, events, and results collected before the pause remain intact.
Previously assigned visitors are unaffected. If a visitor was assigned to a group before the pause and returns during the pause, their cached assignment (ab_data cookie, 1 hour) may still show the variant. After the cache expires, they'll see the original experience until the experiment resumes.
Pause when you need a temporary stop. You plan to resume the experiment once the disruption is over (sale ends, issue is fixed, holiday period passes).
End when you're done with the experiment permanently. You've seen enough data, or the experiment is no longer relevant.
The key difference: paused experiments can be resumed. Ended experiments cannot.
Pausing an experiment introduces a gap in your data. The time series chart in the Results tab will show a period with zero visitors during the pause. This doesn't invalidate your results, but be aware that the gap could coincide with different traffic patterns (e.g. if you paused over a weekend).
If possible, avoid pausing experiments mid-week. Pause at the end of a full weekly cycle and resume at the start of the next one to keep your data clean.
Declaring a winner in AB Genius is not the end of the process. It's the signal to implement the change on your live store. Here's how to do that for each test type, and what to monitor after implementation.
If the challenger page won:
Option A — Replace the original. Rebuild the original page to match the winning challenger design. This keeps your URL structure clean.
Option B — Redirect. Set up a permanent redirect from the original URL to the winning page URL. This is faster but means maintaining a separate page.
Option C — Swap URLs. If both pages are product pages, you might update the original product page to match the challenger's design and content.
The right approach depends on your store's URL structure and SEO considerations. If the original URL has SEO authority and backlinks, Option A (rebuilding in place) or a 301 redirect is usually best.
Implementing a winner isn't "set and forget." Monitor your store's key metrics for 1–2 weeks after the change:
Conversion rate — Does the overall store conversion rate reflect the lift you saw in the test?
Revenue per visitor — Is the revenue improvement holding at the expected level?
No unexpected drops — Sometimes a change that wins in a test causes unintended issues when applied to all traffic (e.g. a price increase that works for US visitors but hurts international conversion). Watch for segment-level drops.
Customer feedback — If you implemented a price increase, monitor customer support inquiries for any pricing-related concerns.
Once you've implemented a winner, that becomes your new baseline. Your next experiment should build on top of it.
For example:
Test 1: Price increase from $39 to $44. Winner: $44.
Test 2: Now test $44 vs $49 — can you go higher?
Test 3: Test new headline copy on the page with the winning $44 price.
Over time, compounding small wins produces significant cumulative improvements. This is how professional CRO programs work — not one big test, but a sequence of experiments that systematically improve performance.
The most common mistake isn't implementing wrong — it's not implementing at all. Merchants run a test, see a winner, and then get distracted and never make the change.
A winning test that isn't implemented is worth nothing. Put implementation on your task list the same day you declare a winner. The longer you wait, the more revenue you leave on the table.