Продуктовый аналитик: кто это и чем занимается на примере недели

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

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

Отчёт заканчивается числом: «конверсия 30,3%». Работа аналитика заканчивается действием: «включаем чек-лист на десктопе, мобильную версию переделываем». Проверка простая — изменилось ли что-нибудь в планах команды после вашего ответа. Если нет, получилась справка.

Неделя ниже собрана на учебной базе симулятора SQL-аналитика. Это подписочный сервис «Маяк»: 4 613 регистраций с 1 июня по 29 августа 2026 года, события в продукте, оплаты и один эксперимент; выгрузка закрыта 30 августа в 13:00. Дни недели здесь — рамка для пяти типовых вопросов. В живой команде они приходят вперемешку, а часть времени уходит на встречи и починку данных.

Понедельник: сколько у нас активных и растём ли мы?

На планёрке менеджер продукта просит одну цифру об аудитории. До запроса нужны два определения. Активный — тот, кто хотя бы раз за период открыл приложение (событие app_open). Период — календарная неделя с понедельника: WAU считает разных людей за неделю, DAU — за день. Открытие приложения — слабое определение: для решений о продукте точнее считать тех, кто сделал ключевое действие. Здесь его хватает, потому что вопрос — о размере аудитории.

За последнюю полную неделю, 17–23 августа, WAU равен 2 045 — на 4,1% больше, чем неделей раньше (1 964). Предыдущий шаг был +6,4%. Ответ на вопрос «растём ли» — да, на 4–6% в неделю.

Ловушка сидит в последней строке. Средний DAU за 24–30 августа — 481,9 против 484,6 неделей раньше: рост будто остановился. Но события за 30 августа обрываются в 12:59, и за этот день посчитан 221 человек, тогда как в прошлое воскресенье было 475. Если сравнить одинаковые дни, с понедельника по субботу, выйдет 525,3 против 486,2 — плюс 8%; неделей раньше этот же показатель рос на 4,9%. WAU за те же шесть дней — 2 037 против 1 884, тоже +8%. Последняя неделя идёт быстрее прежних. Полный WAU этой недели, 2 118, занижен: в нём нет второй половины воскресенья.

Решение: в отчёт идёт неделя 17–23 августа, текущая показывается по шести дням или не показывается вовсе. На дашборде рядом с графиком нужна дата, по которую загружены данные.

WITH daily AS (
  SELECT CAST(event_time AS DATE) AS day,
         COUNT(DISTINCT user_id) AS dau
  FROM events
  WHERE event_name = 'app_open'
    AND event_time >= TIMESTAMP '2026-08-03'
  GROUP BY CAST(event_time AS DATE)
),
weekly AS (
  SELECT CAST(date_trunc('week', event_time) AS DATE) AS week_start,
         COUNT(DISTINCT user_id) AS wau
  FROM events
  WHERE event_name = 'app_open'
    AND event_time >= TIMESTAMP '2026-08-03'
  GROUP BY CAST(date_trunc('week', event_time) AS DATE)
)
SELECT w.week_start,
       w.wau,
       ROUND(AVG(d.dau), 1) AS dau_7_days,
       ROUND(AVG(CASE WHEN EXTRACT(isodow FROM d.day) <= 6
                      THEN d.dau END), 1) AS dau_mon_sat
FROM weekly w
JOIN daily d
  ON d.day >= w.week_start
 AND d.day < w.week_start + 7
GROUP BY w.week_start, w.wau
ORDER BY w.week_start;

Вторник: где мы теряем новых пользователей?

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

Из 4 613 зарегистрированных рабочее пространство создали 2 750, отчёт — 1 775. До первого действия не доходят четверо из десяти, и это самая большая потеря на пути.

Если продолжить воронку ещё двумя ступенями, получится приглашение — 1 135, экспорт — 988 и «конверсия из отчёта в приглашение» 63,9%. Это ловушка: последние два действия путь не продолжают. 456 человек отправили приглашение, не создав рабочего пространства, 331 сделал экспорт без единого отчёта. Среди создавших отчёт приглашение отправили 437 человек, 24,6% — столько же, сколько среди всех зарегистрированных (1 135 из 4 613). Все пять действий есть у 166 человек.

Вторая оговорка — возраст регистраций. В учебной базе приглашение отправляют на следующий день после регистрации, экспорт — через два дня. У 88 человек, пришедших 28 августа, день экспорта — 30 августа — записан только до 12:59, у 38 пришедших 29 августа его нет вовсе; без этих 126 человек доля сделавших экспорт — 22,0% вместо 21,4%. У тех же 38 обрезан и день приглашения, но на долю это почти не влияет: 24,7% вместо 24,6%.

Решение: разбираться начинаем с первого шага, но переделывать экран рано. Тот же запрос с разбивкой по каналу показывает: в рекомендациях пространство создают 74,73% пришедших, в платном поиске — 37,04%, хотя экран у всех один. Сначала смотрим, кого приводит платный поиск и не теряется ли событие, и только потом зовём дизайнера. Приглашение и экспорт вести отдельными метриками. И вопрос к разработке и продукту: событие invite_sent записывается там, где мы думаем, и что отправляют коллегам 456 человек без рабочего пространства? Сами цепочки действий разобраны в статье про STRING_AGG и путь пользователя.

WITH steps AS (
  SELECT u.user_id,
         MAX(CASE WHEN e.event_name = 'workspace_created' THEN 1 ELSE 0 END) AS workspace,
         MAX(CASE WHEN e.event_name = 'report_created' THEN 1 ELSE 0 END) AS report,
         MAX(CASE WHEN e.event_name = 'invite_sent' THEN 1 ELSE 0 END) AS invite,
         MAX(CASE WHEN e.event_name = 'export_completed' THEN 1 ELSE 0 END) AS exported
  FROM users u
  LEFT JOIN events e ON e.user_id = u.user_id
  GROUP BY u.user_id
)
SELECT COUNT(*) AS signups,
       SUM(workspace) AS workspace,
       SUM(report) AS report,
       SUM(invite) AS invite,
       SUM(exported) AS exported,
       SUM(report * invite) AS report_and_invite,
       SUM(report * invite * exported) AS all_steps,
       SUM(invite * (1 - workspace)) AS invite_no_workspace,
       SUM(exported * (1 - report)) AS export_no_report
FROM steps;

-- 4613 | 2750 | 1775 | 1135 | 988 | 437 | 166 | 456 | 331

Среда: какой канал приводит платящих пользователей?

Маркетинг готовит бюджет и спрашивает, откуда приходят те, кто платит. Метрика — доля зарегистрированных, сделавших первую оплату.

По всем регистрациям платный поиск (paid_search) выглядит совсем слабым: первую оплату сделали 8,47% пришедших. Сравнивать это число с другими каналами нельзя по двум причинам. Платный поиск запущен 1 июля, остальные каналы работают с 1 июня. А первая оплата в этой базе приходит через 3–20 дней после регистрации, и пришедшие после 9 августа оплатить успели не все. В платном поиске таких 38,8%, в органике — 28,0%.

На общем окне — регистрации с 1 июля по 9 августа — у платного поиска 10,79% вместо 8,47%. У рекомендаций (referral) 31,40%, у органики (organic) 25,51%, у партнёров (partner) 21,27%. Платный поиск отстаёт от рекомендаций в 2,9 раза. Окно — часть определения метрики: с другим окном получатся другие доли.

Насколько разница надёжна, показывают 95%-е доверительные интервалы. У платного поиска — от 8,35% до 13,23%, у ближайшего к нему партнёрского канала — от 16,75% до 25,79%; разница между ними 10,48 процентного пункта (п. п.), интервал от 5,34 до 15,62. А вот партнёров и органику эти данные не различают: 4,24 п. п. при интервале от −1,21 до +9,70. Расставлять их по местам рано.

Решение о бюджете отложить: без расходов по каналам нельзя ни добавлять, ни резать. В базе нет расходов, а значит, и стоимости платящего пользователя. Следующий запрос — к маркетингу, за расходами по каналам. Как из них собрать окупаемость, показано в статье про LTV/CAC по каналам.

WITH c AS (
  SELECT u.channel,
         COUNT(*) AS signups,
         COUNT(p.user_id) AS payers,
         1.0 * COUNT(p.user_id) / COUNT(*) AS share
  FROM users u
  LEFT JOIN payments p
    ON p.user_id = u.user_id
   AND p.payment_type = 'first'
  WHERE u.signup_date >= DATE '2026-07-01'
    AND u.signup_date < DATE '2026-08-10'
  GROUP BY u.channel
)
SELECT channel, signups, payers,
       ROUND(CAST(100 * share AS numeric(18, 6)), 2) AS paid_pct,
       ROUND(CAST(100 * (share - 1.96 * SQRT(share * (1 - share) / signups))
                  AS numeric(18, 6)), 2) AS ci_low,
       ROUND(CAST(100 * (share + 1.96 * SQRT(share * (1 - share) / signups))
                  AS numeric(18, 6)), 2) AS ci_high
FROM c
ORDER BY paid_pct DESC;

-- referral    | 449 | 141 | 31.40 | 27.11 | 35.70
-- organic     | 780 | 199 | 25.51 | 22.45 | 28.57
-- partner     | 315 |  67 | 21.27 | 16.75 | 25.79
-- paid_search | 621 |  67 | 10.79 |  8.35 | 13.23

Четверг: сработал ли чек-лист в онбординге?

В продукте уже идёт эксперимент onboarding_checklist: части новых пользователей на первом экране показывают чек-лист. В тест попали 3 068 из 4 613 зарегистрированных: 1 527 в контроле и 1 541 с чек-листом. Метрика — флаг converted: целевое действие, записанное в таблице эксперимента; с событиями воронки он не совпадает.

Общий результат: 20,04% в контроле и 30,30% с чек-листом, разница +10,27 п. п., 95%-й интервал от +7,22 до +13,31. На этом месте легко остановиться и написать «включаем всем».

Ловушка — в среднем: у двух половин участников эффект разный. На десктопе разница +19,75 п. п. (от +15,37 до +24,13), на мобильных −0,16 п. п. (от −4,25 до +3,92). Мобильных в тесте 48,0%, в обеих группах примерно поровну, поэтому среднее оказалось посередине.

Доверять срезу можно осторожно. Устройство известно до показа и от варианта не зависит. Разница эффектов — 19,9 п. п. с интервалом от 13,9 до 25,9. Третье условие — гипотеза о срезе записана до теста — по данным проверить нельзя: в рабочем эксперименте её фиксируют заранее, иначе срез остаётся находкой для следующего теста.

Команде стоит сказать так: чек-лист работает на десктопе, включаем его там; на мобильных эффекта не видно, эту версию нужно переделать и проверить отдельно. Вопрос вторника тест не закрывает: рабочее пространство создали 60,55% участников с чек-листом и 58,15% в контроле, интервал разницы — от −1,08 до +5,87 п. п. Проверку деления на группы и цену подглядывания в результаты до конца теста разбирает полный расчёт этого теста в SQL.

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

WITH x AS (
  SELECT u.device,
         e.variant,
         CASE WHEN e.converted THEN 1 ELSE 0 END AS conv
  FROM experiment_exposures e
  JOIN users u ON u.user_id = e.user_id
  WHERE e.experiment_name = 'onboarding_checklist'
),
seg AS (
  SELECT 'all' AS segment, variant, conv FROM x
  UNION ALL
  SELECT device, variant, conv FROM x
)
SELECT segment,
       SUM(CASE WHEN variant = 'control' THEN 1 ELSE 0 END) AS n_control,
       SUM(CASE WHEN variant = 'control' THEN conv ELSE 0 END) AS x_control,
       SUM(CASE WHEN variant = 'checklist' THEN 1 ELSE 0 END) AS n_checklist,
       SUM(CASE WHEN variant = 'checklist' THEN conv ELSE 0 END) AS x_checklist
FROM seg
GROUP BY segment
ORDER BY segment;

-- all     | 1527 | 306 | 1541 | 467
-- desktop |  789 | 158 |  807 | 321
-- mobile  |  738 | 148 |  734 | 146

import numpy as np
import pandas as pd
from scipy.stats import norm

# строки из запроса выше: участники и конверсии в контроле и с чек-листом
ab = pd.DataFrame(
    {'n_c': [1527, 789, 738], 'x_c': [306, 158, 148],
     'n_t': [1541, 807, 734], 'x_t': [467, 321, 146]},
    index=['all', 'desktop', 'mobile'],
)

p_c, p_t = ab.x_c / ab.n_c, ab.x_t / ab.n_t
diff = p_t - p_c
se = np.sqrt(p_c * (1 - p_c) / ab.n_c + p_t * (1 - p_t) / ab.n_t)
z = norm.ppf(0.975)  # 1.96 для 95%-го интервала

out = pd.DataFrame({
    'control_pct': 100 * p_c,
    'checklist_pct': 100 * p_t,
    'diff_pp': 100 * diff,
    'ci_low': 100 * (diff - z * se),
    'ci_high': 100 * (diff + z * se),
}).round(2)
print(out)

#          control_pct  checklist_pct  diff_pp  ci_low  ci_high
# all            20.04          30.30    10.27    7.22    13.31
# desktop        20.03          39.78    19.75   15.37    24.13
# mobile         20.05          19.89    -0.16   -4.25     3.92

Пятница: как написать записку менеджеру?

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

Перед отправкой стоит перевести процентные пункты в людей. За последнюю полную неделю с десктопа зарегистрировались 230 человек; в тест попали 148 из них, и 74 уже видят чек-лист. Если показать его всем 230 и считать, что остальные ведут себя как участники теста, выйдет около 45 дополнительных целевых действий в неделю по сравнению с неделей без чек-листа: 230 × 19,75%, по границам интервала — от 35 до 55. Если охват останется как в тесте — около 29, от 23 до 36. Интервал учитывает только неопределённость эффекта; изменится поток регистраций — изменится и число.

Три проверки перед отправкой: каждое число пересчитывается запросом из приложения; определения те же, что в прошлых отчётах; оговорка стоит рядом с числом, к которому относится. Сама записка по четвергу — шесть строк под запросом.

SELECT u.device,
       COUNT(*) AS signups,
       COUNT(e.user_id) AS in_test,
       SUM(CASE WHEN e.variant = 'checklist' THEN 1 ELSE 0 END) AS with_checklist
FROM users u
LEFT JOIN experiment_exposures e
  ON e.user_id = u.user_id
 AND e.experiment_name = 'onboarding_checklist'
WHERE u.signup_date >= DATE '2026-08-17'
  AND u.signup_date < DATE '2026-08-24'
GROUP BY u.device
ORDER BY u.device;

-- desktop | 230 | 148 | 74
-- mobile  | 251 | 167 | 81

• Вопрос: включать ли чек-лист онбординга всем новым пользователям.
• Ответ: включить на десктопе, на мобильных оставить текущий экран.
• Число: на десктопе целевое действие совершили 321 из 807 с чек-листом (39,78%) против 158 из 789 без него (20,03%): +19,75 п. п., 95%-й интервал от +15,37 до +24,13. Общие +10,27 п. п. — среднее с мобильными, на всех его не переносим.
• Масштаб: от 29 до 45 дополнительных целевых действий в неделю в зависимости от охвата — в тест попали 148 из 230 десктопных регистраций.
• Оговорка: на мобильных разница −0,16 п. п. при интервале от −4,25 до +3,92 — пользы не видно, небольшой вред не исключён.
• Дальше: переделать мобильный чек-лист и проверить его отдельным тестом; на десктопе на две недели оставить 10% новых пользователей без чек-листа, чтобы сверить эффект.

Какие навыки и инструменты нужны для такой недели?

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

Инструменты следуют из задач. SQL — к хранилищу данных. BI-система — для регулярных графиков, чтобы не отвечать на один вопрос дважды. Python с pandas — там, где нужен ноутбук: интервалы, симуляции, графики под конкретный вопрос. Плюс система экспериментов и трекер задач, где вопрос записан словами заказчика.

Работает аналитик с теми, кто принимает решения, и с теми, кто создаёт данные. Менеджер продукта приносит вопросы и забирает рекомендации. Дизайнер и разработчики меняют продукт и размечают события. Маркетинг отвечает за каналы, дата-инженеры — за то, чтобы таблицы обновлялись вовремя.

Где граница с аналитиком данных, BI- и маркетинговым аналитиком?

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

Десять ролей, включая системного и бизнес-аналитика, сравнивает карта аналитических ролей. Работу BI-аналитика на таком же недельном примере показывает статья о BI-аналитике.

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

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

• Активность: DAU, WAU и MAU и доля DAU в MAU — сколько людей пользуются продуктом и как часто.
• Активация: activation rate — доля новых пользователей, дошедших до первой ценности.
• Конверсия: формула и знаменатель, воронка по шагам.
• Удержание: retention D1, D7 и D30 и когортный анализ.
• Деньги: ARPU и ARPPU, LTV по когортам.
• Система: North Star и дерево метрик — как связать эти числа между собой.

Как растёт продуктовый аналитик и с чего начать?

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

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

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

Продуктовый аналитик — кто это? Специалист в команде продукта, который отвечает на её вопросы данными и доводит ответ до рекомендации: что включить, что починить, от чего отказаться.

Что должен знать продуктовый аналитик? SQL на уровне соединений, агрегатов и дат; определения продуктовых метрик; основы статистики для A/B-тестов — доли, доверительные интервалы, проверку групп; и как уложить вывод в шесть строк.

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

Нужен ли Python продуктовому аналитику? Для первых задач хватает SQL. Python нужен там, где запрос неудобен: интервал для разницы, симуляция, график. Где проходит граница, показано в статье SQL или Python.

К чему готовиться на стажировке продуктового аналитика? Набор, условия и этапы у каждой программы свои, и актуальны они только на её официальной странице. Готовиться стоит к задачам на SQL и к разбору метрики: что считать, на что делить, какому числу не верить. Подробнее — в статье про стажировку аналитика данных.

Что повторить самому и что читать дальше?

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

Упражнение: повторите среду для устройств. На том же окне, с 1 июля по 9 августа, посчитайте долю сделавших первую оплату для desktop и mobile. Должно получиться 24,30% (269 из 1 107) и 19,38% (205 из 1 058); разница 4,92 п. п. с интервалом от 1,45 до 8,40. Вывод об устройствах делать рано: платный поиск — 19% десктопных регистраций этого окна и 38% мобильных. Если пересчитать обе группы к общему составу каналов, получится 22,96% и 20,91%, разница 2,05 п. п. с интервалом от −1,45 до +5,55. Как делается такой пересчёт, показано в статье про парадокс Симпсона.