Google lists INVALID_CUSTOM_VARIABLE_VALUE separately from CUSTOM_VARIABLE_NOT_FOUND, CUSTOM_VARIABLE_NOT_ENABLED, and CUSTOM_VARIABLE_VALUE_CONTAINS_PII. That distinction matters. The route may be correct and the variable may exist, while a specific transformed value violates the accepted representation. The pipeline needs field-level diagnostics without leaking raw lead data.
Use this for WordPress forms, WooCommerce events, CRM stages, lead scoring, and offline conversions that map business fields into Data Manager custom variables. Involve the measurement owner before changing categorical meaning, numeric units, null handling, or destination variable definitions.
Quick answer
Capture the variable name, destination, redacted source type, transformation version, output type, length, empty state, and error field. Compare successful and failed values without logging personal content. Define an allowlisted representation, handle absent and unknown states explicitly, test boundary values with synthetic data, and replay only rejected rows under a versioned mapping with stable event IDs.
What to check first
- Separate variable lookup, enablement, privacy, and value errors so a valid variable is not recreated or renamed unnecessarily.
- Record source field type, source system, mapping rule, transformation version, output representation, character length, byte length, null or empty state, destination, and request status.
- Build privacy-safe frequency counts for successful and rejected representations, including booleans, numbers, arrays, objects, whitespace, encoded values, locale formats, and sentinel strings.
- Confirm business meaning and accepted units with the measurement owner before coercing values such as revenue bands, lead stages, subscription terms, or product categories.
- Test valid, empty, minimum, maximum, unknown, Unicode, numeric, categorical, and deliberately invalid synthetic values, then verify request and destination diagnostics.
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 |
|---|
| Confirm the exact error family | Separate variable lookup, enablement, privacy, and value errors so a valid variable is not recreated or renamed unnecessarily. | Lookup, enablement, PII, and invalid-value errors are measured separately. |
| Profile redacted source and transformed value shapes | Record source field type, source system, mapping rule, transformation version, output representation, character length, byte length, null or empty state, destination, and request status. | Synthetic boundary tests establish the accepted representation and null policy. |
| Approve a typed allowlist and null policy | Build privacy-safe frequency counts for successful and rejected representations, including booleans, numbers, arrays, objects, whitespace, encoded values, locale formats, and sentinel strings. | The corrected mapping preserves business meaning and does not log raw user data. |
| Test synthetic boundary values | Confirm business meaning and accepted units with the measurement owner before coercing values such as revenue bands, lead stages, subscription terms, or product categories. | Replayed rows keep event identity and complete without duplicate conversions. |
Why this usually happens
- WordPress form fields often arrive as strings even when the destination expects a normalized category or number.
- Empty strings, nulls, missing fields, and the word unknown can be treated differently.
- Locale decimal, date, currency, or boolean formats may survive into the API payload.
- A mapping change can produce arrays or objects where a scalar was expected.
- Quick truncation or hashing can change business meaning and still fail privacy requirements.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
variable: lead_stage
source_type: string
source_value_class: internal_enum
transform_version: lead-stage-v4
raw_value_logged: false
normalized_value: qualified
output_type: string
output_bytes: 9
destination_enabled: true
validation_result: pass
event_id: wp-lead-9901-stage-2
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.
- Confirm the exact error family
- Profile redacted source and transformed value shapes
- Approve a typed allowlist and null policy
- Test synthetic boundary values
- Version the mapping and replay rejected rows
Decision rule
Do not coerce a rejected value until the accepted type and business meaning are known. Drop the variable from a row only when the measurement owner confirms it is optional and the omission does not misclassify the event.
What to tell the client or owner
Give the measurement owner the variable name, destination, source type, rejected shape counts, mapping version, approved representations, null policy, test results, affected row count, and replay boundary. Do not include raw personal values.
Production verification checklist
- Lookup, enablement, PII, and invalid-value errors are measured separately.
- Synthetic boundary tests establish the accepted representation and null policy.
- The corrected mapping preserves business meaning and does not log raw user data.
- Replayed rows keep event identity and complete without duplicate conversions.
Mistakes to avoid
- Do not recreate the variable when the error says the value is invalid.
- Do not stringify objects or arrays blindly.
- Do not truncate or hash values without checking meaning and privacy policy.
- Do not log rejected raw lead values in application or support logs.
Questions teams ask during testing
Is this the same as CUSTOM_VARIABLE_NOT_FOUND?
No. Google lists separate reasons. INVALID_CUSTOM_VARIABLE_VALUE means the value is invalid, while NOT_FOUND concerns the destination variable name.
Can I omit the custom variable and send the event?
Only if the field is optional and the measurement owner confirms omission will not change event interpretation or downstream use.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, fix a Data Manager variable mapping.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references