A/B test results become unreliable when a visitor moves between domains and your analytics tool treats them as separate people. The problem gets worse when the conversion happens on a checkout, booking, or app domain.
Cross-domain A/B testing with Mida.so requires more than adding a tracking script to each website. You need consistent experiment IDs, preserved visitor identity, stable UTMs, and verified conversion attribution. Set up those pieces before launching the test, not after the first report looks wrong.
Key Takeaways
- Install Mida tracking across every domain in the customer journey.
- Use one experiment ID, consistent event names, and stable UTMs.
- Preserve the visitor’s identity and variant assignment between domains.
- Gate tracking behind the required consent state.
- Test attribution with real browser journeys before sending traffic.
Why Cross-Domain A/B Tests Break
A browser cookie normally belongs to one domain. A cookie created on example.com isn’t automatically available on checkout.example-payments.com, and it won’t be available on an unrelated domain such as example-app.com.
That creates three common tracking problems.
First, the same visitor can receive two different IDs. Mida may record the first visit on your marketing site as one user and the purchase on your checkout domain as another.
Second, the test assignment can disappear. A visitor sees variation B on the landing page, then loads the checkout without the experiment context. The purchase event may become unattributed or appear under the control group.
Third, campaign parameters can be lost. A link from the landing page to the checkout may remove utm_source, utm_medium, or utm_campaign. Your reports then show direct traffic or unknown traffic instead of the original campaign.
Cross-domain measurement is not the same as campaign tracking. A UTM parameter tells you where a visit came from. It doesn’t prove that two sessions belong to the same person. You need both campaign context and a visitor identifier.
Google’s cross-domain measurement guidance describes the same core issue. Domains must pass identity information between them instead of creating a new identity at each step.
For Mida, the practical target is simple: one visitor, one test assignment, and one conversion path across the domains involved.
Map the Journey Before Configuring Mida
Start with the full path a visitor takes. Write down every domain, subdomain, redirect, and third-party service involved.
A typical journey might look like this:
www.example.comcontains the landing page and experiment.app.example.comhandles account creation.pay.example-payments.comprocesses payment.www.example.com/thank-yourecords the final conversion.
Mark the domain where Mida assigns the test variation. Then mark the domain where the primary conversion occurs. The second domain is often where attribution fails.
Define the conversion event before creating the experiment. A purchase, completed signup, activated account, or submitted lead form can work. Pick one primary event for the test. Add secondary events for guardrails, such as checkout errors, refund requests, or account cancellations.
Use one naming system across all domains. For example:
- Experiment ID:
pricing_checkout_v1 - Variations:
control,variant_a - Primary event:
purchase_completed - Secondary event:
checkout_error
Keep these values stable. Don’t call the experiment pricing_test on one domain and pricing_v2 on another. Mida reports need a shared reference that joins the exposure and conversion events.
UTMs also need a clear rule. Preserve the original parameters when a visitor moves between domains. Don’t replace the first campaign with a new internal link label unless you have a reporting reason to do so.
Configure Mida Across Every Domain
Open the relevant Mida project or workspace and confirm that every participating domain sends data to the same destination. Use the official Mida website and current product documentation for the exact installation and experiment settings available in your account.
The interface can change. The tracking logic doesn’t.
1. Install tracking on each site
Add Mida tracking to the landing page, application flow, checkout, and confirmation page. A script on the first domain isn’t enough if the conversion happens elsewhere.
Check that each page sends the expected pageview or visit data. Then check that important actions send events with the same names and properties.
Don’t create separate projects for each domain unless you have a clear reporting reason. Separate projects make it harder to connect exposure data with conversion data.
2. Apply the same consent rule everywhere
Your consent management platform must control Mida tracking on every domain. A visitor who rejects analytics cookies on the landing page shouldn’t be tracked after reaching the checkout.
Consent also needs to survive the domain transition. If each domain displays a separate consent banner, users may receive inconsistent treatment. Coordinate the consent state through your CMP or another approved method.
The exact legal requirement depends on the visitor’s location and the data you collect. The ICO guidance on cookies and similar technologies is a useful reference for UK teams. Treat it as guidance, not a substitute for legal review.
3. Preserve identity and assignment
Configure the supported Mida cross-domain identity method for your setup. This may involve a linker parameter, a shared identifier, or server-side handoff. Use the method documented for your current Mida implementation.
The important point is that the destination domain must receive the visitor context. Opening a new page with no identity handoff creates a fresh user record.
Pass the experiment ID and variation with the journey when your implementation requires it. Keep the values in a first-party cookie, URL parameter, server session, or another approved storage method. Don’t rely on the browser to remember the assignment across unrelated domains.
Never randomize the same visitor again on the checkout domain. The checkout should record the existing assignment. It shouldn’t create a second one.
4. Preserve UTMs without corrupting them
Keep the original UTM values when linking between domains. Test links containing parameters such as:
utm_source=linkedin&utm_medium=paid&utm_campaign=pricing_launch
Watch for redirects that strip the query string. Payment providers, authentication tools, and form platforms often create these breaks.
UTMs identify acquisition context. The Mida visitor ID and experiment metadata connect that context to the test exposure and conversion.
5. Keep experiment IDs consistent
Use the same experiment ID in the exposure event and the conversion report. Store it as a property if Mida supports event properties in your setup.
A useful exposure record contains the experiment ID, variation, timestamp, page, and visitor identifier. A useful conversion record contains the same visitor identifier, conversion event, timestamp, and order or signup reference.
This structure lets you audit the path when the numbers disagree. It also prevents a test from becoming dependent on page names that may change during development.
Don’t launch until you can trace one consented browser journey from exposure to conversion across every domain.
Validate Attribution Before Sending Traffic
Run a controlled test with a real browser. Use a fresh profile or private window, but don’t assume private browsing is identical to normal browsing. Test both conditions.
Start with a URL that contains your planned UTMs. Accept analytics consent where required. Enter the experiment page and record the assigned variation. Continue through the application, checkout, and confirmation steps.
Then inspect the data in Mida. Confirm that:
- The landing page created an exposure event.
- The experiment ID stayed the same.
- The variation stayed the same.
- The visitor remained connected across domains.
- The conversion event reached the same Mida project.
- UTM values were preserved or mapped according to your reporting rule.
- Consent status matched the visitor’s choice.
Repeat the journey after rejecting analytics consent. Mida shouldn’t collect the same analytics data if your consent policy blocks it.
Test redirects separately. Add identity and UTM checks after login, payment, and third-party form steps. A journey can work in development and fail in production because the live redirect removes a query parameter.
Also test direct visits. A visitor who starts on the checkout page should not be assigned to an experiment that only runs on the landing page. Your implementation needs a defined rule for these users.
Attribution should be validated before launch, not inferred from a clean-looking dashboard. A report can contain numbers while still connecting the wrong visitors.
Read Mida Results Without Mixing Traffic
Create one primary success metric before reviewing the result. If the test changes pricing, the primary metric may be completed purchase rate. If it changes signup copy, it may be account creation rate.
Use Mida’s experiment report to compare the assigned variations, but inspect the supporting events as well. A higher landing-page click rate doesn’t matter if the checkout conversion rate falls.
Separate the main result from diagnostic segments:
- Visitors who reached the checkout
- Visitors who completed payment
- New and returning visitors
- Paid and organic traffic
- Consent granted and consent denied
- Mobile and desktop users
Don’t combine visitors who never saw the experiment with visitors who were assigned a variation. Exposure is the denominator for an A/B test. A conversion from an unexposed visitor shouldn’t inflate the result.
Check for missing events, unusual traffic splits, duplicate purchases, and large drops between domains. If the control receives 80% of traffic despite an intended 50/50 split, stop and investigate the assignment logic.
A clean result requires more than a difference between two percentages. You need reliable exposure data, a stable identity, complete conversion events, and a test period that matches your decision rule.
Conclusion
Cross-domain A/B testing with Mida.so works when the entire customer journey uses one measurement plan. Install tracking across all domains, preserve identity and variation assignments, retain UTMs, and apply the same consent rules at every step.
The strongest safeguard is a completed browser test before launch. If you can follow one visitor from experiment exposure to conversion in Mida, your production results have a reliable foundation. If you can’t, fix the tracking before trusting the test.
