Трекинг-план бессмысленен, если до него не задать продукту 15 вопросов
Типичная картина: аналитик собирает “что трекать”, команда накидывает 50 событий, через месяц воронки не сходятся, свойства дублируются, а на вопрос “зачем это событие” никто не отвечает. Цена простая: вы тратите время на сбор мусора и потом спорите не о решениях, а о данных.
Почему так происходит: трекинг начинают с интерфейса (“вот кнопка, давайте событие”), а не с решения (“что мы будем делать иначе, если увидим X”). В итоге события расползаются, единица анализа плавает, сегменты не определены, а ограничения (privacy, платформы, latency) всплывают, когда уже поздно.
Вот минимальный чек-лист до первого трекинг-плана. Если на часть пунктов нет ответа, трекинг лучше притормозить, чем “начать хоть как-то”.
- Какие 3–5 продуктовых решений будут приниматься на этих данных в ближайший квартал?
- Какая главная метрика успеха и какие 2–3 поддерживающие, без попытки измерить всё сразу?
- Какие “провалы” считаем критичными: где продукт точно не должен ухудшиться?
- Как выглядит воронка словами: от какого состояния к какому, без экранов и кнопок?
- Какая единица анализа: пользователь, аккаунт, устройство, сессия, заказ?
- Что считаем “новым” и “активным” пользователем, и где это будет зафиксировано?
- Какие ключевые сегменты будут сравниваться регулярно (не “когда-нибудь”), и почему именно они?
- Какие разрезы обязательны всегда: платформа, страна, канал, тариф, эксперимент?
- Что является источником истины для денег, подписок, статусов: продукт, биллинг, CRM?
- Какие идентификаторы есть на каждом шаге и как склеиваем: user_id, device_id, account_id?
- Какие события должны быть строго один раз, а какие могут срабатывать много раз?
- Какие поля должны быть одинаковыми по именам и значениям во всех событиях (например, currency, plan, screen)?
- Какие свойства нельзя собирать или хранить по правилам privacy и комплаенса?
- Какая задержка данных приемлема: “в реальном времени” или “завтра утром тоже ок”?
- Как будем валидировать качество: кто и как подтверждает, что цифры сошлись после релиза?
В правильной практике трекинг-план выглядит как контракт: на каждое событие есть владелец, цель в метриках и место в воронке, а свойства стандартизированы заранее. Спор обычно возникает про “давайте соберём на всякий случай” — и это как раз главный красный флаг: без решения и единицы анализа “на всякий случай” превращается в “никогда не используем”.
