Слабая задача аналитику: «Посмотри, что происходит с пользователями». Сильная постановка начинается с решения:
Анализ без решения часто превращается в красивый отчёт, который не влияет на продукт.
Событие называют как завершённый факт, например order_created, а не расплывчатое button_clicked, если продуктовый смысл заключается в создании заказа. Клиентские и серверные события могут расходиться; критичные бизнес-факты лучше подтверждать сервером.
Для каждого события укажите:
| Поле | Содержание |
|---|---|
| Название | Единое техническое имя |
| Пользовательский смысл | Что произошло в продукте |
| Триггер | Точный момент отправки |
| Свойства | Контекст, нужный для анализа |
| Источник | Клиент, сервер, внешняя система |
| Проверка качества | Как обнаружить пропуски или дубли |
| Владелец | Кто отвечает за определение |
Не собирайте данные «на всякий случай». У каждого поля должен быть вопрос, которому оно служит, срок хранения и допустимый уровень чувствительности.
SQL полезен продакту для самостоятельных проверок, но в базовом курсе важнее логика запроса. Нужно понимать строки, фильтры, группировки, соединения и различие между количеством событий и уникальных пользователей.
Опрос полезен, когда нужно измерить распределение мнений, намерений или самоописанного опыта в определённой аудитории. Он не заменяет событийные данные: человек может неточно помнить частоту действий или отвечать так, как считает социально приемлемым.
Качество опроса зависит от выборки и формулировок. Вопрос «Почему вам не понравилась новая функция?» предполагает, что функция не понравилась. Варианты ответа могут не покрывать реальные причины. Шкала без подписанных крайних значений читается неодинаково.
Перед запуском опроса зафиксируйте:
NPS, CSAT и CES являются частными измерениями опыта, а не универсальными оценками здоровья продукта. Их стоит сопоставлять с поведением и читать по сегментам.
Проверьте полноту, уникальность, своевременность, согласованность определений и резкие изменения после релиза трекинга. Отсутствующие события могут означать как отсутствие поведения, так и поломку сбора.
Не делайте причинный вывод из одного совпадения. Учитывайте сезонность, изменение маркетингового трафика, состав пользователей, релизы и внешние события.
Фраза «retention упал» недостаточна для анализа. Нужно знать определение возврата, когорту, период и момент изменения. Снижение повторных заказов может быть вызвано качеством доставки, ростом доли промо-трафика, сезонностью, изменением ассортимента или ошибкой трекинга.
Аналитический план нужен до выгрузки. Он заставляет связать возможную причину с ожидаемым рисунком данных. Например, если проблема возникла из-за задержек, падение должно быть сильнее у пользователей с опоздавшим первым заказом. Если виноват состав трафика — различие может исчезнуть внутри одинаковых каналов привлечения.
Доля новых клиентов, сделавших второй заказ за 14 дней, снизилась с условных 31% до 26%. В тот же месяц изменились рекламные каналы, расширилась зона доставки и обновился каталог. Реальные данные компании искать не нужно.
Analytical brief, таблица гипотез и tracking plan. Не подставляйте вымышленные результаты — задача состоит в проектировании исследования.
Ты — ведущий продуктовый аналитик. Проверь мой аналитический план.
Оцени связность цепочки «решение → вопрос → гипотезы → данные → метод → вывод → действие». Найди неразличимые гипотезы, лишние данные, недостающие события, смену единицы анализа, риск двойного счёта, ошибки сегментации и причинные выводы, которые метод не поддерживает.
Не выполняй анализ и не выдумывай результаты. Сначала составь список блокирующих пробелов, затем задай до семи вопросов. После этого покажи улучшенный вариант только одного слабого участка плана или псевдо-SQL и объясни ограничения.
Мой план:
[вставить работу]