Customer Data Not in Data Layer
GTM variables for customer PII (email, phone, first_name, address, etc.) return undefined, or the customerData object does not exist in the data layer.
1. Enhanced Conversions Is Not Enabled
The customerData object is not pushed by default. It requires the Enhanced Conversions setting to be explicitly enabled in the module.
Check: Go to Addons → Google Tag Manager → Enhanced User Conversion. Verify the "Enable Enhanced Conversions" checkbox is checked.
Fix: Check the box and click Save. The customerData object will now be injected on every page load for logged-in users.
This feature is available from module v4.2+. If you are on an older version, upgrade the module first.
2. User Is Not Logged In
Even with Enhanced Conversions enabled, customerData is only pushed when the user is authenticated. Guest sessions, unauthenticated page views, and the login page itself will not include customerData.
Check: Log in to your WHMCS store as a client and then open GTM Preview. The customerData object should appear on the first page load after login.
Expected behavior:
- Logged-in client →
customerDatapresent ✓ - Guest / not logged in →
customerDataabsent (by design) ✓
3. Client Profile Is Incomplete
The customerData object is always pushed for logged-in users (when Enhanced Conversions is enabled), but individual fields like phone, address.city, or address.postal_code will be empty strings if the client has not filled them in their WHMCS profile.
Empty string fields are still pushed to the data layer — they will appear as "" rather than undefined. GTM variables reading these paths will return an empty string, which most tag configurations treat as a falsy/non-matching value.
Fix: This is a data quality issue. If consistent phone and address data is critical (e.g. for Facebook CAPI Event Match Quality), encourage your clients to complete their billing profile, or use a WHMCS requirement hook to make those fields mandatory on registration.
4. Specific Fields Are undefined vs Empty String
There is an important distinction:
| Situation | GTM variable value |
|---|---|
| Enhanced Conversions disabled | undefined (key does not exist in data layer) |
| Enhanced Conversions enabled, user logged in, field is empty in WHMCS | "" (empty string) |
| Enhanced Conversions enabled, user logged in, field has a value | "[email protected]" |
If you see undefined for a specific field like customerData.email, it almost always means Enhanced Conversions is disabled and the entire customerData object is absent — not that the email field specifically is missing.
5. customerData Present But Hash Variables Are Empty
The email_hash, phone_hash, first_name_hash, and last_name_hash fields are computed using SHA-256 only if the source field is non-empty. If the plain text field is empty, the hash is also an empty string.
Check: Verify the source field in the client's WHMCS profile first. If customerData.email has a value but customerData.email_hash is empty, please open a support ticket — this would be an unexpected behavior.
6. Using Container Template Variables — Verify Data Layer Path
If you are using the Container Template, the customer data variables are pre-built. However, if you manually created your own variables with different data layer paths, they may not match the actual structure.
The correct paths in the data layer are:
| Field | Correct Data Layer Variable Path |
|---|---|
customerData.email | |
| Email (hashed) | customerData.email_hash |
| Phone | customerData.phone |
| Phone (hashed) | customerData.phone_hash |
| First name | customerData.first_name |
| Last name | customerData.last_name |
| City | customerData.address.city |
| Region / State | customerData.address.region |
| Country | customerData.address.country |
| Postal code | customerData.address.postal_code |
| Street | customerData.address.street |
A common mistake is using customer_data.email (underscore) or userData.email instead of customerData.email (camelCase).