Продуктовая аналитика
События
Помогает увидеть, получают ли пользователи пользу, где останавливаются и какие причины потерь нужно проверить.
Что подготовить. Один бизнес-вопрос, описание полезного действия и доступ к проверке событий.
Что получите. Составите план измерения, позволяющий принять решение без разночтений в событиях.
Когда пригодится
Есть посещения и регистрации, но непонятна связь с результатом клиента и бизнеса.
Как использовать
- Начните с решения: что хотите изменить и какой ответ нужен.
- Назовите действие, которое отражает получение пользы.
- Опишите события, свойства, пользователя и правила учёта.
- Проверьте качество сбора и отсутствие дублей.
- Смотрите переходы и возвращения по сегментам, затем разбирайте причины через наблюдения и разговоры.
Что учесть
Клик по кнопке не обязательно означает выполненную задачу. Для отчётного сервиса полезнее знать, создан ли отчёт и использован ли он. В B2B отдельно считайте человека и компанию, если решение покупается командой.
Заполненный учебный пример
| Поле | Заполнение |
|---|---|
| Вопрос | Почему компании не получают первый рабочий отчёт? |
| Единица | Компания; действия отдельных сотрудников связываются с ней. |
| События | Данные приняты → отчёт создан → отчёт открыт нужным участником. |
| Свойства | Источник компании, дата первого запуска, тип отчёта, версия импорта. |
| Проверка качества | Тестовый сценарий записывается один раз; ошибка импорта не считается успехом. |
Вывод. План позволит увидеть место потери, но причина потребует наблюдений и разговоров. Открытие отчёта остаётся лишь признаком использования, а не автоматическим доказательством принятого решения.
Следующее действие. Определить, какие события отражают активацию и первый полезный результат, и проверить проблемный шаг с помощью юзабилити-теста.
Что проверить после изменения. Доля компаний с полезным результатом, время до него и обращения за помощью. Источники и сроки сравнения должны совпадать.
После релиза нет эффекта
Разделите доступность функции, её использование и влияние на целевой результат. Выпуск кода не доказывает изменение поведения.
| Вопрос | Если ответ отрицательный |
|---|---|
| Измерение корректно? | Исправить события, проверить раскатку, дубли и единицу учёта. |
| Нужная аудитория получила функцию? | Проверить доступ, тариф, версию и условия включения. |
| Пользователи замечают вход? | Проверить обнаружение сценария; не считать отсутствие клика отсутствием потребности. |
| Начинают и завершают задачу? | Посмотреть выполнение через юзабилити-тест. |
| Получают нужную пользу? | Проверить задачу и ценность результата, в том числе по разговорам. |
| Меняется целевой показатель? | Проверить дизайн оценки, период, охват и побочные последствия. |
Учебный пример: новый фильтр доступен всем, но используют его немногие. В наблюдении нужные пользователи не находят вход. Сначала меняют обнаружение, затем проверяют завершение задачи. Развивать новые возможности фильтра до этого преждевременно.
Управленческий выход: исправить измерение, доступность, обнаружение, выполнение, ценность — либо остановить развитие. Назначьте владельца и условие возврата к решению.
Как измерить сценарий, а не набор кликов
План событий начинается с вопроса о поведении. Опишите вход в сценарий, значимые действия, успешный результат и свойства, по которым нужно различать группы. Согласуйте идентификацию пользователя и компании, повторные события и время. Проверьте несколько реальных сценариев от начала до конца: отчёт может выглядеть правдоподобно даже при потере части событий или двойной отправке.
Как соединить данные с исследованием
Количественный отчёт показывает масштаб и место изменения, но не всегда объясняет мотив. Выберите конкретный проблемный шаг и дополните его наблюдением или разговором, прежде чем назначать решение.