Overview
This check inspects the actual variable payloads sent by tags for raw, unhashed personal data structures (phone numbers, email addresses, physical addresses, or explicit demographic arrays) that should never appear in outbound tag traffic in plain form, whether by design or as a side effect of a misconfigured data layer.
Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific GDPR compliance obligations.
Why it is important
GDPR's data minimization principle combined with Recital 26's pseudonymization guidance establishes a clear expectation: where an identifier must be shared with a marketing or measurement vendor for a legitimate purpose (such as an audience-matching or conversion-tracking use case), it should be cryptographically hashed (e.g., SHA-256) or otherwise pseudonymized rather than transmitted as raw, directly identifying data, a distinction most opt-out jurisdictions don't draw as explicitly, but which GDPR treats as a specific, checkable expectation.
Implementation
Create an authenticated Audit and run it. Authenticated audits are much higher risk for collection and sharing of personal data. Also, create Journeys for high-risk flows like sign-up, login, and checkout. Pro-tip: You can use ObservePoint's MCP Server to create the Audit and Journeys.
Connect an AI agent platform (e.g. ChatGPT, Claude, Microsoft Co-pilot Agents, etc.) to the ObservePoint MCP Server to the ObservePoint.
Ask the agent to flag any Tag variable in your Audit and Journey runs that contains raw personal data, such as emails, phone numbers, or addresses, starting with marketing and advertising tags.
Confirm each flagged value is truly raw and not a correctly hashed (SHA-256) identifier before treating it as a leak.
Remediation
For each tag flagged with a raw PI-matching variable, trace the value back to the data-layer field or DOM element it's bound to, a mis-bound data-layer variable is the most common root cause, and the fix is typically a data-layer correction rather than a tag-manager change.
Where the identifier is genuinely needed by the vendor for a legitimate matching or measurement purpose, implement hashing at the application layer before the value ever reaches the data layer, rather than relying on the vendor's own script to hash it — the raw value should never be observable on the wire in the first place.
Confirm with the vendor's documentation which hashing algorithm and normalization steps they expect (case-folding, whitespace-trimming) before hashing, since a mismatched normalization step will cause the vendor's matching to silently fail even though the value is technically hashed.
Re-run the Audits, Journeys, and agent check after remediation to confirm the pattern no longer appears in raw form.
Conclusion
Because a single mis-bound data-layer variable can silently leak PII across every tag reading from it, treat any raw-PI finding as a signal to review the underlying data layer's field bindings, not just the individual tag where it happened to surface.