{# DE + SK hreflang odebráno 2026-05-24 — viz core/settings.py LANGUAGES. cross_lang_alternates is set False by views whose CS/EN versions live on DIFFERENT paths (KB articles/categories, blog posts) — there the naive same-path alternate would point at a non-existent URL, so we emit only the self-canonical instead of a wrong reciprocal. #} Skip to content

Cross-domain tracking with server-side GTM: one journey across multiple domains

When the buying journey spans multiple domains (site and payment gateway, language versions), client-side tracking easily splits it. How server-side keeps it together.

D
DataNostro Team 7. 6. 2026 · 9 min · Intermediate

Many stores have a buying journey spread across multiple domains — the main site on one, a payment gateway or booking system on another, language versions on a third. For measurement it's a trap: if visitor identity is lost between domains, one conversion fragments into several unrelated visits. Here's how to handle it.

Why the journey fragments

Visitor identification rests on cookies, which are inherently bound to a domain. A cookie from shop.com isn't available on payments.com. When the visitor moves to another domain, they look new — and the conversion on the payment gateway isn't attributed to the original ad.

How client-side handles it

Web GTM and GA4 have cross-domain measurement built on a "linker" — when moving between configured domains, the identifier is carried in the URL (the _gl parameter). It works, but it's fragile: a misconfigured domain, a redirect that drops the parameter, or an ad-blocker, and the journey breaks.

How server-side helps

Server-side tracking makes cross-domain more robust in several ways:

  • Server-set first-party cookies. If the domains share a common parent (e.g. shop.company.com and payments.company.com), the server can set a cookie at the company.com level and identity persists across subdomains.
  • Less dependence on URL parameters. The more robust the identification on the server, the less you rely on fragile URL carrying.
  • One place for the logic. Identity stitching and deduplication are handled centrally in the container, not in each site's configuration.

Note: for genuinely separate domains (a different registered domain), not even the server can share a cookie directly — you still need to carry the identifier across the transition. Server-side just makes the rest of the chain more reliable.

Practical advice

  • Where possible, keep the buying journey on subdomains of one domain — it simplifies identification.
  • Configure cross-domain for all participating domains so the client-side part works.
  • Test the move between domains and confirm session and identity stay connected.
  • For multi-domain operation, the Multi-domains power-up helps — see Multi-domains.

Summary

Cross-domain measurement is one of the things client-side handles worst — and where server-side brings the most peace of mind. Robust server-set first-party identification keeps the buying journey together even where the fragile linker would break. More in the complete guide to server-side tracking.

Share

A new article once a month

In-depth server-side tracking guides + case studies from the CZ market. No spam, just 1 email a month. Unsubscribe anytime.

Back to Tracking