Quick answer
Check whether the source data is missing or whether Content Security Policy blocks the Custom JavaScript variable from evaluating. Google documents this CSP limitation and recommends Custom Templates as an alternative. Do not add unsafe-eval just to remove an undefined value before reviewing simpler variable types and the security impact.
Check the event where the variable is used
Open the exact event in Tag Assistant rather than looking only at the latest values after the page has finished loading. A value can be absent when the tag runs and appear later. Record the event name, source field, expected output, and actual output at the point of use.
Also check container and environment identity. A staging preview can use a different version from the published site. A variable with the same display name can be implemented differently across containers. Confirm that the test is exercising the version you intend to repair before editing production configuration.
Distinguish absent input from blocked evaluation
Inspect the source value and its type using redacted test data. If the source itself is absent, fix the event timing or field mapping. If the source is present but the custom variable is undefined, check for a JavaScript exception and a policy violation. These are evidence for different repairs.
Google's CSP guide states that Custom JavaScript variables can evaluate to undefined without unsafe-eval and identifies Custom Templates as the recommended alternative. A valid nonce for the container does not prove that every form of JavaScript evaluation is allowed. Do not confuse permission to load the container with permission to evaluate custom code.
Write down the variable contract
Record what the variable is supposed to return for ordinary, missing, blank, and malformed input. Include the output type. A number, a numeric string, a Boolean, and an empty string can behave differently in downstream conditions. Replacing a variable while changing its type can silently change which tags fire.
For a fictional lead-type field, the intended output might be a short category such as enquiry or quote. It should not be a customer email, a whole form object, or a serialized record. Minimize the data used for measurement and respect the approved consent configuration. A technically working variable can still collect inappropriate data.
Prefer the simplest suitable implementation
Check whether a built-in variable, Data Layer Variable, lookup table, or other supported configuration already expresses the requirement. A direct field read should not need a custom program. If transformation is genuinely required, review a suitable Custom Template and its permissions rather than assuming all templates are equally safe.
Keep the replacement scoped to the actual contract. Avoid broad DOM scraping when the application can provide a deliberate event field. Do not copy a random template or paste code from an unreviewed source into the container. Establish who maintains the implementation and which tags consume its result.
Test the edge cases before publishing
Use fictional values and test the variable at the same event as the affected tag. Compare the old expected contract with the replacement across ordinary and unusual inputs. Include a missing field and a value that should not trigger a conversion. The safest fallback may be to send no event rather than fabricate a valid-looking category.
- Valid input: correct value and correct type.
- Missing input: deliberate empty or absent behavior, not invented data.
- Unexpected input: handled without an exception or accidental trigger.
- Sensitive input: not copied into analytics parameters or logs.
Keep a policy change as a separate decision
If no suitable replacement exists, document the requirement and ask the security owner to review options. Do not silently weaken CSP as part of a tracking cleanup. A broad evaluation exception affects more than one variable and can alter the protection the site relies on.
Test the final solution on staging and ordinary non-preview traffic. Preview mode has its own resource requirements, so success there is not the entire acceptance test. Check that the relevant tag receives the correct value, the intended request is sent, and the destination receives the event without duplicate or unexpected parameters.
Leave a useful change record
Document the old variable, replacement, consuming tags, expected types, and the test cases that passed. Include the published container version and the site policy version. That record lets the next maintainer distinguish a later data-layer change from a security-policy regression.
Monitor the specific event after release rather than looking only at total traffic. A narrow conversion path may break while page views look normal. Keep the previous container version available for a reviewed rollback, and preserve consent and security settings while correcting any unexpected measurement behavior.
Illustrative diagnostic example, not customer measurements.When to bring in help
Ask HandL WP to review the variable contract when several tags depend on custom JavaScript. Bring redacted inputs, expected types, the event name, and the policy error. Do not share the full data layer if it contains customer details.
Related troubleshooting
Trace the form event before changing variables. Separate fired tags from blocked collection requests.
Helpful references
Google Tag Manager and Content Security Policy. Google consent mode overview.