Cross-domain tracking is a method to recognize the same user across two or more separate domains (e.g., brand.com → checkout-partner.com) so analytics doesn’t split one journey into multiple sessions or generate fake referral traffic. Without it, your funnel looks fractured: two users, two sessions, and a referral from your own site. With it, you get one coherent path and correct attribution.
Why it matters
- Accurate end-to-end journeys across properties
- No self-referral noise corrupting reports
- Cleaner attribution model decisions
How it works (in practice)
- Share a visitor ID: when a user clicks from Domain A to Domain B, you pass a stable first-party identifier via link decoration (URL parameter) or a short redirect. Keep campaign tags like UTM parameters intact.
- Rehydrate on arrival: Domain B reads that ID and sets/updates its own first-party cookie / third-party cookie to the same value.
- Stitch events: subsequent hits on both domains carry the same visitor ID, so analytics merges them into one user/session.
Minimal formula:
Unified Visitor ID = First-party ID on A → propagated via link → adopted as first-party ID on B
Mini example
A visitor lands on brand.com, clicks “Buy,” lands on shop.com, and completes checkout.
| Scenario | Observed Users | Sessions | Referral on checkout |
|---|---|---|---|
| Without cross-domain tracking | 2 | 2 | brand.com (self-referral) |
| With cross-domain tracking | 1 | 1 | Original source (preserved via UTM parameters) |
Implementation notes
- Prefer first-party storage; third-party cookies are deprecated.
- Decorate only links you control between domains; keep IDs opaque (hash/UUID), no PII in URLs.
- Ensure middleware doesn’t strip parameters; align session timeout and clocks across domains.
- For robust setups, coordinate your data layer and consider server-side tagging and consent mode to respect privacy constraints.