Running Multiple Experiments

Split Test Pro lets you run several experiments at the same time, and a visitor can be in more than one of them. There’s no mutual exclusion between tests. Some plans do cap how many tests run at once — if you hit the cap, the Launch Test error names the number; see Billing and Plans. The discipline that matters is which experiments you run together.

How Concurrent Experiments Work

When a visitor lands on your site, the script runs through every active experiment in parallel:

1. For each experiment, it checks whether the visitor’s URL matches the targeting rules.

2. For each matching experiment, it deterministically assigns the visitor to a variant.

3. Each assignment is stored in a single cookie using a multi-experiment format:

   splittestpro-experiment=expA-uuid:varA-uuid|expB-uuid:varB-uuid

4. All matching variants are applied to the page (CSS and JS injection from each).

This means a single visitor can be in several experiments at once, each independently bucketed and tracked. Their assignments are sticky across page loads and visits via that cookie.

The Overlap Banner

When another test shared visitors with yours in the same period, your test’s Results page shows an Overlap banner. It reads “N overlapping tests · X% shared visitors” and offers an Overlap view switch to compare how those shared visitors behaved. Split Test Pro doesn’t stop you from launching overlapping tests; the banner is there so you can judge whether the overlap matters for your result.

For what the Overlap view shows and how to read it, see the Overlapping experiments section of Reading the Results Dashboard.

When Concurrent Experiments Are Fine

Run them in parallel when:

• They target completely different pages — a homepage hero test and a product-page CTA test can run at the same time. Same for /blog/* vs /products/*.
• They target the same page but different DOM regions — a header test and a footer test. The variants don’t interact, so the data stays clean.
• They use different variant types that don’t overlap — a CSS test on a button color and a JS test that fires a tracking event are independent.

When Concurrent Experiments Are Trouble

Avoid running parallel tests when:

• Both touch the same DOM element. Two CSS rules targeting the same selector will fight, and which one wins is essentially random per visitor depending on injection order.
• They have interaction effects on the same conversion goal. A test on the product image and a test on the add-to-cart button on the same page can produce results that depend on each other in non-obvious ways.
• One is a redirect test and the other is a CSS or JS test on the redirect’s source page. The redirect happens first; the other variants never apply.

When you genuinely need to test multiple changes on the same surface, run them sequentially — one experiment at a time, ship the winner, then start the next. Sequential testing takes longer overall but produces cleanly attributable wins.

Why There Are No Mutual Exclusion Groups

Some testing tools support “holdout groups” or “mutually exclusive experiments” where the platform guarantees a visitor isn’t in two specified experiments at once. Split Test Pro doesn’t have this today. The trade-off:

• Without mutex: more parallelism, faster overall throughput, simpler mental model for the merchant.
• With mutex: stronger guarantees about interaction effects, but slower throughput because the visitor pool is split across exclusive groups.

For most teams running independent tests on different pages, the lack of mutex isn’t a real constraint. If you genuinely need to run two interacting tests on the same surface, the right move today is to run them sequentially or accept that you’re measuring the combined effect.

Reviewing What’s Running

On the Experiments page, click the Running card to filter the list to live tests. The Dashboard’s Active experiments table shows the same at a glance. Skim either before launching a new test — if you see one on the same pages, decide whether the new test should wait.

Next Steps

• Get a deeper look at how a single experiment’s traffic is split: Traffic Allocation.
• See what has to be in place before a test can go live: Launch checks.
• Wind down running experiments cleanly: Experiment Lifecycle.