Собеседование на продуктового аналитика: 40 вопросов

Чем занимается продуктовый аналитик

Продуктовый аналитик помогает команде принимать решения на основе данных. Он отвечает на вопрос «что происходит с продуктом и почему» — считает метрики, анализирует поведение пользователей, проектирует и оценивает эксперименты, ищет точки роста.

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

Дата-аналитик (аналитик данных) — более широкое понятие. Продуктовый аналитик — это специализация дата-аналитика с фокусом на продуктовых метриках, воронках, retention и экспериментах. Дата-аналитик может работать в финансах, логистике, маркетинге — где угодно. Продуктовый аналитик всегда работает внутри продуктовой команды.

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

Этапы собеседования

Типичный процесс найма продуктового аналитика состоит из четырёх-пяти этапов. Формат может отличаться в зависимости от компании, но структура почти всегда одна.

1. HR-скрининг

Звонок на 15–20 минут. Рекрутер уточняет ваш опыт, мотивацию, зарплатные ожидания и понимание роли. Здесь важно показать, что вы понимаете разницу между продуктовой аналитикой и другими направлениями. Подготовьте краткий рассказ о себе с акцентом на опыт работы с продуктовыми метриками и экспериментами.

2. SQL-интервью

Техническое собеседование на 60–90 минут. Вам дают задачи, которые нужно решить в реальном времени — на общем экране или в онлайн-редакторе.

Для продуктового аналитика SQL-задачи почти всегда привязаны к продуктовому контексту. Вас не попросят написать абстрактный JOIN — попросят посчитать retention по когортам, построить воронку конверсии или найти аномалию в данных. Подробнее о подготовке к SQL-этапу — в разделе SQL.

3. Продуктовый кейс

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

4. Эксперименты и статистика

Отдельный этап или часть продуктового кейса. Проверяют знание A/B-тестов: как спланировать эксперимент, выбрать метрику, рассчитать размер выборки, интерпретировать результат. Могут спросить про статистические ошибки первого и второго рода, множественное тестирование, сетевые эффекты.

5. Финальное интервью

Встреча с нанимающим менеджером или руководителем аналитики. Обсуждают ваш опыт, подход к задачам, совместимость с командой. Здесь уже не столько проверяют знания, сколько оценивают, как вы думаете и коммуницируете.

SQL-вопросы для продуктового аналитика

SQL на собеседовании продуктового аналитика отличается от общего SQL-интервью. Задачи привязаны к типичным продуктовым задачам: считайте retention, стройте когорты, анализируйте воронку.

Retention по когортам

Классическая задача: посчитать D1, D7, D30 retention по когортам регистрации.

WITH cohort AS (
    SELECT
        user_id,
        DATE_TRUNC('week', MIN(created_at)) AS cohort_week
    FROM users
    GROUP BY user_id
),
activity AS (
    SELECT DISTINCT user_id, event_date
    FROM events
)
SELECT
    c.cohort_week,
    COUNT(DISTINCT c.user_id) AS cohort_size,
    COUNT(DISTINCT CASE
        WHEN a.event_date = c.cohort_week::DATE + 1 THEN a.user_id
    END) AS d1,
    COUNT(DISTINCT CASE
        WHEN a.event_date = c.cohort_week::DATE + 7 THEN a.user_id
    END) AS d7
FROM cohort c
LEFT JOIN activity a ON c.user_id = a.user_id
GROUP BY c.cohort_week
ORDER BY c.cohort_week

На собеседовании обязательно уточните: что считаем «активностью», в каком часовом поясе работаем, нужен классический retention (ровно на N-й день) или rolling (на N-й день или позже). Подробный разбор — в статье про retention.

Конверсия воронки

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

SELECT
    COUNT(DISTINCT user_id) AS registered,
    COUNT(DISTINCT CASE WHEN activated THEN user_id END) AS activated,
    COUNT(DISTINCT CASE WHEN first_purchase_at IS NOT NULL THEN user_id END) AS purchased,
    COUNT(DISTINCT CASE WHEN purchase_count >= 2 THEN user_id END) AS repeat_purchased
FROM user_summary

Здесь важно не просто написать запрос, а обсудить — какие шаги воронки выбрать, что считать «активацией», как обрабатывать пользователей, которые прошли шаги не по порядку.

Скользящие средние и аномалии

«Посчитайте 7-дневное скользящее среднее DAU и найдите дни, когда DAU отклонялось от скользящего среднего больше чем на 20%». Такие задачи проверяют владение оконными функциями и умение формализовать бизнес-вопрос в SQL.

Продуктовые кейсы

Кейс-интервью — то, что отличает собеседование продуктового аналитика от собеседования дата-аналитика. Здесь проверяют не технику, а продуктовое мышление: умение структурировать задачу, выбирать метрики, строить гипотезы.

Кейс 1: метрика упала

«Конверсия из регистрации в первую сессию обучения упала на 15% за последнюю неделю. Как будете разбираться?»

Подход:

1. Уточните контекст. Это абсолютное или относительное падение? Были ли изменения в продукте или трафике? Это все пользователи или определённый сегмент?
2. Декомпозируйте метрику. Разбейте по платформам (iOS/Android/Web), по источникам трафика, по регионам, по дням. Ищите, где именно произошло падение.
3. Проверьте технические причины. Баг в трекинге, проблема с загрузкой, ошибка в данных — прежде чем строить продуктовые гипотезы, убедитесь, что данные корректны.
4. Сформулируйте гипотезы. Изменился состав трафика (пришли менее мотивированные пользователи), сломался UX на конкретном экране, конкурент запустил акцию — и так далее.
5. Предложите анализ. Какие данные посмотрите, какие запросы напишете, какие дашборды проверите.

Кейс 2: спроектировать эксперимент

«Мы хотим изменить онбординг — сократить количество шагов с семи до трёх. Как проверить, что это улучшение?»

Подход:

1. Определите метрику успеха. Не «конверсия онбординга», а что-то более глубокое — например, retention на D7 или доля пользователей, совершивших целевое действие в первые 24 часа.
2. Выберите единицу рандомизации. Обычно — пользователь. Объясните, почему не сессия.
3. Обсудите размер выборки и длительность. Как рассчитаете MDE, сколько нужно ждать, чтобы увидеть эффект на retention.
4. Назовите риски. Novelty effect: новый онбординг может сработать лучше просто потому, что он новый. Эффект самоотбора: сокращённый онбординг может привлечь менее мотивированных пользователей.

Подробнее про проектирование экспериментов — в разделе A/B-тестирования.

Кейс 3: выбрать North Star метрику

«Вы — аналитик в сервисе подписки на обучающий контент. Какую North Star метрику вы бы предложили?»

Здесь нужно показать, что вы понимаете — North Star должна отражать ценность для пользователя, а не просто бизнес-результат. Weekly Active Learners (пользователи, прошедшие хотя бы один урок за неделю) лучше, чем «количество подписчиков», потому что подписчик может платить и не пользоваться — это не ценность, а отложенный churn.

Фреймворк метрик: AARRR

Для структурирования ответов на кейсы полезно держать в голове фреймворк Pirate Metrics (AARRR):

• Acquisition (привлечение) — откуда приходят пользователи, сколько стоит привлечение, CAC по каналам.
• Activation (активация) — доля пользователей, которые дошли до «aha-момента». Для каждого продукта это своё: первый заказ, первое сообщение, первая решённая задача.
• Retention (удержание) — возвращаются ли пользователи. D1, D7, D30, когортный анализ.
• Revenue (доход) — ARPU, ARPPU, LTV, конверсия в платящих.
• Referral (виральность) — приводят ли пользователи других. Виральный коэффициент, k-factor.

На кейс-интервью этот фреймворк помогает не забыть ни один слой метрик. Если вас просят «построить систему метрик для продукта X», пройдитесь по AARRR — это покажет системность мышления.

Для более глубокого понимания продуктовых метрик — воронки, unit-экономика, LTV/CAC — полезно проработать эту тему отдельно.

Частые ошибки на собеседовании

Отвечать метриками без контекста

«Нужно смотреть на DAU, WAU, MAU, retention, конверсию, ARPU...» — это не ответ. Перечисление метрик без объяснения, зачем каждая нужна и как она связана с бизнес-задачей, не показывает продуктовое мышление. Лучше назвать три метрики и объяснить логику их выбора, чем десять без объяснений.

Не уточнять условия задачи

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

Забывать про техническую валидацию

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

Не связывать эксперимент с метрикой

«Давайте проведём A/B-тест» — и всё. А какую метрику меряем? Какой минимальный эффект хотим обнаружить? Сколько нужно ждать? Что будем делать с пограничным результатом? Без ответов на эти вопросы предложение провести тест бессмысленно.

Игнорировать сегменты

«Retention вырос» — но у кого? У новых пользователей или у старых? У пользователей из органики или из рекламы? Продуктовый аналитик всегда думает сегментами. Средние показатели скрывают разнонаправленные тренды — это один из ключевых навыков, который проверяют на собеседовании.

Как готовиться

SQL. Решайте задачи с продуктовым контекстом: retention, когорты, воронки, оконные функции. Абстрактные задачи на JOIN полезны для разминки, но на собеседовании продуктового аналитика ждут именно продуктовые запросы. Раздел — SQL для собеседований.

Метрики. Разберите AARRR, научитесь декомпозировать любую метрику. Для каждого типа продукта (e-commerce, подписка, marketplace, social) метрики свои — поймите, чем они отличаются. Раздел — продуктовая аналитика.

Эксперименты. Поймите, как работает A/B-тест от начала до конца: дизайн, рандомизация, выбор метрики, расчёт размера выборки, интерпретация результатов, типичные ловушки (peeking, множественные сравнения, novelty effect). Раздел — A/B-тестирование.

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

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

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

Метрики и продуктовое мышление

Q: Что такое North Star метрика? Приведите пример. Единственная метрика, которая лучше всего отражает ценность продукта для пользователя. Для Spotify — время прослушивания, для Airbnb — количество забронированных ночей, для мессенджера — количество отправленных сообщений.

Q: Как декомпозировать DAU? DAU = новые пользователи + вернувшиеся + «воскресшие» (те, кто вернулся после длительного отсутствия). Такая декомпозиция помогает понять, откуда берётся рост или падение. Подробнее: метрики продукта.

Q: Чем отличается Retention rate от Churn rate? Retention = доля пользователей, оставшихся активными через N дней. Churn = доля ушедших. Churn = 1 - Retention. Для подписочных продуктов чаще используют Churn, для бесплатных — Retention.

Q: Что такое activation rate и как его считать? Доля новых пользователей, которые совершили «aha-момент» — ключевое действие, после которого вероятность возврата резко растёт. Для Slack — отправка 2000 сообщений в команде, для Dropbox — загрузка первого файла.

Q: Как вы бы измерили успех нового онбординга? Основная метрика: activation rate (процент пользователей, дошедших до ключевого действия). Вторичные: время до activation, drop-off по шагам онбординга, D1/D7 retention новых пользователей. Сравнение — A/B-тест нового онбординга vs старого.

Q: Что такое unit-экономика и какие метрики в неё входят? Экономика на одного клиента: LTV (доход за всё время), CAC (стоимость привлечения), Payback Period (срок окупаемости). LTV/CAC > 3 — здоровый бизнес. Подробнее: unit-экономика.

Q: Какие метрики вы бы выбрали для маркетплейса доставки еды? GMV, количество заказов, средний чек, конверсия (открыл приложение → оформил заказ), время доставки, retention D1/D7/D30, NPS. Ключевая — GMV, но следить за retention обязательно.

Q: Что такое AARRR и как его применять? Pirate Metrics: Acquisition → Activation → Retention → Revenue → Referral. Каждый этап — своя метрика и свои рычаги. Используется для структурирования анализа и поиска bottleneck в продукте.

Q: Как посчитать LTV для подписочного продукта? LTV = ARPU × средний срок жизни клиента. Или LTV = ARPU / Churn Rate (для стабильного churn). Для точного расчёта — когортный анализ с кумулятивным revenue.

Q: Метрика retention выросла — это всегда хорошо? Не обязательно. Если retention вырос за счёт уменьшения новых пользователей (только «костяк» остался), это не рост. Всегда смотрите retention в связке с размером когорты и абсолютным числом активных пользователей.

SQL с продуктовым контекстом

Q: Напишите запрос для расчёта D1, D7, D30 retention по недельным когортам. Стандартная задача: находим дату первого визита каждого пользователя (когорта), затем LEFT JOIN с активностью на N-й день, считаем DISTINCT пользователей. Подробнее: как считать retention.

Q: Как построить воронку конверсии в SQL? COUNT DISTINCT user_id с FILTER по каждому шагу. Для строгой последовательности — оконные функции (LEAD/LAG) для проверки порядка событий. Подробнее: 50 SQL-задач.

Q: Как посчитать скользящее среднее за 7 дней? AVG(metric) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW). Важно: ROWS, не RANGE. Подробнее: оконные функции SQL.

Q: Как найти пользователей, которые были активны 3 дня подряд? Self-join: JOIN user_activity на user_id с условием date = date + 1 и date = date + 2. Или через LAG/LEAD: проверить, что предыдущий и следующий дни совпадают.

Q: Как разбить пользователей на сегменты по активности? CTE с подсчётом действий за период, затем CASE WHEN: heavy (10+), medium (4-9), light (1-3), inactive (0). Важно: LEFT JOIN с таблицей пользователей, чтобы не потерять inactive.

A/B-тестирование и статистика

Q: Как определить размер выборки для A/B-теста? Зависит от четырёх параметров: текущая конверсия, MDE (минимальный детектируемый эффект), alpha (обычно 0.05), power (обычно 0.80). Чем меньше ожидаемый эффект, тем больше нужна выборка. Подробнее: A/B-тестирование.

Q: Что такое p-value простыми словами? Вероятность увидеть такую же или бо́льшую разницу между группами, если на самом деле разницы нет. P-value < 0.05 — обычно считаем разницу значимой. Подробнее: p-value.

Q: Что делать, если p-value = 0.06? Нельзя просто округлить до «значимо». Варианты: продолжить тест (набрать больше данных), посмотреть на размер эффекта и бизнес-значимость, проверить подсегменты.

Q: Можно ли подглядывать в результаты теста до окончания? Нет. Каждая проверка увеличивает вероятность ложноположительного результата. Если нужна промежуточная проверка — используйте sequential testing с коррекцией alpha.

Q: Что такое CUPED и зачем он нужен? Метод снижения дисперсии за счёт данных пре-периода. Повышает чувствительность A/B-теста на 30-50%, что позволяет детектировать меньшие эффекты или быстрее завершать тест. Подробнее: CUPED.

Q: Как тестировать изменение, которое влияет на долгосрочную метрику (LTV)? Нельзя ждать год. Используйте proxy-метрику (D7 retention как предиктор LTV), или проведите краткосрочный тест и экстраполируйте через модель.

Q: Что такое ошибки I и II рода? I рода (false positive): решили, что эффект есть, а его нет. II рода (false negative): пропустили реальный эффект. Alpha контролирует I рода, power = 1 - P(II рода).

Q: Когда A/B-тест неприменим? Когда невозможна рандомизация (ценообразование для всех), когда эффект сетевой (социальные фичи), когда выборка слишком мала. Альтернативы: diff-in-diff, causal impact, pre-post анализ.

Кейсы

Q: DAU упал на 15% за неделю. Ваши действия?

1. Декомпозировать: новые vs вернувшиеся. 2) Проверить по срезам: платформа, гео, источник. 3) Внешние факторы: сбои, релизы, сезонность. 4) Сузить до корневой причины. 5) Предложить действия. Подробнее: кейс «метрика упала».

Q: Как бы вы спроектировали систему метрик для нового приложения такси? North Star: количество завершённых поездок. Воронка: открыл приложение → ввёл адрес → вызвал → водитель принял → поездка завершена. Ключевые: ETA accuracy, cancel rate, surge pricing frequency, NPS. По AARRR — метрика на каждый этап.

Q: Конверсия в покупку выросла, а revenue упал. Почему? Больше мелких покупок, меньше крупных. Проверить: распределение чеков, средний чек по группам, изменился ли ассортимент/промо. Возможно, скидочная акция привлекла low-value покупателей.

Q: Как оценить, стоит ли добавлять новую фичу? Сформулировать гипотезу (какую метрику улучшит и на сколько), оценить стоимость разработки, прикинуть потенциальный uplift через данные (есть ли корреляция поведения с целевой метрикой), запустить MVP или A/B-тест.

Q: Как бы вы выбирали, какой из трёх вариантов онбординга лучше? Не A/B/C-тест (нужна коррекция на множественные сравнения). Лучше: 1) определить ключевую метрику (activation rate), 2) рассчитать выборку с поправкой Бонферрони, 3) запустить тест на все три группы одновременно, 4) сравнить каждый вариант с контролем.

Q: Пользователи жалуются на долгую загрузку, но метрики не показывают проблему. Что делать? Среднее время загрузки может скрывать хвост распределения. Смотреть P95/P99 вместо среднего. Проверить по сегментам: может проблема только у мобильных или у пользователей из определённого региона.

Soft skills

Q: Как вы выбираете, за что браться в первую очередь, если запросов больше, чем времени? Оцениваю по двум осям: impact (влияние на бизнес-метрику) и effort (время на анализ). Начинаю с high-impact / low-effort. Для длинных запросов — договариваюсь о сроках и промежуточных результатах.

Q: Как вы объясняете технический результат нетехнической аудитории? Без жаргона, через аналогии и визуализации. «P-value < 0.05» → «Мы на 95% уверены, что изменение реальное, а не шум». Графики вместо таблиц, выводы вместо методологии.

Q: Расскажите о ситуации, когда данные противоречили интуиции команды. Стандартный behavioral вопрос. Описать ситуацию, данные, реакцию команды, как вы аргументировали позицию, какой был результат. Ключевое — показать, что вы умеете отстаивать данные, но с уважением к мнению коллег.

Читайте также

• SQL-тренажёр: 200+ задач
• 50 SQL-задач для собеседования
• 30 вопросов по A/B-тестам
• Тестовое задание аналитика: 10 примеров
• 3 типа аналитиков: отличия

FAQ

Чем продуктовый аналитик отличается от аналитика данных?

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

Какие вопросы задают на собеседовании продуктового аналитика?

Три основных блока: SQL с продуктовым контекстом (retention по когортам, воронки конверсии), продуктовые кейсы («метрика упала — разберитесь», «спроектируйте эксперимент»), статистика и A/B-тестирование (дизайн эксперимента, интерпретация результатов).

Что такое AARRR фреймворк и зачем его знать?

AARRR (Pirate Metrics) — фреймворк из пяти этапов: Acquisition, Activation, Retention, Revenue, Referral. Он помогает структурировать ответы на кейсы и не забыть ни один слой метрик при построении системы аналитики для продукта.

Какая самая частая ошибка на собеседовании продуктового аналитика?

Перечисление метрик без контекста и объяснения. «Нужно смотреть DAU, MAU, retention, ARPU...» — это не ответ. Лучше назвать три метрики и объяснить логику их выбора, чем десять без обоснования. Интервьюер оценивает продуктовое мышление, а не объём словарного запаса.