Consent categories
AdPix is the tracker, so it enforces consent at the source rather than asking other tags to behave. Each category opens exactly one thing, and every event carries the categories that were accepted at the moment it was collected.
The four categories#
The AdPix consent banner has four categories. Necessary is always on and the visitor cannot switch it off; the other three are theirs to choose.
| Category | What the __sov tracker opens with it |
|---|---|
| Necessary | Always on. The tracker gates nothing on it. |
| Preferences | AdPix ties no behaviour to it. It is there for cookies your own site sets. |
| Statistics | Page views, events, the anonymous id and session cookies, identify and form auto-identify, heatmaps. |
| Marketing | Attribution cookies (first and last touch), the cross-domain id handoff, fingerprint enrichment. |
Preferences is deliberately empty on the AdPix side: nothing of ours depends on it, yet it is still shown to the visitor, written into the consent record and stamped on every event — so that if you set preference cookies of your own, you hold the legal basis for them.
Identifying a visitor follows the same tier that page views and events follow. Under marketing it would silently drop every sign-in and sign-up from a visitor who accepted statistics only.
Two modes, and how opt-in fails#
In the consent builder, Default mode is one of two:
- Opt-in — for the EU and the EEA. Until the visitor chooses, nothing non-necessary runs.
- Opt-out — for the rest of the world. Until the visitor rejects, everything runs.
The important part: opt-in fails closed. An unresolved state — banner not up yet, visitor has not chosen, or their stored choice does not match the current revision — behaves exactly like a rejection. No page view goes out, no anonymous cookie is minted, no heatmap capture starts.
If the banner loads late, or the visitor closes the page without choosing, that visit is never recorded. The drop is real and it shows up in the reports. Set expectations with your team before turning opt-in on.
Every event carries its own categories#
With each event the tracker sends the list of categories accepted at that moment, and the collector stamps that list onto the event row. Rejected categories are not written at all — their absence is what "not accepted" means.
The effect is that every row of data carries its own legal basis. You never have to reconstruct what the settings were on a given day; it is written on the row.
When a visitor rejects a category#
Two things happen back to back, at the moment of the choice.
First, the cookies belonging to the rejected category are cleared immediately: rejecting statistics drops the anonymous-id cookie and the session cookie and removes the matching key from browser local storage; rejecting marketing drops the first-touch and last-touch cookies.
Second, the tracker's own gates stay shut, so none of those cookies is re-created. Without statistics consent the tracker will not even write a visitor id: if one is already present on the browser it only reads it, and otherwise it uses a temporary id held in that page's memory and stored nowhere.
A new choice takes effect at once — no page reload is needed. If the visitor accepts statistics, that same page view is sent immediately.
Revision: when the policy changes#
Every consent configuration carries a revision number, and every stored visitor choice carries the revision it was made under. If the choice's number is lower than the current one, the choice is stale: it is ignored, the banner comes back, and until a new choice is made the unresolved rule applies — which under opt-in means closed.
Bump the revision when the categories or their meaning change, not when you recolour a button.
What the consent record keeps#
Each time a visitor accepts, updates or withdraws, one record is stored: timestamp, consent ID, accepted and rejected categories, mode, revision, a hash of the exact configuration the visitor saw, locale, the IP address as a hash, and the browser's user agent.
The raw IP address is never stored. The write is idempotent on the consent ID, so a retried request never creates a duplicate row, and this endpoint never returns an error into your page: even if the record fails to store, the visitor's choice is already valid in their own browser.
When the module is off#
If cookie consent has not been enabled for a property, all of these gates are inert and the tracker behaves exactly as it did before. Nothing is stamped on the events either. That is the default state of a new property.
Turning it on and building the banner happens in Cookie consent; the full path is in set up the consent banner. If data drops after you enable it, see consent is blocking data.
Frequently asked questions#
Is anything collected before the visitor touches the banner?
It depends on the mode. Under opt-in, no - no page view is sent and no cookie is minted until a choice is made. Under opt-out, yes - everything runs until the visitor rejects a category.
If someone rejects statistics, what happens to their id?
No durable id is written. The tracker sets no cookie and writes nothing to local storage; if an id is already present it is only read, and otherwise a temporary in-memory id is used for that page and disappears when the page is closed.
Are already-collected events deleted when consent is rejected?
No. Rejecting or withdrawing consent stops collection from that moment and clears that category's cookies, but it does not remove what was already recorded. Deleting data is a separate path.
After editing the banner text, do I have to re-ask everyone?
Only if you bump the revision number. Once you do, every earlier choice counts as stale, the banner reappears, and until a new choice is made the tracker behaves as if consent were unresolved.
Thanks — your feedback helps us improve the docs.