<b>Latencies в трекинге: как ловить задержки отправки событий до потери данных</b>

<b>Latencies в трекинге: как ловить задержки отправки событий до потери данных</b>

Задержка в отправке события — это не просто «поздний лог». Она ломает порядок цепочки: сессия, клик, конверсия, атрибуция. Если событие приходит через минуты, а не секунды, отчёты по воронке и ретаргетингу начинают врать.

Что мониторить:
— разницу между временем события на клиенте и временем приёма на сервере;
— долю событий с задержкой выше порога;
— хвост распределения: не среднее, а p95/p99;
— расхождение по браузерам, устройствам, сетям и страницам входа.

Практика простая: пишите в событие два времени — client_ts и server_ts. Дальше считайте latency = server_ts - client_ts и стройте алерты не по среднему, а по всплескам хвоста. Среднее может быть нормальным, пока часть событий уже «опоздала» и выпала из окна атрибуции. Аналитика — это не гадание, а интерпретация метрик.

Если задержки растут, проверяйте очередь отправки, блокировки на стороне клиента, повторные ретраи, потерю соединения и тяжёлые страницы. Отдельно сравните postback и browser events: часто проблема не в пикселе, а в том, как браузер завершает сессию.

Настраиваем эвенты так, чтобы видеть путь пользователя целиком: сначала измеряем задержку, потом ищем источник, и только затем меняем логику отправки.