От события к метрике: как данные превращаются в число

Четыре части строки события

В нашей упрощённой схеме первые три поля есть у каждого события. event_name говорит, что произошло, event_time — когда, а user_id позволяет связать действия одного пользователя между собой. В реальных системах бывают и анонимные события без известного user_id, но пока будем работать с более простой моделью.

Свойства (их ещё называют параметрами события) у каждого типа свои: у purchase — сумма заказа и способ оплаты, у search — запрос и число найденных товаров. По свойствам потом разбивают метрику на срезы: например, «покажи DAU отдельно по Android и по iOS».

В Котомаркете для событий использовали короткие имена в snake_case: app_open, product_view, add_to_cart, checkout_start, purchase. Единый стиль здесь важен не только ради порядка. Если одно и то же действие половина команды записывает как add_to_cart, а другая — как cart_add, запрос, который ищет только add_to_cart, потеряет часть реальных добавлений в корзину.

Событие — не объект

Объект — сущность с текущим состоянием: пользователь 4412 (Мурманск, зарегистрирован 2 января), заказ №812 (статус «доставлен», 1290 ₽), товар «Лежанка-гамак» (цена, остаток). Состояние объекта меняется: например, заказ переходит из статуса «оплачен» в статус «доставлен».

Событие — факт, который произошёл в определённый момент. Запись «19:02:03, checkout_start, заказ 812» описывает именно тот момент и не превращается позже в другое событие, даже если заказ в итоге отменят. В событийном логе такие записи обычно сохраняют как историю произошедшего, а новое изменение фиксируют отдельным событием.

Отсюда следствие, на котором легко ошибиться в первых расчётах:

таблица users:    1 строка = 1 пользователь   →       380 000 строк
таблица orders:   1 строка = 1 заказ          →     4 100 000 строк
таблица events:   1 строка = 1 действие       → 1 900 000 000 строк

Строк в таблице событий обычно намного больше, чем строк в таблицах объектов: один пользователь может совершить сотни действий. Поэтому число строк в events — это число записанных действий, а не число пользователей. Чтобы посчитать пользователей по событиям, нужно считать уникальные user_id, а не все строки подряд.

Из строк — в число

Возьмём восемь строк одного вечера и посчитаем из них метрики. Все шаги — руками, чтобы было видно, где рождается число.

#  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

Метрика 1 — DAU:

1. Взять все строки за нужный день — здесь все восемь.
2. Оставить одну колонку, user_id: 4412, 4412, 4412, 4412, 7781, 7781, 2043, 2043.
3. Убрать повторы: 4412, 7781, 2043.
4. Посчитать, сколько осталось: DAU = 3.

Здесь мы считаем активным пользователя, у которого за день было хотя бы одно событие. В реальном продукте точное определение DAU может отличаться — например, команда может учитывать только определённые события. Главное, чтобы это правило было зафиксировано заранее.

Метрика 2 — число заказов:

1. Отфильтровать строки, где event_name = purchase — остаются строки 4 и 8.
2. Посчитать строки: заказов = 2.

Заметь разницу: в DAU мы убирали повторы пользователей, а в заказах — нет. И это правильно: если бы 4412 купил дважды за вечер, это были бы два заказа, но по-прежнему один активный пользователь.

Для этих двух метрик цепочка похожа: выбрать нужные строки → решить, нужны ли уникальные сущности → посчитать. Но не все метрики сводятся к подсчёту строк. Например, для среднего чека придётся ещё сложить выручку и разделить её на число заказов.

Такое превращение множества строк в итоговое число называется агрегацией. Конкретные правила агрегации — часть определения метрики: кого считать, какие события брать, удалять ли повторы, что складывать или делить. Без этих правил само число мало что значит.

Метрика 3 — конверсия считается делением одной метрики на другую: покупателей / активных пользователей = 2 / 3 ≈ 66,7%, или 67% после округления. Покупателей здесь тоже двое — 4412 и 2043; это не то же самое, что число заказов, просто в нашем вечере каждый купивший сделал по одному заказу. На восьми строках цифра мало о чём говорит; на настоящем дне Котомаркета расчёт выглядел так:

DAU 14 марта                        4 200
покупателей (уникальных purchase)   1 050
конверсия в покупку                  25.0%

Здесь 1 050 — это число уникальных пользователей, у которых был purchase, а не число самих событий покупки. Проверка: 1 050 / 4 200 = 0,25, то есть 25%.

Дальше метрики станут сложнее: retention потребует сравнить пользователей между периодами, средний чек — работать с суммой покупок, LTV — собирать денежный результат пользователя за длительное время. Но принцип останется тем же: сначала точно определить, какие строки и значения нужны, затем применить правила расчёта и только после этого получить число.

Тезис, который надо запомнить на весь курс

Трекинг — это код в приложении, который отправляет события в систему аналитики. Несколько строк, написанных разработчиком, могут сломаться так же, как любой другой код: при переписывании экрана, обновлении библиотеки или слиянии веток.

Смотри, что происходит, если в новой версии приложения случайно удалили отправку app_open, а дашборд считает активных пользователей именно по этому событию:

                    было      стало
app_open за день    4 200       910   ← −78%
purchase за день    1 050     1 045   ← без изменений

По данным о покупках не похоже, что аудитория действительно исчезла: число purchase почти не изменилось. Пользователи могут по-прежнему открывать приложение, ходить по каталогу и покупать — просто значительная часть app_open перестала попадать в данные.

На дашборде при этом появится обрыв. Если аналитик сразу решит «у нас катастрофа с аудиторией», компания может начать лечить не ту проблему: откатывать релиз, заливать деньги в рекламу или искать причину в продукте, хотя сломалось измерение.

Отсюда правило, которым ты будешь пользоваться до конца курса:

Метрика упала — сначала проверь, не упал ли измерительный прибор.

Один из частых признаков такой поломки — метрики рассогласовались. Если показатель активности падает на десятки процентов, а связанный с ним показатель покупок почти не двигается, это повод проверить сбор данных: какие события приходят, из каких версий приложения, в каком объёме и с какого момента начался разрыв.

Но рассогласование — не доказательство само по себе. Такое может произойти и по реальной бизнес-причине. Задача аналитика — не объявить трекинг виноватым заранее, а проверить эту гипотезу прежде, чем объяснять падение поведением пользователей.

Верно и обратное, и это опаснее: сломанный трекинг умеет прятать настоящее падение. Если событие purchase начали по ошибке отправлять дважды, а число заказов считается простым подсчётом этих событий без удаления дублей, метрика примерно удвоится — и на этом фоне никто не заметит, что реальные продажи просели на четверть.

Дашборд

Дашборд — экран, на котором собраны графики и числа метрик, важных для одной аудитории или одного вопроса. У Котомаркета BI-система называлась «Пульт», и главный дашборд выглядел примерно так:

┌─ Пульт · Главный ────────── 14 марта 2184 ─┐
│ DAU         4 200   ▁▂▃▄▅▆▇                │
│ Покупатели  1 050   ▂▃▃▄▅▅▆                │
│ Конверсия    25.0%  ▄▄▅▄▅▅▅                │
│ Средний чек   730 ₽ ▅▅▅▅▅▅▅                │
└────────────────────────────────────────────┘

Дашборд обычно показывает не сырые события, а метрики — числа, посчитанные по определённым правилам из этих событий. За каждой линией стоит цепочка, которую ты только что прошёл руками.

Поэтому вопрос «а как здесь считается конверсия?» — не придирка новичка, а первое, что спрашивает опытный аналитик у чужого дашборда. Например, доля покупателей среди всех активных пользователей за день и доля покупателей среди тех, кто открыл карточку товара, — два разных показателя. У них разные знаменатели, а значит, и выводы из них могут быть разными.

Л., запись №5: Три отдела спорили полдня о падении конверсии. К обеду выяснилось, что маркетинг считает её от кликов в рекламе, продукт — от заходов в приложение, а финансы — от уникальных плательщиков. Никто не был неправ. Просто никто не спросил.