# Проводите регулярный продуктовый разбор - **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-review/index.html - **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-review/index.md - **Раздел:** Удержание - **Время:** 60 минут на первый разбор Продуктовый разбор — не встреча для демонстрации всех цифр. Команда связывает изменения с результатом и выбирает не больше трёх следующих решений. ## Результат Одностраничный протокол: здоровье продукта, три изменения периода, один главный вывод и до трёх решений с владельцами. ## Встреча нужна, чтобы уменьшить список задач За один период команда могла выпустить релиз, изменить онбординг и запустить сообщения. Разбор отвечает: что произошло с опытом пользователя, какое изменение могло повлиять и что проверяем дальше. Итогом становятся решения, а не набор слайдов. ## Что понадобится - **Участники:** Менеджер продукта, аналитик или владелец данных, технический представитель, поддержка и специалист по коммуникациям. - **Один экран:** 5–7 показателей качества, первого полезного пути, удержания, обращений и коммуникаций в динамике. - **Ритм:** Еженедельно для быстро меняющегося продукта или ежемесячно для стабильного; один и тот же период сравнения. ## Термины простыми словами - **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%. - **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей. - **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом. - **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%. - **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%. ## Когда применять Команда выпускает изменения, но не возвращается к их эффекту; встречи превращаются в отчёт по цифрам, а список задач только растёт. ## Что подготовить до встречи Не собирайте десятки дашбордов. Принесите только данные, изменения и живые сигналы, необходимые для решения в этом периоде. - **Экран здоровья** - **Источник:** Покажите crash-free, конверсию первого пути, FTD, D1/D7, обращения и реакцию на сообщения рядом с прошлым периодом. - **Если доступа нет:** Без единого дашборда соберите семь чисел в таблице и укажите источник, период и владельца каждого. - **Журнал изменений** - **Источник:** Запишите три главных релиза, эксперимента или коммуникации периода с датами и ожидаемым эффектом. - **Если доступа нет:** Если журнал не вёлся, восстановите изменения по задачам, версиям в сторе и календарю отправок. - **Живые сигналы** - **Источник:** Добавьте три повторяющиеся темы поддержки или отзывов и один конкретный пример пользовательского пути. - **Если доступа нет:** Попросите поддержку заранее выбрать пять характерных обращений вместо общего впечатления «жалоб стало больше». ## Проведите продуктовый разбор за 60 минут 1. **Покажите здоровье продукта.** Начните с 5–7 показателей в динамике и отметьте только существенные изменения. Не обсуждайте каждую цифру по очереди. - **Где сделать:** На одном экране с периодом, источниками и прошлым значением. - **Пример:** Crash-free 99,6% без изменения; первая ценность +8 п.п.; D7 без изменения; вопросы о статусе +40%. 2. **Поставьте рядом изменения.** Назовите три главных релиза или коммуникации с датой и ожидаемым эффектом. Не приписывайте причинность без проверки. - **Где сделать:** Во второй колонке протокола. - **Пример:** 3 июня сократили онбординг; 7 июня выпустили новый экран статуса; 10 июня изменили push-маршрут. 3. **Добавьте голос пользователя.** Покажите повторяющиеся вопросы и один характерный путь. Качественный сигнал помогает понять, что скрывается за метрикой. - **Где сделать:** Рядом с соответствующим показателем. - **Пример:** 12 пользователей спрашивают, завершилась ли операция, хотя технической ошибки нет. 4. **Выберите один главный вывод.** Сформулируйте проблему или возможность одним предложением. Не смешивайте качество, удержание и рост в одну абстрактную тему. - **Где сделать:** В заметном блоке перед решениями. - **Пример:** Новый экран работает технически, но не объясняет статус — это создаёт обращения и недоверие. 5. **Ограничьте решения тремя.** У каждого решения должны быть владелец, срок и сигнал проверки на следующем разборе. Остальные идеи явно отложите. - **Где сделать:** В последней колонке протокола и списке задач. - **Пример:** Добавить статус — Анна — 21 июня — обращения по теме и завершение действия. ## Примеры из практики - **Сигнал превращается в решение:** После нового экрана технические показатели стабильны, но вопросы о статусе выросли на 40%. Вывод — неясный процесс; решение — добавить статус, владельца и проверку обращений. - **Три решения вместо двадцати идей:** Команда исправляет маршрут push, объясняет статус операции и проверяет следующую когорту. Остальные идеи явно отложены до следующего разбора. ## Готовый артефакт: Протокол продуктового разбора Не переписывайте все обсуждения. Зафиксируйте сигнал, связь с изменением и решение, которое можно проверить. | Сигнал | Что изменилось | Вывод | Решение и владелец | | --- | --- | --- | --- | | Crash-free стабилен | Релиз 4.3 | Технического ухудшения нет | Наблюдать · мобильная команда | | Первая ценность +8 п.п. | Сократили онбординг | Изменение помогает | Расширить на Android · продукт | | D7 без роста | Новый путь 2 недели | Эффект ещё не дошёл | Проверить следующую когорту · аналитик | | Вопросы о статусе +40% | Новый экран операции | Не хватает объяснения | Добавить статус · дизайн + поддержка | | Push открывают, действие не растёт | Общий deep link | Теряется контекст | Исправить маршрут · коммуникации | Фокус периода: объяснить статус операции. Не больше трёх решений: исправить маршрут, обновить текст статуса, проверить следующую когорту. Остальные идеи остаются вне плана до следующего разбора. ## Чек-лист встречи Не начинайте встречу, пока данные и изменения не собраны: время группы должно уходить на решения. - [ ] На одном экране есть 5–7 показателей с динамикой и единым периодом. - [ ] Названы три главных изменения периода и их ожидаемый эффект. - [ ] Поддержка принесла повторяющиеся темы и конкретные примеры. - [ ] Сформулирован один главный вывод без неподтверждённой причинности. - [ ] Принято не больше трёх решений с владельцами, сроками и метриками проверки. ## Как понять, что разбор работает - **Решения выполнены:** На следующей встрече команда начинает с прошлых договорённостей и фактического результата. - **Фокус сохраняется:** В работу уходит не больше трёх согласованных действий, а новые идеи не вытесняют их без причины. - **Опыт улучшается:** Выбранные сигналы качества, удержания или доверия меняются после выполненных решений. ## Главное правило Хороший продуктовый разбор уменьшает список задач и оставляет команде несколько решений, эффект которых можно проверить. --- - [HTML-версия](https://playbook.affpartners.io/ru/practices/retention-review/index.html) - [Все практики](https://playbook.affpartners.io/ru/)