Personal Data Inventory Under Consent Mode: GA4, CAPI, Newsletter and Webhook Leakage Surfaces

Personal data doesn’t sit in one place inside a measurement system. It moves through client-side event parameters, server-side via sGTM, persists in BigQuery exports, flows out via webhook payloads, and sits in newsletter lists under a different purpose. Consent Mode v2 carries four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization); but the data these signals gate and the data they leak past is not the same set. This post does a data-type inventory and maps each type to a consent signal, with the practical leak-prevention surfaces called out.

The mechanics of Consent Mode v2 setup are covered separately in Google Consent Mode v2 Implementation. This piece focuses on the data inventory and leakage surfaces.

Personal Data in Three Forms

Personal data travels in three shapes inside a measurement stack:

1. Raw PII. Email, phone, first/last name, address in plaintext. Arises naturally in form submissions, logins, subscription payloads. Should not flow directly to measurement platforms.

2. Hashed PII. Normalized (lowercase, trim) email or phone hashed via sha256. Used in server-side match patterns like Enhanced Conversions, Meta CAPI user_data, LinkedIn Insight Tag CAPI. The platform receives the hash and matches it against its own hash.

3. Pseudonymized ID. GA4 client_id (_ga cookie), Meta _fbp and _fbc, Google Ads gclid, gbraid, wbraid. Doesn’t identify the user directly but provides a consistent pseudonymous identifier. When Consent Mode v2 analytics_storage or ad_storage is denied, cookies aren’t created and the user arrives with a fresh random ID per event (GA4 transient token).

IP and User-Agent sit in a separate category: device- and network-layer data. Consent Mode v2 doesn’t gate them directly; their use is constrained by analytics_storage or ad_storage state on the platform side.

PII Leakage in GA4

GA4 itself doesn’t expect PII, but default event parameters can leak PII into it. Three common surfaces:

page_location query string. Site-search or form-submission URLs that keep the email/phone parameter flow straight into GA4 as events. Example: /search?q=user@example.com. A GTM variable should strip PII patterns from page location and emit a cleaned URL. Simo Ahava’s Custom Task pattern is the common solution¹. At the GA4 property level, Admin > Data Collection and Modification > Data Redaction enables native email-pattern redaction (available since late 2023); Google’s internal regex is [A-Z0-9.*%+-]+@[A-Z0-9.-]+\.[A-Z]{2,} (case-insensitive) and it scans page_location, page_referrer, page_path, link_url, video_url, and form_destination².

Site search (search event) parameter. If a user types an email into the search box, it lands in GA4’s search_term. Same redaction logic applies. Automatic site-search tracking via enhanced measurement can also be disabled and replaced with a custom event under stricter control.

User property and custom dimensions. If a developer or GTM tag sends user_properties or custom event parameters containing email/phone, GA4 attaches that to the user profile. GA4’s UI rejects some PII fields, but automatic enforcement is limited; naming convention (customer_hash not customer_email) and code review responsibility sits with you.

There’s a property-level safety layer: GA4 Data Redaction Settings. Enable email pattern redaction there; URLs and parameters written into events are filtered at egress from the property. This is the last line of defence; ideally data is scrubbed before it reaches GA4.

Enhanced Conversions and Meta CAPI: Hashed PII Responsibility

Enhanced Conversions (Google Ads) and Meta CAPI accept hashed user data to improve conversion match quality.

Enhanced Conversions installs in two modes:

• Auto-collect (Google Tag): The Google Tag reads form fields on the page, hashes them, and sends them. Hashing responsibility lies with Google; on your side, form fields should be correctly attributed so Google can identify them, and raw PII must not leak elsewhere.
• Manual or sGTM: If your own code or GTM tag builds the user_data object, hashing is your responsibility. Format: sha256 over lowercase + trim. For email: normalize: email.trim().toLowerCase() then sha256. For phone: E.164 format then sha256. Google Ads Enhanced Conversions accepts unhashed values over HTTPS and hashes them server-side³; but the best-practice pattern is to pre-hash on the client or in sGTM so raw PII never appears in the browser console or network inspector, strengthening the compliance argument. Meta CAPI accepts only hashed em/ph; sending raw values causes the payload to be rejected.

Meta CAPI user_data: Same hashing rules. em (email sha256), ph (phone sha256), fn/ln (name sha256), db (date of birth sha256), ge (single-letter gender sha256). Additionally, client_ip_address and client_user_agent are sent raw; required for match quality. Deduplication with Meta Pixel is via event_id.

In sGTM setups the common pattern is to build user_data server-side. Advantages: hashing is standardized on the server, unhashed data never leaves the browser. When Consent Mode v2 ad_user_data: denied, even hashed PII must be stripped from the payload; sGTM custom templates must enforce this. Meta’s official sGTM CAPI Tag Template includes this behaviour.

Newsletter Subscription: Purpose Scope Expansion

The email captured in a newsletter form is processed for the subscription purpose. Under GDPR and KVKK this is one specific purpose. Using the same email to:

• Add to a Google Customer Match audience
• Upload to a Meta Custom Audience
• Seed a Lookalike / Similar audience

are separate marketing purposes, and the subscription consent does not cover them. For compliance, the newsletter form should have:

• A separate checkbox for subscription (opt-in unless mandatory)
• A separate checkbox for marketing communications (opt-in, independent of subscription)
• A separate checkbox for third-party audience sync (opt-in, separate again)

In practice, Klaviyo, Omnisend and similar ESPs support consent category management at the form level. Listmonk self-hosted handles it via List > Privacy settings and multi-category tags. Each category’s opt-in must be stored with its own timestamp; critical evidence for audits.

If the subscription list is used for remarketing, a pipeline must keep suppressed/unsubscribed emails removed from Customer Match / Custom Audience in near real-time. Scout-style custom routing platforms automate this job⁴.

Webhook: Raw Data Transit Surface

Form submissions, checkout events, user registration triggers carry raw email, phone, and other PII in plaintext in the webhook payload. When the webhook receiver (CRM, ESP, custom endpoint) persists PII:

• TLS 1.2+ is required (transit encryption)
• Column-level encryption at rest
• Log-level PII masking (log aggregation services should not store PII in plaintext)
• If PII is forwarded to a 3rd-party destination, add a hashing layer before forwarding

Shopify, WooCommerce, Paddle webhooks fit this category; checkout-completed events deliver raw customer email. Consent Mode v2 doesn’t affect webhook traffic directly, but data derived from webhooks (e.g., email → Customer Match) is subject to ad_user_data and ad_personalization consent gates.

When webhooks forward to a Scout-style pipeline⁴, PII should travel with Consent Mode v2 signals in the payload; at destinations (Klaviyo, Meta CAPI, Google Customer Match) tags should fire conditionally based on consent state.

IP Anonymization and Trimming

IP is treated as a pseudonymized identifier (GDPR Recital 26); not PII on its own, but combined with other data it can identify a user.

GA4: Does not store or report IP. The old UA IP Anonymization (AIP) setting became default behaviour in GA4. BigQuery export has no IP column; only derived geo (country, city) is available.

Meta CAPI: Expects full IP in client_ip_address; required for match quality. If you prefer not to send raw IP under KVKK, strip the last octet in sGTM or a reverse proxy (Cloudflare Worker, Caddy): 192.168.1.42 → 192.168.1.0. Match quality drops slightly but compliance improves.

Enhanced Conversions: IP is not required on the Google Ads side; hashed user_data suffices for matching.

sGTM custom Transformation: A Transformation applies IP trim or masking to all outbound events. Meta’s official Tag Template sends IP as-is; the Transformation layer overrides that default. Stape’s Anonymizer power-up and the community IP Transformer / Anonymizer template are ready-made solutions⁵⁶.

GPC, TCF and International Signals

Consent Mode v2’s four signals cover Google’s ecosystem; but browsers and regulators add additional signal layers.

Global Privacy Control (GPC). Legally binding opt-out from January 1, 2026 in 12 US states starting with CA, CO, CT. Firefox, Brave, and DuckDuckGo send it at the header level (Sec-GPC: 1). Even if the user clicks “accept all” on the banner, when GPC is detected the ad_storage, ad_user_data, ad_personalization signals flip to denied automatically, and Shopify Customer Privacy API flips sale_of_data to false⁷. Tractor Supply was fined $1.35M by the California AG in 2025 for ignoring the GPC signal. GPC detection should be enabled by default on the CMP side.

TCF 2.2 and Google Additional Consent (AC string). IAB Europe’s TCF 2.2 framework is common on the publisher/programmatic side. For its own ad-tech partners (ATPs) not in the IAB GVL, Google uses a separate addtl_consent string. On publisher sites running GAM/AdSense, sending TCF + AC string together is required; otherwise Google eligibility drops⁸. Not usually relevant for e-commerce storefronts.

Hashed PII: Pseudonymization, Not Anonymization

GDPR Recital 26 and EDPB guidance are clear: a sha256-hashed email is not “anonymous” but pseudonymous. Even though the hash is one-way, the same email always hashes to the same value; dictionary attacks, brute-force (email rainbow tables), or cross-reference make re-identification theoretically and practically possible⁹.

Operational consequences:

• Hashed PII still requires consent; sending a hashed email to Meta CAPI while ad_user_data: denied is a violation.
• Hashed PII is still covered by DSAR (subject access request); when a user requests deletion, the hashed column must also be wiped.
• Hashed PII shouldn’t be marketed as “anonymous data” in client-facing reports. Regulators don’t accept that framing.

Offline Conversion Uploads

Uploading conversions from a CRM or call centre to Google Ads (ConversionUploadService) is another personal-data transfer point. Up to 5 user_identifiers per conversion (hashed email, hashed phone, mailing address) are sent¹⁰. Because it’s CRM → API rather than web → tag, it’s often missed in Consent Mode v2 matrices; the same principle applies: the user must have ad_user_data consent or the upload must be skipped. Consent state should be stored in the CRM and used as a filter on upload.

Consent Signal × Data Type Mapping Matrix

Data	Primary Consent Signal	Transit	Notes
Raw email (form)	n/a (gated at API level)	Client or server	Must not reach GA4; goes to Meta/Google as hash
Hashed email (CAPI em)	ad_user_data	sGTM or client	Normalize + sha256; strip from payload when denied
Hashed phone (ph)	ad_user_data	sGTM or client	E.164 + sha256
GA4 client_id (_ga cookie)	analytics_storage	Client cookie	Denied: transient token
Meta _fbp / _fbc	ad_storage	Client cookie	Denied: cookieless
gclid / gbraid / wbraid	ad_storage	URL → cookie	Denied: passable via url_passthrough, no cookie
Newsletter subscriber email	First-party (purpose: subscription)	Server	Separate opt-in for remarketing
Webhook payload email	First-party (purpose: transaction)	Server-to-server	Consent gate required for 3rd-party forward
IP (GA4)	analytics_storage (default masked)	Client → Google edge	Geo derivation only
IP (Meta CAPI, client_ip_address)	ad_storage	sGTM → Meta	Intentionally raw; sGTM/proxy trim optional
User-Agent (Meta CAPI)	ad_storage	sGTM → Meta	Intentionally raw; required for match quality
GA4 user_property (custom)	analytics_storage	Client → GA4	Naming convention to avoid PII
GA4 page_location	analytics_storage	Client → GA4	Query-string PII redaction mandatory
Offline conversion upload	ad_user_data	Server → Google API	Store consent state in CRM, filter at upload
GPC signal	override: ad_* = denied	Browser header	Overrides CMP banner decision

Related Posts

• Google Consent Mode v2 Implementation
• You Added a Consent Banner and Traffic Dropped 30%
• GA4 and Google Ads Data Controls Consolidation
• Google Ads Enhanced Conversions Guide

Footnotes

1. Remove PII from Google Analytics hits. Simo Ahava ↩
2. Data redaction. Google Analytics Help ↩
3. Set up Enhanced Conversions. Google Ads Help ↩
4. Scout: Data Enrichment & Routing ↩ ↩²
5. Anonymizer power-up. Stape ↩
6. Using the IP Transformer / Anonymizer server-side GTM template. dumbdata ↩
7. Global Privacy Control 2026. Clym ↩
8. About Additional Consent Mode. Google Ad Manager Help ↩
9. GDPR alert: Are your Enhanced Conversions legal? Optimize Smart ↩
10. Upload offline conversions. Google Ads API ↩

Key Takeaways

• 01 Personal data moves in three forms in measurement: raw (email, phone), hashed (sha256 PII for Enhanced Conversions/CAPI), and pseudonymized IDs (client_id, fbp, gclid). Each form has different consent requirements.
• 02 The most common GA4 PII leakage happens in page_location and site-search parameters. URLs with email or phone in query strings flow straight to GA4; event scrub is mandatory.
• 03 Hashing responsibility for Enhanced Conversions and Meta CAPI user_data lies either client-side or in sGTM; sending unhashed PII to Meta is rejected, while Google accepts unhashed over HTTPS and hashes server-side.
• 04 Using a newsletter subscription email for a remarketing audience is an opt-in scope expansion; a separate consent base is required (marketing purpose opt-in).
• 05 IP is masked by GA4 by default; Meta CAPI and other server-to-server calls send the full IP, which can be trimmed at an sGTM or reverse-proxy layer.

Frequently Asked Questions (FAQ)

+ Which data types do the four Consent Mode v2 signals cover?

ad_storage governs advertising cookies (_fbc, _fbp, _gcl); analytics_storage governs GA4 first-party cookies (_ga); ad_user_data gates transmission of hashed email/phone to Google/Meta; ad_personalization controls whether a user is added to remarketing audiences. IP and pseudonymized IDs don't map 1:1 to these signals; they form a separate layer.

+ What should I do about emails in GA4 page_location?

Event scrub: a GTM variable strips hashable PII patterns (email, phone regex) from page_location and emits the cleaned URL. Alternatively, GA4 property-level redaction (Admin > Data Collection > Redact Data) can be enabled; it uses the pattern [A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,} across page_location, page_referrer, page_path, link_url, video_url, and form_destination.

+ Who hashes email for Enhanced Conversions?

With client-side Enhanced Conversions auto-collect, the Google Tag reads form fields and hashes them. With manual or sGTM setups, hashing is your responsibility: sha256 over a normalized value (lowercase, trim). Google Ads also accepts unhashed values over HTTPS and hashes server-side; pre-hashing on the client remains the best-practice pattern so raw PII never leaves the browser.

+ Can I use a newsletter subscriber email for remarketing?

No, newsletter subscription consent is limited to content delivery. Adding the same email to a Google Customer Match or Meta Custom Audience is a separate marketing purpose and requires its own consent base. The subscription form should have a distinct 'usable for marketing communications' checkbox.

+ How do I anonymize IP in sGTM?

A custom Transformation or variable inside the sGTM container can mask the last octet of the IP (e.g., 192.168.1.42 → 192.168.1.0). The Transformation is applied to all outbound events, so CAPI, Enhanced Conversions, and other destinations share a consistent IP behaviour. Stape's Anonymizer power-up and the community IP Transformer template are ready-made solutions.