Cookie declaration
AdPix generates its own cookie list per property so you can drop it into your privacy or cookie policy. This page opens that list up in full: every cookie the tracker and the collector write, its purpose, its lifetime, and the category it sits under.
Where the declaration lives and what builds it#
The Cookie consent page — /cookie-consent — has three tabs: Builder, Consent log and Cookie declaration. The third is a ready-to-publish table with six columns: Cookie / storage, Provider, Category, Purpose, Expiry and Type.
Two sources fill it:
- AdPix's own cookies, self-described. A small set of rows built into the product rather than discovered by a scan, so the table has content on day one, before any traffic. It is a starting point, not a complete inventory — it does not list every cookie and storage key in the tables below.
- The property's cookie catalogue. Rows recorded for this property are added to the table, and a row whose name matches one of the AdPix rows overrides it. A row that has been set aside is not shown at all. This is where anything the built-in set misses belongs.
No automatic scan runs against your pages today, and the last-scan value is empty. That means any cookie set by the other tools on your site — an ad pixel, a chat widget, an embedded video, another analytics tool — is not in this table. The declaration you publish has to cover those too, and that part you write yourself.
The category label prints in English in this table (Necessary, Statistics, Marketing). The same categories appear to visitors in the consent banner under whatever locale the banner is set to.
Every cookie AdPix writes#
There are two writers: the tracker inside the page, and the collector that receives events. The tables below are what actually gets written. Compare the generated list in the console against these names before you publish it.
Cookies the tracker writes#
| Name | What it holds | Lifetime | Category |
|---|---|---|---|
__sov_did |
The visitor's anonymous ID — a random value carrying no identifying information | 365 days | Statistics |
__sov_ft |
First touch: source, medium, campaign, content, term, click-ID type, landing path, referrer and timestamp | 365 days | Marketing |
__sov_lt |
Last campaign touch, same shape; updated only when the page URL carries campaign parameters | 90 days | Marketing |
cc_cookie |
The consent choice: accepted categories, revision number, config version, mode, consent ID and timestamp | 182 days by default | Necessary |
_svp |
Probe cookie used to find the broadest writable domain; its value is only 1 |
Until the browser closes | No identifier |
_apxcp |
The same probe, this time from the consent banner bundle | Until the browser closes | No identifier |
__sov_test |
Only when the tag was initialised in test mode | Until the browser closes | No identifier |
cc_cookie carries the one lifetime you set yourself: the Consent expiry (days) field on the Builder tab.
Cookies the collector writes#
| Name | What it holds | Lifetime | Category |
|---|---|---|---|
__sov_aid |
The visitor's anonymous ID, as the server sees it | 365 days, matching the attribution window | Statistics |
__sov_ses |
Session ID and last-activity time, as <id>|<timestamp> |
30 minutes, rolling | Statistics |
These two are written only when the request is genuinely first-party — Tag Gateway on your own subdomain, or a single-domain deployment. On a direct install the request is cross-domain as far as the browser is concerned, and the collector sets no cookie on that path at all.
Every cookie above is written with Path=/ and SameSite=Lax on the broadest registrable domain the browser allows, so that shop.example.com and www.example.com count as one visitor. None of them is HttpOnly, because the tracker has to be able to read them. None of them holds an email, a phone number, a name or an IP address.
The cookie AdPix only reads#
__sov_x is the opt-out cookie. When its value is 1 the tracker sends nothing and the collector discards any event that arrives with it. AdPix does not create this cookie; you do — behind a "do not track me" control in your footer, for instance — and its lifetime and domain are yours to choose. If your privacy policy promises such a control, this cookie is how you implement it.
Things that are not cookies but stay on the device#
The declaration's first column is Cookie / storage, because part of what AdPix stores is not a cookie. If your cookie policy has a local-storage section, these belong there:
| Key | Where | What it holds |
|---|---|---|
__sov_aid |
Local storage | The same anonymous visitor ID; survives when cookies are cleared or shortened |
__sov_q |
Local storage | The queue of not-yet-sent events, capped at 200, so a hard page close loses nothing |
__sov_em |
Local storage | The last known-good stream config: enhanced measurement, internal domains, the heatmap block and consent metadata |
_apx |
URL parameter | Hands the visitor ID between your own domains, as <id>.<timestamp> |
_apx does not stay on the device: it is valid for two minutes after it is created and is validated before use. Handing it over sits under the Marketing category and does not happen without it.
What rejecting each category actually stops#
A declaration is not just a list; it is a claim the product has to stand behind. Here is the behaviour:
| Category | On accept | On reject |
|---|---|---|
| Necessary | cc_cookie is written |
Always on, cannot be rejected |
| Statistics | __sov_did, __sov_aid and __sov_ses are created, page views and events are sent, the heatmap bundle loads |
No ID is written or persisted and no event is sent; an ID already on the browser is read, never rewritten |
| Marketing | __sov_ft and __sov_lt are written, cross-domain handoff and fingerprint enrichment are active |
None of that happens |
| Preferences | AdPix writes no cookie of its own for this category | — |
In Opt-in — EU/EEA mode every non-essential category stays shut until the visitor chooses. In Opt-out — rest of world mode they are open until the visitor rejects. Each category is described in Consent categories.
Before you publish#
The records behind the declaration#
The declaration says what gets written; the Consent log says what each visitor actually chose. Every consent action is stored with its timestamp, consent ID, accepted and rejected categories, mode, revision number, locale, and a hash of the exact banner configuration the visitor saw. The IP address is hashed and never kept raw. The same tab exports to CSV and JSON.
AdPix gives you the list, the records and the gates. What your privacy policy has to say, and what you are obliged to do, is a decision to take with your own legal counsel.
The full technical table — headers, the exact rules for server-side cookie writes, and cache values — is in Cookies and headers. How long each class of data lives on the server is covered in Data retention.
Frequently asked questions#
Does the declaration find cookies set by the other tools on my site?
No. No scan runs against your pages today, and the last-scan value is empty. The declaration builds AdPix's own cookies from the product itself and merges in whatever rows the property's cookie catalogue holds; an ad pixel, a chat widget or another analytics tool you installed does not appear there and has to be added to your cookie policy separately.
Are AdPix cookies third-party cookies?
No. All of them are written on your own site's registrable domain, so they are first-party and third-party cookie blockers do not remove them. Identity across different domains is not built from a shared cookie either — that happens server-side.
Do the cookies store a visitor's email or phone number?
No. The cookies hold an anonymous ID, a session ID, campaign parameters and the consent choice. An email or phone number only enters AdPix when the visitor types it into a sign-in or sign-up form, and it goes straight to the server — never into a cookie.
What happens to the cookies when a visitor rejects the statistics category?
The consent banner deletes __sov_did and __sov_ses at that moment and removes the ID key from local storage; rejecting Marketing deletes __sov_ft and __sov_lt. After that the tracker's own gates stay shut, so none of them is recreated.
Thanks — your feedback helps us improve the docs.