From event to metric: how data turns into a number

The four parts of an event row

The first three fields are always there — without them the row is useless: an event without a user cannot be tied to a person, without a time it cannot be plotted, without a name you cannot tell what happened at all.

Properties (also called event parameters) differ per type: purchase carries the order amount and payment method, search carries the query and result count. Properties are what you later slice the metric by: "show me DAU split by Android and iOS".

Kotomarket named events in object_action style: app_open, product_view, add_to_cart, checkout_start, purchase. Not cosmetics: when half the team writes add_to_cart and the other half writes cart_add, the metric starts counting half the carts and nobody knows why.

An event is not an object

An object is an entity with a current state: user 4412 (Murmansk, registered January 2), order #812 (status "delivered", 1290 ₽), the product "hammock bed" (price, stock). An object's state changes: the order moves from "paid" to "delivered".

An event is something that happened to an object once. It never changes: the row "19:02:03, checkout_start, order 812" stays like that forever, even if the order is cancelled later.

Hence the consequence people trip over in their first calculations:

table users:    1 row = 1 user      →       380,000 rows
table orders:   1 row = 1 order     →     4,100,000 rows
table events:   1 row = 1 action    → 1,900,000,000 rows

There are orders of magnitude more events than objects: one user produces hundreds of them. Counting "how many users we have" by the number of rows in the events table is the most common first-week mistake — and it is wrong by a factor of thousands.

From rows to a number

Take eight rows from one evening and compute metrics from them. Every step by hand, so you can see where the number is born.

#  user_id  event_name      event_time
1  4412     app_open        19:00:04
2  4412     product_view    19:00:12
3  4412     add_to_cart     19:01:47
4  4412     purchase        19:02:58
5  7781     app_open        19:02:15
6  7781     product_view    19:02:41
7  2043     app_open        19:05:10
8  2043     purchase        19:07:33

Metric 1 — DAU:

1. Take all rows for the day — here, all eight.
2. Keep one column, user_id: 4412, 4412, 4412, 4412, 7781, 7781, 2043, 2043.
3. Drop duplicates: 4412, 7781, 2043.
4. Count what is left: DAU = 3.

Metric 2 — number of orders:

1. Filter rows where event_name = purchase — rows 4 and 8 remain.
2. Count the rows: orders = 2.

Note the difference: for DAU we dropped duplicates, for orders we did not. And that is correct: had 4412 bought twice that evening, that would be two orders but still one active user.

Every metric is the same chain: filter → (drop duplicates or not) → count. Whether to drop them is a human decision based on the metric's meaning, written into its definition. The definition is part of the metric; without it the number means nothing.

Metric 3 — conversion is calculated by dividing one metric by another: buyers / actives = 2 / 3 ≈ 66.7%, or 67% after rounding. There are also two buyers here — 4412 and 2043; that is not the same as the number of orders, it is just that in our evening each buyer placed one order. On eight rows the figure is comic; on a real Kotomarket day it looked like this:

DAU on March 14                       4,200
buyers (unique purchase)              1,050
purchase conversion                    25.0%

Here, 1,050 is the number of unique users who had a purchase, not the number of purchase events themselves. Check: 1,050 / 4,200 = 0.25, that is 25%.

That is the whole magic. Every metric later in this course — retention, average check, cancellation share, LTV — is the same chain, just with more filters and steps.

The thesis to remember for the whole course

Tracking is the code inside the app that sends events. A few lines written by a developer — and they break like any other code: when a screen is rewritten, a library upgraded, two branches merged.

Watch what happens when a new app version accidentally drops the app_open call:

                     before     after
app_open per day     4,200     910   ← −78%
purchase per day      1,050     1,045   ← unchanged

The people did not go anywhere. They open the app, browse the catalog and buy exactly like yesterday. But DAU is computed from events, and the events are gone. A cliff appears on the dashboard, management types in caps in the chat. And if the analyst says "we have an audience catastrophe", the company starts treating a healthy patient: rolling back releases, pouring money into ads, firing the wrong people.

Hence the rule you will use for the rest of this course:

A metric fell — first check whether the measuring instrument fell.

The symptom is almost always visible: the metrics disagree. Live users cannot vanish by 78% while buying at the same rate. When one number falls and the number physically tied to it does not, look for the cause in data collection, not in the business.

The reverse is also true and more dangerous: broken tracking can hide a real collapse. If purchase starts being sent twice by mistake, the order count doubles — and against that backdrop nobody notices that real sales sank by a quarter.

The dashboard

A dashboard is a screen collecting the charts and numbers of the metrics that matter to one audience or one question. Kotomarket's BI system was called "Pult", and the main dashboard looked roughly like this:

┌─ Pult · Main ───────────── March 14, 2184 ─┐
│ DAU          4,200  ▁▂▃▄▅▆▇                │
│ Buyers       1,050  ▂▃▃▄▅▅▆                │
│ Conversion    25.0% ▄▄▅▄▅▅▅                │
│ Avg check    730 ₽  ▅▅▅▅▅▅▅                │
└────────────────────────────────────────────┘

A dashboard does not "show data". It shows metrics — numbers computed by somebody's rules from somebody's events. Behind every line stands the chain you just walked by hand.

That is why "and how is conversion computed here?" is not a beginner's nitpick but the first thing an experienced analyst asks of someone else's dashboard. Conversion against DAU and conversion against product-page viewers are two different numbers wearing one word, and they lead to different decisions.

L., entry #5: "Three departments argued half a day about a conversion drop. By lunch it turned out marketing counts it from ad clicks, product from app opens, and finance from unique payers. Nobody was wrong. Nobody had asked."