What tracking does with a consent answer
How the tracking script reads your banner's decision, what it collects in each state, and what a declining visitor costs your reports.
If your site asks visitors for consent, the tracking script obeys the answer. It does not ask for consent itself and it does not show a banner: it reads the decision your banner has already recorded and adjusts what it collects.
This page is not the banner
Two different products meet here, and confusing them gets your data model wrong.
| Add a cookie consent banner | This page | |
|---|---|---|
| What it is | Lessly Consent — the banner that asks the visitor and stores the answer | Lessly Tracking — the script that reads that answer |
| What it does | Shows the dialog, neutralises third-party tags by hostname, records the decision | Switches itself between full and cookieless mode, and collects accordingly |
| What you configure | Providers, categories, theme, the embed snippet | Nothing. There is no consent setting in Tracking |
You can run either without the other. Tracking reads a lessly_consent cookie and a window.LesslyConsent object — the signals the Lessly banner writes — and behaves correctly on a site with no banner at all.
Load the tracking snippet unconditionally. Do not wrap it in a consent check and do not insert it only after someone accepts. A visitor who declines, or who leaves without answering, is still worth counting; gating the tag hides those visitors completely, which is exactly the blind spot this behaviour exists to remove. Install your banner’s tag above the tracking snippet — see Install the tracking script.
The three states
Consent belongs to the individual event, not to the visitor. One person in one session can produce events in more than one state, and they are kept apart.
| State | What it means | What the script does |
|---|---|---|
| Granted | Your banner recorded a yes to statistics | Full mode |
| Declined | Your banner is on the page and the answer is no — or there is no answer yet | Cookieless mode |
| No banner | The site runs no consent banner at all | Full mode |
Declined and No banner are never merged. “The visitor said no” and “nobody was ever asked” are different facts, and reporting the second as the first would tell you people refused when they were never given the choice.
Two answers are read. Statistics decides whether the script may use cookies and identify the visitor at all. Marketing decides only what is told to Google Ads about a click — see Close the loop on Google Ads.
How the script learns the answer
At start-up, before it touches a single cookie, the script looks for:
- a
lessly_consentcookie — the decision your banner recorded. If it is there and readable, that is the answer; - otherwise, a
window.LesslyConsentobject. Its presence means a banner is installed but has no decision yet, which counts as declined until the visitor answers; - neither — no banner on this site. This is the
No bannerstate.
Order matters on the very first page view of a visit. If the tracking script runs before your banner’s tag, it sees neither signal and treats that visit as No banner; from the next page load on, the cookie exists and the correct mode is picked.
What is collected with consent
Everything described in the rest of the Tracking documentation: page views, your own events with their properties, the anonymous id and session id in cookies, form capture, cross-domain linking, and the full page URL with its campaign tags and advertising click ids. Nothing about consent changes it.
What is collected without it
In cookieless mode the script writes no cookies at all and mints no identifiers. There is no anonymous id, no session id, no cookie-domain probe, no cross-domain linking, and form capture is not installed. Each event becomes a small ping carrying only:
- the event name and the time;
- the page URL cut down to its origin and path — the query string is discarded in the browser, so nothing from it ever leaves the visitor’s machine;
- the referrer cut down to its origin;
- the campaign tags, and only these:
utm_source,utm_medium,utm_campaign,utm_content,utm_term, and the suffix markers_lt_campaign,_lt_adgroup,_lt_creative,_lt_keyword,_lt_network,_lt_matchtypeand_lt_extid.
That list is exhaustive, not a pattern. _lt_device is left out because it describes the visitor’s device rather than the campaign, and advertising click ids such as gclid are left out entirely.
What it costs you:
| You lose | Consequence |
|---|---|
| Properties | The properties you pass to lt('track', …) are dropped. The event name and the fact that it happened still arrive |
| Identity | A call to lt('identify', …), and any form the script would have captured, is dropped whole rather than sent stripped |
| The person | A cookieless event never creates or joins a person, so it never appears on People, in a journey, or in the reports that count people or credit revenue to a source |
| The click id | A paid click from a declining visitor cannot be tied to the conversion it later produced |
What you keep: the click is still counted. Cookieless pings are stored, appear in the event catalog and in Live, and count towards paid tracking health on the Google Ads page — so a campaign’s real traffic is visible even when most visitors decline.
Counting people without identifying them
To count people among declining visitors without storing anything that identifies them, a key is derived on arrival from a secret that is destroyed every UTC midnight. Tomorrow the same visitor gets a different key.
The consequence is not a footnote:
- a unique-visitor count over more than one day is overstated for this traffic — someone who visits on ten days counts as ten people, and the longer the range the worse it gets;
- returning-visitor, retention and frequency analysis do not work on this traffic at all, because the identity that would link the days was never created.
Nothing recovers the exact figure afterwards. For an exact count of people, ask for a single UTC day. The one place a number is put on how much of your traffic this affects is paid tracking health on the Google Ads page, which says how many of the paid clicks in its window were cookieless.
When consent changes during a visit
Your banner signals the change and the script acts on it immediately, without a page reload.
A visitor who accepts moves to full mode at once: the identifiers are minted there and then rather than waiting for the next event, so the rest of the visit is tracked normally. Cross-domain linking comes back in the same moment. Form capture is the one thing that waits for the next page load.
A visitor who withdraws moves to cookieless mode at once, and the script deletes the _lt_aid and _lt_sid cookies it wrote. From that moment its events are pings.
In both directions, events already sent are never revisited. They keep the state they were collected under. Data gathered before consent was granted is not retroactively enriched, and data gathered before a withdrawal is not deleted by the withdrawal — it was collected under an answer that was valid at the time. To remove a person’s data, delete the person.
Sites with no banner
If you run no consent banner, nothing is lost: the script behaves exactly as it does in full mode, and the events carry no consent answer at all rather than a fabricated one. Consent management is not something Lessly Tracking does for you — that is the banner’s job.
Events sent from your backend
Consent describes a browser visit. Events you send from your own backend with an API key — revenue and the other lifecycle events — carry no consent answer and are stored as unknown. Deciding whether you may send them is yours.
Keeping the script current
You do not re-paste the snippet to pick up consent handling or any other change. The script keeps its filename and is served with a short cache lifetime, so an existing install picks up a new version within about ten minutes.
Next steps
- Add a cookie consent banner: the other half — the product that asks the question and stores the answer.
- Install the tracking script: where the snippet goes, and why it goes there unconditionally.
- Read the attribution reports: why declining visitors land in
Unattributedand no setting fixes it. - Understand what Lessly stores about you: the platform-wide data and privacy picture.