Google Data Manager API lists CUSTOM_VARIABLE_VALUE_CONTAINS_PII when a custom variable value contains personally identifiable information. WordPress forms and CRM schemas make this easy to cause when generic mapping rules copy email, phone, name, address, click metadata, notes, or free text into custom-variable slots.
Use this for teams mapping Elementor, Gravity Forms, WPForms, Contact Form 7, WooCommerce, or CRM records into Data Manager API events.
Quick answer
Inventory every custom-variable source, classify the field, and block direct values or transformed strings that can identify a person. Put allowed user-provided data only in the API's approved user-data structure with the required consent and normalization. Keep custom variables limited to non-personal business categories, validate before send, and quarantine rejections without logging raw values.
What to check first
- Export the mapping schema, not production values, and identify every source field that can reach a custom variable through defaults, wildcards, templates, or fallback logic.
- Classify email, phone, name, postal address, IP, user IDs, click IDs, order notes, URLs, file names, CRM notes, and free text under the organization's privacy rules.
- Inspect transformations for concatenation, hashing, encoding, truncation, or labels that still leave a value personal or reversible.
- Move approved user-provided data into the correct API fields only when consent, policy, normalization, and destination rules permit it.
- Add pre-send validation, redacted error telemetry, permanent-error quarantine, synthetic tests, and controlled replay after the mapping is corrected.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory mappings without raw values | Export the mapping schema, not production values, and identify every source field that can reach a custom variable through defaults, wildcards, templates, or fallback logic. | No direct or indirect personal field reaches custom variables. |
| Classify every source field | Classify email, phone, name, postal address, IP, user IDs, click IDs, order notes, URLs, file names, CRM notes, and free text under the organization's privacy rules. | Approved user-data fields follow consent and normalization rules. |
| Move or remove personal data | Inspect transformations for concatenation, hashing, encoding, truncation, or labels that still leave a value personal or reversible. | Logs, alerts, and dead-letter records redact rejected values. |
| Add redacted validation | Move approved user-provided data into the correct API fields only when consent, policy, normalization, and destination rules permit it. | Synthetic and replay requests pass without duplicate events or renewed PII errors. |
Why this usually happens
- Generic field mappers treat every string as suitable for a custom variable.
- Hashing a personal value does not automatically make it appropriate for an arbitrary field.
- Free-text fields can contain names, emails, phone numbers, and case details even when the field label sounds harmless.
- Debug logs and dead-letter queues can preserve the rejected raw value long after the API call.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
source_field: lead_email
source_class: direct_identifier
current_target: custom_variables.lead_detail
decision: block
approved_target: user_data.email_address
consent_required: true
telemetry_value: '[redacted]'
error_reason: CUSTOM_VARIABLE_VALUE_CONTAINS_PII
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory mappings without raw values
- Classify every source field
- Move or remove personal data
- Add redacted validation
- Replay only corrected rows
Decision rule
A custom variable should describe the event or business category without identifying the person. If a field can contain personal data or arbitrary text, block it unless an approved, documented transformation produces a genuinely non-personal category.
What to tell the client or owner
Share the schema-only mapping inventory, field classifications, approved targets, blocked transformations, consent requirements, redaction controls, affected row count, validation requests, replay IDs, and monitoring result.
Production verification checklist
- No direct or indirect personal field reaches custom variables.
- Approved user-data fields follow consent and normalization rules.
- Logs, alerts, and dead-letter records redact rejected values.
- Synthetic and replay requests pass without duplicate events or renewed PII errors.
Mistakes to avoid
- Do not solve the rejection by renaming the variable.
- Do not assume hashing makes every personal value acceptable everywhere.
- Do not send free text as a diagnostic field.
- Do not keep raw rejected payloads in support tickets or long-lived logs.
Questions teams ask during testing
Can email be sent as a custom variable if it is hashed?
Use the API's approved user-data fields and current Google requirements for allowed user-provided data. Do not use a custom variable as an alternate email field.
Are click IDs considered custom-variable values?
Use the API's designated identifiers and event fields. Mapping identifiers into arbitrary custom variables can create policy, reporting, and debugging problems.
When HandL WP should help
HandL WP can audit WordPress and CRM tracking fields, separate approved user data from custom dimensions, fix Data Manager mappings, and verify privacy-safe uploads.
If this is active on a production site, audit Data Manager privacy mappings.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references