Проверка качества данных

В рабочих материалах такую проверку часто называют QA — контролем качества.

Данные события

1. Call type и название совпадают с планом сбора данных?
2. Вызов отправился один раз в момент, указанный в Trigger?
3. Все обязательные свойства присутствуют?
4. Имена и типы данных правильные?
5. userId и anonymousId соответствуют состоянию пользователя?
6. Source и Platform соответствуют реальному способу отправки?
7. event_id связывает денежное событие с бизнес-операцией?
8. Если Segment должен автоматически распознавать дубли, задан корректный messageId?

event_id — поле учебной бизнес-операции. Поле верхнего уровня messageId позволяет Segment автоматически распознавать дубли сообщений.

Порядок проверки

1. Вызов виден в консоли браузера или журнале сервера?
2. Запрос виден во вкладке Network, если он выполняется в браузере?
3. Данные события появились в Source Debugger нужного источника?
4. Раздел Event Delivery не показывает ошибку, если подключена система-получатель?
5. Событие появилось в системе-получателе, если она подключена?

Если система-получатель не подключена, пункты 4–5 отмечаются как N/A — «не применяется».

reset() проверяется по изменению данных пользователя в браузере после выхода. Он не отправляет отдельный вызов и не должен появляться в Debugger.

Разбор ошибки

Симптом	Фактические данные	Нарушенное правило	Исправление	Повторная проверка
Поле не попало в отчет	countri вместо country	Имя не совпадает с планом сбора данных	Исправить имя	Повторить действие и сравнить данные в Source Debugger