Lead attribution · cross-domain
Cross-domain tracking: one journey, from the blog to the app
Cross-domain tracking in Skald carries one anonymous visitor ID from your main site to its subdomains, your other domains and your booking links, so a lead made on the app still shows the blog post that started it.
Cross-domain tracking is following one browser's anonymous journey across more than one site you own. Skald does it with one random visitor ID: a first-party cookie for subdomains, an skv link parameter for other domains, and utm_content for Calendly.
30-day free trial · no card · we set it up within one working day · free to self-host
- www.example.com/blog/attribution/ · from perplexity.aiThe tag makes the ID and keeps it in local storage, a small store the browser keeps for that one site.
- app.example.com/signup/shared cookie skald_vid on example.com, with sharing on
- example.net/start/link ?skv= on the click; the tag there keeps it and cleans the address
- calendly.coma demo bookedutm_content on the Calendly link, back in Calendly's webhook
hosts 4visitor ID skv_Q2xh… (1)journey whole
Sample journey. Each hop is how Skald's script tag carries the same random ID. Visitor IDs are off by default.
[01] the skv link
Carry the visitor ID to another domain, never from a stranger's link
A link to your other domain gets ?skv= and the ID. The tag on the other side keeps it only from a domain you listed, or when you told it to accept, then takes skv out of the address bar so it is never bookmarked or shared. It is what keeps a journey whole in lead attribution.
change where it came from
tag on example.net: data-link-domains="example.com" · came from example.com
Kept
The visitor came from example.com, a domain this tag lists. The ID becomes this browser's ID on example.net, so the journey goes on.
- visitor ID here
- skv_Q2xh… (the same journey)
- address bar
- skv taken out, plan=team stays
Sample addresses. The rule, from Skald's script tag: keep a valid skv only with data-accept-id on, or when the referrer's host is, or ends in, a domain this tag lists. With Wait for consent, the ID is kept only after yes; the address is cleaned at once either way.
[02] subdomains share one cookie
Share one visitor ID across www and app: see which domain the cookie lands on
With Share across subdomains on, the ID is also kept in a first-party cookie, one set by your own domain, named skald_vid, for up to 400 days, so every subdomain reads the same one. Type a host to see the domain the tag gives that cookie.
If your host refuses the cookie (some free hosting addresses do), the ID still works on each subdomain on its own.
type a host or pick one
Rule 1: the tag's data-site, example.com, holds this host, so the cookie goes on example.com.
skald_vid=skv_Q2xh…; path=/; max-age=34560000; domain=example.com; samesite=lax; secure
The tag's own rule: data-site when it holds the host; none for an address or a one-word host; else the last two labels, or three after co.uk, com.au and the like. max-age 34,560,000 seconds is 400 days.
[03] no tag change
Your developer cannot edit the tag? Switch sharing on in Skald.
An admin turns on Share the ID across subdomains in Settings > Sites > Script tag. The tag learns it from Skald's answer to a page view and remembers that answer for a day, so each browser starts sharing on its next visit, or at the latest a day later.
- 0 hYou switch it on in SkaldThe tag on your pages stays exactly as it is.
- 22 more hoursThe tag trusts its stored answerskald.sh says "0" and is less than a day old, so it does not ask yet and shares nothing.
- next page viewThe page view asksSkald answers it with the header
X-Skald-Sh: 1. - same pageThe answer is kept, the cookie written
skald.sh= "1" and the time, for a day;skald_vidon example.com, for 400 days. - app.example.comThe app reads the same IDA sign-up there joins the blog visit that started it.
Switching it off works the same way: within a day, each browser stops sharing and deletes the shared cookie. It needs visitor IDs on for the site.
[04] consent and Do Not Track
Cross-domain tracking that stores nothing until the visitor says yes
Visitor IDs are off by default and turned on per site. Where consent comes first, tick Wait for consent: the tag sends nothing and keeps no ID until your banner calls skald('consent', true). Pick a state to see what the browser holds.
| Where | Key | Value |
|---|---|---|
| Local storage | skald.vid | skv_Q2xhc3NpY0V4YW1wbGVJRA |
| Session storage | skald.src | perplexity.ai |
| Local storage | skald.sh | 1|1792540800000 |
| Cookie · example.com | skald_vid | skv_Q2xh… · 400 days |
| Nothing stored by Skald | ||
The ID, the visit's source for this tab, the sharing answer, and the shared cookie because sharing is on. Events are sent with the ID.
Sample values. The ID is random: no name, no email, no address. skald.src is the visit's referring host and utm_source, for this tab only.
[05] where it stops
Where a cross-domain journey still breaks
The ID follows a browser, not a person. A new phone, a cleared browser or a private window starts a new journey.
What it does not do
- It is off until you turn it on: visitor IDs are off by default, and sharing across subdomains is a choice on top.
- The ID belongs to one browser. A new device or browser gets a new ID, and Skald never links it to the old one.
- A shared cookie needs subdomains of one domain. Between different domains the ID travels only in a link you click.
- A Calendly popup opened only from your own JavaScript is not changed, and a Calendly link that already has a utm_content keeps it; those bookings have no journey.
- The ID carries no name. An address tied to a lead by the form it sent is likely, never certain; owners and admins only, audit-logged.
keep reading
More on cross-domain tracking
questions
Cross-domain tracking FAQ
Straight answers, including what Skald does not do.
Does Skald set a cookie for cross-domain tracking?
Only for subdomains, and only when you ask for it. With Share across subdomains on, the visitor ID is also kept in a first-party cookie named skald_vid, for up to 400 days, so www and app see the same ID. Without it, the ID lives in the browser's local storage on each site.
How does the ID move to a different domain?
List the other domain in data-link-domains. When a visitor clicks a link to it, the tag adds ?skv= and the visitor ID. The tag on the other domain keeps that ID and takes skv out of the address bar, so it is not bookmarked or shared.
Can someone fake a visitor ID with a link?
The other domain takes the ID only when the visitor came from a domain listed in its own Other domains you own, or when it is set to accept the ID with data-accept-id. Any other skv is ignored and left alone.
What about consent, Do Not Track and Global Privacy Control?
When the browser sends Do Not Track or Global Privacy Control, the tag does nothing at all: no ID, no cookie, no event. With Wait for consent, the ID is kept only after your banner calls skald('consent', true). skald('consent', false) deletes the ID and the cookie.
How do Calendly bookings join the journey?
With visitor IDs on, the tag adds the visitor ID to every Calendly embed and link on your page as utm_content. Calendly sends it back in its webhook, so the booking joins the visit. A link that already has a utm_content is left alone, and that booking has no journey.
Is cross-domain tracking on by default?
No. Visitor IDs are off by default and switched on per site, and sharing across subdomains is a separate choice on top. Turn them on only when your privacy notice says so.
$ tail -f access.log | skald
See what AI does with your site. Free for 30 days.
No card. We set up hosted Skald for you within one working day, or you self-host it free. Every line of your log, sorted and added up.