Track events

Tracking across domains

Your visitor reads about rooms on hotelli.com and pays on varaamo.com. Link the two in Servoki and that is one visit, one visitor and one conversion — with the same snippet on both domains and nothing to change in it.

When you need this

Only when one visit moves between domains you control: a booking engine, a checkout or payment page, a support portal, a second brand domain. Subdomains of your own domain (www., shop.hotelli.com) are already one site — nothing to do. A partner site you do not run is a referrer, and should stay one.

Set it up

  1. Put the same snippet on every domain. Copy it from Settings › Tracking & install; the data-site value stays the same everywhere.
  2. Link the domains in Servoki. In the same place, under Domains, add the other hostname — or click Link next to it if Servoki already sees events arriving from it. Tick the statement that the domains are one site with one privacy policy and one consent prompt.
  3. Check. Check snippet fetches a page on the linked domain and confirms the script is there; the status pill shows when events arrive.

What changes

  • Traffic between the linked domains is no longer a referral, so hotelli.com stops appearing in its own Referrers report and the booking pages keep the campaign that brought the guest.
  • Clicks between them are no longer outbound clicks.
  • Each domain appears under the new Hostname dimension: a card on Behavior › All pages, a host: filter chip, a secondary dimension, and a View filter — a "hostname view" is the classic Google Analytics way to report on one domain at a time.
  • Sessions and visitors are counted once across the domains. In the default cookieless mode this already holds by construction; with first-party collection, the identity is carried across the boundary as described next.

How the identity crosses over (first-party mode)

With a verified custom collection domain and consent, Servoki identifies the visitor with a first-party cookie on that domain. A page on the linked domain cannot see that cookie, so the script carries the identity in the link instead: when the visitor clicks a link (or submits a form) that leads to a linked domain, a short-lived encrypted parameter, ?_svk=…, is appended at that moment. The page on the other side reads it, keeps it for the rest of the visit in that tab, and sends it with every event. Nothing is stored on the linked domain beyond the browser tab, and no cookie is set there.

Links and forms are handled automatically. If your booking widget navigates from JavaScript, ask for the decorated URL yourself:

// Navigating to a linked domain from JavaScript
location.href = window.servoki.decorate('https://varaamo.com/h/hotelli?room=12');

servoki.decorate(url) returns the URL unchanged when the destination is not a linked domain or there is nothing to carry, so it is always safe to call.

Consent travels with the link. The parameter can only exist after the visitor accepted your consent prompt, and you have declared the domains to be one site. A consent banner on the linked domain that reports "denied" by default at load does not cancel it; an explicit withdrawal there (servoki('consent', false) after a grant on the same page) does. Servoki adds a sentence about this to the privacy-policy text in Identity center once domains are linked.

Good to know

  • The hand-off needs first-party collection and consent. Without them, cross-domain stitching relies on the cookieless daily identifier, which breaks when the visitor's IP changes or at UTC midnight — exactly as on a single domain.
  • The parameter is good for one hop from a clicked link. A page on the linked domain opened later from a bookmark or history starts a new visitor.
  • Goals and funnel steps match paths, not hostnames. Give the domains distinct paths, or scope a View with a host: filter.
  • Google Analytics called this cross-domain tracking and the exclusion list referral exclusions; here both are one setting.