Running Multiple Experiments

Split Test Pro lets you run as many experiments concurrently as you want. There’s no platform-level limit on parallelism, and visitors handle multiple experiments cleanly. The discipline that matters is which experiments you run at the same time.

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 5 experiments at once, each independently bucketed and tracked. Their assignments are sticky across page loads and visits via that cookie.

The Conflict Warning

Split Test Pro’s pre-launch checklist surfaces a conflict warning when:

• Another experiment is currently running, and
• Its URL targeting overlaps yours (substring match after normalization — deliberately conservative, false positives are acceptable).

The warning is advisory, not blocking — you can launch through it. It exists to flag the most common foot-gun: starting a second experiment that targets the same page as one you forgot about.

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 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

The Experiments view filtered to “Running” shows you everything currently live. Skim this list before starting a new test — if you see overlap with what you’re about to launch, decide whether the new test should wait.

Next Steps

• Get a deeper look at how a single experiment’s traffic is split: Traffic Allocation.
• Understand what counts as a conflict for the pre-launch warning: Pre-Launch QA.
• Wind down running experiments cleanly: Experiment Lifecycle.