Подключили PostHog (или любую аналитику) и метрики поехали? Значит, трекинг не “поставили”, а тихо переписали продукт.

Самый частый сценарий: релизнули SDK, события полились, дашборды красивые, команда начала мерить конверсию, удержание, A/B. А через месяц выясняется, что рост/падение был в трекинге, а не в продукте. Цена — неверные решения, спор с разработкой и вечное “данным нельзя доверять”.

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

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

  1. События совпадают с продуктовыми определениями. Не “button_click”, а ровно то действие, которое вы считаете шагом воронки. Один шаг — одно событие, без двойных трактовок.

  2. Стабильность user_id. Где и когда он присваивается, не меняется ли после логина, не создаётся ли новый при каждом запуске, не склеивается ли случайно между пользователями.

  3. Мульти-девайс и кросс-платформа. Один человек с телефона и ноутбука — это один пользователь или два? Если склейки нет, метрики пользователей и retention будут системно “худее”.

  4. Боты и внутренний трафик. Мониторы, тестировщики, автотесты, предпросмотры, сканеры — всё это умеет выглядеть как “активные пользователи” и “конверсия”.

  5. Ретроактивные изменения. Переименовали событие, поменяли свойства, обновили правила дедупликации — и графики “за прошлый квартал” стали другими. Это должно быть осознанно и зафиксировано.

  6. Сверка с серверными логами или источником истины. Ключевые факты (регистрация, оплата, создание объекта) должны сходиться хотя бы по порядку величины и тренду. Клиентский трекинг всегда может недослать.

  7. Контрольные дашборды качества данных. Отдельно от продуктовых метрик: доля событий без user_id, доля unknown device, распределение дублей, задержки доставки, резкие скачки объёма по версии приложения.

В правильной практике трекинг выкатывают как изменение контракта: есть определения, владелец, проверки, и только потом — интерпретация метрик и эксперименты. Исключение одно: совсем ранний MVP, где вы заранее соглашаетесь, что это “примерно”, и не принимаете на этом необратимые решения.