Common sGTM Transformation Bugs and How to Catch Them (2026)

What are the most common sGTM bugs?

The seven recurring sGTM transformation bugs in 2026: (1) Consent Mode V2 signals stripped in server transformations (breaks EU/UK Google Ads measurement), (2) event_id missing on Meta CAPI causing browser-pixel + CAPI conversion duplication, (3) GA4 Client claiming requests before the intended client (most painful since v3.2.0 changed the client priority logic), (4) PII passed through to GA4 violating Google's TOS, (5) Meta CAPI user data unhashed causing match quality drops to 0–4, (6) user_properties array dropped in transformation, and (7) currency code missing on purchase events.

Most are caught only after they've shipped to production. The diagnostic pattern is consistent: GTM Server preview mode + curl-based payload inspection + downstream platform admin signals.

The seven bugs

Bug 1 — Consent Mode V2 signals stripped in transformation

Symptom: GA4 admin shows "Ads measurement consent signals not detected" even though DevTools shows gcd parameter present in incoming requests.

Cause: A server-side transformation (often a Variable that rewrites the event_data object) drops the consent signals before forwarding to GA4. Common culprits: a Variable that whitelists specific keys and forgets to include consent_* keys, or a custom Tag template that constructs the outgoing payload from scratch without copying consent fields.

Fix:

1. In sGTM, view the Tag → check the event_data being sent
2. Confirm gcs, gcd, consent_default, and consent_update fields are present
3. If using a custom Variable, ensure all four V2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) are in the whitelist
4. Re-test with DevTools → the GA4 admin signal indicator should turn green within 24 hours

This is the single most common bug we see in 2026 audits — affects roughly 25% of audited sGTM implementations.

Bug 2 — event_id missing on Meta CAPI causing duplication

Symptom: Meta Events Manager shows roughly 2x the conversion count expected. Match quality drops because Meta sees "duplicate" events and weights them lower.

Cause: Meta CAPI requires an event_id parameter that matches between the browser pixel firing and the server-side CAPI event. When the IDs match, Meta deduplicates. When they don't (or one is missing), Meta counts both events.

Fix:

1. Generate a unique event_id at the page level (e.g., <timestamp>_<random>) and store it in dataLayer
2. Pass the same event_id to BOTH the Meta browser pixel AND the sGTM Meta CAPI tag
3. In sGTM, verify the event_id parameter is included in the CAPI payload
4. Check Meta Events Manager → Diagnostics tab for "Deduplication" status — should show "Working"

This bug is silently inflating conversion counts on roughly 30% of sGTM Meta CAPI implementations we audit.

Bug 3 — GA4 Client claims requests before intended client (post-v3.2.0)

Symptom: Custom client logic doesn't fire. Events appear in GA4 with default GA4 Client transformation rather than the custom processing you configured.

Cause: sGTM v3.2.0 (September 2025) changed Client priority logic. The GA4 Client now claims requests with higher priority than custom Clients in some configurations. If your custom Client was relying on the previous priority order, it stops getting requests.

Fix:

1. Check Client priority in sGTM (Clients tab)
2. If GA4 Client is priority 1 (highest), and your custom Client is meant to handle GA4-format requests first, change priority order
3. Verify in Preview mode: incoming request → expected Client claims it → expected Tags fire
4. Test with both GA4 events and your custom event types

The v3.2.0 update also stopped the GA4 Client from loading gtag.js — it now relies on the Web Container Client. Implementations that didn't update their Web Container configuration broke quietly.

Bug 4 — PII passed through to GA4

Symptom: GA4 admin sends a TOS violation notice. Or audit detects email addresses, phone numbers, or names in event_params.

Cause: Server-side transformations didn't strip PII before forwarding. Common patterns: page_location includes ?email=user@example.com from a query parameter, search_term contains identifiable data, or a custom event includes unhashed user data.

Fix:

1. Add a server-side Variable that strips known PII patterns from page_location, page_referrer, and event parameters
2. Use regex to detect email-like patterns: /[\w.-]+@[\w.-]+\.\w+/g — replace with [REDACTED]
3. Strip phone-number patterns: /\b\d{3}[-.]?\d{3}[-.]?\d{4}\b/g
4. Test with sGTM Preview mode: send a synthetic event containing fake PII, verify it's redacted before the GA4 Tag fires

GA4 TOS prohibits PII in any form sent to GA4. Server-side filtering is the cleanest place to enforce this — better than relying on client-side correctness alone.

Bug 5 — Meta CAPI user data unhashed

Symptom: Meta CAPI match quality stays at 0–4 instead of expected 7–10. Meta Events Manager → Diagnostics → "User data quality" shows hashes failing validation.

Cause: Meta requires user data (email, phone, name, address) to be SHA-256 hashed before sending. If your sGTM transformation passes raw values, Meta either rejects the data entirely or matches at low quality.

Fix:

1. Use sGTM's built-in SHA-256 transformation Variable (or a custom one)
2. Apply it to: em (email), ph (phone), fn (first name), ln (last name), ge (gender), db (date of birth), ct (city), st (state), zp (ZIP), country
3. Lowercase before hashing — Meta requires email.toLowerCase().trim() then SHA-256
4. Verify in sGTM Preview: outgoing CAPI payload should show 64-character hex strings, not raw values

Match quality 9+ is achievable with proper hashing of email + phone + first name + last name. Below 7 indicates either incomplete data or hashing problems.

Bug 6 — user_properties array dropped in transformation

Symptom: Custom user-level dimensions don't populate in GA4 reports. user_pseudo_id remains the only user identifier.

Cause: A server-side transformation that constructs the outgoing event payload doesn't copy the user_properties field. Often happens when a custom Tag template is used instead of the default GA4 Tag.

Fix:

1. In sGTM Preview, inspect the incoming request's user_properties field
2. Check the outgoing GA4 event payload — verify user_properties is present
3. If using a custom Tag template, explicitly pass user_properties in the outbound configuration
4. Test by setting a custom user_property client-side and verifying it appears in GA4 User properties report

Bug 7 — Currency code missing on purchase events

Symptom: GA4 purchase revenue reports show currency mismatch warnings. Some purchases land in default currency (USD) instead of the property's configured currency.

Cause: Currency parameter not preserved through server-side transformation. Sometimes happens when the client sends currency: 'GBP' but the server transformation only forwards value without currency.

Fix:

1. Verify the client-side purchase event includes the currency parameter (ISO 4217 format: GBP, EUR, USD)
2. In sGTM, check the outgoing GA4 purchase Tag includes currency in event parameters
3. Use sGTM Preview: synthetic purchase event → confirm currency reaches GA4
4. Cross-check GA4 Monetisation report → revenue by currency. Should be 100% in your configured currency.

The diagnostic pattern

The same diagnostic workflow catches all seven:

Step 1 — sGTM Preview mode

In sGTM, click Preview. This loads the preview console showing:

• Incoming requests (what your client-side sent)
• Client claims (which Client picked up the request)
• Tags fired (and what data they sent to where)
• Outgoing requests (what was forwarded to GA4, Meta, etc.)

For each bug above, the Preview mode shows you exactly where the data is being lost or transformed incorrectly.

Step 2 — curl-based payload inspection

For requests that go to your sGTM endpoint, inspect them with curl from a different terminal:

This sends a synthetic event to your sGTM and lets you inspect the response headers and any logging you've configured. Useful for debugging routing issues.

Step 3 — downstream platform admin signals

Each downstream platform has admin indicators of data quality:

• GA4: Admin → Data Streams → Configure tag settings → Consent settings (V2 signal indicators)
• Meta: Events Manager → Diagnostics tab (deduplication status, match quality, user data quality)
• Google Ads: Tools → Conversions → check Enhanced Conversions match rate
• TikTok: Events Manager → Diagnostics → similar to Meta

If sGTM Preview shows everything correct but the platform admin shows red, the issue is in transit between sGTM and the platform — usually authentication, API tokens, or network egress restrictions.

Step 4 — production validation 7 days post-deploy

After deploying, wait 7 days then revisit:

• GA4 admin V2 signal indicators should be green
• Meta match quality should reach target (9+ ideally)
• Google Ads Enhanced Conversions match rate should be 70%+
• No PII alerts in GA4
• No discrepancies between client-side pixel and server-side CAPI event counts

If any of these fail at the 7-day mark, the bug is still active. Re-run the diagnostic pattern.

Prevention pattern: the sGTM QA checklist

Before any sGTM change ships to production, run this checklist:

1. ☐ Preview mode shows expected Client claims request
2. ☐ Outbound payload includes all consent parameters (gcs, gcd, V2 signals)
3. ☐ Outbound payload to Meta CAPI includes event_id matching the client-side pixel
4. ☐ User data fields are hashed (SHA-256, lowercased) before forwarding to Meta/Google Ads
5. ☐ user_properties is present in outbound GA4 events
6. ☐ Currency code is preserved in purchase events
7. ☐ No PII (email, phone, name) appears in any outbound event_params
8. ☐ Custom event types route to expected destination Tags
9. ☐ Logging is configured to capture errors but not log every request (cost containment)
10. ☐ Staging environment tested with synthetic data matching production patterns

This checklist should be in your CI/CD or change-management workflow, not a manual document people forget about.