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

Коротко

Отвечай продуктовым каркасом: цель пользователя → ключевое действие → метрика успеха → 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. За две минуты назови декомпозицию и данные. За минуту объясни два возможных результата. Последнюю минуту потрать на рекомендацию и следующий шаг. Запиши ответ и проверь, не превратился ли он в список инструментов.

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