Tracking

Register the domains you track

Tell three different domain lists apart, confirm the snippet is live, and serve the script from a host on your own domain.

Three different things in Tracking are called a domain. They are independent — adding a domain to one list does nothing to the other two — and each answers a different question.

The list	The question it answers	Where you work with it
Install domains	Which of my sites is the script actually running on?	`Install`, step 2
The tracking domain	Which host serves my script?	`Tracking domain`
Link domains	Which of my domains should carry a visitor from one to the next?	Part of the snippet

In particular, install domains are a report, not a filter: events are collected from whatever host runs your script, whether or not you list it.

Confirm the snippet is live

Install domains are the checklist you use to confirm the snippet is running. You list the hostnames you expect to track, and each turns green once an event arrives from it. You need this once, right after you paste the snippet, and again whenever you add a new site.

Open Install and go to step 2, Verify your install. Type the hostname — acme.com — and press Add.
Load a page on that domain yourself. The check is driven by real traffic; a site nobody visits never verifies.
Watch the row. It rechecks about every ten seconds while you have the page open, so a domain usually confirms within seconds.

MCP. tracking_install-domains_create, tracking_install-domains_list and tracking_install-domains_delete.

What you type is cleaned up before it is stored: lower-cased, trimmed, and a scheme, a port, a path or a trailing dot are dropped, so https://Acme.com/pricing and acme.com are the same entry. Hostnames, IPv4 addresses and IPv6 literals are accepted; anything that is not a hostname is refused with an error under the field. Adding the same domain twice changes nothing.

www is not removed. acme.com and www.acme.com are two separate entries, because they are two separate hostnames in the events your visitors send. List the one your pages actually run on.

What verified means

A domain is verified when at least one event has arrived from that exact hostname in the last 30 days. That is the whole test — there is no DNS record and no file to upload. Until an event arrives the row reads Waiting for events; once one has, it reads Script seen together with the time of the most recent one.

Because the window is 30 days, a domain that stops sending events for longer falls back to Waiting for events. That is a real signal: the snippet is no longer running there.

Domains we already see

Under the checklist, Also sending events lists hostnames that sent events in the window but that you never registered. This is where a www or subdomain mismatch shows itself, and it is how you notice a site you had forgotten. Add any of them with one click; the list holds the most recently active of them.

Removing a domain from the checklist removes it from the checklist only. The events already collected stay, and if it keeps sending events it reappears under Also sending events.

Where the checklist cannot help

Pages you do not host cannot run the script — an externally hosted checkout is the usual case — so they never appear here. Track what happens on them by sending events from your own backend instead.

Serve the script from your own domain

By default your snippet is served from the shared Lessly edge. On the Tracking domain page you can claim a host on a domain of your own instead, so the script loads from, say, analytics.acme.com. Everything else works the same either way; this is about the URL the script comes from.

Pick a domain from the list. The page lists the domains that belong to your product; adding a domain to the product is a platform step — see Serve a product on your own domain. If the list is empty, that is what is missing.
Claim a host under it. It is filled in for you as analytics. plus your domain, and you can change it. It must be a plain hostname under that domain — not an address, not a URL — and the page tells you so if it is not.
Publish the DNS records the page gives you, at your DNS provider, against the host you chose.
Press Check now as soon as your records are out, instead of waiting for the next automatic check.
Re-copy the snippet from Install once the binding reads Active. The script URL is written into the HTML you pasted, so pages still carrying the old snippet keep loading from the old host.

MCP. tracking_domains_create, tracking_domains_list, tracking_domains_verify and tracking_domains_delete.

How it is verified, and the two clocks

The script is fetched over your host and what comes back is checked to be really the script. A host that answers with a redirect, with a parked page, or with anything that is not JavaScript does not pass — a domain that merely resolves is not enough.

Status	What it means
`Waiting for DNS to publish`	The records are outstanding. Rechecks happen on their own — often at first, then further apart — and stop after 72 hours.
`Active`	A check passed. Your snippet serves from your host.
`Verification failed`	The 72 hours ran out with no check passing. The reason names what the last check got: a redirect, an HTTP status, a content type that was not JavaScript, or no answer at all.

Verification failed does not mean the host is unusable. DNS changes can take up to 72 hours of their own to reach everyone, and those two windows are unrelated — the checks may well give up while your records are still propagating. That is exactly when Retry matters: press it whenever you believe the host is ready, as often as you like. The first check that passes flips the binding to Active.

Release gives the host up. Your snippet stops serving from it and falls back to the shared edge. You can claim it again later, but DNS has to propagate again.

Treat several of your domains as one journey

If your product spans several root domains — acme.com and acme.io — a visitor who crosses from one to the other looks like two different people, because the browser keeps their identity separate per domain. The link domain group is the list of your root domains that should be treated as one journey.

What belongs in the group is your own root domains, the ones you own and want counted as one product. Entries are normalised exactly like install domains: lower-cased, trimmed and reduced to a bare hostname, so acme.io is what to write.

MCP. tracking_link-domains_create, tracking_link-domains_list and tracking_link-domains_delete.

Decoration happens only between domains that are in the group. A link to a domain you left out is an ordinary link, and the visitor arrives on it as somebody new. A group with one domain in it, or none at all, changes nothing: no cross-domain work is done and the code for it is never loaded.

The group is baked into the snippet, so re-copy it after every change — and replace it on every site in the group, including the ones you did not change. It is not fetched at run time. Install the tracking script covers the mechanics and what the script does with the group.

Next steps

Install the tracking script: what the script does with the link domain group, on both ends of a hop.
Fix a domain that never turns green: the checks in the order worth making.
Send events from your backend: for the pages the script cannot run on.
Look up a setting: the three lists, their defaults and their normalisation rules in one table.

Was this page helpful?