Cookies and headers

Two writers, and one of them is usually silent#

Two things can write a cookie on your visitor's browser.

The tracker, which is the JavaScript inside the page and creates cookies with document.cookie. Its public global is window.ap(), and window.__sov() is another name for the same function.

The collector, which answers with a Set-Cookie header. In the default deployment this writer is completely silent: when an event goes from your domain to the collector's domain, the request is cross-origin as far as the browser is concerned and its cookie would be a third-party cookie — something browsers either drop or partition. So the collector sets no cookie at all on that path, and identity rides on the durable ID in local storage. Only when the traffic is genuinely first-party — Tag Gateway on your own subdomain, or a single-domain deployment — do the server-side cookies come back.

None of these cookies holds an email, a phone number or a name.

Cookies the tracker writes#

All of these are written with Path=/ and SameSite=Lax, on the widest registrable domain the browser will allow. The tracker finds that domain at startup with the _svp probe cookie, working from a two-part domain outward to a three-part one, because browsers reject public suffixes like .co.uk. The result is that shop.example.com and www.example.com see one ID and one first touch.

Cookies the collector writes#

Both are written with Path=/ and SameSite=Lax on the domain the collector is configured for. __sov_ses is refreshed on every event; 30 minutes of inactivity means the next session is a new one.

The rule for writing these two is simple:

When no server-side cookie is written, the session is computed from the browser's durable ID and the same 30-minute window, not from a cookie.

The cookie AdPix only reads#

__sov_x is the opt-out cookie. If its value is 1, the tracker sends no events and the collector discards any event that arrives with it — and still returns a 200. AdPix does not create this cookie; you do, for example behind a "do not track me" link in your site's footer. Its lifetime and domain are yours to choose.

Things that are not cookies#

The _apx parameter is accepted for only 2 minutes after it is created, and its value is validated before use, so nobody can attach an arbitrary ID to a visitor with a tampered link. This transfer sits under the marketing category and does not happen without it.

Without "statistics" consent the tracker writes neither __sov_did nor the local storage key: if an ID is already on the browser it only reads it, otherwise it creates a temporary in-memory ID for that page which is never stored anywhere.

When consent is rejected#

At the moment the choice is recorded, the consent banner itself clears the rejected category's cookies:

• Rejecting "statistics" → __sov_did and __sov_ses are deleted and the __sov_aid key is removed from local storage.
• Rejecting "marketing" → __sov_ft and __sov_lt are deleted.

After that the tracker's own gates stay closed and none of them are recreated. A __sov_aid cookie written by the collector is not part of this cleanup, but since no event is sent from that moment on, the collector never refreshes it and it expires on its own. What each category means is in Consent categories, and the publishable declaration is generated under Cookie consent → Cookie declaration.

Request headers#

The visitor's IP address is resolved in this order: Ar-Real-Ip first, then X-Real-IP, then the first public address inside X-Forwarded-For — private addresses are skipped so a proxy's internal address is not recorded instead of the visitor's — and finally the connection's own address.

Response headers#

The collector returns these on every path:

An OPTIONS request is answered with 204. The Access-Control-Allow-Credentials header is deliberately not sent: when the origin is reflected, granting credentials to any origin is a full vulnerability. Its practical consequence is exactly what was said above — no cookie is exchanged at all on the cross-origin path, and the durable ID does all the work.

Two cache values are worth noting: the tracker files are cached for five minutes, but the stream configuration for only one — because the consent block arrives in that same response, and a change to it has to reach live visitors within about a minute, not five.

The console cookie#

ap_admin is the AdPix console's own session cookie. It is written on the console's domain, is HttpOnly and Secure, uses SameSite=Lax, and lasts 12 hours for a local sign-in. This cookie is never written on your site visitors' browsers and has nothing to do with your site's cookie declaration; it exists only when you sign in to the console yourself.

Frequently asked questions#

Related#