Count people, not events

The dashboard says the export feature fired 12,400 times in October, up 40%. That is the number in the deck, and it is the number that gets the feature a second phase.

Change the denominator and the story changes completely. Fourteen people. One of them accounts for nine thousand of those events, because their integration retries on a 500 and nobody noticed.

Why the event count is the flattering one

The difference is structural rather than a matter of preference.

An event count is additive and unbounded. Nothing in its definition limits how large it can get. One enthusiastic user, one retry loop, one crawler, one instrumentation bug that double-fires, and the number moves arbitrarily. It is a count of things that happened, and things can happen any number of times.

A user count is bounded by your actual audience. It cannot exceed the number of people you have. That ceiling is the entire value: a metric that cannot be inflated by one person having a bad day.

Google’s own API defines them plainly side by side. eventCount is “The count of events.” activeUsers is “The number of distinct users who visited your site or app.” And every analytics vendor defaults its charts to the second one. Amplitude states it outright: “Uniques is the default measure for the Event Segmentation chart.”

That default is a decision the vendors made about which number misleads less, and they made it in the direction that produces smaller, less impressive charts.

The ratio is the interesting number

You do not have to choose. The one worth watching is the ratio, and it is shipped as a metric: Google defines eventCountPerUser as “The average number of events per user (Event count divided by Active users).”

WHAT THE DECK SAID              WHAT THE RATIO SAYS

 exports: 12,400                exports:        12,400
 up 40% month on month          active users:       14
                                per user:          886

 a successful feature           886 exports per person per month
                                is not a usage pattern. it is
                                either an integration or a bug

                                strip the top user:
                                  exports:       3,400
                                  users:            13
                                  per user:        262

                                still not people. still a machine.

The ratio is where instrumentation bugs and automated traffic announce themselves. A human does not export a report eight hundred times a month. When the number per person stops looking like something a person would do, it is not a person.

The move

Put a person in the denominator, then read events per person, and treat any implausible ratio as a bug report rather than a success.

What “a person” actually means

Here is the correction to the usual version of this advice, and it matters because you may end up defending the number in a room.

Unique users tell you the truth is too strong. They are estimates. Google’s own developer documentation states that GA4 user counts are approximations, computed with HyperLogLog++, while nothing says the same about event counts. So the more reliable-sounding number is the modelled one.

And the identity underneath it is not a person, it is an account or a device. Twitter had to restate three years of its monetisable daily active users because one person’s linked accounts were being counted as several. If a company with that much at stake got the definition wrong for three years, your distinct(user_id) is doing something approximate too.

None of this makes the user count worse than the event count. It makes it a better-shaped approximation, and you should describe it that way rather than as truth.

What it costs

Bot filtering is weaker than you think. GA4 excludes “Traffic from known bots and spiders” using the IAB’s list, and you cannot disable it. But that is only the general, list-based category. The industry standard splits invalid traffic in two, and the sophisticated kind “consists of more difficult to detect situations that require advanced” analytics to catch. Your default filtering catches the crawlers that identify themselves.

And user counts are non-additive, which will trip somebody up. You cannot sum daily uniques to get a monthly figure, because the same person appears on multiple days and gets counted once. Amplitude documents this directly. Expect somebody to build a spreadsheet that adds them up, and expect the resulting number to be confidently wrong.

Try this week

Take the metric your team quoted most recently and divide it by active users for the same period.

Then ask one question about the answer: would a real person plausibly do this thing that many times in a month?

If the answer is no, you have not found a successful feature. You have found either a machine or an instrumentation bug, and either way the number in the deck is measuring something other than what everyone believes it measures.