Key event

Until 2024 GA4 called these conversions, which was the same word Google Ads used for a different measurement in the same account, usually open in an adjacent browser tab.

The two were routinely compared, occasionally added together, and never agreed. A GA4 conversion counted an action attributed by GA4 model across every channel, on the day it happened. A Google Ads conversion counted an action credited to an ad click, dated to the click, sometimes modelled for a user the platform could not observe.

Renaming one of them to key event was an attempt to make the distinction visible in the vocabulary rather than in a footnote. It helps, and it does not solve the problem, because clients still have two numbers and still want to know which is right.

The answer that works in practice is to pick one as the number decisions are made on, write that down at the start of the engagement, and report it consistently. Both are defensible. Switching between them, especially when one looks better that month, is what damages trust.

Because any event can be flagged with a toggle, and because flagging one feels free, key events accumulate. Somebody marks a form submission, then a phone tap, then an outbound click, then a scroll depth, then a video play, then a PDF download.

Each was defensible on the day. Together they produce a conversion report in which the genuinely commercial actions are a minority of the total, and a conversion count that goes up when somebody scrolls.

The damage is to the conversations the number is supposed to support. Cost per conversion becomes meaningless when the denominator mixes a sales enquiry with a scroll event. Comparing months becomes meaningless when the set of flagged events changed in between. And the client learns, correctly, that the number does not mean anything specific.

The fix is a deliberate short list rather than a cleanup. Two or three events the client is actually judged on, agreed out loud, with everything else measured as an ordinary event and reported separately when it is useful. Micro-conversions are worth watching; they are not worth flagging.

Marking an event as a key event applies from that moment forward. It does not reclassify history, so last quarter reports will not show it, and a year-on-year comparison will show the new action appearing from nothing.

This catches teams out in a specific and predictable way. A client decides mid-year that a particular action is the one that matters, the agency flags it, and the first report shows it starting at zero on the day of the change. The chart implies the business began doing something in June that it had been doing all along.

The event data itself is usually fine, which is the saving grace. If the event was being collected before it was flagged, the occurrences exist and can be pulled from Explore or from BigQuery to build the historical view manually. What cannot be recovered is the conversion reporting, which only knows about flagged events going forward.

So the habit worth having is to collect generously and flag narrowly. Send events for everything that might matter, because collecting is retroactive in effect, and flag only the short list, because flagging is not.

A GA4 session counts as engaged if it lasted more than ten seconds, included two or more page views, or triggered a key event. That third condition is the one people forget, and it links two metrics that look unrelated.

Flagging a new key event therefore raises engagement rate mechanically, and lowers bounce rate by the same mechanism, since bounce rate in GA4 is defined as the inverse of engagement. Nothing about the site or the traffic has changed.

If the flagged event is common, such as an outbound click or a scroll, the movement can be large enough to look like a result. It will appear in the month the change was made, which is exactly when somebody is writing commentary about what improved.

Which makes it a checklist item rather than an insight: before writing about a jump in engagement rate, check whether the key event list changed. It takes a moment and it avoids reporting a configuration change as performance.