Skip to main content

​
What this lets you do

Recognise the same visitor as they move across your subdomains (for example www.example.com, app.example.com, shop.example.com) so an AI-referral touch on one subdomain is attributed to a signup or purchase that completes on another. Without this, each subdomain mints its own visitor ID and one person is counted as several visitors. This is off by default and you turn it on explicitly in Settings. The rest of this page explains what confirming it sets, how to change it, and when it does not apply.

​
Subdomains are not cross-domain

These are two different situations, and only one of them is solved by a cookie:
  • Subdomains of one registered domain (www.example.com, app.example.com): same site, solved with one shared cookie. This page.
  • Separate registered domains (example.com and example-checkout.com): genuinely cross-site. Cookies cannot bridge them; you pass the visitor ID in the link between the two domains. That is not covered here.

​
What we set, and when

Creating a site turns this on only if you fill in Cookie domain in the Add site form, which we strongly recommend. Otherwise we compute a suggestion: we take the domain you entered and derive your registered (apex) domain from it (app.example.com gives example.com; example.com gives example.com) and pre-fill it into Cookie domain under the site’s Settings → Cookies, unconfirmed. Nothing is applied until you save that field. Once you do, the value goes on every snippet the install page hands out, as data-cookie-domain:
data-cookie-domain broadens the identity and cart cookies (_traceten_vid, _traceten_sid, _traceten_cart) to Domain=example.com so every subdomain reads the same values. A broadened cookie also gets your site key appended to its name, so in the browser you will see _traceten_vid_7Rb4TrC1 rather than _traceten_vid. That is what stops two Traceten sites under one registered domain from sharing a visitor, since the wider cookie is visible to both. _traceten_optout keeps its plain name on purpose, so an opt-out covers every site under the domain. Update every copy of the tag at once. Because the cookie name follows the scope, a page still serving an older tag without data-cookie-domain writes _traceten_vid while your updated pages write _traceten_vid_7Rb4TrC1. Neither reads the other, so a visitor moving between them is counted as a new person each time. If you cannot deploy every template together, expect visitor counts to run high until you have. Two more consequences of a shared domain worth knowing, both of which follow from any subdomain being able to write these cookies:
  • A page on a subdomain you do not control can set _traceten_optout for the whole domain, which silently stops measurement on your main site. It fails toward the visitor’s privacy rather than against it, which is why it is not blocked.
  • The same page can set _traceten_consent, which your Consent Management Platform also writes and which is not per-site. Traceten reads it to decide whether the consent-gated signals are collected.
Cookies are written to each exact host, with no attribute on the snippet, unless you set a cookie domain when adding the site, confirmed one under the site’s Settings → Cookies, or connected a Shopify store. Host-only is the default for every site, new or existing. Two things stop it from applying even once you do:
  • Your domain has no registered domain a browser would accept, such as localhost or a bare IP address. In that case Settings has nothing to suggest and the field stays empty.
  • You cleared the field yourself, after previously confirming a value.
We derive the suggestion from the Public Suffix List, so a store on a shared platform stops at your own boundary. A Shopify store at mystore.myshopify.com is suggested mystore.myshopify.com, never myshopify.com, which is shared with every other merchant on the platform.

​
Shopify sets this for you

Connecting a Shopify store is the one case where Traceten confirms a value rather than suggesting one, because a Shopify business usually runs on two properties: content on example.com and the store on shop.example.com, or the reverse. AI assistants cite the content and the purchase happens on the store, so host-only cookies would count one buyer as two strangers. Two details worth knowing:
  • The domain comes from the storefront Shopify reports, not from whatever you typed as the site’s domain. Only Shopify knows which host your buyers actually browse.
  • It is applied only to a site the domain can genuinely cover. A store on mystore.myshopify.com and a content site on example.com are different registrable domains, so no cookie spans them, and Traceten writes nothing rather than a setting that looks applied and covers nothing.

​
Changing it or turning it off

Open your site in the dashboard, go to Settings, and find Cookie domain under Cookies. It shows a suggested domain if we could compute one and none is confirmed yet, or your currently confirmed value otherwise. Enter a different domain and save to confirm it, or clear the field to write cookies to each exact host. Clearing changes what the snippet writes from then on. It does not reach into browsers and withdraw a cookie already stored at the wider scope: that one stays until it expires, up to a year for _traceten_vid, 30 minutes for _traceten_sid and 24 hours for _traceten_cart. Expire them yourself from a page on your domain if you need them gone sooner. Two reasons to clear it:
  • You do not control every subdomain under your domain. The cookies can be read and written on all of them, and the snippet trusts the visitor ID it finds, so a subdomain you do not control could set one. They hold pseudonymous identifiers, never a name, email address or password, though on a Shopify store _traceten_cart holds the checkout token.
  • You run more than one Traceten site under the same domain, for example a separate site for blog.example.com and another for app.example.com. Those two sites then share the same session cookie, and its 30-minute window is refreshed by activity on either one, so both sites report longer sessions and fewer of them. The better fix is one Traceten site for the whole domain: you can still see each host separately in the hostname breakdown, and you get the cross-subdomain journey as well.
The value is validated against the page it runs on. If the current host is not the domain you set or a subdomain of it, the snippet ignores the attribute and keeps cookies host-only, so a staging host on a different domain degrades quietly instead of misfiring. If you do set a value a browser refuses (a public suffix such as co.uk, which nobody owns), the snippet notices the cookie did not stick and rewrites it host-only. Cross-subdomain identity is lost, but tracking on that page keeps working. Set it to the domain you actually own.

​
Install the same snippet on every subdomain

The snippet is per-page, not per-domain. A subdomain served by a codebase that does not include the script tag emits no events, even though it can read the shared cookie. Add the same tag (same site key, same data-cookie-domain) to the <head> of every subdomain you want to appear in reports. The shared cookie still carries across a subdomain that has no snippet: the visitor ID set on www is present on app, so the moment app does include the tag, continuity is preserved. Use one site key across all your subdomains. Do not create a separate site per subdomain. You do not have to show a cookie banner on every subdomain. A consent decision collected once can be honoured across all subdomains of one registered domain, because it is the same data controller (you) and the same purposes. The mechanism is your Consent Management Platform (CMP), not Traceten. Configure your CMP to write its consent cookie scoped to the apex (Domain=example.com). Then the banner remembers the choice everywhere and Traceten reads the resolved state on each subdomain (the snippet auto-detects OneTrust, Cookiebot, and IAB TCF v2.2). See Consent mode. If you use a custom banner instead of a supported CMP, write your consent signal to an apex-scoped cookie yourself so sibling subdomains inherit it, and call traceten.resolveConsent() on each subdomain as described in Consent mode. Only do this if you control every subdomain under the apex: a consent-granted signal broadened this way unlocks the extra fingerprint-class signals (Consent mode) on every subdomain that inherits it, whether or not a visitor actually saw a consent banner running there. The same caveat applies here as to data-cookie-domain generally: an untrusted subdomain that can write the cookie can grant itself consent it was never given. Opting out propagates on its own. _traceten_optout is scoped to the same domain, so a visitor who opts out on one subdomain is opted out on all of them.

​
Third-party auth and checkout redirects

Flows that leave your domain and come back (a hosted login, a payment processor) do not break identity, as long as they return to your domain:
  • On the third-party page you do not control, no events fire. That is expected.
  • Your _traceten_vid cookie is not deleted while the visitor is away. When they return to a page on your domain that has the snippet, tracking resumes with the same visitor ID.
  • If the third party is served under your own domain (a reverse-proxy path or a subdomain like accounts.example.com), the shared cookie is readable throughout, so the round trip is seamless.

​
Verify it worked

  1. Open www.example.com, accept cookies, and look under Application, Cookies for a cookie whose name starts with _traceten_vid. With cross-subdomain cookies on it carries your site key, for example _traceten_vid_7Rb4TrC1. Note its value and its Domain column.
  2. Navigate to app.example.com. The value should be identical, under the same name.
  3. In the dashboard, a session that spans both subdomains appears as one visitor, not two.

​
Troubleshooting

  • Each subdomain shows a different visitor ID. The tag on one of them is missing data-cookie-domain, or carries a different value. Copy the tag from the install page again and confirm every subdomain has the same one.
  • The Domain column on the cookie shows the exact host, not your domain. Either the page host does not belong to the domain you set (the snippet then ignores the attribute), or the browser refused the value and the snippet fell back to host-only. Check the value is the domain you own.
  • The banner re-appears on each subdomain. Your CMP is writing its consent cookie host-only. Scope it to the apex.
  • A subdomain records no events. The snippet is not installed on that subdomain’s pages. Add the tag to that codebase.
  • Sessions look longer than they are, across two of your sites. You have two Traceten sites under one domain sharing a session cookie. See “Changing it or turning it off” above.

​
Next