Cross-Domain A/B Testing for a Hotel Booking Widget

The client is a luxury independent hotel weighing how guests should complete a booking: through a widget embedded directly on its own site, or by redirecting to a separate, third-party reservation engine the hotel had used for years.

• A test that spans two domains. Comparing the on-site booking widget against the third-party reservation engine meant tracking a single guest's journey across a domain boundary — something standard A/B testing tools aren't built to attribute correctly on their own.
• Real revenue riding on the outcome. This wasn't a cosmetic UX test; the "losing" option meant walking away from a booking flow the hotel had relied on for years, so the read needed to be trustworthy enough to justify that call.
• No existing way to thread identity across the handoff. For the test to work, the same visitor needed to be recognized as the same experiment participant whether they stayed on the hotel's domain or were redirected to the reservation engine's domain to complete checkout.

We built a cross-domain Statsig Sidecar experiment specifically designed to solve the identity-threading problem: a stable user ID is generated when a visitor enters the test on the hotel's own site, then carried across the domain boundary via a combination of URL parameters and a sessionStorage relay, so the reservation engine's domain can pick up exactly where the hotel's domain left off. That stable ID is what let us attribute a completed booking on the reservation engine back to the correct test arm with confidence.

On the reservation-engine side, we also built a GTM-based checkout-total calculation to capture accurate booking values as they completed — since without it, revenue figures for that arm of the test would have been incomplete or approximate at best.

Because this pattern is common to any hotel using this same reservation platform, we packaged the entire build — the identity threading, the cross-domain relay, and the checkout-value capture — as a reusable framework rather than a one-off script, so it can be redeployed quickly for other hotel clients running the same redirect-based booking setup.

To make the results usable by non-technical stakeholders, we built a four-page Looker Studio dashboard that breaks the experiment down by device, funnel stage, and value — rather than leaving the read buried in Statsig's own interface. Partway through analysis, we also caught a data-quality anomaly: bookings attributed to the control group were appearing on the reservation-engine's domain, which shouldn't have been possible under the test's design. Catching that before finalizing the read prevented a flawed conclusion from reaching the client.

Visitor enters test on hotel domain
  -> assigns stable ID -> Statsig Sidecar experiment
       |
       +-- Arm A: on-site Selfbook widget
       |     -> booking completes on Domain A --------+
       |                                              +-> 4-page Looker Studio dashboard
       +-- Arm B: ID relayed via URL param + sessionStorage
             -> reservation-engine domain
             -> booking completes on Domain B --------+

# The stable ID generated on the hotel's own domain is what let a booking
# completed on the reservation engine's separate domain still be attributed
# to the correct test arm.

• The redirect-based reservation engine converted at a meaningfully higher average order value — roughly 46% higher — than the on-site widget.
• On mobile, that advantage reversed dramatically: the reservation engine converted at a fraction of a percent (0.06%), while the on-site widget converted at 0.91% — more than 15 times higher.
• The net finding: neither option was a universal winner. The right choice depended heavily on device mix, which is a materially more useful and specific answer than a simple "which one performed better" verdict would have been.
• The cross-domain data-quality anomaly (control-attributed bookings appearing on the wrong domain) was caught and flagged before it could distort the experiment's conclusions.

[CHECK] Still to confirm: the final routing decision the client made based on these results, any resulting revenue or conversion lift once it shipped, and the confirmed root cause of the cross-domain attribution anomaly.

A cross-domain funnel is one of the easiest places for an A/B test to quietly lie to you. If you're running (or considering) a similar test across two domains, it's worth having the identity-threading and data quality checked before you trust the readout.