GDPR and ePrivacy for ecommerce analytics: consent without losing all your data

Analytics and privacy law are often framed as opponents: comply and go blind, or measure and risk a fine. In practice they coexist if you design for consent from the start. The trick is to separate what you are legally allowed to run without permission from what you are not, share the visitor's consent choice cleanly across your domains, strip personal data out of your event pipeline, and — crucially — read your dashboards knowing they are undercounted on purpose. This is a practitioner's guide, not legal advice.

Two buckets: strictly necessary vs everything else

Under the GDPR and the ePrivacy rules, reading or writing information on a user's device requires consent unless it is strictly necessary to provide the service the user asked for. That gives you two buckets, and the whole design follows from sorting cookies and storage into them correctly.

The safe rule is: if it is not needed to deliver what the shopper asked for, it waits for consent. Analytics, session replay and marketing pixels all live in the second bucket and must not fire until the visitor opts in. Be honest about the sort — dropping an analytics cookie under the "strictly necessary" label because it is convenient is a common and avoidable mistake.

Gate non-essential tracking behind consent

Concretely, nothing in the second bucket loads until consent is granted. That means the analytics library, the replay recorder and any pixel are loaded after the choice, not loaded-but-dormant. We gate ours behind the recorded consent state and a feature flag, so a visitor who declines simply never has that code executed. The reward for doing this properly is that your consent banner is not theatre — declining actually stops the tracking, which is the entire point of the law.

"Loaded but dormant" is the trap worth naming. A script that has already been fetched and initialised has often already dropped a cookie or fingerprinted the device before your logic decides not to use it, so gating usage is not the same as gating loading. The safe pattern is to withhold the third-party code entirely until consent exists, then load it. This is also the honest position when a regulator or a user asks what runs before a choice is made: the answer should be "only the strictly-necessary essentials", and you should be able to demonstrate it in the network trace.

Sharing consent across subdomains

A marketplace that lives on a subdomain of a content site has a specific problem: a shopper who accepts or declines on the main site should not be asked again on the storefront, and the choice must be honoured on both. If consent is stored per-host, you get inconsistent behaviour and, worse, tracking that runs on one subdomain against a choice made on another.

Keep this first-party and strictly-necessary: the consent record is one of the few things you may store without consent, precisely because it is what enforces consent. Content-to-commerce setups that span a site and a storefront depend on getting this right; the analytics side of that architecture is covered in an ecommerce analytics stack you own.

PII redaction and retention in the event pipeline

Consent decides whether you collect; data minimisation decides what you keep once you do. Behavioural events rarely need to identify a person to be useful — you want to know that a search returned nothing, not who searched. So redact personal data at the edge of the pipeline: avoid capturing raw identifiers in event payloads, mask form fields and anything that looks like an email or a name in session recordings, and prefer rotating pseudonymous session identifiers over durable user ids for behavioural analytics.

Then set retention windows and actually enforce them, because indefinitely retained behavioural data is a liability rather than an asset. Session recordings especially should expire on a defined schedule. The engineering of consent-gated, anonymised replay — and why it is worth the effort — is in session replay for ecommerce.

Low numbers are not broken tracking

The consequence operators find hardest to accept is that consent-gated analytics undercount by design. Every visitor who declines, or who leaves before choosing, is invisible to your behavioural metrics. When a dashboard shows fewer product views than you expected, the first instinct is "the tracking is broken" — and usually it is not; those are simply the consenting visitors.

Two habits keep this from causing bad decisions. First, verify server-side truth where you can: things like impressions and orders can be confirmed in your own database rather than inferred from consent-gated client events, so a real total exists to sanity-check against. Second, read behavioural analytics as a consistent sample of consenting users and watch trends and ratios, not absolute counts. A funnel measured the same way month over month is still informative even if it never sees every visitor. Some of the most valuable signals — like which searches returned nothing — can be captured server-side without consent-gated client cookies at all, which is one reason site-search analytics stays useful even under strict consent. Do not tune the consent banner into a dark pattern to inflate the numbers — the point of the banner is a real choice, and a coerced yes is both unlawful and useless data.

The same honesty runs through the rest of your storefront. Truthful pricing under the Omnibus Directive, accurate VAT and non-coercive consent are the same instinct applied to different surfaces: show the customer what is real, and let the systems fail closed when they cannot prove a claim.

Frequently asked questions