We measure traffic without ever sending your raw details off this site. You choose what to allow.
Measured baseline across Amplio Data client implementations. 20–40% is recoverable. Actual results depend on traffic mix, regions and tag configuration. Velo is a product, not legal advice.
Velo masks gclid, identifiers and email at the edge before any of it leaves the page. The visitor stays measurable; you lose nothing you actually use.
Swapped for an opaque token at the edge. The real one stays with you.
Hashed to the platform spec, never sent in the clear, gated on consent.
Re-minted as a first-party pseudonym; the IP is truncated.
// captured on your site — full fidelity, you hold the key gclid = "Cj0KCQjw_e2…AcEALw" email = "walter@ampliodata.io" user = "u_8821_walter" ip = "81.42.110.7" // sent to third parties — masked before any tag fires gclid → tok_3f9a21c7e0b4 email → 8f4e…b21c // SHA-256, platform spec user → fp_5d2c9e // first-party pseudonym ip → 81.42.0.0 // truncated
The Velo Worker sits in the request path and rewrites the payload before any tag fires — nothing raw is ever transmitted off-site. Illustrative values.
We measure traffic without sending your raw details off this site.
Masking is deterministic — the same person makes the same token every time. Attribution and dedup still work; only you can turn a token back into a human.
Conversions still match clicks and orders, because the token is stable per visitor.
Server-side dedup keys on your stable order_id — not the browser value that double-fires.
Without your salt and your map, a hash is just a string. That is the whole point.
"Hash before sending" is the rule — but how you hash depends on who receives it. Get this wrong and you break the accuracy you set out to protect.
Google matches the raw gclid it minted; Enhanced Conversions needs Google's hash spec. A custom token would simply fail to match. Privacy here = consent-gating and sending only the platform-spec hash, never extra PII.
Your warehouse, self-hosted analytics, vendors that never need to re-identify anyone. Here you own the hashing end to end — the first-party-clear / third-party-opaque split works cleanly.
Preserved — first-party analytics, conversion counts, server-side dedup. Full resolution.
Modelled — the sessions consent hides, recovered via Consent Mode v2 advanced modelling.
Given up — cross-site, user-level identity for third parties. On purpose. That is the trade.
Measured range. Depends on traffic, regions and tags.
No raw identifier leaves the page — a real, demonstrable reduction in exposure.
It does not. Data you can reverse is still personal data. Hashing is not a consent bypass.
Append-only, redacted record of every choice — evidence for a DPA or an audit.
You remain the data controller. Velo lowers risk and exposure; it does not replace your legal basis.
Even the big CMPs forward your raw identifiers. Velo masks them at the edge — before they ever leave the page.
| Capability | Velo | Usercentrics | Cookiebot | OneTrust |
|---|---|---|---|---|
| Masks identifiers at the edge, before they leave the page — on by default | ● | — | — | — |
| First-party clear, third-party hashed | ● | ◐ | — | — |
| Cookie banner + Consent Mode v2 wiring | ● | ● | ● | ● |
| One-snippet drop-in install | ● | ● | ● | ● |
| Server-side tagging / first-party routing | ◐ | ● | ● | — |
| Agency / multi-client management | ● | ● | ● | ◐ |
Capabilities as publicly documented, June 2026; vendors may offer configurable or roadmap features not shown. Velo masks at the edge by default; its server-side routing pairs with your sGTM (◐). Usercentrics can hash PII server-side as a configured rule (◐), not automatic edge masking.
Default the masking on, prove the recovery on a low-risk pilot, then roll it out through the agency channel.
velo-privacy.ampliodata.io · a product of Amplio Data®
We use cookies to measure traffic and improve your experience. With masking on, your raw details never leave this site — you choose what to allow.