The onboarding event that fired on every page load for 10 days

On July 22, we found an onboarding event that had fired on every page load since July 12. For 10 days, our signup funnel had been counting navigation as progress.

The event stream was busy. Dashboards rendered and reports produced percentages, and we read those numbers as a funnel doing fine. We could have spent a week debating conversion behavior when the system was really measuring a tag manager mistake. The only reason we didn’t is that July 22 happened to be the day we looked closely enough.

What we had was an event storm with no sudden burst of healthy onboarding behind it. A GTM trigger was attached broadly enough to fire the onboarding event on each page load. The signal we needed was a user reaching a specific onboarding step. The signal we had was the browser loading another page.

Those two things are not close substitutes.

Too much arrived

A broken event pipeline is usually obvious when nothing arrives. This was harder because too much did. Every page load added a record that looked like a legitimate onboarding action, so event volume stopped being evidence that people were moving through the flow.

The failure had two layers. First, the trigger manufactured events. Second, the funnel did not yet have the step dimension needed to tell real signup progress from a generic event count. The trigger was the source of the pollution, and the missing dimension made it easy to mistake for behavior.

Tracing it back

The diagnostic path started with the storm itself. We traced the onboarding event back to GTM and found the trigger firing on every page load. That explained the shape of the stream, and it explained the gap between the July 12 break and the July 22 discovery. Nothing was technically down. The analytics path was accepting exactly what we sent it.

That distinction matters. Delivery checks answer “did the event arrive?” They don’t answer “did the event mean what its name says?” A tag can successfully transmit a false fact thousands of times.

The question that cracked it was: what condition causes this event to fire, and does that condition represent the business action the event claims to record? Here the condition was page load. A user could generate repeated onboarding events without advancing at all.

We now run a simple test. Describe the event and its trigger in one sentence each. If the two sentences don’t say the same thing, inspect the event. “Onboarding step completed” cannot be triggered by “page loaded.”

We also registered the step dimension, so the signup path can be queried as steps instead of one undifferentiated bucket of onboarding traffic. That did not repair the historical data. It restored our ability to separate stages going forward.

Containment first

We shipped a deduplication hotfix first. That was containment, and it stopped the junk stream from compounding while a teammate published the trigger correction. Within minutes of the trigger fix, the flood collapsed.

The order was deliberate. Deduplication alone would have left the misconfigured trigger generating bad intent at the source, and it would have made the reporting layer responsible for compensating for a tag-management error. The trigger should emit one event for one business action, and downstream deduplication should be a guardrail for retries or accidental duplicates.

We also pushed a full legacy-tag cleanup into the release train. Stale tags create a second failure mode. Once several tags describe roughly the same action, nobody can tell whether a spike comes from behavior, an old container rule, or two instruments reporting the same thing under different names. The cleanup leaves fewer moving parts to inspect the next time a chart looks implausibly healthy.

Marking the bad interval

The polluted window from July 12 to July 22 cannot support claims about onboarding behavior. We marked it unusable for funnel interpretation, permanently. The stream still has value as forensic evidence, because it tells us when the trigger began firing and why the funnel looked so active. It is not product signal, and nobody can use those ten days to say what onboarding looked like in that window.

After the fix, we validate three things in order. The GTM trigger fires only when the named action occurs. One action produces one event. The step dimension makes the funnel queryable as a sequence. Each check covers a different failure point.

Check that each key event’s firing condition matches the business action its name claims, since an event arriving says nothing about what it means. Inspect an unusually active chart before you read it as good news. When a trigger turns out to be broken, fix it at the source and mark the affected interval as unusable.

dxdev LESSON · paste into your AI coding agent
LESSON: Event Volume Is Not Evidence the Event Means What Its Name Says
SOURCE: dxdev.com/blog/gtm-trigger-event-pollution
WHAT HAPPENED: A Google Tag Manager trigger was attached broadly enough to fire an "onboarding step completed" event on every page load rather than only when a user actually reached that step. For 10 days the signup funnel dashboard stayed busy, producing legible-looking conversion percentages built entirely on navigation events mislabeled as progress. The fix was a deduplication hotfix for containment, a corrected trigger, a new step dimension so the funnel could be queried as a real sequence, and marking the 10-day interval as unusable for behavioral interpretation rather than trying to retroactively clean it.
THE RULE: A rising or steady event count is not evidence a pipeline is healthy; describe the event name and its firing condition in one sentence each, and if those two sentences are not semantically identical ("onboarding step completed" cannot mean "page loaded"), the event is lying regardless of how much volume or how clean the resulting dashboard looks.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any analytics or tag-manager trigger whose firing condition (page load, route change, DOM ready) is broader than the specific user action the event's name claims to represent.
  2. Any funnel or conversion dashboard with no step or stage dimension, meaning event volume cannot be distinguished from actual sequence progress after the fact.
  3. Any period of anomalous-looking-good analytics data that was accepted at face value rather than checked against the literal firing condition of its source event.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.