Подключили PostHog (или любую аналитику) — и метрики поехали: 7 проверок после внедрения трекинга

Классика: вчера конверсия была “норм”, сегодня внезапно упала, DAU вырос, а retention стал “лучше, чем у Netflix”. Команда уже спорит про продукт, а на деле вы обсуждаете не поведение пользователей, а артефакты трекинга. Цена ошибки простая: неверные решения, сломанные A/B-тесты, недоверие к данным и вечная война “продукт vs аналитика”.

Почему так происходит: трекинг внедряют как инженерную задачу (“шлём события”), а метрики живут по продуктовым правилам (“что считаем покупкой”, “кто активный”, “когда сессия началась”). Любой разъезд в определениях, идентификации или фильтрах превращает дашборд в генератор уверенности без оснований.

Минимальный стандарт после внедрения:

  1. События соответствуют продуктовым определениям. Не “button_click”, а чётко: что является попыткой, что успехом, что отменой, какие статусы исключаем. Если определение нельзя проверить по payload — оно не определение.
  2. Стабильность user_id. Гость, регистрация, логин-логаут, переустановка, сброс куки — проверьте, не “рождается” ли новый пользователь посреди воронки.
  3. Мульти-девайс и мульти-платформа. Один человек с мобилы и веба не должен превращаться в два независимых retention’а. Если кросс-девайс не решён — это должно быть явно отражено в метриках.
  4. Боты и внутренний трафик. Мониторы, автотесты, QA, скрейперы, превью-сервисы, “проверка платежа” от провайдера — всё это умеет выглядеть как пользователь. Фильтры должны быть в одном месте и воспроизводимы.
  5. Ретроактивные изменения в трекинге. Переименовали событие, поменяли schema, удалили параметр, “пофиксили дубль” — и тренды за прошлые недели стали другими. Любое изменение должно быть видно как изменение, а не как “рынок изменился”.
  6. Сверка с серверными логами/истиной бэкенда. Особенно для оплат, подписок, доставок, статусов заказов. Клиентский трекинг удобен, но не является источником правды.
  7. Контрольные дашборды качества данных. Не про бизнес, а про здоровье: доля событий без user_id, дубляжи, лаг доставки, распределение платформ/версий, резкие скачки объёма, доля “unknown” в ключевых параметрах.

Правильная практика выглядит скучно: сначала вы приводите трекинг к предсказуемости, и только потом начинаете спорить про продуктовые гипотезы и экспериментирование. Исключение одно: совсем ранний MVP, где вы сознательно используете метрики как ориентир, а не как доказательство — и это проговорено заранее.