GDPR-friendly tracking with Google Consent Mode

Privacy law and accurate measurement are often presented as a trade-off: respect your visitors' choices and lose your data, or keep your data and risk a fine. That framing is wrong. With Google Consent Mode v2 and a server-side setup done correctly, you can honour consent fully and still measure your PrestaShop store well.

This article explains how Consent Mode v2 works, what "default-denied" means in practice, how server-side tracking and SHA-256 hashing support compliance, and — just as importantly — what these tools do not do for you. Compliance is a combination of technology and the legal basics, and you need both. None of this is legal advice; treat it as a practical orientation.

What Google Consent Mode v2 is

Consent Mode is Google's framework for adjusting how its tags behave based on a visitor's consent choices. Rather than a binary on/off, it uses consent signals — such as analytics_storage and ad_storage — that your cookie banner sets to granted or denied.

Version 2 (Consent Mode v2) added two ad-related signals, ad_user_data and ad_personalization, and Google now requires it for advertisers using its platforms in the European Economic Area. When a visitor denies consent, Google's tags respect that choice and limit what they collect and store.

The key idea is that Consent Mode is the bridge between your consent banner and Google's tags. The banner captures the choice; Consent Mode communicates it to GA4 and Google Ads so they behave accordingly.

Default-denied: starting from no

A compliant setup starts from denial, not permission. "Default-denied" means that before a visitor interacts with your banner, consent signals are set to denied, so no analytics or advertising cookies are written and no personal data is collected for those purposes.

Only when the visitor actively grants consent do the signals flip to granted and full tracking begins. This ordering matters: under GDPR and the ePrivacy rules, consent must be given before non-essential tracking, not assumed and withdrawn later.

When consent is denied, Consent Mode can still send cookieless pings that Google uses for privacy-preserving, aggregated modelling — but no identifiers and no personal data. The visitor who says no is respected; you simply lose granular measurement for that visit, which is exactly as it should be.

How server-side tracking fits in

A frequent misconception is that server-side tracking is a way to dodge consent. It is not, and treating it that way would be a serious compliance mistake. A correct server-side setup respects the same consent signals as client-side tracking — when consent is denied, the events are not sent.

What server-side delivery genuinely improves is reliability and control for the visitors who have consented. It recovers consented conversions that ad-blockers and ITP would otherwise drop for purely technical reasons, and it gives you a single point — the self-hosted sGTM container — where you control exactly what data is sent onward and what is stripped.

That control is itself a privacy benefit. You decide what leaves your store, you can minimise the payload, and you keep sensitive credentials server-side. See how it works for the PrestaShop specifics.

Hashing and data minimisation

The other pillar is what happens to personal data before it is transmitted. PrestaSignal normalises and SHA-256 hashes all PII — email, phone, name, city, state, and similar — inside your store before anything is sent. SHA-256 is a one-way function, so the recipient receives an irreversible fingerprint, never a readable email or phone number.

This supports the GDPR principle of data minimisation: you share only what is needed for matching, in a form that cannot be reversed. Country and postal code are sometimes sent in plaintext where a platform requires it, but the identifying details that matter most are hashed first.

Hashing is not a magic exemption from GDPR — hashed data tied to a person can still be personal data — but it meaningfully reduces exposure and is a recognised safeguard. Our privacy & data page lists exactly what is sent and in what form.

What you still need

Technology handles the mechanics of consent, but it does not make you compliant on its own. You still need the legal and operational basics in place around it.

First, a proper consent banner (a Consent Management Platform) that genuinely blocks non-essential tags until the visitor opts in, and that records their choice. Second, a clear, accurate privacy policy explaining what you collect, why, and who you share it with — kept up to date with your actual setup. Third, an honest cookie policy describing the cookies in use.

Consent Mode, server-side delivery, and hashing are the technical enforcement layer that makes those documents true in practice. Get both halves right — the paperwork and the plumbing — and you have a setup that respects your visitors and stands up to scrutiny. For help aligning the technical side, book a teardown.