Is Adobe Analytics GDPR Compliant?

The question hides two different laws

Most discussion of analytics and GDPR conflates two frameworks that apply independently, and the confusion is where bad answers come from.

The ePrivacy Directive governs storage on and access to a user’s device. Article 5(3) requires consent before you write anything to a visitor’s browser, and it applies whether or not the stored value is personal data. GDPR governs the processing of personal data, wherever it comes from. A tool can engage one, the other, or both.

Adobe Analytics engages both. It sets cookies, which triggers ePrivacy Article 5(3) regardless of what those cookies contain, and it processes identifiers that are personal data under GDPR. So the honest answer to “is it compliant” is: it is compliant when you have satisfied both, and neither is satisfied by default.

What a compliant Adobe deployment actually requires

Prior consent. The Experience Cloud ID service sets identifiers before Adobe Analytics can attribute anything. Under Article 5(3) that has to wait for an affirmative signal from the visitor. Not implied consent, not legitimate interest — ePrivacy does not offer the legitimate-interest route that GDPR does for some processing.

A Data Processing Agreement. Adobe acts as your processor. Article 28 requires the contract, and your record of processing activities has to reflect it.

A transfer assessment — and this is more nuanced than it is usually presented. The lazy version of this argument says Adobe is a US company, therefore data leaves the EU, therefore Schrems II kills it. Our own measurement says otherwise: when we catalogued the external domains every analytics tool contacts, Adobe’s collection endpoints resolved inside the EU — dpm.demdex.net on AWS Dublin, alongside sc.omtrdc.net and the Akamai-hosted tag manager. Server location is not the whole test, though. Schrems II is about legal access regimes, not geography, so the assessment turns on Adobe Inc.’s corporate structure and the safeguards in place — which is a genuine legal exercise for your counsel, not a line item you can settle from a blog post.

Deliberate configuration. Retention windows, IP obfuscation and the privacy settings in the Experience Cloud ID service all ship with defaults that were not chosen for your risk posture. A DPO reviewing the deployment will ask who chose them and when.

None of that is the expensive part

Every item above is solvable. Enterprises solve them routinely, and the paperwork is a one-off. The recurring cost is the one nobody signs off on, because it does not appear on an invoice.

Consent is load-bearing in that architecture. Adobe measures the visitors who accepted your banner and no one else. In European eCommerce, banner rejection runs 40–60%, which means a fully compliant Adobe deployment is reporting on a minority of your real traffic — and not a random minority. The visitors who reject banners skew by device, by browser, by acquisition channel and by privacy posture. You are not sampling your audience, you are selecting a biased slice of it and calling it the audience.

We measured a related effect directly. In a 30-day parallel run on a European media site, SealMetrics recorded 25% more pageviews than Adobe with Adobe firing without a consent gate at all — the gap coming from privacy filter lists blocking its collection endpoints and a pageview that fires roughly three seconds into the load, so any visit that bounces earlier never existed. Put the consent banner back in front and the gap widens from there.

The architectural answer

There is a second route, and it is the one European regulators have been signposting. If a tool sets nothing on the device, ePrivacy Article 5(3) is not engaged. If it collects no personal data, the GDPR consent question does not arise either. Compliance stops being a configuration you maintain and becomes a property of the architecture.

That is the basis for consentless analytics, and the reason the coverage problem disappears with it: there is no banner to reject, so the 40–60% never goes missing in the first place. The trade is real and worth stating plainly — you give up individual-level analysis, cross-session stitching and audience activation, because those are exactly the capabilities that require the identifiers you are no longer collecting.

For teams that need Adobe’s segmentation depth, the two are not mutually exclusive. Replacing the collection layer while keeping Adobe for analyst-driven work is a common arrangement, and it is covered in the head-to-head comparison. If you are weighing a move away from Adobe entirely, the five realistic alternatives separate on this exact axis — four of the five are cookie-based, so they inherit the same consent gap.

So — is it compliant?

Yes, if you do the work: consent before the cookies, a signed DPA, a documented transfer assessment, and configuration you actually chose. Adobe gives you every mechanism you need to get there.

But compliance was never the interesting question. The interesting question is what a compliant deployment can still tell you, and the answer is: whatever 40–60% of your visitors permitted it to. If your reports have stopped reconciling with revenue, that number is where to look first — before you blame the attribution model.

This is an assessment of how the technology interacts with the regulation, not legal advice. Your DPO or counsel owns the conclusion for your deployment.