Кейс на собеседовании по продуктовой аналитике: если вы сразу “решаете”, а не уточняете — вам ставят минус

Типичная сцена: дают задачу “падает конверсия/нужен A/B/хотим фичу” и ждут красивую аналитику. На самом деле проверяют не эрудицию и не формулы, а то, как вы защищаете решение от самообмана. Цена ошибки в реальной работе ровно та же: вы уверенно принесёте вывод, который нельзя воспроизвести и нельзя использовать.

Почему это ломается: кейс всегда неполный. Интервьюер намеренно не договаривает цель, контекст, ограничения данных и способ принятия решения. Если вы не достраиваете рамку, вы “оптимизируете” случайный кусок системы, а потом удивляетесь, что бизнес спорит с выводом.

Мой скрипт решения кейса, который показывает качество мышления:

  1. Уточняю цель как решение, а не как метрику. Что считаем успехом: рост, удержание, маржа, снижение риска, скорость? Кто принимает решение и какой порог “достаточно, чтобы действовать”.

  2. Фиксирую north star и guardrails. Одна главная метрика и 2–3 защитные: чтобы не купить рост ценой возвратов, саппорта, отмен, LTV, качества.

  3. Сразу говорю про разрезы и сегменты, но не “давайте всё порежем”. Только те, где эффект может быть разным и это меняет решение (новые/старые, каналы, платформы, гео, cohort).

  4. Проговариваю риски данных. Где может врать трекинг, какие события недоопределены, есть ли изменения в логировании, задержки, дубли, бот/фрод, смещения из-за сезонности и акций. Что проверю первым, прежде чем верить цифрам.

  5. План анализа или эксперимента на уровне шагов. Если A/B — что рандомизируем, единица рандомизации, длительность как принцип (минимум полный цикл поведения), критерии остановки, как избегаем подглядывания. Если не A/B — какой квази-эксперимент, какие контрольные группы/синтетика, какие допущения и как их валидируем.

Ловушки интервьюера, на которые спокойно реагируете этой рамкой: “выберите одну метрику и всё”, “данные точно чистые”, “сделайте вывод за минуту”, “достаточно средних”, “A/B всегда лучший вариант”. Вы не спорите, вы ставите условия применимости и предлагаете минимальный набор проверок.

В правильной практике финал выглядит так: короткий вывод, степень уверенности, что может сломать вывод, и какое решение можно принять уже сейчас, а какое нельзя. Исключение одно: совсем маленький продукт без трафика — тогда вместо A/B честнее говорить про качественные сигналы и накопление данных, а не имитировать статистику.