продуктовый аналитиккейс-интервьюсобеседованиеSQLпродуктовые метрикидекомпозицияконверсия

Разбор продуктового кейса на собесе аналитика

2026-07-05 12 мин

BLUF (главное сразу). На кейс-интервью аналитика вам дают одну фразу: «Конверсия из просмотра объявления в контакт с продавцом упала на 12% за две недели. Разберись». Правильный ответ — не набор гипотез вслух, а последовательность: уточнить определение метрики → разложить её на множители → сегментировать и найти, где именно провал → сформулировать 2-3 гипотезы под этот сегмент → написать SQL, который их проверяет → собрать вывод в одну фразу с рекомендацией. Ниже — полный разбор такого кейса с таблицей данных, декомпозицией, запросами и разбором того, как это подаётся вслух. Кейс собран по мотивам реального кейс-интервью продуктового аналитика Авито и структуры тестового задания Ozon (описание — в конце).

Откуда взялся кейс

Формат «метрика упала на N% — твои действия» — самый частый на продуктовых собеседованиях в РФ. Его дают в Авито, Ozon, Т-Банке, ВКонтакте, МТС, Учи.ру — почти везде, где есть продуктовая аналитика. Интервьюер смотрит не на то, знаете ли вы конкретную формулу, а на то, насколько последовательно вы отсекаете неверные версии и не хватаетесь за первую попавшуюся гипотезу.

Я взял конкретику из двух реальных источников. Первый — кейс-интервью аналитика Авито (руководитель аналитики Комфортной сделки Игорь Сухарев разбирал живой кейс со старшим аналитиком): там центральная метрика классифайда — конверсия из просмотра карточки в контакт с продавцом (написать/позвонить). Второй — тестовое задание Ozon на аналитика, где данные приходят в разрезе date / platform / action / count / uniq (события, штуки, уникальные пользователи). Из этих кусков собирается один реалистичный кейс — с ним и работаем.

Кейс. Продукт — маркетплейс объявлений (недвижимость, авто, вещи). Ключевая метрика воронки: contact_rate = контакты / просмотры карточек. За последние 14 дней она упала с 8,3% до 7,3% — это −12% относительно базы. Продакт прибегает к вам: «Что случилось, чинить или нет?»

Шаг 0. Уточнить метрику, прежде чем бежать в данные

Первое, что должен сделать аналитик, — не молча кивнуть, а задать уточняющие вопросы. Это не тянет время, это часть оценки. Три вопроса, которые снимают половину неопределённости:

Проверьте определение так — сразу видно уровень гранулярности:

SELECT
    event_date,
    COUNT(DISTINCT CASE WHEN action = 'card_view' THEN user_id END)  AS viewers,
    COUNT(DISTINCT CASE WHEN action = 'contact'   THEN user_id END)  AS contactors,
    ROUND(
        COUNT(DISTINCT CASE WHEN action = 'contact' THEN user_id END)::numeric
        / NULLIF(COUNT(DISTINCT CASE WHEN action = 'card_view' THEN user_id END), 0),
        4
    ) AS contact_rate
FROM events
WHERE event_date >= CURRENT_DATE - INTERVAL '28 days'
GROUP BY event_date
ORDER BY event_date;

Если график — плавный склон без ступеньки, версию «сломанный релиз» отодвигаем. Если ступенька 3-го числа — почти наверняка выкатка. Это уже сужает пространство поиска вдвое, а бинарное отсечение (делить проблему пополам) — то, что интервьюер хочет увидеть в первую очередь.

Шаг 1. Декомпозиция: не «почему упало», а «что именно из чего состоит»

Не вываливайте 15 гипотез сразу — так делают все, и это читается как хаос. Сначала разложите метрику на множители и слои. contact_rate — это не атом, это результат:

$$\text{contact\_rate} = \frac{\text{контакты}}{\text{просмотры}} = \sum_{s} w_s \cdot cr_s$$

где $w_s$ — доля сегмента $s$ в просмотрах, а $cr_s$ — конверсия внутри сегмента. Отсюда два принципиально разных механизма падения:

Первое, что должен показать аналитик, — умение эти два механизма различать. Дальше режем по осям, где обычно и прячется причина:

Шаг 2. Пример данных

Таблица events — одна строка на событие (структура ровно как в тестовом Ozon, плюс атрибуты для сегментации):

event_dateuser_idactionplatformuser_typecategory
2026-06-148123card_viewiosreturningauto
2026-06-148123contactiosreturningauto
2026-06-144471card_viewandroidnewrealty
2026-06-159902card_viewwebnewelectronics
2026-06-154471contactandroidnewrealty

Агрегат contact_rate по неделям и платформам — то, что вы кладёте на whiteboard:

ПлатформаНеделя 1 (до)Неделя 2 (после)Δ
iOS9,1%9,0%−1%
Android8,0%8,1%+1%
web7,6%4,9%−36%
Итого8,3%7,3%−12%

Вот он, момент истины. iOS и Android не двигались. Всё падение — на web, где конверсия обвалилась с 7,6% до 4,9%. Общая метрика упала на 12% не потому, что «продукт стал хуже везде», а потому что просела одна платформа. Дальше копаем строго внутри web — остальное можно не трогать.

Шаг 3. Гипотезы — только под найденный сегмент

Теперь гипотезы точечные, а не веером:

Порядок проверки — от дешёвого к дорогому: сначала трекинг и mix shift (один запрос каждый), потом гипотезы про продукт.

Шаг 4. SQL, который проверяет гипотезы

Проверка H2 (mix shift): выросла ли доля new-юзеров на web и хуже ли они конвертят. Если общая по web упала из-за сдвига долей, а не из-за падения внутри new/returning — это маркетинг, а не продукт.

WITH weekly AS (
    SELECT
        CASE WHEN event_date < DATE '2026-06-21' THEN 'w1_before' ELSE 'w2_after' END AS period,
        user_type,
        COUNT(DISTINCT CASE WHEN action = 'card_view' THEN user_id END) AS viewers,
        COUNT(DISTINCT CASE WHEN action = 'contact'   THEN user_id END) AS contactors
    FROM events
    WHERE platform = 'web'
      AND event_date >= DATE '2026-06-14'
    GROUP BY 1, 2
)
SELECT
    period,
    user_type,
    viewers,
    ROUND(viewers::numeric / SUM(viewers) OVER (PARTITION BY period), 3) AS share_of_traffic,
    ROUND(contactors::numeric / NULLIF(viewers, 0), 4)                   AS contact_rate
FROM weekly
ORDER BY period, user_type;

Читаем результат так. Если contact_rate для new и returning не изменился между неделями, но share_of_traffic у new вырос с 0,30 до 0,55 — это чистый mix shift. Продукт не сломан, метрика упала из-за структуры трафика. Если же contact_rate внутри new или returning сам просел — это реальная деградация, идём в H1/H3.

Проверка H4 (трекинг) и H1 (релиз): ступенька по дням внутри web. Ровный обвал в один конкретный день = релиз или отвал событий, а не поведение людей.

SELECT
    event_date,
    COUNT(*) FILTER (WHERE action = 'card_view')                       AS view_events,
    COUNT(*) FILTER (WHERE action = 'contact')                         AS contact_events,
    ROUND(
        COUNT(*) FILTER (WHERE action = 'contact')::numeric
        / NULLIF(COUNT(*) FILTER (WHERE action = 'card_view'), 0), 4
    ) AS event_ratio
FROM events
WHERE platform = 'web'
  AND event_date >= CURRENT_DATE - INTERVAL '21 days'
GROUP BY event_date
ORDER BY event_date;

Если view_events держатся ровно, а contact_events рухнули строго с 21-го числа — это либо кнопка перестала слать событие (баг/трекинг), либо релиз. Смотрим changelog на эту дату. Если совпадает с выкаткой веб-версии — гипотеза почти подтверждена.

Разбор такой воронки по слоям — стандартная тема на собесе; если хотите потренировать сегментацию и оконные функции на реальных данных, это ровно то, что лежит в /sql-sandbox с автопроверкой, а связанные продуктовые ситуации разобраны в /cases.

Финальная валидация: размер эффекта. Прежде чем нести вывод продакту, оцените, объясняет ли найденный сегмент всё падение. Веб-трафик — скажем, 22% просмотров. Падение его конверсии с 7,6% до 4,9% даёт вклад в общую метрику:

$$\Delta_{\text{total}} \approx w_{web} \cdot (cr_{after} - cr_{before}) = 0{,}22 \cdot (0{,}049 - 0{,}076) = -0{,}0059$$

Это −0,59 п.п. при базе 8,3% — то есть примерно −7% из −12%. Значит web объясняет большую часть, но не всё: остаток −5% нужно добить (возможно, лёгкий mix shift на мобильных). Хороший аналитик замечает этот зазор сам, а не рапортует «нашёл причину», закрыв 60% дельты.

Как подать это на собеседовании

Кейс проверяют не по «угадал причину», а по структуре мышления под неопределённостью. Что сработает вслух:

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

Больше формулировок реальных кейс-вопросов и разборов ответов — в базе /interviews и на странице подготовки /sobesedovanie-analitika-dannyh. Если SQL пока хромает — бесплатный /course даёт базу JOIN, GROUP BY и оконных функций, без которых декомпозицию воронки не написать.

Частые вопросы

Что отвечать, если данных для проверки гипотез нет прямо на собесе?

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

Сколько гипотез называть — чем больше, тем лучше?

Нет. Ценится не количество, а структура и приоритет. Лучше 3-4 гипотезы, привязанные к найденному сегменту и отсортированные по стоимости проверки, чем 15 версий веером. Сначала фреймворк (mix shift vs деградация), потом сегментация, потом точечные гипотезы под конкретный провал. Хаотичный перебор читается как отсутствие системы.

С чего начинать — с данных или с фреймворка?

С уточнения метрики, затем фреймворк, и только потом данные. Частая ошибка — сразу «пойду посмотрю дашборд». Сначала: как считается метрика, относительно чего −12%, резко или плавно. Потом декомпозиция на множители. И лишь затем SQL. Порядок «уточнил → разложил → сегментировал → проверил → собрал вывод» — то, что оценивают по матрице компетенций.

Чем кейс отличается от тестового задания?

Кейс-интервью — устный разбор в реальном времени, где смотрят на ход мысли и умение рассуждать под стрессом; данных может не быть вовсе. Тестовое задание — домашняя работа с настоящим датасетом (как у Ozon: CSV с date / platform / action / count / uniq, посчитать CTR полок и метрики на пользователя), где важен чистый код и корректные цифры. К первому готовятся проговариванием фреймворков, ко второму — практикой на /tasks и /python-sandbox.

Разбирай реальные кейсы
618 продуктовых кейсов и 545 SQL-задач с автопроверкой. Первые — без регистрации.
Разобрать кейсы в тренажёре →

Похожие статьи