Running Tailor Alongside Another Experimentation Platform
Most teams that adopt Tailor already have a testing tool in place. You don't have to pick one.
The Short Answer
Tailor coexists with Optimizely, VWO, Convert, AB Tasty, Adobe Target, Kameleoon, Statsig, LaunchDarkly, and in-house testing frameworks. This guide applies to any of them, plus server-side tests your engineering team runs.
Experiments don't need to be mutually exclusive
If both platforms randomize visitors independently and the two tests don't interact, they can usually run in parallel without harming either result. A pricing or checkout test in your existing platform can run at the same time as a Tailor test on the headline, hero image, or CTA.
Independent randomization means each platform's treatment group is spread evenly across the other platform's groups. The other test widens your confidence intervals, but it does not push either result in a particular direction:
When the tests do interact, separate them using one of the five options below.
When Parallel Is Safe
Run both platforms at once when all of these are true:
Different page elements
The two tests change different things. The other platform tests pricing, form fields, or navigation, while Tailor tests the headline, hero, or CTA copy.
Independent randomization
Neither platform's assignment depends on the other. Both bucket visitors on their own, so each test's groups stay balanced.
No plausible interaction effect
You wouldn't expect the winner of one test to change depending on the other. If a new price only works with a new value-prop headline, that's an interaction.
Enough traffic
Overlapping tests add variance. If either test is already slow to reach significance, running them sequentially is faster than debugging a muddy result.
When to Separate Instead
Signs the tests will collide
- Both tests edit the same element, or one hides an element the other rewrites
- Both platforms write to the same DOM node, so the final state depends on load order
- One test changes the offer and the other changes the message describing that offer
- Your stakeholders need a clean, attributable read on one specific change
Five Ways to Separate Traffic
Pick the lightest option that gives you a clean read. The first two are configuration changes, the third and fourth give each platform its own page, and the last one needs engineering.
Separate by campaign or URL parameter
Tailor targets specific traffic using parameters such as utm_campaign, utm_term, or utm_medium, while your other platform runs on the traffic without those parameters.
Best when: Tailor is scoped to the traffic you're buying and the other platform is testing the broader site experience. Nothing changes on the other platform's side. See the Targeting Guide for the full parameter list.
Use a Tailor-specific parameter as an exclusion flag
Add a parameter such as tailor=1 to the URLs Tailor should own, then gate the other platform's experiments on its absence. Tailor-eligible traffic carries the flag, the other platform sits out, and everything else runs as usual.
// Audience or activation condition in the other platform:
// run only when Tailor does not own this visit.
!new URLSearchParams(window.location.search).has("tailor")Best when: The other platform owns most of the traffic and you want a carve-out for Tailor without rewriting its audience rules. It needs a one-time change on the other platform's side, and whoever administers it has to agree to the convention.
Separate by page or path
Each platform owns different URL paths. Tailor runs experiments on the paid landing pages, the other platform runs on the core site, and neither touches the other's pages.
Best when: Ownership is already split by team. Product and Engineering test the app and core site, while Marketing tests the campaign pages. This assumes the second path already exists. If it doesn't, option 4 is how you get one without a dev ticket.
Have Tailor host a separate copy of the page
Hosted Pages serves a full copy of a page from its own URL on your domain, with your edits already built into the HTML. That gives you the second path option 3 needs without asking your web team to duplicate a template, and the other platform keeps the original untouched.
Because Tailor serves the page rather than editing it in the visitor's browser, there is also no client-side edit for the other platform's script to collide with.
Best when: You want path separation but creating the duplicate page yourself is the blocker, or you want the tailored version rendered server-side. A hosted page is frozen at the moment it was cloned, so later changes to the original do not reach it.
Coordinate between the platforms
Most testing platforms already expose the visitor's assignment on a global JavaScript object. Tailor can read that signal and skip the conflicting Tailor test for those visitors, so only one platform ever modifies the page. Check your platform's docs for the exact global, since the name and shape differ between vendors and versions.
Server-side tests work the same way. Expose the assignment before Tailor evaluates targeting, either as a variable or a URL parameter:
// Set by your app before the Tailor tag evaluates targeting.
window.myExperiments = { pricing_test: "treatment" };Best when: The tests genuinely overlap on the same page and you still want both running at full traffic. This is the most precise option and the one that needs the most setup. Send us the variable you can expose and we'll wire the targeting up with you.
Which Option to Pick
| Your situation | Recommended approach |
|---|---|
| Tests change different elements and don't interact | Run in parallel, no separation needed |
| Tailor is only for paid campaigns | Option 1, separate by UTM parameter |
| Other platform covers nearly all traffic | Option 2, exclusion flag on the other platform |
| Marketing and Product own different pages | Option 3, separate by path |
| You want separate pages but can't easily create one | Option 4, let Tailor host the copy |
| Same page, both tests must keep running | Option 5, coordinate via JavaScript variable |
| Low traffic and a high-stakes read | Run the tests sequentially instead |
Keeping Measurement Clean
Whichever setup you choose, protect the reporting on both sides:
- Use the same conversion definition in both platforms so the two reports are comparable
- Don't add the two lifts together. Overlapping tests measure overlapping traffic, so summing the wins overstates the result
- Check traffic splits on both platforms early. A lopsided split is the first sign that one platform's targeting is filtering the other's population
- Pass the variant into your analytics tool from both platforms, so you can segment one test by the other if a result looks odd
- Watch for flicker on shared elements during QA. It means both platforms are writing to the same node, and no script order fixes that cleanly
See Analytics Integration for passing Tailor variant data into GA4, Amplitude, or Segment, and Conversion Goals & Tracking for aligning goal definitions.
Before You Configure Anything
The right setup depends on which experiments your Product and Engineering teams are already running and how their traffic allocation works. Gather this first:
- Which pages the other platform's live experiments run on
- What percentage of traffic each of those experiments takes
- Which elements they change, and whether any are elements you want Tailor to test
- Whether any are server-side, since those need a JavaScript variable or URL parameter to coordinate
- Whether the other platform can be configured to exclude traffic by URL parameter
We have a number of customers running Tailor alongside another experimentation platform. Send us your current setup and we'll recommend the simplest approach.
FAQ
Can I run Tailor and Optimizely (or VWO, Convert, AB Tasty, Adobe Target) at the same time?βΆ
Yes. Tailor loads as its own async script and applies changes in the browser, so it does not depend on or interfere with another platform's SDK. What matters is whether the two specific experiments interact. Tests on different page elements that each randomize visitors independently can run in parallel. Tests that edit the same element, or where one changes the offer and the other changes the message describing it, should be separated.
Do the experiments have to be mutually exclusive?βΆ
No. Mutual exclusion solves a specific problem: two tests that interact. When both platforms randomize independently, that problem does not arise. Forcing mutual exclusion anyway costs you traffic in both tests and slows both results down, so reach for it when you have identified an actual conflict.
Will running two platforms on the same page cause flicker?βΆ
Only if both platforms modify the same DOM node. Each platform applying changes to different elements is fine. When two platforms write to the same element, the final state depends on which script lands last, and a result that hinges on load order is not one you can trust. Separate those two tests.
How do I keep the two platforms' reports comparable?βΆ
Use the same conversion definition in both platforms, and pass each platform's variant into your analytics tool so you can segment one test by the other. Do not add the two reported lifts together: they are measured on overlapping traffic, so summing them overstates the combined effect.
Can Tailor coordinate with a server-side test?βΆ
Yes. Have your application expose the visitor's assignment as a JavaScript variable or a URL parameter before Tailor evaluates targeting. Tailor can then key a test's targeting off that value, so a visitor in your server-side treatment group is excluded from the conflicting Tailor test.
Should I just move everything onto one platform?βΆ
Not as a first step. Running both lets you compare the two workflows on real traffic before committing, and product-side tests on pricing, onboarding, or app surfaces often belong in a platform your engineering team already owns. Consolidate later if you find you are maintaining two overlapping setups for the same job.