Google Data Manager API lists CUSTOM_VARIABLE_NOT_ENABLED when the custom variable is not enabled. Retrying the same event cannot change destination configuration. The response should identify the exact destination reference, variable name, enablement state, deployment timing, affected queue rows, and whether the field belongs in a custom variable at all.
Use this for WordPress forms, WooCommerce events, CRM uploads, and server-side conversion pipelines that map business fields into Google Ads custom variables.
Quick answer
Stop automatic retries for the affected mapping, record the request and destination references, and verify that the exact custom variable exists and is enabled in the selected destination. Correct scope, spelling, or deployment state, validate a synthetic event, then replay only queued rows that failed for this permanent configuration reason.
What to check first
- Capture request ID, event ID, destination references, account, conversion action, variable name, value type, source field, first failure time, and retry count.
- Compare the payload variable and destination references with the current destination configuration, including case, scope, status, account, and environment.
- Confirm whether the variable was created but not enabled, enabled on another destination, renamed, deleted, pending deployment, or unavailable for the event type.
- Run validate-only or a non-converting synthetic request when supported, and confirm diagnostics no longer return the error before releasing production rows.
- Replay only the quarantined rows with stable event IDs and deduplication, then monitor request status and downstream reporting.
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 |
|---|
| Quarantine the permanent error | Capture request ID, event ID, destination references, account, conversion action, variable name, value type, source field, first failure time, and retry count. | The destination and variable state are captured from the correct account. |
| Verify destination and variable | Compare the payload variable and destination references with the current destination configuration, including case, scope, status, account, and environment. | A synthetic or validate-only request completes without the error. |
| Correct configuration or mapping | Confirm whether the variable was created but not enabled, enabled on another destination, renamed, deleted, pending deployment, or unavailable for the event type. | Replay preserves event IDs and produces no duplicate conversion. |
| Validate one synthetic event | Run validate-only or a non-converting synthetic request when supported, and confirm diagnostics no longer return the error before releasing production rows. | Request-status monitoring shows accepted rows and no renewed enablement failures. |
Why this usually happens
- A variable can exist in one Google Ads account or destination but not the destination referenced by the event.
- Configuration deployment can lag behind a WordPress or CRM mapping release.
- Copying a mapping between environments can preserve the source field while changing destination references.
- Retry workers often treat every API error as temporary and create queue noise without fixing configuration.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id: lead-18422
source_field: lead_quality
custom_variable.variable: lead_quality_band
custom_variable.value: high
destination_references: [google_ads_main]
error_reason: CUSTOM_VARIABLE_NOT_ENABLED
retry_class: permanent_configuration
replay_after: enablement_verified
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.
- Quarantine the permanent error
- Verify destination and variable
- Correct configuration or mapping
- Validate one synthetic event
- Replay with stable IDs
Decision rule
Do not retry until the exact destination confirms the variable is enabled. If the field has no durable reporting use or carries privacy risk, remove the mapping instead of enabling it automatically.
What to tell the client or owner
Share request and event IDs, destination references, account, source field, variable name and state, mapping version, first failure, retry count, configuration change, validation result, replay set, and monitoring result.
Production verification checklist
- The destination and variable state are captured from the correct account.
- A synthetic or validate-only request completes without the error.
- Replay preserves event IDs and produces no duplicate conversion.
- Request-status monitoring shows accepted rows and no renewed enablement failures.
Mistakes to avoid
- Do not confuse NOT_ENABLED with NOT_FOUND.
- Do not create another similarly named variable before checking destination scope.
- Do not replay the whole queue after changing one mapping.
- Do not place personal data in a custom variable to improve match rate.
Questions teams ask during testing
Is CUSTOM_VARIABLE_NOT_ENABLED retryable?
Treat it as a permanent configuration error until the destination or mapping changes. Time alone does not enable a variable.
What if the variable is enabled in the UI?
Verify the account and destination reference used by the request, wait for documented propagation when applicable, and test a synthetic event. A similarly named variable in another destination does not satisfy the event.
When HandL WP should help
HandL WP can trace WordPress and CRM fields to the exact Data Manager destination, correct mappings, quarantine permanent errors, replay safely, and verify Google Ads reporting.
If this is active on a production site, fix Data Manager custom variable uploads.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references