Качество данных продуктовой аналитики: проверки событий

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

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

Что означает качественное событие

Для каждого события полезно проверить семь свойств:

1. Смысл. Название описывает состоявшийся факт.
2. Момент. Команда одинаково понимает, когда событие считается произошедшим.
3. Источник. Определены браузер, приложение, сервер или интеграция.
4. Идентификатор. Событие связано с нужным пользователем и аккаунтом.
5. Время. Время действия и время приёма не перепутаны.
6. Свойства. Типы и допустимые значения соответствуют контракту.
7. Уникальность. Повторная доставка не превращается в новое действие.

Если хотя бы один пункт остаётся неясным, отчёт получает скрытое допущение.

Контракт события

Минимальная запись в словаре содержит:

Поле	Пример вопроса
Имя	Почему используется именно project_created?
Описание	Какой факт подтверждён?
Момент	До или после успешного ответа сервера?
Источник	Браузер или бэкенд?
Идентификаторы	Пользователь, аккаунт, проект
Свойства	Какие обязательны и каких они типов?
Дедупликация	Как распознать повтор?
Владелец	Кто согласует изменение?

Практический набор событий для подписочного продукта есть в шаблоне B2B SaaS.

Проверяйте критичный путь вручную

До массового запуска создайте тестового пользователя и пройдите один сценарий. Запишите ожидаемую последовательность заранее, например:

signup_completed → workspace_created → integration_connected → first_data_received → report_opened.

После прохождения сравните:

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

Проверка одного HTTP-запроса в браузере недостаточна. Событие может быть принято API, но потеряться дальше или попасть в отчёт под другим идентификатором.

Пропуски

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

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

Полезные сигналы:

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

Дубли

Повторы появляются при ретраях, двойной инициализации SDK, повторном обработчике или отправке одного факта из браузера и бэкенда.

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

Время и порядок

События могут приходить позже из-за офлайн-режима, очереди или повторной отправки. Поэтому храните отдельно:

• время действия на источнике;
• время приёма сервером;
• при необходимости версию часового пояса или клиента.

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

Проверяйте невозможные интервалы: отрицательное время до результата, оплата до регистрации, завершение операции раньше старта.

Идентификация

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

Для B2B одновременно нужны человек и аккаунт. Событие без account_id может быть пригодно для индивидуального пути, но не для активации рабочего пространства.

Контрольные проверки:

• доля событий без user_id и account_id;
• число пользователей на аккаунт;
• неожиданные скачки объединений;
• один анонимный id у большого числа пользователей;
• смена аккаунта без явного контекста.

Свойства и схема

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

Используйте:

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

Не передавайте всё состояние интерфейса «на всякий случай». Большое число свойств увеличивает стоимость, риск утечки и сложность проверки.

Мониторинг после релиза

Для ключевых событий настройте наблюдение за:

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

Аномалия не обязана означать поломку. Рекламная кампания или сезонность тоже меняют поток. Сигнал должен вести к проверке, а не автоматически останавливать продукт.

Чек-лист перед доверием отчёту

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

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

Итог

Качественные данные — это наблюдаемая и версионируемая система контрактов. Если команда может восстановить путь конкретного тестового аккаунта, объяснить исключения и связать критичный факт с источником, отчёт становится пригодным для решения.