Key events

What marking one changes#

A key event creates no new event and changes nothing about collection. What it does is register the event's name on the property's conversion list — and every report with a notion of "conversion" reads that list.

The list lives under Admin → Property settings → Key events.

Adding and removing key events requires the marketer role or above. If you are writing a Create-event rule, the Mark as key event (conversion) tick in that form creates precisely this same row.

This one applies to history#

That is its most important difference from event rules, and the one that surprises people.

An event rule runs at collection time, so it only ever affects what comes next. A key event is the reverse: the conversion list is read at the moment you open a report and applied as a filter over the data. So the instant you save, every historical event with that name counts as a conversion — no background job, nothing rewritten.

Removing the mark reverses just as fast: the events stay exactly where they were, they simply stop counting as conversions.

Where you see the effect#

There is one less obvious effect too: the definition of an engaged session. A session counts as engaged if it has at least 10 seconds of engagement, or two page views, or a key event. So each new key event nudges the engagement rate up as well.

Where the revenue comes from#

The key-event revenue column sums the value parameter from the key events themselves. An event with no value contributes zero.

So if you want a conversion to show revenue, send the amount with the event:

ap('track', 'lead_qualified', { value: 1200, currency: 'USD' });

For purchases, the ecommerce command does the same thing and carries the line items as well — E-commerce events.

The name has to match exactly#

Counting is an exact name match. Purchase and purchase are two different things, and a key event whose name matches nothing simply stays at zero — you get no warning.

Register a name you have seen with your own eyes in the Events report. There is one exception: a page view carries an empty event name and holds its name in the event type, so registering page_view as a key event counts nothing. If loading a particular page is your conversion, first mint an event under your own name with a Create-event rule on that URL, then mark that — the method is in Create and Modify event rules.

The fraud module's guardrail#

This is the furthest-downstream effect of key events, and the most overlooked.

Fraud Protection is tuned for precision above all: a source that genuinely converts has real people behind it and must not be flagged. To decide whether a source converts, the module reads that property's key-event list — plus purchase, which always counts.

The consequence cuts both ways:

• If your conversions have custom names and are not registered as key events, the module cannot see them, and perfectly healthy traffic that merely looks unusual can be flagged by mistake.
• If they are registered, a source converting at that level is exempted from being flagged on model opinion alone.

Converting is not blanket immunity, though: hard structural signals — a fingerprint ring, known bot traffic — still apply to a converting entity and send it to the human review queue rather than to the clean list. The reason is plain: a key event arrives from the browser, and a bot can fire one too. The full logic is in Why was this flagged.

How many key events#

A workable rule: mark something a key event if the business loses money or an opportunity on the days it does not happen. A purchase, a sign-up, a consultation request, a trial start. Everything else remains fully available in the Events report and in Explore without being marked.

Frequently asked questions#

Related#