4 апреля 2026 г.

Кейсы на собеседовании аналитика: 15 примеров с разбором

Зачем компании дают кейсы

Кейс — это ситуация из реальной работы, которую вас просят разобрать. Это самая «аналитическая» часть собеседования: проверяют не SQL-синтаксис, а способность думать данными.

Что проверяют:

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

Фреймворк для решения кейсов

Используйте эту структуру для любого кейса:

Уточните условие. Задайте 2–3 вопроса: какой продукт, какая платформа, какой временной период, что считаем «нормой»
Декомпозируйте метрику. Разложите на составные части (DAU = новые + вернувшиеся)
Сформулируйте гипотезы. 3–5 возможных причин, от самых вероятных к менее вероятным
Предложите проверку. Для каждой гипотезы — конкретный SQL-запрос или срез данных
Сделайте вывод и рекомендацию. Что делать, если гипотеза подтвердилась

Кейсы «метрика упала»

Кейс 1. DAU упал на 15% за неделю

Разбор:

Декомпозиция: новые пользователи (acquisition) или вернувшиеся (retention)?
Срезы: платформа (iOS/Android/web), гео, источник трафика, версия приложения
Внешние факторы: обновление приложения, технический сбой, сезонность, конкурент
Если упали новые → проблема с маркетингом или ухудшение ASO/SEO
Если упали вернувшиеся → проблема с продуктом (баг, UI-изменение)

Подробнее: метрика упала — полный разбор.

Кейс 2. Конверсия в покупку упала на 10%

Декомпозиция воронки: просмотр → корзина → checkout → оплата. На каком шаге падение?
Если между корзиной и checkout → проблема с UI корзины, появился bug
Если между checkout и оплатой → проблема с платёжным шлюзом
Проверить: новые vs старые пользователи, платформа, метод оплаты

Кейс 3. Среднее время сессии выросло на 30%

Рост не всегда хорош. Возможные причины:

Позитивная: пользователи стали больше взаимодействовать с контентом
Негативная: пользователи не могут найти нужное и блуждают по сайту
Техническая: страницы стали загружаться медленнее
Проверить: корреляция с целевым действием (покупка, регистрация). Если время выросло, а конверсия нет — скорее проблема

Кейс 4. NPS упал с 45 до 30

Сегментировать по когортам: новые vs старые пользователи
По платформе, по тарифу, по региону
Посмотреть текстовые отзывы: о чём жалуются?
Совпало ли с релизом, изменением цен, инцидентом?
Рекомендация: если причина конкретная (баг, повышение цен) — исправить. Если системная — глубокое исследование

Кейсы «спроектируйте»

Кейс 5. Спроектируйте систему метрик для приложения доставки еды

Ответ по AARRR:

Acquisition: установки, CAC по каналам
Activation: первый заказ, время до первого заказа
Retention: D1/D7/D30, частота заказов
Revenue: GMV, средний чек, ARPU, LTV
Referral: приглашения, виральность

North Star: количество завершённых доставок (отражает ценность для обеих сторон)

Guardrail-метрики: время доставки, процент отменённых заказов, NPS

Кейс 6. Спроектируйте A/B-тест для нового onboarding

Метрика успеха: activation rate (% пользователей, совершивших ключевое действие)
Guardrail: D1 retention, время прохождения onboarding
Размер выборки: зависит от текущей activation rate и MDE
Длительность: минимум 1-2 недели (учесть day-of-week эффект + novelty)
Рандомизация: по user_id, только новые пользователи
Что может пойти не так: novelty effect, sample ratio mismatch, пересечение с другими тестами

Подробнее: A/B-тестирование на собеседовании.

Кейс 7. Как измерить эффект рекомендательной системы

Основная метрика: CTR рекомендаций → конверсия в целевое действие
Не просто CTR — отслеживать downstream-метрики (покупка, retention)
A/B-тест: рекомендации vs случайная выдача (или старый алгоритм)
Сложность: долгосрочный эффект (discovery → возврат → покупка через неделю)
Метрики: diversity (разнообразие), serendipity (неожиданные находки), coverage

Кейсы «выберите метрику»

Кейс 8. Какую метрику выбрать для оценки качества поиска?

Не просто CTR. Варианты:

CTR@N: доля кликов в топ-N результатах
pFound: вероятность, что пользователь нашёл ответ (по моделированию внимания)
NDCG: качество ранжирования с учётом позиции
Zero-result rate: доля запросов без результатов
Reformulation rate: доля запросов, после которых пользователь переформулировал

Хороший ответ: назвать 2–3 метрики, объяснить trade-offs, выбрать основную.

Кейс 9. Как оценить качество модерации контента

Precision: доля верных блокировок среди всех блокировок (ложноположительные вредят честным пользователям)
Recall: доля заблокированного контента среди всего плохого (ложноотрицательные вредят аудитории)
Time to action: скорость реакции модерации
Appeal rate: доля обжалований → индикатор ошибок

Кейс 10. Как сравнить два ML-алгоритма для таргетинга push-уведомлений

Offline метрики: AUC-ROC, precision@K, lift
Online метрики: CTR push → conversion → retention
Не забыть: opt-out rate (если push раздражают — долгосрочный вред)
A/B-тест обоих алгоритмов на рандомных группах

Кейсы «что делать»

Кейс 11. Данные в отчёте не сходятся с данными коллеги

Проверить определения: одинаково ли считаем метрику?
Проверить фильтры: тот же период, те же условия (статус заказа, платформа)?
Проверить источник: одна и та же таблица? Есть ли дубли?
Проверить временну́ю зону: created_at в UTC или локальном времени?

Кейс 12. Продакт-менеджер просит «просто показать, что фича работает»

Аналитик не подгоняет данные под вывод. Ваша задача — объективный анализ
Предложить корректный A/B-тест вместо cherry-picking метрик
Если данные показывают, что фича не работает — это тоже ценный результат
Коммуникация: «Данные показывают X. Вот что можно попробовать дальше»

Кейс 13. Бизнес хочет запустить фичу без A/B-теста — «нет времени»

Предложить компромисс: поэтапный rollout (5% → 25% → 100%) с мониторингом
Определить guardrail-метрики, которые отследите даже без полноценного теста
Задокументировать baseline до запуска — сможете сделать pre-post анализ
Если фича критичная и необратимая — настаивать на тесте

Кейсы для Senior

Кейс 14. Спроектируйте систему аналитики для нового продукта с нуля

Событийная модель: какие события трекать (регистрация, действия, покупки)
Хранилище: ClickHouse для аналитики, PostgreSQL для приложения
Метрики: AARRR + North Star + операционные
Дашборды: executive (1 экран), operational (по командам), ad-hoc (SQL)
Инфраструктура: event tracking (Segment/Amplitude), ETL (Airflow/dbt), BI (Looker/Metabase)

Кейс 15. Ваша рекомендация не совпала с решением руководства. Что дальше?

Задокументировать свою рекомендацию и обоснование
Предложить измерить результат решения через конкретные метрики
Если решение привело к ухудшению — показать данные без «я же говорил»
Если решение сработало — пересмотреть свои предположения и учиться

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

Тренируйтесь вслух. Проговаривание — отдельный навык. Попросите друга задавать кейсы
Разберите 5 публичных кейсов. Любой продукт: «если DAU Spotify упал на 20% — ваш анализ?»
Знайте метрики наизусть. DAU, MAU, retention, воронка конверсии, unit-экономика
Практикуйтесь на вопросах. 1500+ вопросов в тренажёре

FAQ

Сколько кейсов дают на собеседовании?

Обычно 1–2 кейса за 30–40 минут. Один «метрика упала» + один «спроектируйте». На позицию продуктового аналитика кейсов больше — до 3–4.

Можно ли просить уточнения у интервьюера?

Да, и это оценивается положительно. «Это мобильное приложение или web?», «Рост произошёл резко или плавно?», «Были ли релизы на этой неделе?» — всё это показывает аналитическое мышление.

Что важнее — правильный ответ или ход мысли?

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

Как отличить хороший ответ от среднего?

Средний: «Нужно посмотреть DAU, retention, конверсию». Хороший: «Сначала декомпозирую DAU на новых и вернувшихся, проверю по платформам, затем сузю до конкретного сегмента, предложу 3 гипотезы с конкретными SQL-запросами для проверки».

Потренируйтесь решать аналитические кейсы — откройте тренажёр с 1500+ вопросами для собеседований аналитиков.

Тренироваться в Telegram