The GA4 events that break without telling you

A tag that never fires gets noticed. Conversions drop to zero, someone asks, and it gets fixed the same week.

The expensive failures are partial. Conversions still arrive, the number looks plausible, and a quarter of your leads have been invisible since a form variant shipped in March.

Nothing alerts on plausible. That is the whole problem: the failure mode is designed to look like success.

There is a cost that outlives the fix, too. GA4 does not retroactively repair a period of bad collection, so a conditional failure does not just distort this month's report, it puts a permanent hole in the year you will later want to compare against. The repair is forward-only, which is the strongest argument for catching these early rather than thoroughly.

Duplicate firing. The same user action triggers two events: a tag manager tag and a hard-coded gtag call, or a thank-you page view alongside a form submission event. Conversions inflate by an unknown and variable factor.

Broken cross-domain measurement. The visitor moves to a booking platform, payment processor or subdomain, and the session breaks. GA4 records a new session from a referral, and the conversion loses its paid attribution entirely. The fix is configuration rather than code: the destination domains have to be listed on the data stream so the identifier carries across in the link parameter.

Thank-you page dependence. Form submissions tracked from a redirect URL that some forms no longer redirect to. Ship one inline-confirmation form variant and that path goes dark.

Unverified primary conversions. Someone marked a phone-number click or a PDF download as a key event, and Smart Bidding is now optimising toward it. The count is high, the quality is unknown, and the CRM disagrees with everything. Marking is a deliberate act with a limit attached: Analytics documents key events as the ones you have designated as important, and standard properties allow only thirty.

Call tracking double counts. The call platform reports a conversion and a click-to-call event fires for the same call. Both reach the ad platform.

Missing parameters. Events fire correctly and carry nothing useful, so they cannot be segmented by location, service line or value: the gap that makes per-location performance unmeasurable.

The sixth failure has a variant that fools experienced people, because the tag is genuinely correct. The event fires, the parameter is on it, and the report still shows nothing useful. The parameter was never registered as a custom dimension, so it exists in collection and not in the reporting surface.

Google's guidance is explicit that these are two steps: data appears in reports 24 to 48 hours after both the data has been sent and the custom dimension has been created. Sending is the developer's job, registering is the analyst's, and a handover between two people is exactly where a step goes missing.

There are ceilings on registration that matter for multi-location and multi-service businesses. Standard properties allow 50 event-scoped custom dimensions, 25 user-scoped custom dimensions, 50 custom metrics and 30 key events. Those are generous until somebody spends them casually, and then the parameter you actually need has no slot.

Treat the registry as a budget rather than a form. Decide what each slot buys before you spend it, and audit the list once a quarter. A property with twenty-eight key events does not have a measurement plan, it has a history of people marking things.

Read the right-hand column as the actual test matrix. Almost every conditional failure lives in a row of it.

The consent row deserves more than a line. Where consent is denied, some figures in your reports are estimated rather than counted, and Analytics labels modelled key events as such. That is not a defect, but it is a thing to know before a finance team asks whether a number was measured.

The last row is the one no implementation survives on its own. Tracking is not a project that completes; it is a thing that decays every time the site ships.

Walk each conversion path end to end in a real session with debug tooling open: user action, data layer, trigger, tag fire, platform receipt. Tag Manager's preview and debug mode connects to the live site and shows which tags fired and why, which turns "the tag should fire here" into an observation. Record the result in a QA document per path. This takes minutes per path and finds things reports hide for months.

Then repeat after a week of live traffic, on real segments rather than your own test session. That second pass is where the conditional failures surface.

Then keep a conversion definition register: what counts as a conversion, and where it is counted. When four systems each count something slightly different, the register is what makes the difference explicable rather than an argument.

Verification, not deployment, is the deliverable. Tags are easy to deploy and easy to deploy wrong, which is why GA4 and Tag Manager work should be scoped around proving the paths rather than shipping the container.

Everything above is a discipline, and disciplines decay. The version that survives a busy quarter is automated: something watches the numbers and tells a human when they move.

Analytics can do a usable share of this itself. Custom insights let you define a condition and email a named person when it triggers, and the same feature can watch for statistical anomalies rather than a fixed threshold using anomaly detection. Set one per primary conversion path, addressed to a person rather than a shared inbox.

Two alerts are worth more than ten. One on the conversion count for your highest-value path, and one on a proxy for the collection layer itself, such as sessions from a key landing template. A conversion alert tells you an outcome moved; a collection alert tells you why, and it usually fires first.

The threshold that catches conditional failures is not a big drop. It is a moderate drop that persists, because a form variant taking a quarter of your submissions dark looks like a bad fortnight rather than an outage. Set the alert to notice a sustained shift, not a cliff.

Some of the gap between Google Ads and GA4 is designed in. Different attribution models, click-date versus conversion-date, session-scoped versus click-scoped counting. That variance should be quantified, written down, and then ignored.

The rest is defects, and the two categories need separating before anyone makes a budget decision. Which differences are structural and which are broken is the first question to answer.

If four systems disagree and nobody can say which is authoritative for which decision, that is a conversion attribution audit rather than a tagging task. Fixing tags under unreconciled definitions just moves the disagreement.

The payoff for getting this right is not a tidier report. For a franchise operator with more than fifteen clinics, correcting the event layer so location resolved on every conversion is what made per-location reporting possible at all. Until the events are right, everything built on top of them inherits the defect.