How to Audit What an Ad Partner Stores on Your Users' Devices
- Tor Olav Haugen
- Aug 8
- 3 min read
When a legal team starts asking what an advertising partner writes to a user's device, the usual answer is a link to a privacy policy. That is the wrong document. Under the IAB Europe Transparency and Consent Framework, every registered vendor must publish something far more specific: a machine-readable Device Storage Disclosure listing each cookie or storage item by name, its maximum lifetime in seconds, whether it is refreshed, and which processing purposes it serves. It is public, it is standardised, and you can read a partner's one without asking their permission.
Every TCF vendor publishes one. Almost nobody reads them.
A vendor's registration on the Global Vendor List carries a Vendor ID and a URL pointing at that disclosure file. Both are public. That means the compliance question an operator usually has to take on trust — what is this partner actually doing on my users' devices — is, uniquely in this corner of adtech, answerable from the outside and without a meeting.
What to check, in order
1. Ask for the Vendor ID, not the policy. A partner who cannot give you one in a sentence either is not registered or does not know. Both are answers.
2. Open the disclosure file itself. Count the storage items. Read the lifetimes. A vendor declaring more identifiers than it can explain, or lifetimes it cannot justify against its stated purposes, has a problem it has not thought about.
3. Check the file against the registration. This is where most vendors fail, and it is invisible unless you look. The registration and the disclosure file are two separate records maintained by hand, and they drift. Passing the official JSON validator proves only that the syntax is well formed — it does not check whether the two records agree.
Ours, since it is only fair to go first
ThumbAd is TCF Vendor ID 1460. The disclosure declares two cookies and nothing else: thumbad_uid and _ttduid, each with a maximum lifetime of 31,536,000 seconds — one year — both refreshed, both serving four declared purposes. The SDK section is an empty array, because ThumbAd distributes no package to any app store; in-app and connected TV inventory is bought through The Trade Desk's own integrations. An empty array is the honest declaration there, and inventing entries to look more substantial would be a false one. The page itself is here: ThumbAd's device storage disclosure.
Three failure modes worth knowing about
These are not hypotheticals. Each one produced a compliance notice against ThumbAd's own registration, and each was resolved.
The refresh flag has to agree in two places. If the registration says a cookie is not refreshed and the disclosure file says it is, that is a mismatch — and it is the registration, not the file, that most people forget to update.
The maximum age has to match the longest item. A registration declaring a shorter cookie life than the disclosure file's longest entry is a contradiction in the vendor's own paperwork.
The published URL has to serve the current file. This one is genuinely easy to get wrong. A hosting URL without an explicit commit reference can keep serving a cached older version indefinitely, so a vendor updates its file, sees the change, and unknowingly leaves the old one published to everyone else. Updating the file and updating the registered URL are two separate acts; doing only the first changes nothing anyone outside can see.
What this does not prove
A clean disclosure tells you what a vendor has declared. It does not tell you what runs in a live auction, it does not audit the partners downstream of them, and it is not a substitute for a data protection assessment. It is a floor, not a ceiling. But it is a floor most operators never check, and a partner who cannot pass it is unlikely to survive the harder questions.
Device storage is one of twenty questions worth putting to any programmatic partner. The rest — and ThumbAd's own answers to all of them, on the record — are in the 20-Question Partner Scorecard. If the question underneath yours is really about what your measurement can and cannot see, that is what the Measurement Integrity Audit exists for.
Comments