Собеседование продуктового аналитика: метрики и кейсы с разбором

Коротко

Отвечайте продуктовым каркасом: цель пользователя → ключевое действие → метрика успеха → guardrails → сегменты → данные → решение. Не называйте DAU, retention или LTV по привычке. Сначала объясните, какое поведение должно измениться и почему это важно бизнесу.

• Метрика без определения active action и знаменателя не готова для решения.
• Падение общего числа нужно разложить по сегментам, а не сразу объяснять одной причиной.
• Для новой функции заранее определите adoption, value и guardrail.
• A/B-тест нельзя интерпретировать без primary metric, окна и качества рандомизации.
• Заканчивайте ответ действием: что проверить, изменить или не делать пока.

Как строить ответ на продуктовый кейс

Начните с контекста: кто пользователь, какая задача продукта и какое решение нужно принять. Затем выберите одну основную метрику и две-три защитные. Для изменения onboarding primary может быть activation24h, а guardrails — error rate, D7 retention и доля обращений в поддержку. Для paywall — payer conversion и net revenue, но рядом нужны возвраты и удержание.

Дальше назовите разрезы и план проверки. Не обязательно перечислять весь warehouse. Достаточно показать, что вы знаете, где искать причину: платформа, канал, новая когорта, версия, тариф, путь пользователя. После этого скажите, какой результат подтвердит гипотезу и какое действие последует.

Кейс 1: DAU упал на 15%

Не говорите «проверю retention» первым предложением. Сначала проверьте, полон ли день, не поменялось ли определение активности и не сломалась ли отправка события. Затем разделите DAU на новых, returning и resurrected пользователей. Если падение только у returning, смотрите повторную ценность и релизы. Если новый трафик исчез, проверяйте каналы и кампании. Если активность есть, но исчез core action, проблема может быть в качестве сценария, а не в привлечении.

На интервью полезно назвать конкретный результат, который изменит решение: «Если падение объясняется одной версией Android и началось после релиза, сначала эскалирую техническую проблему. Если все версии стабильны, но D7 новых когорт просел, иду в onboarding и качество каналов». Это показывает причинную дисциплину без обещания доказать причину одним графиком.

• Проверка данных: таймзона, неполный день, schema и tracking.
• Декомпозиция: new, returning, resurrected.
• Разрезы: канал, платформа, версия, страна, тариф.
• Соседние показатели: core action rate, retention, revenue.
• Решение: исправление трекинга, технический fix, исследование или эксперимент.

Кейс 2: где пользователи выпадают из воронки

Сначала договоритесь о типе воронки. Для checkout нужна последовательность событий и разумное окно. Для изучения adoption функции может быть полезна открытая воронка. Затем зафиксируйте стартовую базу и единицу пользователя: не считайте события вместо людей. Для каждой ступени покажите абсолютное количество, конверсию, медианное время и ошибки.

Если drop-off появился только на мобильном web после релиза, это не повод менять текст на pricing-странице. Если он одинаков во всех сегментах, но пользователи долго стоят на одном шаге, нужен UX-разбор. Если провал виден только у трафика из конкретной кампании, проверьте соответствие обещания объявления и опыта внутри продукта.

Кейс 3: какую метрику выбрать для новой функции

Для новой функции недостаточно adoption: кнопку можно нажать и больше никогда не вернуться. Разделите метрики на три слоя. Adoption показывает, дошёл ли пользователь до функции. Value показывает, получил ли он результат. Retention или repeat usage проверяет, вернулся ли к сценарию. Если функция приносит деньги, добавьте net revenue или contribution margin, но не заменяйте ими пользовательскую ценность.

Для каждой метрики назовите окно и знаменатель. Например, «доля активированных команд, которые создали хотя бы один отчёт в течение семи дней после включения функции». Это лучше, чем «feature usage вырос». Guardrail защищает от локальной оптимизации: ускоренный импорт может поднять adoption, но увеличить ошибки и обращения в поддержку.

Кейс 4: A/B-тест дал +5% к конверсии

Положительный uplift — только начало разговора. Проверьте доверительный интервал и мощность, качество сплита, длительность и зрелость пользователей. Уточните, не было ли SRM, peeking, множественных метрик и изменений трекинга. Затем посмотрите guardrails: возвраты, latency, ошибки, retention и средний чек.

Если conversion растёт, но net revenue падает из-за дешёвого тарифа или возвратов, решение «выкатить всем» может быть неверным. Если primary статистически неопределённа, а направление стабильно, можно продолжить сбор или провести качественное исследование — но нельзя выдавать отсутствие доказательства за доказательство эффекта.

Кейс 5: LTV одного канала выше

Сначала проверьте зрелость когорт и одинаковый горизонт. LTV90 свежего канала нельзя сравнивать с LTV90, который рассчитан только по старым когортам. Затем разложите разницу на activation, retention, payer conversion, ARPPU и возвраты. После этого добавьте CAC и contribution margin. Высокая выручка не означает прибыльность, а корреляция канала с LTV не доказывает причинность.

На собеседовании важно не прыгать сразу к совету отключить канал. Сильнее звучит: «Разрыв появляется на D7 и сохраняется к D90, но перед изменением бюджета сравню CAC, маржу и состав кампаний. Если проблема в конкретной кампании, отключу её, а не весь канал».

Что спрашивают о продуктовой коммуникации

Вас могут попросить объяснить падение метрики PM, директору или разработчику. Меняйте уровень детализации, но не смысл. Для PM сначала дай сегмент, масштаб и следующую гипотезу. Для разработчика добавьте событие, версию и воспроизводимый сценарий. Для руководителя покажите риск, варианты действия и стоимость ожидания.

Не прячьте неопределённость за формулировкой «данные показывают». Говорите, что является фактом, что гипотезой и какую проверку нужно провести. Это не делает ответ слабее. Наоборот, продуктовый аналитик ценен тем, что умеет не только найти сигнал, но и обозначить границы знания.

• Факт: что изменилось и в каком сегменте?
• Гипотеза: какой механизм может это объяснить?
• Проверка: какие данные различат гипотезы?
• Решение: что делаем сейчас и что отложим?
• Риск: что произойдёт, если ничего не менять?

Дерево метрик: как не назвать десять KPI подряд

Если просят метрики продукта, начните с результата, а не с привычного DAU. Разложите цель на пользовательское поведение и бизнес-эффект. Например, для сервиса совместной работы дерево может выглядеть так: активные аккаунты → созданные рабочие объекты → повторное использование → платная конверсия → net revenue. На каждом уровне добавьте один показатель качества, чтобы локальная оптимизация не выглядела победой.

Такой ответ можно адаптировать к любому продукту. В игре это может быть meaningful session → завершение уровня → D7 → payer conversion. В маркетплейсе — поиск → просмотр → сообщение → заказ → повторная покупка. Не существует единственной правильной North Star Metric: правильна та, которая связана с ценностью и может менять решение команды.

Мини-кейс: метрика растёт, а продукт хуже

Представьте, что после нового paywall выросла конверсия в оплату. Если смотреть только на payer conversion, изменение выглядит успешным. Но в первые дни увеличились возвраты, снизился ARPPU и ухудшился D30 у новых плательщиков. Правильный ответ не выбирает одну цифру. Он говорит, что изменение расширило вход в оплату, но может ухудшать качество и долгосрочную ценность.

На собеседовании проговорите, какие данные нужны: cohorts по дате оплаты, тариф, канал, возврат, повторный платёж и маржа. Затем сформулируйте решение: оставить rollout, если contribution LTV и guardrails устойчивы; ограничить сегмент, если проблема локальна; откатить или переделать paywall, если краткосрочный uplift не компенсирует долгосрочный ущерб.

• Отделить изменение поведения от изменения состава аудитории.
• Сравнить одинаковые когорты на одном горизонте.
• Проверить деньги после возвратов и скидок.
• Посмотреть сегменты, а не только среднее.
• Назвать критерий, при котором решение изменится.

Как работать с неоднозначным условием

Интервьюер может сказать: «Нужно улучшить retention». Это не готовая задача. Уточните, какой продуктовый сценарий должен повторяться, какая когорта важна, какой горизонт и что команда уже пробовала. Если бизнес хочет увеличить D30, но продукт используется раз в квартал, проблема может быть в неверной метрике, а не в самом продукте.

Если данных недостаточно, не останавливайтесь на фразе «нужно больше данных». Предложите минимальный набор: события старта и возврата, user_id, timestamp, канал, платформа, версия и признак доступа к функции. Затем скажите, какой первый срез сделаете и какое решение он поддержит.

Практика: отвечайте на кейс за семь минут

Возьмите любой промпт: «после редизайна упала конверсия регистрации». За первую минуту задайте уточнения. За две минуты сформулируйте primary и guardrails. За две минуты назовите декомпозицию и данные. За минуту объясните два возможных результата. Последнюю минуту потрать на рекомендацию и следующий шаг. Запишите ответ и проверьте, не превратился ли он в список инструментов.

Хороший кандидат не обязан угадать единственную причину в условиях неполной информации. Он должен показать, как быстро сузит пространство причин и не даст команде принять дорогое решение по одному графику. Как те же вопросы приходят уже в работе — в разборе недели продуктового аналитика: от вопроса команды до записки менеджеру.