Event Lifecycle

This page follows one page view from the visitor’s browser to the public record. Each step leaves something that can be checked later.

1. Capture, in the browser

The publisher’s page loads the AdPriva Tag. The tag renders nothing and sets no cookies.
While the visitor is on the page, the tag keeps aggregate counts: foreground dwell time, scrolls, clicks, pointer speed, and automation hints such as navigator.webdriver. It never records keystrokes, form values or absolute pointer positions.
About one second after the page loads, the tag sends one view event. The event carries the aggregates collected so far, a low-detail device snapshot, the page path, the referrer and a one-time nonce. The server uses only the snapshot’s platform value, to classify the device type, and does not store the snapshot.

The full list of fields is on the AdPriva Tag page.

2. Seal, on the ingest server

The server refuses the event if its nonce has been used before.
It signs the event with an HMAC. The signature is the proof id.
It stores the proof with the request’s IP address and user agent, and derives a country, device class, browser and OS from the request. The raw IP address and user agent are emptied after 30 days. Hashes of both, and the derived fields, stay.

3. Score

The ingest server scores each view proof from its user agent (L0 self-identification) and the class of its IP address (L1 environment). The proof gets a validity score from 0 to 100 and a verdict: human, uncertain or abusive_bot. This is the public score and verdict.
The scoring service then checks behaviour (L2) and signed agent identity (L3). Its result, which can also be authorized_agent, is kept privately next to the proof and shown in the console. It does not change the public verdict.
AdPriva runs in shadow mode. The verdict is stored and published, but no proof is blocked or left out of a batch because of it.

See Proofs of Engagement for how each layer works.

4. Batch and anchor

Every 5 minutes, the anchor worker takes the proofs that are not yet in a batch and builds a Merkle tree from them.
It anchors the batch’s Merkle root on Horizen through AdPriva’s Anchor.sol contract, which emits an Anchored(merkleRoot) event.

5. Report and verify

The publisher sees the proof, its verdict and its anchor status in the console. The publisher can also download a Portable Verification Certificate for a date range.
Anyone who has the proof id can look it up on the Explorer or through GET https://api.adpriva.com/public/proofs/{proof_id}. Once the proof is batched, the response includes a Merkle inclusion receipt, so the batch root can be recomputed and compared with the on-chain event.

What each step guarantees

Step	Guarantee	Limit
Capture	No cookies, no cross-site identifier, no keystrokes or form values	The tag only sees the page it is loaded on
Seal	A replayed event is refused; changing a sealed field breaks the HMAC	Only AdPriva holds the HMAC key. The anchored root does not stand in for it: for a view proof it covers batch membership, not the proof’s fields
Score	Every view proof gets a score and a verdict that anyone can see	The public verdict uses L0 and L1 only; the L2 and L3 result is private. Shadow mode: verdicts do not block traffic yet
Anchor	The batch root, and so the batch’s membership, is public and permanent on Horizen	A view proof’s score and verdict are not part of its leaf. A proof is pending until its batch is anchored
Verify	Anyone can recompute a proof’s batch root offline	The public record does not say which site a proof came from

Consent follows its own path. When a visitor submits a form the publisher has marked, the tag sends the consent evidence, and the server seals it as a consent certificate instead of a view proof. See Consent Certificates — Quickstart.

← Previous Fraud & Threat Model Next → Benchmarks