План событий веб-аналитики: как настроить измерение продукта

Зачем нужен план событий

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

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

Вопросы и карта воронки

До таблицы событий продукт, маркетинг, аналитик и разработка согласуют определения и источники истины.

• Ключевые решения команды и показатели, которые должны на них влиять.
• Путь пользователя с началом, обязательными шагами, ошибками и бизнес-результатом.
• Сегменты, которые реально меняют интерпретацию: роль, тариф, устройство, канал или продукт.
• Серверные статусы для заказа, оплаты, заявки и других результатов, недоступных браузеру.
• Требования согласия, минимизации данных, срока хранения и удаления идентификаторов.

Как создать tracking plan

План проектируют как версионированный контракт и проверяют на тестовом потоке до публикации дашборда.

• Выбрать события, отражающие изменение состояния или значимое намерение пользователя.
• Установить единый стиль имен, время события и владельца определения.
• Описать параметры, типы, допустимые значения, обязательность и пример полезной нагрузки.
• Разделить клиентские взаимодействия и серверное подтверждение бизнес-результата.
• Реализовать data layer, автоматические проверки схемы и тестовый режим без production-шума.
• Сверить события с логами и источником истины, затем документировать изменения версии.

Структура карточки события

Одно событие должно быть понятно человеку, который не участвовал в его первой реализации.

• Название, бизнес-определение и точное условие отправки.
• Источник: клиент, сервер, CRM или другая система подтверждения.
• Параметры с типами, словарями, примером и запретом чувствительных данных.
• Связанные метрики, отчеты, ответственный владелец и уровень критичности.
• Версия, дата выпуска, изменения и правило обратной совместимости.

Что портит аналитические данные

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

• Отправлять покупку по клику на кнопку до подтверждения платежа или создания заказа.
• Передавать локализованный текст интерфейса вместо стабильного кода значения.
• Менять смысл события без нового имени или версии и смешивать периоды.
• Собирать email, телефон, текст формы и другие данные без необходимости и согласия.
• Не фильтровать тестовые, внутренние и повторные события после обновления страницы.

Как проверять качество данных

Мониторинг аналитики нужен постоянно, потому что интерфейс и интеграции меняются чаще отчетов.

• Соответствие числа серверных результатов и событий аналитики с объяснимой разницей.
• Доля событий без обязательного параметра или с неизвестным значением справочника.
• Резкие изменения объема после релиза по платформам, версиям и типам пользователей.
• Дубли одного результата и нарушение ожидаемого порядка этапов воронки.
• Покрытие критических событий автоматическим тестом в основном пользовательском пути.

Как поддерживать карту событий

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

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