Overview
This check monitors the network requests sent to Adobe Analytics to ensure they do not contain sensitive data. Adobe’s terms of service strictly prohibit the collection of PII (e.g., email addresses, social security numbers, full names, or physical addresses) and PHI (e.g., medical record numbers or specific health condition data) within standard Adobe Analytics variables.
If this sensitive information is captured, it is stored in plain text within your report suites, creating a significant security and compliance liability.
Why it is important
Collecting PII or PHI is one of the highest-risk implementation errors an organization can make:
Regulatory Penalties: Violating privacy laws like GDPR, CCPA, or HIPAA can lead to massive legal fines and mandatory reporting of data breaches.
Adobe Terms of Service: Adobe reserves the right to terminate your account or delete entire report suites if PII is found within the data.
Data Deletion Complexity: Removing PII from Adobe Analytics is a difficult and expensive process (Data Repair API), often requiring you to delete vast amounts of legitimate data to ensure the sensitive bits are gone.
Reputational Risk: A leak of user emails or health data in a data export can lead to a loss of customer trust and negative media coverage.
Implementation
ObservePoint identifies PII/PHI leakage by scanning every network request for specific patterns and strings that match sensitive data formats.
Trigger: The check is active during all Audits and Journeys.
Logic: The platform uses Regular Expressions (Regex) to look for common sensitive data patterns (e.g.,
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}for emails) across all tag variables (eVars, props, etc.).Validation: You can configure ObservePoint with custom "Deny-lists" containing specific sensitive terms or internal IDs that should never be tracked.
Failure: The check flags any page or interaction where a tag variable contains a string that matches a PII/PHI pattern.
Remediation
If PII or PHI is detected in your tags, take immediate action to sanitize your implementation:
1. Redact Sensitive Data via TMS
If your site naturally includes sensitive data in the URL (e.g., a "Welcome" page with an email parameter), you must strip it before it is sent to Adobe.
Action: In Adobe Launch (AEP Tags), use a Custom Code block to "scrub" high-risk variables.
Example:
s.pageName = s.pageName.replace(/email=[^&]*/, "email=REDACTED");
2. Mask Form Inputs
If you are tracking "Form Errors" or "Field Names," ensure you are not accidentally capturing the value of the input.
Action: Verify that your "Interaction" rules only capture the
nameorIDof the field, never the user's input (e.g., track that "Password Field" had an error, not what the password was).
3. Audit Query String Parameters
Often, PII "leaks" into eVar1 (Page URL) or eVar2 (Referrer) automatically.
Action: Use the Query String Management settings in the Adobe Analytics Admin console to "Exclude" specific parameters from being recorded in your reports.
4. Data Layer Scrubbing
Prevent the issue at the source by ensuring the Data Layer is cleaned by the development team before the TMS even sees it.
Action: Ask developers to ensure that any "User Object" in the Data Layer only contains an anonymized Global UID or hashed ID, never a plaintext name or email.
Conclusion
Protecting user privacy is a non-negotiable part of modern data governance. By ensuring that your Adobe Analytics tags do not collect PII or PHI, you protect your customers, your brand reputation, and your historical data.
Regular automated monitoring via ObservePoint is the only scalable way to catch accidental "leaks" across a large site before they become a liability.