Кейс на собеседовании продуктового аналитика валится не из‑за «неумности», а из‑за пропущенных шагов мышления.

Типичная сцена: дают задачу уровня «падает конверсия», «нужно вырастить retention», «выкатили фичу — стало хуже». Кандидат сразу рисует дашборд, предлагает A/B и сыпет метриками. Интервьюер кивает, а потом одним уточнением ломает всё: «а что именно считаем конверсией?», «а данные вообще полные?», «а раскатка была на всех?». Цена ошибки в реальной работе ровно та же: неделю анализировали не то, приняли решение, которое нельзя защитить.

Почему так происходит: кейс проверяет не знание формул, а умение держать в голове контекст, причинность и ограничения данных. Интервьюер часто специально подбрасывает «неполные условия», чтобы увидеть, как вы их добираете и где ставите стоп‑кран.

Скрипт решения, который почти всегда выглядит «взросло»:

  1. Уточнить цель как решение, а не как метрику. Что именно выбираем в конце: выкатывать, откатывать, править воронку, менять таргетинг, ставить алерт?
  2. Зафиксировать одну основную метрику и 2–3 guardrails. Основная отвечает за цель, guardrails — за побочные эффекты и качество трафика/выручки/нагрузки.
  3. Проверить данные до анализа. Определения событий, дедупликация, задержки, изменения трекинга, пересечения сегментов, влияние ботов/фрода, неполные окна (например, ретеншн “не успел дозреть”).
  4. Выбрать дизайн: диагностика или причинный ответ. Если это «почему упало» — сначала декомпозиция и срезы. Если это «помогла фича» — условия эксперимента, единица рандомизации, влияние сезонности/раскатки, риск интерференции.
  5. Коммуникация вывода: тезис, уверенность, альтернативные объяснения, что проверяем дальше, какие решения безопасны уже сейчас.

Типовые ловушки интервьюера: заставить вас назвать 20 метрик вместо одной цели; спровоцировать «корреляция = причина»; заставить не заметить, что изменился трекинг/окно/сегментация; увести в SQL‑детали, когда ещё не понятно, что именно ищем.

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