Что важно проверять в аналитике кроме записи и отправки данных?
Что проверяют
Видите ли вы аналитическое событие как контракт, а не как факт отправки запроса. Проверка вида «запрос ушёл, код 200» закрывает малую часть рисков, а бизнес принимает решения по цифрам, которые получаются дальше по цепочке.
Как отвечать
Разложите по слоям.
- Схема. Имя события и набор параметров совпадают с согласованной схемой, типы верные, обязательные параметры заполнены, значения из допустимого перечня, лишнего не отправляется.
- Смысл. Событие возникает ровно один раз на действие пользователя и только на него. Типичные источники мусора: повторный рендер, ретрай, возврат на экран, поворот, автозаполнение.
- Связность. Воронка сходится, следующий шаг не бывает многочисленнее предыдущего, у событий одной сессии общий идентификатор, анонимный профиль корректно склеивается с авторизованным.
- Доставка. Что происходит в офлайне и при закрытии приложения: буфер, повторная отправка, дедупликация на приёмнике по идентификатору события.
- Приватность. В параметры не утекают персональные данные, содержимое полей ввода и токены, отказ от трекинга уважается.
- Окружение. Трафик со стендов и автотестов не попадает в боевой поток.
- Сходимость. Число событий сверяется с серверными данными, например оплаты в аналитике против заказов в базе.
Где спотыкаются
Проверяют факт отправки и останавливаются. Событие ушло, но параметр пустой, приходит строкой вместо числа или несёт внутренний идентификатор вместо человекочитаемого значения, и отчёт разваливается уже на стороне аналитики.
Второе: не воспроизводят реальные условия. Дубли и потери вылезают на быстрых повторных нажатиях, возврате назад, плохой сети и выгрузке приложения из памяти, а не на спокойном проходе по сценарию.
Третье: смотрят события поштучно и не проверяют воронку целиком. Расхождение видно только на связке: шагов оплаты больше, чем открытий корзины, значит событие шлётся не там, где предполагалось.