What exactly are we counting

Before you count — look at what is in the box

"You are about to count users. Not so fast. First answer this: what in this archive even is a user?" — QUERY

Kotomarket's black box is not a "users" table and not a "metrics" table. It is an event log: a long list of rows, each meaning "this happened at this moment".

Here are nine rows from a single day — March 14:

Every column answers its own question:

• time — when it happened. Periods are built from it: day, week, month;
• user_id — who. The same cat carries the same id across all their visits;
• session_id — which visit it belongs to. A new visit after a long pause gets a new session id;
• event — what the person actually did;
• properties — the details of that particular action: which source they came from, which item they viewed, how much they paid.

The key thing to absorb right now: metrics are not stored in the black box. Only events are. A metric is an instruction for folding the log into a single number. The analyst writes that instruction — and the number changes with how it is written.

The same data — four different answers

Take those same nine rows and ask four simple questions.

How many events? Nine — one per row. The most mechanical number there is: how many records landed in the log.

How many users? Three — 4412, 7781 and 9003. Cat 4412 left six traces, but he is one cat. Here we drop duplicates by user_id.

How many visits (sessions)? Four — s-101, s-102, s-140, s-166. Cat 4412 came twice: in the morning and in the afternoon.

How many orders? One — the single purchase event.

9 events → 4 visits → 3 users → 1 order

Nine, four, three, one. The data did not change — the counting unit did. And none of the four numbers is "more correct" than the others: they answer different questions.

Hence the first professional habit: when you hear a number, ask what unit is underneath it. "We have forty thousand" — forty thousand what: events, people, visits, purchases? At Kotomarket the gap between the extreme units is nearly tenfold, and in a report they all look equally solid.

Entry #2 in L.'s journal:

"For six months the board was shown 'activity' counted in events and compared with the customer count from billing. Nobody noticed they were dividing apples by kilometres. The 'events per customer' ratio was growing — engagement was celebrated. It turned out that for some people the app was restarting itself."

It also helps to keep the ordering in mind: there are always at least as many events as visits, and at least as many visits as people. If a report shows more "users" than "events", that is not a record — that is a broken count.

A metric definition has four parts

A metric is not a name. The name is the label on the jar; the definition is what is inside. A complete definition answers four questions:

1. Object — what do we count one by one: users, sessions, orders, events?
2. Event — what has to happen for the object to be counted: opened the app, viewed a product, paid?
3. Period — over which time window: a calendar day (in which timezone?), a calendar week, the last 7 days?
4. Counting method — do we count unique objects or every match? Do we sum, average, take a share?

Here is a complete definition worth getting used to:

DAU = the number of unique user_ids (object) that have at least one app_open event (event) during a calendar day in Moscow time (period), each user counted once (counting method).

Long-winded? Yes. But with a definition like that, two different people get the same number — and that is the whole point.

Uniques versus event counts

The most common substitution lives in part four. Compare two phrasings on the same day:

Both numbers are honest, both come from the same log, and they differ by 4.4x. But they behave differently: if a bug makes the app restart itself, the first number grows and the second does not. The first measures activity, the second measures people.

Rule of thumb: the moment you hear "how many users do we have", mentally add the word unique — then check that it is actually there.

Why two analysts get different numbers

Entry #5 in L.'s journal. A manager asks two analysts for "the number of active users in March". Two answers come back: 41,200 and 33,900. Both counted honestly, neither made an arithmetic mistake. Here is where they diverged:

The gap is 7,300 people — 18%. Arguing about who is right is pointless: both are. It was the question that was incomplete.

Notice exactly where it split: rows two and three. The first analyst counted anyone who left any trace at all — including people who merely received a push and had its delivery recorded. The second demanded a deliberate app open. Plus different windows: 31 calendar days versus 30 consecutive days ending today.

The classic beginner mistake is treating the definition as "obvious" and being shy about clarifying it. In practice the question "active — meaning who exactly, over which window?" sounds like professionalism, not ignorance. Ignorance is quietly counting by your own definition and shipping the number unsigned.

The investigator's practical rule, useful for the rest of this course:

Before you count, write the definition in one sentence — object, event, period, method — and show it to whoever asked. Five minutes of agreement save a day of rework and spare you a conclusion built on someone else's arithmetic.

And if the number goes into a report, let the definition travel with it as a footnote. In a month you will not remember what you meant either.