Latencies в трекинге: как поймать задержки, пока они не сломали отчёты

Latencies в трекинге: как поймать задержки, пока они не сломали отчёты

Задержка отправки события — это не просто «поздний лог». Это смещение в атрибуции, провал по воронке и ложные выводы о каналах. Аналитика — это не гадание, а интерпретация метрик.

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

Для контроля latencies нужны распределения, а не среднее. Смотрите p50, p95 и p99 отдельно по типам событий, устройствам и источникам трафика. Если p95 растёт, а p50 стабилен, проблема обычно в хвосте: медленные сети, фоновые вкладки, блокировки JS или перегрузка SDK. Проверим в системе трекинга.

Полезный минимум: логируйте timestamp на клиенте и timestamp при приёме, считайте delta, помечайте источник задержки и отделяйте отбрасывания от поздних доставок. Настройка пикселя завершена, переходим к валидации входящего потока данных.

Любая неточность в трекинге ведет к неверным бизнес-решениям. Оптимизируем сбор, чтобы не терять контекст событий: latency нужно мониторить как отдельную метрику, а не как побочный эффект доставки.