Кейс-интервью аналитика: четыре задачи с разбором решения

Коротко: маршрут ответа на кейс

Уточните, какое решение должна принять команда и какой показатель или ограничение для неё важны. Определите единицу наблюдения и временное окно. Разложите результат по этапам, сегментам или факторам; назовите две-три гипотезы и самый дешёвый тест каждой. Затем предложите действие при подтверждении и при опровержении. В конце назовите риск решения и один следующий шаг.

Не начинайте с «проведём A/B-тест», пока не ясны вмешательство, единица рандомизации и возможность измерения. Не начинайте с SQL, если условие не говорит, какие таблицы существуют. Можно попросить данные или сделать явное допущение и продолжить. На собеседовании важна не только финальная цифра, но и способ восстановить её смысл.

Уточняющие вопросы должны сужать пространство решений. «Можно ли подробнее?» почти не помогает; «Сравниваем новых пользователей с новыми или все активные аккаунты?» меняет знаменатель. После двух-трёх таких вопросов повторите условие в собственной формулировке. Это даст интервьюеру возможность исправить понимание до того, как вы потратите время на неверную модель. Если данных не дадут, фиксируйте допущение и продолжайте, а не ждите идеального задания.

Какие кейсы бывают и чем они отличаются

Продуктовый кейс спрашивает, почему изменилось поведение или какую функцию запускать. Аналитический — как определить метрику, собрать витрину и проверить качество. Бизнесовый — как выбрать изменение процесса или посчитать экономику. Оценка рынка проверяет арифметику и чувствительность к допущениям, а не тайное знание численности неизвестного сегмента.

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

Двенадцать вопросов, которые держат разбор честным

Таблица — не сценарий для допроса интервьюера. Выберите несколько вопросов, которые влияют на решение. Остальные используйте как внутреннюю проверку собственной гипотезы.

Практикуйте таблицу не как список, который надо произнести целиком, а как набор развилок. Выберите случайный кейс и отметьте три вопроса, ответы на которые способны поменять рекомендацию. Например, для функции автосборки отчёта ключевыми будут получатели, их рабочий цикл и критерий пользы; подробность о цвете кнопки решение не меняет. Для оценки рынка важнее доля действительно достижимых клиентов и конверсия в продажу, чем очень точное число всех организаций.

Кейс 1. Активных стало больше — стоит ли праздновать?

Условие вымышленное. В прошлой когорте пришло 1 000 organic и 1 000 paid пользователей; полезное первое действие сделали 400 и 200. В новой когорте — 1 000 organic и 3 000 paid; активировались 400 и 600. Число активировавшихся выросло с 600 до 1 000, но доля всей когорты снизилась с 30% до 25%. Внутри каждого канала доля не изменилась: organic 40%, paid 20%. Изменился состав привлечения.

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

Здесь полезно вычислить и абсолютное изменение: активировавшихся стало на 400 больше. Это не противоречит падению общей доли на пять процентных пунктов; два показателя отвечают на разные вопросы. Если цель команды — число людей, совершивших полезное действие, рост может быть ценен. Если цель — качество привлечения на вложенный рубль, понадобятся затраты и последующее поведение. Решение невозможно вывести из одного процента без знания цели.

Проверьте также, что новая когорта получила столько же времени на первое действие. Если organic наблюдали семь дней, а paid — два, утверждение о неизменных 20% paid может быть преждевременным. В учебном условии окна предполагаются равными; в реальном кейсе это первое, что стоит уточнить. Хороший ответ не отменяет арифметику оговоркой, а показывает, при каком условии арифметика пригодна для решения.

Кейс 1: какое решение и что ещё проверить

Слабый ответ: «Активаций стало больше, значит запуск успешен» — игнорирует долю и состав. Другой слабый ответ: «Доля упала, значит новая функция сломала продукт» — подменяет сравнение причинным выводом. Сильный: «В абсолюте полезных действий стало больше, общий rate ниже из-за большего веса paid с прежней 20% долей. Сверю окна и качество источника, затем сравню цену и последующее поведение пользователей по каналам».

Если бы внутри paid доля изменилась с 20% до 15%, возникла бы другая гипотеза: качество трафика или продукта. Но в данном условии этого нет. Важно не добавить выдуманный сигнал в момент ответа. Хороший кандидат ясно произносит, какие данные ему дали, что он вычислил и какую проверку только предлагает.

Кейс 2. Согласование заявок тормозит

Вымышленное условие: сотрудники жалуются на долгий цикл согласования. Вам не дали журнал событий, только схему: заявка → проверка полноты → финансы → решение, с возможным возвратом на доработку. Первый вопрос — для чего ускоряем: снизить ожидание клиента, стоимость ручной обработки или потери заявок? Далее нужны события начала и конца каждого шага, владельцы, причины возврата и различие типов заявок.

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

Попросите три примера: заявку, прошедшую быстро, заявку с длительным ожиданием и заявку, возвращённую на доработку. Сравните, где они расходятся в журнале, а не только по словам участников. Если нет времени построить полный процесс, можно начать с карты состояний и владельцев перехода. Этого достаточно, чтобы увидеть, где нужен новый факт. Владелец финансового контроля может обоснованно не согласиться с автоматическим пропуском проверки; включите его ограничение в решение.

Метрика пилота — не только среднее время. Добавьте долю заявок старше согласованного срока и ошибки решения. Если процесс ускорился за счёт отказа от проверки документов, защитный показатель покажет цену. На интервью не объявляйте предложенный пилот «эффективным»: пока это способ получить сравнимые данные и решить, масштабировать ли изменение.

Кейс 3. Как измерить новую функцию автосборки отчёта

В вымышленном SaaS-продукте команда запускает автосборку еженедельного отчёта. Менеджер предлагает считать число открытий страницы. Уточните цель: сэкономить время подготовки и помочь пользователю довести отчёт до решения. Открытие страницы показывает контакт с функцией, но не пользу. Предложите primary metric на уровне подходящего аккаунта: доля аккаунтов, создавших автоматический отчёт и вернувшихся к нему в следующем цикле. Определите, что значит «подходящий»: имеет источник данных и право на отчёт.

Guardrail: ошибки генерации, число обращений в поддержку и доля пустых отчётов. Диагностика: открытие страницы, старт генерации, успешное создание, повторное использование. Для оценки эффекта сравните группы с одинаковым окном зрелости и проверьте, кто реально получил доступ к функции. Слабый ответ «посмотрим DAU» слишком далёк от механизма. Сильный показывает действие, которое должно измениться, и способ заметить цену ошибки.

Выбранная метрика имеет слабое место: повторное использование может отражать привычку одного сотрудника, а не ценность для всей организации. Поэтому заранее уточните, одна ли строка — аккаунт, пользователь или отчёт, и как учитывать несколько отчётов в одном аккаунте. Для B2B-продукта разумно смотреть на аккаунт и одновременно иметь диагностический срез по ролям пользователя. Отдельно проверьте, не созданы ли отчёты автоматически без действия человека: тогда создание само по себе перестанет измерять принятие функции.

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

Кейс 3: что делать, когда событие неполное

Если событие «отчёт открыт» отправляется только в вебе, а мобильный клиент не покрыт, нельзя считать общую долю повторного использования. Сначала проверьте схему и источник по платформам. На время проверки можно ограничить вывод веб-сегментом и явно подписать охват. Затем поставьте задачу на единое событие и зафиксируйте версию определения. Это решение скучнее новой диаграммы, зато удерживает команду от ложного вывода.

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

Кейс 4. Оценить ёмкость без готовой статистики

Условие специально синтетическое: представим 2 000 000 организаций на условном рынке, из них 8% подходят по размеру. Компания способна достучаться до 15% подходящих; 3% достигнутых купят сервис за 12 000 ₽ в год. Считаем последовательно: 160 000 подходящих, 24 000 достижимых, 720 покупателей, 8 640 000 ₽ годовой выручки. Это не оценка какого-либо реального рынка и не прогноз продаж: все входы заданы как допущения для упражнения.

В ответе покажите чувствительность. Если конверсия в покупку окажется 1%, при прочих равных будет 240 покупателей и 2 880 000 ₽. Разница в три раза показывает, что исследование этого допущения важнее дополнительной точности в общей численности организаций. Спросите, включает ли цена НДС, сколько длится продажа, какова доля продлений и стоимость привлечения. Нельзя назвать выручку прибылью или размер всего рынка доступной компании выручкой.

Если интервьюер спросит, откуда взялись 8%, 15% и 3%, ответ: они заданы учебным условием. Для настоящего проекта их пришлось бы оценить отдельно: определить критерий подходящего клиента, проверить доступные каналы, провести пилот продаж. Не подменяйте эту работу уверенной ссылкой на «среднюю конверсию по рынку» без источника. Полезно разложить неопределённость и показать, какой вход сильнее меняет решение. В данном расчёте конверсия покупки от 1% до 3% меняет выручку от 2,88 до 8,64 млн ₽ при неизменных прочих входах.

Даже получив выручку, нельзя сказать, окупится ли продукт: не учтены стоимость продаж, внедрения, поддержки и срок получения платежей. Следующий разумный вопрос — какой минимальный поток клиентов покроет эти расходы. Если интервьюер не дал затраты, скажите, какие именно нужны, и остановите расчёт прибыли. Это демонстрирует границу модели, а не слабость математики.

Синтез: как закончить кейс рекомендацией

После разбора не оставляйте на столе россыпь гипотез. Назовите решение для владельца: «В этом условии я бы не откатывал продукт из-за общего падения доли; сперва проверил окна и экономику paid». Или: «Пилот изменения согласования стоит делать после замера, где именно очередь». Добавьте, какой факт заставит изменить рекомендацию. Это показывает, что анализ ведёт к действию и допускает пересмотр.

Сформулируйте уровень уверенности. Есть вычисленный факт, есть допущение, есть гипотеза причины. Для кейса рынка честный итог — диапазон при разных конверсиях и вопрос, какое значение можно проверить в пилоте. Для кейса функции — определение метрики и план измерения, а не обещание роста. Не выводите причинность из соседних дней без сравнимой основы.

Тренируйте формат «решение — основание — условие пересмотра». Например: «Я бы сначала проверил, одинаковы ли окна наблюдения по каналам; при равных окнах падение общей доли объясняется сменой смеси, поэтому следующий анализ — экономика paid. Если внутри канала тоже упала доля, вернусь к качеству трафика и событию активации». Такой финал держится на данных условия и оставляет место для новой информации. Список гипотез без выбора первой проверки не заменяет рекомендацию.

Ошибки кандидатов и цена каждой

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

Пятая — записать предположение о рынке как факт: модель приобретёт ложную точность. Шестая — считать выручку прибылью: бизнесовый вывод станет неверным. Седьмая — дать 20 гипотез без выбора первой проверки: команде нечего делать завтра. Восьмая — закончить словами «нужны данные» без безопасного следующего шага: навык принятия решения не виден.

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

План подготовки на десять дней

Дни 1–2: разберите продуктовую метрику по числителю, знаменателю и окну. Дни 3–4: потренируйте сегментацию и смешение, пересчитайте учебный кейс активации без подсказки. Дни 5–6: опишите два процесса и найдите владельца решения в каждом. День 7: сделайте оценку ёмкости с явными допущениями и сценариями. День 8: сформулируйте primary и guardrail для новой функции. День 9: решите незнакомое условие вслух с другим человеком. День 10: переслушайте ответ и уберите скачок от наблюдения к причине.

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

Для самопроверки через несколько дней поменяйте одну предпосылку в каждом кейсе. В случае активации пусть доля paid снизится внутри канала; в процессе заявок пусть задержка окажется на первом шаге; в оценке рынка пусть цена будет ежемесячной, а не годовой. Пересчитайте только то, что изменилось, и пересмотрите рекомендацию. Так вы учитесь работать с новым фактом, а не запоминать четыре готовых финала.

Частые вопросы и следующий шаг

Что такое кейс-интервью? Разговор о задаче с неполным условием, где виден ход решения. Обязательно ли назвать точный ответ? Для синтетического расчёта — да, если заданы входы; для открытой ситуации важнее корректные допущения и решение. Можно ли задавать вопросы? Да, но выбирайте те, что меняют подход. Нужно ли знать продукт компании заранее? Полезно понять его модель, однако непроверенные внешние факты не подменяют условие.

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