Условие
Product Owner сообщает, что скоро выкатывается новая фича, и хочет отслеживать её успех. Как вы поддержите этот запрос?
Решение
Подход
Предложить трёхступенчатый план: success criteria → tracking plan → дашборд + ритуал ревью. Все три должны существовать ДО релиза.
1. Success criteria (что считаем успехом)
С PO согласуем заранее:
- North Star для фичи: одна метрика, которая компактно отражает ценность. Например:
% активных клиентов, использующих фичу хотя бы 1 раз в неделю. - Adoption funnel: discovery → first try → repeat use → habit (4+ раз/мес).
- Quality / activation: для пользователей, начавших использовать фичу — дошли ли до valuable action (создали кампанию / экспортировали отчёт).
- Business: связан с retention, NPS, revenue.
- Guardrails: latency, error rate, отток уже существующих пользователей.
Прибиваем числовые целевые значения:
- «За 4 недели после релиза 30% client_holding используют фичу как минимум 1 раз».
- «Конверсия из first-try в repeat-use ≥ 40%».
- «Latency P95 < 1 sec».
2. Tracking plan
Перед релизом совместно с инженерами фиксируем события:
| Event | Properties | When |
|---|---|---|
feature_x_seen |
user_holding_id, source, page_url | Пользователь увидел entry-point |
feature_x_clicked |
+ variant | Клик на entry-point |
feature_x_started |
+ config | Начал работу с фичей |
feature_x_completed |
+ duration, items_count | Завершил valuable action |
feature_x_error |
+ error_code | Ошибка в работе |
Каждое событие — с user_id (или user_holding_id), session_id, role, timestamp. Пишем PRD-документ tracking-plan и утверждаем у PO до релиза.
3. Dashboard
Через 1–2 недели после релиза готовим Looker/Tableau дашборд:
- Top: North Star + 3 главные метрики, плюс trend WoW.
- Funnel: entry-point → click → start → complete.
- Сегменты: internal vs external, по client_holding (топ-10), по странам.
- Гарды: error rate, latency.
- Cohort retention: % когорты «впервые попробовавших на неделе X», использующих фичу через 1, 2, 4 недели.
4. Ритуал ревью
- Daily в первую неделю — гарды (нет ли регресса).
- Weekly — North Star + воронка.
- Monthly — глубокий анализ, рекомендации.
Через 4–8 недель — solidify решение: продолжить инвестиции, итерировать, депрекейт.
5. A/B-тест
Если возможно — выкатывать фичу через A/B, а не на 100% сразу:
- Группа A — без фичи (или со старым флоу).
- Группа B — с новой фичей.
- Размер выборки расчитан под MDE на North Star.
Это единственный способ корректно ответить на вопрос «реально ли фича помогает». Без A/B мы видим только тренд, который может быть сезонным.
Подводные камни
- Tracking after release. Если события не залогированы заранее — измерить нечего. Tracking plan ДО релиза, обязательно.
- Vanity metrics. «Сколько людей увидели banner» ≠ «Сколько людей получили ценность». Adoption ≠ value.
- Нет baseline. Без замера до релиза сложно сказать, что выросло. Снимаем baseline.
- Только positive metrics. Гарды обязательны: фича может ускорять onboarding, но ломать legacy флоу для опытных.
- Один срез. Сегментация по client_holding и роли важна — фича может работать для одних и провалиться у других.
- Краткое окно. Novelty-effect неделю → потом плато. Решение через 4+ недель.
Эталонный ответ
Поэтапно: до релиза — согласовать success criteria и tracking plan с PO и инженерами, забронировать события и атрибуты; на релизе — A/B-тест если возможно, иначе фиксируем baseline; после — дашборд (North Star + воронка + сегменты + гарды) + ритуал weekly review. Главный принцип — измерить можно только то, что заранее залогировано.