Продуктовая аналитика — это система, которая превращает события из продукта (клики, оплаты, отказы) в понятные решения: что менять, где теряете деньги и как проверить гипотезу без «кажется». Рабочая схема всегда одна: сбор данных → хранение и качество → модель метрик → визуализация данных → действия команды.

Боль, которую вижу в проектах чаще всего: компания думает, что у неё «есть аналитика», потому что стоит счётчик и есть дашборд. А потом выясняется, что события названы как попало, воронка не сходится с оплатами, маркетинг считает одно, продукт — другое, а руководитель верит Excel-табличке, которую обновляют по пятницам вручную. И да, это не «детские болезни». Это вас просто догоняет стоимостью ошибок.

Вторая боль — карьерная. Новичку обещают «станешь продуктовым аналитиком за 2 месяца», но на собеседовании спрашивают: чем отличается event time от processing time, как бы вы настроили идентификаторы пользователя, почему метрика Retention может “врать”, и как вы докажете, что рост конверсии не от смены трафика. Короче, продуктовая аналитика — это не про графики. Это про систему, где графики — последний, самый красивый слой.

Система продуктовой аналитики: слои и ответственность

Слой 1. Сбор данных: что именно вы логируете и зачем

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

• События (events): действия в продукте — регистрация, просмотр карточки, добавление в корзину, оплата.
• Свойства (properties): контекст — тариф, источник трафика, платформа, цена, эксперимент.
• Сущности (entities): user / device / session / order / subscription.

Практический вывод: начинайте не с инструментов, а со списка продуктовых вопросов. Пример: «Где отваливаются платящие пользователи?» → значит нужны события, которые описывают ключевые шаги воронки, и идентификаторы, чтобы связывать с оплатой.

Подводный камень: “событийный ад”. Когда event’ов 500, но нет двух обязательных — purchase с суммой и user_id, который стабильно переживает авторизацию, девайсы и переустановки.

Слой 2. Идентификация: кто этот пользователь на самом деле

Тезис: без нормальной идентификации продуктовая аналитика превращается в гадание по сессиям.

1. device_id — до логина (аноним).
2. user_id — после логина (из вашей БД).
3. mapping — склейка: один пользователь может иметь 3 устройства и 10 сессий.

Практический вывод: зафиксируйте правила: когда склеиваем, когда нет, как обрабатываем “guest → login”, что делаем с shared-устройствами.

Подводный камень: маркетинг любит считать по cookies, продукт — по user_id, финансы — по оплатам. Получается три правды и один конфликт.

Слой 3. Хранение и качество: где лежат данные и почему им можно верить

Тезис: визуализация данных не спасёт, если данные “плывут”. Стабильность важнее красоты.

Практический вывод: заведите минимальные проверки: объёмы событий по дням, доля пустых полей, распределение ключевых свойств (например, platform), сверка оплат с биллингом.

Подводный камень: «у нас всё в аналитической системе, значит ок». Нет. Если нет мониторинга качества, вы узнаете о поломке на совещании у директора. Обычно в понедельник.

Слой 4. Модель метрик: договор о том, что считается успехом

Тезис: метрики — это не цифры, а контракты. Определения должны быть одинаковыми для продукта, маркетинга и финансов.

• North Star Metric (северная звезда): одна метрика ценности. Пример: «оплаченные поездки» или «кол-во доставок без отмены».
• Воронка: шаги до ценности (activation → purchase).
• Retention: возвращаемость по когортам (D1/D7/D30), но с чётким определением “активности”.
• Юнит-экономика: ARPU/ARPPU, LTV, CAC (и да — зафиксируйте формулы).

Практический вывод: сделайте “словарь метрик” (metrics dictionary) — один документ/таблица: название, формула, фильтры, источник данных, владелец метрики.

Подводный камень: «конверсия выросла» без сегментации. Иногда вы просто привели другой трафик. Иногда — сломали оплату для Android, а iOS всё вытянул.

Слой 5. Визуализация данных: дашборды, которые принимают решения

Тезис: визуализация данных нужна не для отчётности, а для действий. Хороший дашборд отвечает на вопрос за 30 секунд и не требует шамана с SQL.

Практический вывод: правило “1 экран — 1 решение”. На графике должна быть подпись: «если просело X — делаем Y». Иначе это интерьер.

Подводный камень: дашборды как KPI-плакаты. Когда команда начинает “рисовать метрику”, а не улучшать продукт. Особенно весело, когда бонусы завязаны на один показатель.

Сколько времени и денег стоит построить такую систему (и почему это важно для карьеры)

Если вы в небольшом продукте, базовую систему продуктовой аналитики реально собрать за 4–8 недель усилиями 1 аналитика + 1 backend/mobile разработчика на события + минимальная помощь DevOps. В более зрелой компании “по уму” это превращается в постоянный процесс: данные меняются вместе с продуктом.

По рынку вакансий в РФ продуктовых аналитиков обычно ждут стек уровня: SQL (обязательно), понимание воронок/когорт, базовая статистика и A/B-тесты, опыт с BI (Power BI / Yandex DataLens / Superset) и понимание, как устроен сбор данных (SDK/логирование). Зарплатная вилка зависит от региона и компании, но ориентир по рынку: Junior чаще стартует примерно от 120–180 тыс. в крупных городах и сильных компаниях, Middle — заметно выше; а в регионах и в “не-IT” может быть скромнее. Главный ускоритель роста — не «ещё один курс», а умение строить систему целиком: от события до решения.

Экспертный вердикт и инструмент: чек‑лист, чтобы продуктовая аналитика не была декорацией

• 1) Какие 5 продуктовых вопросов вы хотите закрыть? (не “посмотреть метрики”, а “почему падает повторная покупка”).
• 2) Есть ли единый словарь метрик? Если нет — готовьтесь к бесконечным спорам «у меня конверсия 3%, у тебя 5%».
• 3) Как устроена идентификация пользователя? device_id, user_id, склейка, дедупликация.
• 4) Есть ли контроль качества данных? алерты на падение событий, пустые поля, лаги загрузки, сверка оплат.
• 5) Дашборды отвечают на решения или просто “красиво”? На каждом ключевом графике должно быть: что считаем, как, и что делаем при отклонении.

Если вы меняете профессию: учитесь мыслить системой. SQL и визуализация данных — это инструменты, а не профессия. Если вы уже в IT: перестаньте спорить о графиках и начните выстраивать контракты на данные — это то, за что платят на уровне Middle+.

Частые вопросы