# What tracking does with a consent answer

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](/privacy/cookie-consent) | 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](/acquire/tracking/install).

## 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](/acquire/tracking/google-ads).

## How the script learns the answer

At start-up, before it touches a single cookie, the script looks for:

1. a `lessly_consent` cookie — the decision your banner recorded. If it is there and readable, that is the answer;
2. otherwise, a `window.LesslyConsent` object. Its presence means a banner is installed but has no decision yet, which counts as declined until the visitor answers;
3. neither — no banner on this site. This is the `No banner` state.

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_matchtype` and `_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](/acquire/tracking/identity).

## 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](/privacy/cookie-consent) 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](/privacy/cookie-consent): the other half — the product that asks the question and stores the answer.
- [Install the tracking script](/acquire/tracking/install): where the snippet goes, and why it goes there unconditionally.
- [Read the attribution reports](/acquire/tracking/reports): why declining visitors land in `Unattributed` and no setting fixes it.
- [Understand what Lessly stores about you](/privacy/data-and-privacy): the platform-wide data and privacy picture.