v2.0's PII Leak Detector scans every captured fire's URL and parsed payload for personally-identifying information. Findings are tiered per-platform and badged inline on affected events.
What it scans
- The fire's URL — query string and path
- The parsed payload — fetch body, form data, JSON, sendBeacon body
- JS hook arguments — gtag/fbq/uetq/clarity call args
What it catches
Raw email addresses
RFC-5321-ish regex. Catches [email protected] in any param value, even if the param is named something innocuous like x or data.
Raw phone numbers
International / national format regex. Catches numbers with + prefix, dashes, parentheses, or spaces. False-positive guard against IDs that happen to match (requires a +, a country-code-like prefix, or specific length thresholds).
Named PII fields (15+)
Parameters whose name matches a known PII vocabulary, with their values flagged regardless of format:
email,e_mail,user_email,user_data.emailphone,phone_number,tel,mobilefirst_name,last_name,fullname,namedob,date_of_birth,birthdayssn,social_security,ninzip,postcode,postal_codeaddress,street,city,state,region,countrygender,ge(Meta short-code)
Short-code parameters (heuristic)
Meta and other vendors use 2-letter shortcodes for PII fields:
| Code | Field | Heuristic check |
|---|---|---|
em | value contains @ | |
ph | phone | value matches phone regex |
fn | first_name | value is alphabetic, not all caps |
ln | last_name | same as fn |
ge | gender | value is f / m / o |
db | date of birth | value matches date regex |
ct | city | value is alphabetic |
st | state / street | contextual |
zp | zip | value matches postal regex |
co | country | value is 2-letter ISO code |
em=marketing on a UTM-style param shouldn't trigger a PII alert. The value has to actually look like the relevant PII type.
Hashed values
If a value matches a SHA-256 / MD5 pattern (64 / 32 hex chars), Pixel Auditor flags it as "likely hashed PII" at lower severity. Hashed PII is what Meta's Advanced Matching is designed to ship — it's expected, but worth knowing it's there.
Per-platform tiering
Different platforms have different "expected PII" profiles:
- Meta Pixel with Advanced Matching — hashed em / ph / fn / ln are expected; raw values are still flagged red
- GA4 — any raw PII is flagged red (GA4's terms prohibit it)
- Vendor server APIs — hashed PII is expected (the whole point of server-side matching); raw values are still flagged red
- LinkedIn Insight — no PII expected
- Bing UET — Enhanced Conversions sends hashed; raw flagged
Where findings appear
- Live Events — PII badge inline on affected rows
- Drawer — every leaked field listed with original key + redacted preview
- Audit tab — "PII findings" section grouped by platform
- Tags tab — affected tag cards get a PII badge
- Audit report export — full PII section
Privacy of the detector itself
The detector runs in your browser. PII findings are stored in the panel's in-memory state and in any Saved Run you create on your machine. Nothing is sent anywhere. The redacted previews shown in the UI are computed locally — original values are still in your browser's runtime, exactly as they were before Pixel Auditor saw them.