Продуктовые кейсы на собеседовании аналитика
Зачем на собеседовании дают кейсы
Продуктовый кейс — открытый вопрос без единственного правильного ответа. «Метрика упала — что делать?» или «Как оценить успех нового фичи?» Кейсы проверяют не знание формул, а аналитическое мышление: умение структурировать проблему, генерировать гипотезы, приоритизировать проверки.
На собеседованиях по продуктовой аналитике кейсы — самый частый формат для middle и senior позиций. Интервьюер оценивает не столько финальный ответ, сколько процесс рассуждения.
Структура ответа на кейс
Шаг 1 — уточните контекст. Не начинайте отвечать сразу. Задайте 2-3 уточняющих вопроса: какой продукт, какая метрика, за какой период изменение, есть ли сезонность. Это показывает зрелость и не даёт уйти в неправильном направлении.
Шаг 2 — декомпозируйте метрику. Разложите метрику на составляющие. Revenue = Users * Conversion * ARPPU. DAU = New Users + Returning Users. Retention D7 зависит от активации, engagement, push-уведомлений. Декомпозиция сужает область поиска проблемы.
Шаг 3 — сформулируйте гипотезы. Для каждого компонента предложите возможные причины изменения. Организуйте по MECE (см. ниже). Пример: DAU упал — гипотезы по new users (проблема с привлечением, регистрацией) и по returning users (retention упал, push сломались, баг в приложении).
Шаг 4 — приоритизируйте проверки. Не все гипотезы равноценны. Начните с самых вероятных и легко проверяемых: технические проблемы (баг, даунтайм), изменения в данных (новый трекинг, сломался счётчик), внешние факторы (сезонность, конкуренты).
Шаг 5 — предложите действия. После диагностики — что делать? Краткосрочно (откатить изменение, исправить баг) и долгосрочно (улучшить воронку, настроить мониторинг).
На собеседовании оценивают структуру мышления, а не «угадывание» правильной причины. Интервьюер хочет увидеть: кандидат не паникует, задаёт правильные вопросы, разбивает проблему на части, приоритизирует. Даже если вы не назовёте истинную причину — структурированный подход покажет вашу квалификацию.
MECE декомпозиция
MECE (Mutually Exclusive, Collectively Exhaustive) — принцип структурирования, при котором категории не пересекаются и в совокупности покрывают все возможные варианты.
Пример MECE для «DAU упал»: (1) проблема на стороне данных — трекинг сломался, изменилась методология; (2) проблема с привлечением — меньше новых пользователей; (3) проблема с удержанием — больше пользователей не вернулось; (4) внешние факторы — сезонность, конкуренты, праздники. Эти четыре категории не пересекаются и покрывают все возможности.
Почему MECE важен на собеседовании: без структуры кандидат перечисляет гипотезы хаотично и забывает целые категории. С MECE — показывает, что умеет мыслить системно и ничего не упустит.
Примеры кейсов с разбором
Кейс 1: «Конверсия в покупку упала на 15% за неделю». Декомпозиция: конверсия = клики на товар * add-to-cart rate * checkout completion * payment success. Проверки: (1) данные — не изменился ли трекинг? (2) техника — нет ли ошибок на странице оплаты? (3) сегменты — упала у всех или у определённого сегмента (мобайл, новая география, конкретный канал)? (4) внешние — не запустил ли конкурент акцию?
Кейс 2: «D1 retention упал с 30% до 22%». Декомпозиция по когортам: упал у всех когорт или только у новых? По источникам трафика: изменился ли микс каналов? По платформам: iOS vs Android. Проверки: не сломался ли онбординг? Не изменилась ли скорость загрузки? Нет ли бага, мешающего активации?
Кейс 3: «Как оценить успех нового экрана онбординга?» Определить метрики: primary — onboarding completion rate и D7 retention. Secondary — time-to-value, количество действий в первой сессии. Guardrail — не увеличилось ли время онбординга, не упала ли конверсия в регистрацию. Дизайн: A/B-тест, сегментация по когортам.
Кейс 4: «ARPU растёт, но revenue падает. Почему?» ARPU = Revenue / Active Users. Если ARPU растёт, а Revenue падает — Active Users уменьшаются быстрее, чем растёт средний доход. Проверки: что происходит с DAU/MAU? Уходят ли бесплатные пользователи (тогда ARPU растёт механически)? Или уходят все, но мелкие клиенты быстрее, чем крупные?
Частые ошибки кандидатов
Сразу называют причину — без анализа и структуры. «Наверное, баг» — это не ответ. Интервьюер хочет видеть процесс, а не угадывание.
Забывают про данные. Первый шаг — убедиться, что метрика действительно упала, а не сломался трекинг. На практике «падение метрики» оказывается проблемой с данными в 30-40% случаев.
Не сегментируют. Общее падение почти всегда скрывает неоднородность. Разбейте по платформе, географии, когорте, источнику — и проблема локализуется.
Не предлагают действий. Диагностика без плана действий — неполный ответ. Даже если точная причина не найдена, предложите приоритизированный план проверок и потенциальные действия для каждого сценария.
MECE — это не просто красивый фреймворк для собеседования. Это рабочий инструмент аналитика. Когда в реальной работе метрика падает и все паникуют, MECE-декомпозиция позволяет системно перебрать причины и не пропустить очевидное.
FAQ
Сколько гипотез нужно предложить на кейсе?
Оптимально 4-6 гипотез, организованных по MECE-категориям. Меньше — рискуете выглядеть поверхностно. Больше — начнёте перечислять маловероятные сценарии и потеряете фокус. Качество важнее количества: лучше 4 хорошо обоснованные гипотезы, чем 10 случайных.
Нужно ли знать SQL для решения кейсов?
Знать SQL полезно для того, чтобы описать, как именно вы проверите гипотезу: «Я бы написал запрос, группирующий D1 retention по source и platform, чтобы найти сегмент с наибольшим падением». Но формальное написание SQL на кейсе обычно не требуется — важнее логика анализа.
Как тренировать решение кейсов?
Берите реальные метрики любого продукта и моделируйте сценарии: «Что если retention упал?», «Что если конверсия выросла, а revenue нет?». Практикуйте MECE-декомпозицию вслух — на собеседовании нужно думать и говорить одновременно. Разбирайте примеры вопросов и записывайте структуру ответа.