Every bid request asks the same quiet question: who is this? Much of the industry answers by guessing — stitching an IP address and a browser into a “user” and following it around. In October we rewrote how our bidder answers. The honest version has one gate, four rungs in strict order, and a rule that the kind of answer decides what it may be used for. Here it is in plain English: what we decide, what each answer is allowed to do, and when we refuse to guess.
One request, one answer, and its kind written down
For every bid request the bidder settles on one identifier, or none, and records which rule produced it. That kind travels with the request into every log, so a report can say how many impressions were tied to a known person, how many to a probabilistic link, and how many to nobody at all — rather than quietly adding them all up as “users”. It also means nobody can pass one kind of id off as another: an id from our own tag is marked as ours, a hashed advertising id as what it is, and a fingerprint as a fingerprint.
The gate, then the four rungs
The order matters, and it is the same for every request.
- The gate comes first. If the device has limited ad tracking, the browser sends Do Not Track or Global Privacy Control, or a privacy law applies and there is no consent, the request gets no identifier at all — not the advertising id, not a fingerprint. Opting out and then being tracked by IP address would make the opt-out meaningless, so we don't. The ad still serves, chosen by the page, not the person.
- An id someone sent on purpose. The exchange's own user id, or the first-party id our web tag keeps in the browser for that site: a random id, not a cookie, not derived from the device — which is why it is allowed on iPhones. Our mobile SDK's install id counts here too. This is a real person for every purpose below.
- The device's advertising id, hashed. Only when the phone has not limited ad tracking, and only ever as a hash: the raw id is never stored, and it leaves the platform only inside the industry's standard verification macros, never when tracking is limited. A real person.
- A fingerprint, under three conditions. Only when the request carries an IP address, never on iOS, and never after a do-not-track signal. Without an IP nothing is derived at all, because a phone model and a browser alone would merge thousands of people into one “user”. The fingerprint is keyed with a secret the platform holds, so a log row cannot be turned back into an address, and it is kept for days, not months. Above all it is a probabilistic link, not a person: never counted in reach, never frequency-capped, never retargeted. Its only job is to tie events together for a short while — a click to its impression, say, when nothing better survived.
- Nothing. When none of the above applies, the request has no id, and that is a legitimate answer. It is logged as such, reach for it is estimated and labelled rather than invented, and the ad is chosen by context.
The kind of id decides what it may do. These rules are enforced in the bidder, not in a policy document.
What each kind of id may do
- Frequency caps count only ids that name one device or person. An opted-out reader may therefore see an ad more often than a capped reader would. We would rather that than track someone in order to cap them.
- Retargeting lists enrol only such ids: never a fingerprint, never a device that limited tracking, never an empty id. Seeing or clicking an ad enrols in real time, and an advertiser can use a list to include or to exclude. Exclude is honoured even where include is denied.
- Reach counts the people it can identify and estimates the rest from the frequency measured on identified impressions in the same campaign. Every table that contains such an estimate says so in a footnote. How the report is built.
- Deletion removes an identifier from every store that holds it — profile, caps and retargeting lists included — whichever kind of id it was.
No personalised ads is not no ads
Some readers do not opt out of everything; they say no to personalised ads. The tag's own flag, Do Not Track, Global Privacy Control, a US-privacy or GPP opt-out, or a GDPR request without consent for personalisation all mean the same thing to the bidder. Such a reader keeps an id for frequency caps and reach, but it is never used to personalise: no profile enrichment, no enrolment into retargeting lists, and a denial on every audience include — while an exclude list, which protects the reader, still applies. The ad that serves is chosen by the page.
Child-directed requests are a different case. A request flagged as child-directed gets no bid from us at all, personalised or otherwise.
What “no personalised ads” changes, and what it doesn't.
What we never do
| Never | Why |
|---|---|
| Fingerprint an iPhone | The platform's rules say so, and so does the point of asking permission to track |
| Derive an id without an IP address | A phone model and a browser alone would merge thousands of people into one |
| Count, cap or retarget on a fingerprint | It is a probabilistic link, not a person |
| Keep the raw advertising id | A hash is enough to match on; the raw id is a liability |
| Use any id after an opt-out | An opt-out that is tracked anyway is not an opt-out |
| Bid on child-directed requests | There is no case, personalised or contextual, worth the risk |
| Set a cookie from our ad tag | The first-party id lives in the browser's own storage, for that site only |
What this costs us, and why we pay it
Honesty about identity is not free. Frequency caps now cover fewer impressions than a system that caps on a fingerprint would, because we refuse to cap on one. Retargeting lists are shorter, because they hold only people who can be addressed without guessing. Reach contains estimates, and says so, where a looser platform would print a bigger number. On our own web supply the first-party id replaced the fingerprint for most readers the day it shipped, which moved a large share of our impressions from “probably someone” to “this browser, on this site”. We measure what share of requests arrives with each kind of id, and we will publish those coverage figures once they have settled — not before.
An identifier is a claim about a person. Record how strong the claim is, let that strength decide what it may be used for, and accept “nobody” as an honest answer.
See how your campaign is counted
Questions we get asked
Does the AdZoic ad tag set cookies?
No. The web tag keeps a random first-party id in the browser's own storage for that site. It is not a cookie, it is not derived from the device, and it is dropped the moment the reader opts out.
Why might a frequency cap not apply to every impression?
A cap counts only identifiers that name one device or person: an id the exchange or our tag sent, or a hashed advertising id. A reader who opted out, or whose request carried no usable id, cannot be capped without tracking them, so we don't. Those impressions are reported as delivery, and reach for them is estimated and labelled.
What happens when a reader opts out?
The request gets no identifier at all: not the advertising id, not a fingerprint. The ad still serves, chosen by the page rather than the person. A reader who only said no to personalised ads keeps an id for caps and reach but is never enrolled in retargeting and is denied on every audience include.
This post describes principles, not configuration: no thresholds, retention periods, keys or endpoints are given, on purpose. The signals named — limit ad tracking, Do Not Track, Global Privacy Control, the TCF and GPP consent frameworks, the US-privacy string, the child-directed flag — are industry standards, used here as the bidder reads them. No coverage or performance figure appears because none has been published yet; they will be, once measured. Behaviour described is how the bidder works as of 13 October 2026 and may change. This describes our own platform; it is not legal advice, and it is not a description of anyone else's.
