Второй сигнал: чёрный ящик Котомаркета
Чему научишься
- читать событие как строку данных: кто, что сделал и когда
- проходить цепочку «нажал Купить → событие → метрика → » на конкретных числах
- различать событие, метрику и график метрики
- понимать, чем вопросы к рабочей базе приложения отличаются от вопросов к аналитическому хранилищу
2184 год. Второй сигнал
Приёмник станции «Свод-9» молчал восемь месяцев — с тех пор, как ты разобрал архив «Котомаркета» до последней таблицы. Сегодня в 03:11 он поймал второй сигнал из того же мёртвого сектора Сети.
Это не витринный магазина, как в прошлый раз. Это чёрный ящик — весь аналитический архив компании за последние два с половиной года её жизни: события приложения — каждый запуск, клик и поисковый запрос, — метрики по дням, журналы «Пульт» и дневник инцидентов, подписанный одной буквой: «Л.».
Последняя запись сделана за девять дней до закрытия компании:
Данные кричали. Никто не слушал. Если этот архив кто-то найдёт — научи их слушать. — Л.

КВЕРИ разворачивает первую страницу журнала и мурлычет непривычно тихо:
Архивист читает то, что было. Дознаватель выясняет, почему оно было. Повышаю тебя. Не благодари — я проверял, ты готов. Многократно.
Но прежде чем открывать дела, надо выучить язык, на котором они написаны. Он начинается с одного слова: событие.
Событие — это строка таблицы
Первая таблица чёрного ящика называется events, и в ней 1.9 миллиарда строк.
Событие — это зафиксированный факт: кто-то что-то сделал в определённый момент. В данных такой факт выглядит буднично — как строка таблицы. Вот пять строк из вечера 14 марта:
user_id | event_name | event_time | product_id
--------+-----------------+------------+-----------
4412 | product_view | 19:00:12 | 812
4412 | add_to_cart | 19:01:47 | 812
4412 | checkout_start | 19:02:03 | 812
7781 | product_view | 19:02:15 | 305
2043 | app_open | 19:02:41 |
Главное правило чтения такой таблицы:
Одна строка = одно зафиксированное действие.
Не один пользователь, не один заказ, не один товар — одно действие, записанное в конкретный момент времени.
Прочитаем первые три строки вслух: пользователь 4412 в 19:00:12 посмотрел товар 812 («Лежанка-гамак Мурзик»), через 1 минуту 35 секунд положил его в корзину, ещё через 16 секунд начал оформлять заказ. Дальше в этом фрагменте его событий нет. Покупки здесь тоже не видно — но по пяти строкам нельзя заключить, что он вообще не купил товар позже. Ты, ничего не считая, восстановил кусок чужого вечера по четырём колонкам и одновременно увидел границу того, что эти строки позволяют утверждать.
Обрати внимание, чего в таблице нет: ни колонки «настроение», ни «почему ушёл». Событие фиксирует факт, но не объясняет его причину. Причину формулирует как гипотезу и проверяет аналитик — в этом и начинается аналитическая работа.
Цепочка, на которой держится вся аналитика
Каждое число, которое видит руководство компании, проходит путь от реального действия до отчёта. Разберём его по шагам — на тех же пяти строках.
Шаг 1. Действие. Кот Барсик тычет лапой в кнопку «В корзину».
Шаг 2. Событие. Приложение отправляет на сервер сообщение: «пользователь 4412, add_to_cart, 19:01:47, товар 812». Сервер дописывает строку в таблицу events. Действие стало фактом в данных. И запомни сразу: для аналитика доступны только те действия, которые система записала. Если событие не отправили или потеряли по дороге, в данных этого действия не будет.
Шаг 3. Метрика. Метрика — это число, посчитанное из фактов по договорённому правилу. Например, если в Котомаркете активным считают пользователя, у которого за день было хотя бы одно событие из нашей таблицы, то DAU (daily active users) — количество уникальных user_id за день. Предположим, что это все строки за день, и посчитаем:
строки событий: 4412, 4412, 4412, 7781, 2043 ← пять строк
уникальные id: 4412, 7781, 2043 ← три пользователя
DAU = 3
Пять событий — но DAU равен трём, потому что 4412 встретился трижды, а метрика считает пользователей, а не действия. Один пользователь может совершить много действий, поэтому строк событий обычно больше, чем уникальных пользователей.
Шаг 4. График и . Одно число показывает состояние одного дня; хорошо это или плохо, без сравнения не видно. Нужен ряд: DAU за 13 марта, за 14-е, за 15-е… Значения можно нарисовать линией и вывести на дашборд — экран с ключевыми показателями, за которыми следит команда.
Три вещи, которые зовут одним словом «данные»
| Что это | Пример | |
|---|---|---|
| Событие | факт: кто, что, когда | «4412 добавил товар 812 в корзину в 19:01:47» |
| Метрика | число из фактов по правилу | «DAU 14 марта = 4 200» |
| График метрики | значения метрики во времени | «DAU с 1 по 31 марта» — линия из 31 точки |
Разница рабочая, а не филологическая. Отдельное событие не может «упасть на 30%» — оно либо произошло и было записано, либо нет. На 30% может упасть метрика: например, из-за реального изменения поведения пользователей или из-за ошибки измерения — потерянных событий, изменившегося правила подсчёта или сломанного кода сбора данных.
Именно здесь начинается работа дознавателя: когда линия проваливается, надо понять, что изменилось — жизнь компании или её измерительный прибор.
Две базы — два вида вопросов
В прошлый раз ты работал с рабочей базой магазина: товары, заказы, пользователи. Её главная работа — обслуживать приложение прямо сейчас.
Сказать «рабочая база хранит состояние, а хранилище — историю» было бы удобно и неточно: история заказов лежит и в рабочей базе тоже. Граница проходит не только по тому, какие данные хранятся, но и по тому, как с ними работают.
Вопросы к рабочей базе: «Какой сейчас статус заказа №812?», «Сколько лежанок осталось на складе в Мяусино?», «Какой адрес доставки у пользователя 4412?» — это короткие запросы к небольшому числу записей. Ответ нужен быстро, потому что его может ждать экран телефона; таких запросов тысячи в секунду, и каждый обычно трогает немного строк.
Вопросы к аналитическому хранилищу: «Как менялась доля отмен по неделям за год?», «Какая доля мартовских новичков дожила до июня?», «Сколько заработала категория „корма“ по городам за квартал?» — это запросы сразу к большим массивам данных за длительный период. Ответ может считаться секунды или минуты; таких запросов десятки в день, но каждый способен обработать миллионы строк.
| Рабочая база () | Аналитическое хранилище | |
|---|---|---|
| Форма вопроса | конкретные записи и текущие операции | множество объектов, за период |
| Кто спрашивает | прежде всего код приложения | аналитики, отчёты и аналитические сервисы |
| Строк на запрос | обычно немного | может быть очень много |
| Скорость ответа | обычно миллисекунды | секунды и минуты |
| Цена ошибки | сбой операции приложения | неверный анализ или решение |
Поэтому аналитические нагрузки часто выносят в отдельное хранилище: тяжёлый запрос по большому объёму истории не должен мешать базе обслуживать покупки, оплаты и доставки. Данные из рабочих систем копируют в хранилище по расписанию или передают потоково — конкретная схема зависит от того, как устроена система.
Аналитик данных большую часть времени работает со второй колонкой. В этом курсе тебе достанется весь чёрный ящик Котомаркета — и все нераскрытые дела Л.
events?Главное из урока
- событие — строка данных: кто, что сделал, когда и с чем; одна строка = одно действие
- цепочка аналитики: действие → событие → метрика → график на
- событие — отдельный факт, метрика — число, рассчитанное по множеству фактов, а график показывает значения метрики, например во времени; упасть может метрика, а не отдельное событие
- рабочая база отвечает на короткие запросы приложения про конкретные записи, хранилище — на вопросы про множество объектов за период
Дальше — разберём шаг «событие → метрика» до последнего винтика.