TL;DR
- Продуктовый аналитик помогает команде понять, что пользователи делают в продукте, почему это влияет на бизнес и какое решение стоит принять.
- Это не "человек для графиков". Хороший аналитик работает с вопросами, событиями, метриками, гипотезами, тестами и внедрением решений.
- Роль стоит между PM, дизайном, разработкой, маркетингом, support и finance.
- Главная ценность аналитика - не отчет, а изменение решения: что строить, что убрать, где исправить friction, какой эксперимент запустить.
- Аналитик бесполезен без доступа к данным, owner метрик и команды, которая готова менять продукт по фактам.
1. Чем занимается продуктовый аналитик
Продуктовый аналитик превращает поведение пользователей в управляемые продуктовые решения.
Пример вопроса: "Почему новые пользователи не доходят до first value?" Плохой ответ - "вот dashboard". Хороший ответ - "на Android 13 пользователи падают на шаге SMS, потому что resend code не трекается и часть кодов не приходит; нужно исправить отправку и пересобрать funnel".
2. Что не является работой продуктового аналитика
| Миф | Реальность |
|---|---|
| Аналитик рисует dashboards | Dashboard - только один формат вывода |
| Аналитик доказывает мнение PM | Аналитик проверяет гипотезу, даже если результат неудобный |
| Аналитик чинит все данные компании | Он должен влиять на data quality, но не заменяет data engineering |
| Аналитик отвечает только за SQL | SQL - инструмент, не роль |
| Аналитик нужен после релиза | Он нужен до релиза, чтобы определить метрики и события |
Если аналитика зовут только после запуска фичи с вопросом "посмотри, сработало ли", половина работы уже упущена. Метрики, события и дизайн эксперимента должны быть готовы до релиза.
3. Отличие от других аналитиков
| Роль | Главный фокус |
|---|---|
| Marketing analyst | Каналы, CAC, ROAS, leads, attribution |
| BI analyst | Управленческая отчетность, модели данных, dashboards |
| Product analyst | Поведение пользователя, activation, retention, experiments |
| Data scientist | Модели, прогнозы, ML, causal inference |
| Business analyst | Требования, процессы, документация |
В маленькой компании один человек может закрывать несколько ролей. Но важно понимать, какую задачу он решает сейчас. Если продуктовый аналитик весь месяц чинит Excel-отчеты для finance, продукт останется без аналитики.
4. Рабочий цикл
Практичный цикл выглядит так:
- Сформулировать вопрос.
- Проверить, есть ли нужные события и данные.
- Собрать funnel, cohort, segment или revenue analysis.
- Найти не только "где", но и "почему".
- Сформулировать гипотезу.
- Помочь PM выбрать решение.
- Спроектировать эксперимент или rollout.
- Проверить результат и guardrails.
- Зафиксировать вывод в продуктовой памяти команды.
Самая слабая часть в компаниях обычно не SQL и не dashboard. Слабая часть - переход от insight к решению.
5. Что должен уметь продуктовый аналитик
| Навык | Зачем нужен |
|---|---|
| SQL | Достать и проверить данные |
| Product metrics | Не путать активность с ценностью |
| Event taxonomy | Знать, что и как трекать |
| Funnels/cohorts/retention | Видеть поведение во времени |
| Experimentation | Проверять причинность, а не только корреляции |
| Business thinking | Связывать продукт с P&L |
| Communication | Объяснять вывод так, чтобы команда действовала |
| Data skepticism | Проверять баги, sampling, definitions, tracking |
Хороший аналитик умеет сказать: "Я не доверяю этому графику, пока мы не проверим event definition". Это не торможение, а защита от дорогих решений на плохих данных.
6. Работа с PM
PM отвечает за продуктовые решения, аналитик - за качество фактов и интерпретации. В сильной паре они спорят не о вкусе, а о гипотезах.
| PM приносит | Аналитик помогает |
|---|---|
| Цель | Перевести в метрики |
| Гипотезу | Проверить данными |
| Roadmap item | Определить success criteria |
| Релиз | Настроить измерение |
| Результат | Понять эффект и сегменты |
Аналитик не должен быть "отделом отчетов". Он должен сидеть достаточно близко к продуктовой команде, чтобы понимать контекст решений.
7. Работа с разработкой
Без разработки продуктовая аналитика быстро становится догадкой. Нужно правильно трекать события, свойства и идентификаторы.
Минимум, где аналитик участвует:
- tracking plan;
- naming convention;
- event properties;
- user/account identity;
- QA событий;
- release monitoring;
- cleanup устаревших events.
Плохая ситуация: разработчик сам называет события button_click_1, button_click_2, а аналитик через месяц пытается понять, какая кнопка была какой.
8. Работа с маркетингом и finance
Продуктовый аналитик помогает связать качество продукта с привлечением и деньгами.
| Вопрос | Почему это важно |
|---|---|
| Какие каналы приводят retained users? | Не все дешевые лиды полезны |
| Какие cohorts окупаются? | CAC без LTV слепой |
| Где activation ниже по источникам? | Возможно, обещание рекламы не совпадает с продуктом |
| Как feature adoption влияет на paid conversion? | Roadmap должен влиять на P&L |
| Где churn связан с support issues? | Проблема может быть операционной, не маркетинговой |
Так аналитика перестает быть "продуктовой игрушкой" и становится частью роста бизнеса.
9. Локальный контекст СНГ/РК
В Казахстане часто встречается гибридная роль: аналитик делает BI, маркетинг, product, CRM и иногда еще выгрузки из 1С. На раннем этапе это нормально. Но по мере роста нужно разделять ответственность.
Практичная модель:
| Этап компании | Как организовать аналитику |
|---|---|
| Ранний продукт | Один strong generalist + понятный tracking plan |
| Рост | Product analyst рядом с PM/growth |
| Несколько команд | Аналитики по squads + общий data owner |
| Enterprise | Product analytics, BI, data engineering, governance |
Главный локальный риск - нанять аналитика и не дать ему доступа к данным, разработке и решениям. Тогда он будет делать красивые отчеты в стол.
10. Ошибки
| Ошибка | Что происходит |
|---|---|
| Аналитик подключается после релиза | Success metrics уже не трекаются |
| Нет доступа к production data | Анализ превращается в ручные просьбы |
| Все запросы идут ad hoc | Аналитик тушит пожары, а не строит систему |
| PM просит подтвердить готовое решение | Данные становятся декорацией |
| Нет owner tracking plan | Events деградируют |
| Аналитик не говорит на языке бизнеса | Insight не превращается в действие |
| Команда игнорирует неудобные выводы | Роль теряет смысл |
11. Практический чеклист
- У продуктового аналитика есть доступ к нужным данным.
- Есть tracking plan и owner taxonomy.
- Аналитик участвует в планировании фич до разработки.
- У каждой крупной фичи есть success metrics и guardrails.
- Команда регулярно смотрит activation, retention и cohorts.
- Insights приводят к решениям в roadmap.
- Аналитик может оспорить метрику, если данные плохие.
- Есть место, где фиксируются выводы экспериментов.
12. Видео
13. Главный совет
Продуктовый аналитик ценен не тем, что знает SQL, а тем, что меняет качество продуктовых решений. Если после его работы roadmap, onboarding, experiment design или pricing не стали точнее, аналитика осталась отчетностью.
Sources / Notes
- Amplitude: Product Analytics Guide
- Atlassian: Product analytics
- Amplitude Docs: Funnel Analysis
- Amplitude Docs: Retention Analysis