Кейс: retention упал. Как решать на собеседовании

Формулировка кейса

Это один из самых частых кейсов на собеседовании продуктового аналитика. Его задают в Авито, Ozon, Wildberries, Яндексе, Тинькофф — варианты отличаются только продуктом и цифрами. Ниже — структурный разбор, который ждут от middle-кандидата.

Что хотят услышать

Интервьюер проверяет три вещи:

1. Умение задавать уточняющие вопросы — не бросаться решать, а понять контекст.
2. Структурность — разбиение проблемы на части, не хаос.
3. Инженерное мышление — конкретные метрики и данные, а не «я бы посмотрел общую картину».

Говорим медленно, вслух формулируем гипотезы, выписываем структуру на листке.

Шаг 1. Уточняющие вопросы

Прежде чем лезть в анализ, проверяем, что правильно поняли задачу:

• Про какой retention речь? D1, D7, D30? Classic retention или unbounded?
• Откуда цифра? Дашборд, выгрузка из БД, репорт?
• Какой сегмент? Все пользователи, новички, платящие?
• Какой продукт/платформа? iOS, Android, web, все сразу?
• Что ещё упало? DAU, конверсия, выручка?

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

Шаг 2. Первая проверка — это не баг в данных?

Самая частая причина «падения метрики» — не реальное падение, а проблема с учётом. Идём по списку:

• Изменились ли ETL-джобы? Новая логика фильтрации или расчёта.
• Не упал ли трекер? Пропуск событий, поломка SDK после релиза.
• Не изменилось ли определение метрики? Кто-то мог редактировать SQL в дашборде.
• Не сломалась ли выгрузка в dashboards? Последние данные неполные.
• Чек на консистентность: сравниваем с параллельными источниками (PostHog, Amplitude, сырые логи).

Ответ на собесе: «Прежде всего проверю, что метрика посчитана корректно — сравню с сырыми данными, проверю changelog ETL». Если кандидат сразу прыгает в продуктовые гипотезы — минус очко.

Прокачать тему на реальных задачах удобно в боте @kariernik_bot — база вопросов собрана с собеседований в Яндексе, Авито, Ozon, Тинькофф.

Шаг 3. Декомпозиция метрики

Retention — не атомарная метрика. Разбиваем:

• Когортный разрез: падение у когорты одной недели или у всех?
• Канал привлечения: органика, paid, реферальные ссылки — где просело сильнее?
• Платформа: iOS, Android, web — одинаково или нет?
• Гео/язык: регионы, города, языки.
• Сегмент пользователей: новички vs старожилы, платящие vs бесплатные.

Это даёт первый сигнал: если упал один сегмент — гипотезы сужаются в 10 раз. Если все одновременно — смотрим на общие факторы (релиз, выходные дни, сезонность).

Пример на собесе: «Разложу по 4 измерениям: день когорты, канал, платформа, гео. Если один сегмент сильно выделяется — копаю туда. Если все — ищу общую причину».

Шаг 4. Построение гипотез

Выписываем список по категориям:

Внутренние (релизные)

• Релиз — что выкатили за две недели? Может быть новая фича, редизайн, изменение онбординга.
• A/B-тесты — сейчас активны какие-то тесты, которые могли негативно повлиять на retention?
• Инфраструктура — деплой с увеличенным временем загрузки, падение конверсии push-ов, ломающие изменения в backend.
• Изменения в пуш-рассылках — сократили частоту, изменили контент.

Внешние

• Сезонность — если падает начало учебного года / праздники / отпуска.
• Конкуренты — запустили промо, новое приложение.
• Маркетинг — изменились каналы привлечения (стало больше «мусорного» трафика из performance).
• Новости/события — что-то в мире, что влияет на категорию.

Смешанные

• Botnet/фрод — накрутка регистраций с низкой вовлечённостью.
• Изменение ценовой политики — повышение цен, отмена промокодов.

Ответ на собесе: «Составлю таблицу гипотез, приоритизирую по ожидаемому эффекту × лёгкости проверки. Начну с релизных — их быстрее всего валидировать».

Шаг 5. Проверка гипотез

Каждую гипотезу проверяем через данные:

Гипотеза 1: новый онбординг снизил retention

• Смотрим на когорты ДО и ПОСЛЕ релиза онбординга.
• Если релиз был A/B-тестом — смотрим метрики групп.
• Если выкатили на 100% — сравниваем с параллельными периодами.

Гипотеза 2: изменилось качество трафика

• Смотрим retention по каналам.
• Если конкретный канал (например, performance TikTok) резко вырос в объёме, но его retention ниже среднего — это объясняет падение среднего.
• Метрика: Simpson's paradox — среднее может падать, хотя ни один сегмент не ухудшился.

Гипотеза 3: технический сбой

• Логи ошибок: увеличилось ли количество crash-ов, таймаутов, 500-х.
• Время загрузки страниц.
• Доля пользователей, которые не доходят до ключевого события (open app → первый клик).

Гипотеза 4: сезонность

• Смотрим retention за тот же период прошлого года.
• Корректируем на YoY тренд.

Шаг 6. Что будем делать дальше

После того как нашли гипотезу-победителя — переходим к действиям:

• Если релиз виноват — откатить или допилить, пока retention не восстановится.
• Если качество трафика — работать с маркетингом над сегментацией источников.
• Если сезонность — задокументировать, не паниковать, не делать лишних изменений.
• Если фрод — поднять тикет на антифрод-команду.

На собесе ждут: «Поделюсь выводами с PM, мы приоритизируем действия по ROI и trust, напишу пост в #analytics-channel — чтобы команда знала, что копаем».

Структура ответа — краткий шаблон

Если забудете детали, помните структуру:

1. Уточнения (что за retention, какой сегмент, тайминг).
2. Проверка данных (баг в ETL, трекере, расчёте?).
3. Декомпозиция (когорты, каналы, платформы, гео).
4. Гипотезы (внутренние: релиз, A/B, инфраструктура; внешние: сезонность, конкуренты).
5. Проверка (каждую через данные).
6. Действия (откат, доработка, коммуникация с PM).

Этот фреймворк работает для любой метрики, которая «упала» — конверсия, DAU, выручка.

На собесе такие штуки часто спрашивают. Быстрый способ довести до автоматизма — тренажёр в Telegram с задачами из реальных интервью.

Типичные ошибки

• Прыгать в решение без уточнений. Первое впечатление — аналитик не владеет собой.
• Давать ответ без гипотез. «Я бы посмотрел данные» — не ответ.
• Игнорировать проверку данных. Каждый 3-й кейс на практике — баг в расчёте.
• Игнорировать сегментацию. Среднее может быть неинформативным.
• Давать одну гипотезу. Всегда 3-5 вариантов, иначе видно тоннельное мышление.

Как подготовиться к таким кейсам

Чтение теории тут почти не помогает — нужна практика. Работают три подхода:

1. Разбирать чужие кейсы — блоги Netflix, Uber, Авито, Яндекс.
2. Прогонять структуру на разных метриках — «DAU упал», «конверсия в покупку упала», «средний чек упал».
3. Задачи на собесах — в Карьернике есть блок продуктовых кейсов с разборами.

Тренажёр Карьерник содержит кейсы такого формата — с гипотезами и разборами. За две недели подготовки структура становится рефлексом: любой кейс раскладывается по шагам без запинок.

Читайте также

• Кейс: метрика упала на собеседовании
• Кейсы на собеседовании аналитика
• Когортный анализ
• Как считать retention
• Парадокс Симпсона

FAQ

Сколько времени на собеседовании даётся на такой кейс?

Обычно 20–30 минут. В некоторых компаниях (Яндекс, Авито) — до 45 минут. Структурный ответ на 10 минут + 10 минут на уточняющие диалоги — нормальный тайминг.

Что важнее — найти правильную гипотезу или показать структуру?

Структура. Интервьюер знает, что в реальной жизни причину никто не находит за 20 минут. Задача кейса — проверить мышление, а не гадание.

Можно ли задавать много уточняющих вопросов?

Да, но не превращайте в интервью наоборот. 3-5 вопросов в начале — нормально, дальше нужно начинать отвечать. Если вопросов больше 10 — интервьюер начнёт подозревать, что вы тянете время.

Что делать, если не знаю специфику продукта из кейса?

Сказать об этом: «я не работал в e-commerce, поэтому сделаю общие предположения про такой тип продукта». Интервьюер либо подкинет контекст, либо согласится с общими рассуждениями. Притворяться, что знаете специфику — хуже всего.