Generate Lead

Symptom

A tag gated by an Additional Consent Check, triggered only by Initialization - All Pages, never fires — even after the visitor accepts consent.

Root Cause

The tag evaluates exactly once, before consent exists by default, and never gets a second chance once consent is later granted.

Fix

Add a second trigger tied to a custom consent_update event so the tag re-evaluates whenever consent state actually changes. Applied to Microsoft Clarity, LinkedIn Insight Tag, and Meta Pixel Base — all page-load, one-time-evaluation tags.

Symptom

A Conversion Label value sent garbage data with zero errors thrown.

Root Cause

The value was manually typed into a field as {{Variable Name}} literal text rather than actually selected via GTM’s variable picker — visually identical in some views, but GTM treats it as a literal unresolved string.

Fix

Always select variables via the picker, never type the {{...}} syntax by hand.

Symptom

A previously-documented Conversion Tracking tag field for Enhanced Conversions no longer exists in the tag editor.

Root Cause

Google removed this option from the client-side Conversion Tracking tag in April 2025. Official documentation continued describing it as available for some time afterward — cost real debugging time before a recent, dated practitioner report clarified the deprecation.

Fix

The current, correct method is a separate, dedicated Google Ads: User-provided Data Event tag.

Symptom

A second, genuinely distinct lead submitted within the same browser session silently produced zero tracking events across every platform.

Root Cause

The thank-you page’s duplicate-prevention guard used a session-wide boolean flag (“has this browser session tracked any lead, ever”) instead of comparing against the specific lead’s unique token.

Fix

Compare against the specific gate token last tracked, not a blanket boolean — a refresh of the same page still correctly deduplicates; a genuinely new submission (a new token) does not get blocked.

Symptom

A duplicate, non-consent-gated CAPI system was found running in parallel to the deliberately-built server-side GTM architecture.

Root Cause

A checkbox (“Add Conversions API for web events to all new and existing datasets”) is checked by default when creating a new Meta Pixel/dataset — this auto-enrolls the Pixel into Meta’s own fully-managed, black-box CAPI system.

Fix

Manually find and disconnect this via the dataset’s own Conversions API settings (Business Settings → Data Sources → Conversions API connection → toggle off Automatically connect + Remove the connection).

Symptom

LinkedIn - Conversion (Generate Lead) had zero consent gating configured, meaning it would fire regardless of visitor consent. Not caught during the original build’s testing.

Root Cause

Surfaced only when a separate AI session, given the raw container export as ground truth, checked every tag’s actual consent configuration systematically rather than trusting the accompanying documentation’s claims.

Fix

Confirmed live via direct testing (declined consent → submitted a lead → tag fired anyway), then fixed with an Additional Consent Check requiring ad_storage + ad_user_data. A follow-up round then found the fix had also attached a Consent Update retry-trigger to this same event-driven tag — recurring the exact mistake from #3 on a different platform. That trigger was removed in a later round, confirmed via the export showing exactly one firing trigger (Generate Lead Event) remaining.

Symptom

Multiple well-isolated test attempts across several sessions all came back inconclusive for the Meta CAPI tag.

Root Cause

Real live confirmation finally arrived unprompted — a timestamped Lead event appeared in Meta’s Test Events tool showing "Received from: Server," correlated with a real, simultaneous increase in Stape’s own request counter. The event was marked "Deduplicated" despite showing no visible Event ID — the project never built the explicit event_id-sharing mechanism between the client-side Pixel and server-side CAPI tag, so Meta most likely deduplicated using a fallback signal (the shared _fbp/_fbc browser cookie) instead.

Fix

The CAPI tag is confirmed genuinely working, via an implicit fallback matching method rather than the more precise, Meta-recommended explicit event_id method. See the Event ID Deduplication guide for closing that remaining gap.

Symptom

Even after confirming user_email/user_phone were genuinely present and correctly populated in the outgoing GA4 event (verified via Tag Assistant, Values mode), Meta’s Test Events tool consistently showed no Email/Phone in that event’s "User data keys."

Root Cause

GTM server-side Event Data variables, when reading GA4-client-parsed events, must reference nested paths (params.user_email), not flat top-level keys (user_email) — GA4’s actual Measurement Protocol structure nests custom event parameters under a params object. Not found in any official documentation or practitioner writeup — identified as a well-reasoned hypothesis, then confirmed correct only by testing it live.

Fix

Built two Event Data variables with keys params.user_email and params.user_phone, then manually added two Property rows in the CAPI tag’s User Data section (Email/Phone), leaving "Automap User Data" checked alongside these explicit overrides, not replacing it. Verified fixed: Meta’s Test Events tool subsequently showed User data keys: Email address, Browser ID, IP address, Phone number, User agent.

Symptom

"Cannot detect if the Google tag is in your container" appears in the GTM editor.

Root Cause

Appears specifically when a Conversion ID field references a variable rather than a literal typed string, because GTM’s static editor-time validator cannot resolve variables at edit-time (only at runtime).

Fix

Unrelated to the "Failed" Preview-status false-negative (#7) — both are real, separate, documented quirks worth not chasing as if they were genuine errors, once confirmed benign.