коротко

Метрики нужны, чтобы ответить на вопрос «фича работает или нет» цифрами, а не верой. Базовый словарь: DAU/MAU — сколько уникальных людей пользуются продуктом за день/месяц; retention — сколько возвращается; conversion — доля дошедших до цели; churn — доля ушедших; ARPU — средний доход с пользователя; LTV — сколько денег приносит пользователь за всю жизнь. Воронка (funnel) показывает, на каком шаге процесса люди отваливаются. A/B-тест — две версии на случайные группы, сравниваем метрику; «статзначимо» значит «разница не похожа на случайный шум», и для этого нужна достаточная выборка. Отличайте vanity-метрики (красивые, но бесполезные) от actionable. Роль аналитика — выбрать одну главную метрику фичи и заложить сбор событий под неё.

Однажды я гордо выкатил фичу — упрощённую форму регистрации — и на ретро сказал «думаю, стало лучше». Лид спросил: «На сколько процентов выросла доходимость до конца регистрации?» У меня не было ответа. Мы не собирали события по шагам формы, и доказать, что стало лучше, было нечем — только ощущение. С тем же успехом могло стать хуже. Я ушёл с ретро с твёрдым уроком: фича без заложенной метрики — это ставка вслепую, и сделать так, чтобы метрика была, — работа аналитика, причём до релиза, а не после. Чтобы вообще понимать, какие фичи стоит мерить и в каком порядке их катать, полезно держать в голове дискавери против дельки и приоритизацию с MVP — метрики дают ту самую обратную связь, которая замыкает этот цикл.

Зачем аналитику метрики

Простой ответ: чтобы отличать «мне кажется» от «вот цифра». Любое продуктовое решение — это гипотеза: «если упростим регистрацию, людей дойдёт больше». Без метрики гипотеза остаётся верой, и команда спорит мнениями. С метрикой гипотеза проверяема: было 60% доходимости, стало 72% — гипотеза подтвердилась, фичу оставляем; стало 58% — откатываем. Метрики превращают продуктовую работу из угадайки в эксперимент.

Ключевые метрики простыми словами

Минимальный словарь, который надо понимать без запинки. По одной фразе на каждую.

  • DAU / MAU (daily / monthly active users) — сколько уникальных людей зашли в продукт за день / за месяц. Отношение DAU/MAU грубо показывает «прилипчивость»: 0.5 значит, что средний месячный пользователь заходит примерно через день.
  • Retention (удержание) — какая доля пользователей вернулась спустя время (день 1, день 7, день 30). Главная метрика здоровья продукта: набрать людей легко, удержать — трудно.
  • Conversion (конверсия) — доля дошедших до целевого действия. Из зашедших на страницу оплаты — сколько оплатили.
  • Churn (отток) — доля пользователей, переставших пользоваться продуктом за период. Зеркало retention: чем выше churn, тем дырявее ведро.
  • ARPU (average revenue per user) — средний доход на одного пользователя за период. Сколько в среднем приносит человек.
  • LTV (lifetime value) — сколько денег пользователь приносит за всё время жизни в продукте. Если привлечь человека стоит дороже его LTV — бизнес-модель в минусе.

Воронка: где отваливаются люди

Воронка (funnel) — это процесс, разбитый на шаги, с числом людей на каждом. Называется воронкой, потому что с каждым шагом людей становится меньше — сверху широко, снизу узко. Смысл воронки — увидеть конкретный шаг, на котором теряется больше всего, чтобы чинить именно его, а не гадать.

flowchart TD
  A["Открыли каталог — 10000"] -->|"-30%"| B["Положили в корзину — 7000"]
  B -->|"-43%"| C["Перешли к оплате — 4000"]
  C -->|"-75%"| D["Ввели данные карты — 1000"]
  D -->|"-10%"| E["Оплатили — 900"]

На схеме воронка оформления заказа из пяти шагов. Сверху 10 000 человек открыли каталог, до оплаты дошли 900 — итоговая конверсия 9%. Но интереснее не итог, а где именно льётся. Между «открыли каталог» и «положили в корзину» теряется 30% — нормально, не все пришли покупать. Самый страшный обвал — между «перешли к оплате» и «ввели данные карты»: с 4000 до 1000, минус 75%. Вот здесь и надо копать: люди дошли до оплаты, явно хотели купить, и отвалились на вводе карты. Причина обычно конкретная — нет нужного способа оплаты, форма требует регистрации, страшная страница, скрытая комиссия всплыла. Чинить надо этот шаг: он теряет 3000 почти-покупателей, тогда как первый шаг — случайных зевак. Воронка не говорит почему отвалились — она говорит где, а это уже половина дела.

Чините самый узкий, а не самый первый

Инстинкт — оптимизировать вход в воронку («давайте нагоним больше трафика в каталог»). Но если у вас дыра на шаге оплаты, нагнанный трафик утечёт туда же. Правильно — найти шаг с самым большим относительным отвалом среди тех, кто уже проявил намерение, и чинить его. Подтянуть оплату с 25% до 50% доходимости часто дешевле и прибыльнее, чем удвоить трафик на входе.

A/B-тест на пальцах

A/B-тест — способ честно проверить, какая из двух версий лучше. Берём целевую метрику (например, доходимость до оплаты), случайно делим пользователей на две группы: группа A видит старую версию (контроль), группа B — новую. Ждём, собираем метрику в обеих группах и сравниваем. Случайное деление — ключ: оно гарантирует, что группы в среднем одинаковы по всему, кроме версии, и разницу в метрике можно списать именно на изменение.

Самое важное и самое недопонятое — слово статзначимо. Допустим, в группе A конверсия 10%, в группе B — 11%. Лучше? Не факт. Если в каждой группе было по 50 человек, эта разница — почти наверняка случайный шум: подкинь монетку 50 раз дважды, и доли орлов разойдутся сами собой, без всякой причины. «Статистически значимо» означает «разница достаточно велика и на достаточной выборке, чтобы её было трудно объяснить простой случайностью». Без формул держите в голове два правила: чем меньше выборка, тем легче обмануться шумом, и нельзя останавливать тест в момент, когда цифра вам понравилась — это подгонка под желаемое. Размер выборки и срок надо прикинуть заранее.

Маленькая выборка лжёт уверенно

Типичная ошибка джуна: выкатили B на 200 человек, увидели +2% за два дня, побежали раскатывать на всех. А +2% на 200 людях — это шум; на полной аудитории фича легко даёт −1%. Правило: если не можете набрать заметную выборку за разумный срок, A/B-тест вам пока не инструмент — для редких событий он требует слишком много данных. Тогда честнее опереться на воронку и здравый смысл, чем на красивую, но недостоверную цифру.

Когда A/B вообще не подходит

A/B — не универсальный инструмент, и аналитик обязан назвать его границы. Он не работает при низком трафике и долгом цикле: в B2B или на дорогих редких покупках набрать значимую выборку можно за годы, и эксперимент бессмыслен. Он ломается при сетевых эффектах (соцсети, маркетплейсы), где группы A и B влияют друг на друга и перестают быть независимыми. И есть ловушка множественных сравнений: гоняете десять метрик разом — одна «выстрелит» статзначимо просто случайно. Когда A/B неприменим, честнее опереться на воронку, качественные интервью и здравый смысл, чем на красивую, но ложную цифру.

Vanity-метрики против actionable

Метрики тщеславия (vanity metrics) — те, что приятно показать на слайде, но по которым нельзя принять решение. «Всего зарегистрировано 1 000 000 пользователей» — звучит мощно, но это число только растёт и ничего не говорит о том, живой ли продукт. Сколько из этого миллиона заходили на этой неделе? Вот это уже actionable.

Actionable-метрики — те, по которым понятно, что делать. «Retention 7-го дня упал с 40% до 30% после релиза» — это сигнал к действию: что мы сломали в релизе. Проверка простая: если метрика изменилась — вы знаете, какое решение принять? Если да — actionable. Если только «ну, приятно» — vanity.

Что меняется для аналитика

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

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

Как это спрашивают на собесе

Любимый вопрос: «Вы выкатываете новую фичу. Как поймёте, что она удалась?» Слабый ответ — «спросим пользователей» или «посмотрим, выросли ли регистрации». Сильный ответ строится так: (1) формулирую гипотезу — что фича должна улучшить; (2) выбираю ОДНУ главную метрику под эту гипотезу и объясняю, почему именно её, а не vanity-метрику; (3) говорю, что заложу сбор событий заранее, до релиза; (4) предлагаю проверить через A/B-тест и оговариваю, что нужна достаточная выборка, иначе разница — шум. Если добавите «и посмотрю на воронку, где именно отваливаются» — это уже сильный продуктовый разговор.

Откуда это взялось

Самый известный набор продуктовых метрик — AARRR, «pirate metrics» (по созвучию с пиратским «ааррр»), который в 2007 году предложил Дэйв МакКлюр: Acquisition (привлекли), Activation (активировали), Retention (удержали), Revenue (заработали), Referral (рекомендовали) — пять стадий жизни пользователя, каждую из которых меряют. Чуть позже, в эпоху роста стартапов, прижилась идея North Star metric — одной «полярной звезды», главной метрики продукта, которая лучше всего отражает ценность для пользователя и вокруг которой выстраивается вся команда (для Airbnb — ночи бронирований, для Spotify — время прослушивания). Обе идеи об одном: не тонуть в десятках цифр, а выбрать те немногие, что реально двигают продукт.

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

Чем vanity-метрика отличается от actionable?

Vanity-метрика приятна на слайде, но по ней нельзя принять решение — например, «всего зарегистрировано 1 млн пользователей»: число только растёт и ничего не говорит о здоровье продукта. Actionable-метрика прямо подсказывает действие — например, «retention 7-го дня упал с 40% до 30% после релиза»: понятно, что надо разбираться, что сломали. Проверка: если метрика изменилась и вы знаете, какое решение принять, — она actionable; если только «приятно посмотреть» — vanity.

Что значит «статзначимо» в A/B-тесте простыми словами?

Это значит «разница между версиями достаточно велика и получена на достаточной выборке, чтобы её было трудно списать на случайность». Если в группе по 50 человек и конверсия 10% против 11% — это почти наверняка шум, как разброс при подбрасывании монетки. Чем меньше выборка, тем легче обмануться. Поэтому размер выборки и срок теста прикидывают заранее и не останавливают тест в момент, когда цифра понравилась, — иначе это подгонка под желаемое.

Какую метрику выбрать для новой фичи?

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