Веб-аналитика на событиях: как собирать данные, которым можно доверять

Событийная веб-аналитика записывает не только просмотры страниц, но и конкретные действия пользователей: регистрацию, добавление в корзину, оплату, использование функций. Чтобы данным можно было доверять, нужен план событий с единой схемой названий и свойств, отправка важных событий с сервера, учёт согласия пользователей и регулярная проверка качества. Без этого аналитика быстро превращается в набор цифр, которые никто не может объяснить.

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

Чем событийная аналитика отличается от просмотров страниц?

Просмотры страниц отвечают на вопрос «куда ходят пользователи», а события — «что они делают». В современных интерфейсах много действий происходит без смены страницы: фильтры, модальные окна, шаги формы. Их видно только через события.

Подход	Что фиксирует	На какие вопросы отвечает
Просмотры страниц	Открытые адреса	Источники трафика, популярные разделы
События	Действия с контекстом	Где пользователи бросают воронку, какие функции используют
Серверные события	Факты в системе	Сколько реально оплат, подписок, возвратов

Как составить план событий?

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

{
  "event": "checkout_completed",
  "when": "После успешной оплаты, отправляется с сервера",
  "properties": {
    "order_id": "string",
    "revenue": "number",
    "currency": "RUB",
    "items_count": "integer",
    "payment_method": "card | sbp | invoice",
    "is_first_order": "boolean"
  },
  "question": "Какая доля оформивших корзину завершает оплату и каким способом"
}

Правила плана:

1. Названия событий в едином формате: объект и действие в прошедшем времени.
2. Одно действие — одно событие, детали — в свойствах, а не в названии.
3. Каждое событие отвечает на конкретный вопрос.
4. План хранится рядом с кодом и меняется через ревью.

Фото: Unsplash

Когда отправлять события с сервера?

С сервера отправляют события, которые важны для денег и не должны теряться: оплаты, подписки, возвраты, регистрации. Браузерные события теряются из-за блокировщиков, закрытых вкладок и плохой сети, а сервер знает факт наверняка.

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

Для больших объёмов событий удобно собственное хранилище — подробнее в статье ClickHouse для аналитики.

Как учитывать согласие пользователей?

Аналитические cookies и передача данных сторонним сервисам требуют согласия пользователя и соблюдения законов о персональных данных. Баннер согласия должен реально управлять загрузкой счётчиков, а не просто висеть на странице.

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

Подробнее о требованиях — статья персональные данные на сайте: 152-ФЗ и GDPR.

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

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

• сверяйте количество серверных событий оплаты с заказами в базе;
• настройте оповещение о резком падении или росте числа событий;
• проверяйте события в тестовом окружении перед релизом;
• валидируйте свойства по схеме из плана;
• ведите журнал изменений плана событий.

О том, какие показатели смотреть, — статьи продуктовые метрики после запуска и A/B-тестирование.

Коротко

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