Data Flows for your DPIA
A publisher that runs a Data Protection Impact Assessment (DPIA) needs to know what AdPriva collects, where it goes and how long it stays. This page lists those facts. It does not include a lawful-basis analysis, which depends on how each publisher uses AdPriva.
Where data goes
- Visitor’s browser → ingest server. The tag sends one event per page load: aggregate interaction counts, automation hints, a low-detail device snapshot, the page path, the referrer and a one-time nonce. The server also receives the request’s IP address and user agent.
- Ingest server → scoring service. The signals needed for a verdict are passed to AdPriva’s internal scoring service. The verdict comes back and is stored with the proof.
- Anchor worker → Horizen. Only a batch’s Merkle root, which is a hash, is revealed. Horizen receives the root itself. New batches send nothing to zkVerify. Batches anchored before 2026-09-28 also sent it a zero-knowledge proof whose only public input was that root.
- Database → console. The publisher sees its own organization’s proofs, verdicts and reports.
- Database → public Explorer and public API. Anyone can look up a proof by its id. No publisher, site, page or visitor data is shown.
- Database → model training. Pseudonymous copies of proof records and their scoring signals are exported to a private storage bucket used to train and test the scoring models. Raw IP addresses, user agents, page URLs and referrers are not exported.
Data inventory
| Data | Source | Used for | Retention | Public |
|---|---|---|---|---|
| Aggregate interaction counts and automation hints | Tag | Scoring | Scoring signals emptied after 180 days | No; only the score and verdict |
| Device snapshot | Tag | The platform value classifies the device type | Not stored | No |
| Interaction summary (mouse-move and touch counts, scroll depth, recent click intervals and relative pointer moves) | Tag | Not used | Not stored | No |
| Page path and referrer | Tag | Console reports (pages, traffic sources) | Kept with the proof record | No |
| IP address, user agent | HTTP request | Scoring; deriving country, device class, browser, OS | Raw values emptied after 30 days; hashes kept | No |
| Proof id, timestamps, validity score, verdict | Ingest server | Verification and reports | Kept: the proof id is a Merkle leaf | Yes |
| Merkle root | Anchor worker | Anchoring | Permanent on Horizen | Yes |
| Consent certificate fields | Tag, on forms the publisher marks | Consent evidence | See Data-Processor Posture §4 | Public lookup shows no personal data |
The retention windows are the current production settings.
Risks and safeguards
| Risk | Safeguard |
|---|---|
| A captured event is replayed | Each event carries a one-time nonce; a reused nonce is refused |
| A stored proof is changed later | Each proof’s sealed fields are covered by an HMAC, which AdPriva checks. The anchored batch root fixes which proofs are in each batch, and for consent certificates their sealed content. It does not fix a view proof’s score or verdict |
| A visitor is identified from the public record | The public record carries no publisher, site, page, IP address, user agent or visitor reference |
| Raw network identifiers are kept too long | Raw IP addresses and user agents are emptied after 30 days |
| Form contents are captured | The tag never reads form field values or keystrokes |
Related pages
- Consent & Privacy Model
- GDPR, ePrivacy, CCPA
- Data-Processor Posture: processor terms, sub-processors, consent-certificate retention, subject access and breach notification