Контрольные суммы воронки: как заметить потерянные события

Редакция mevrica

Аналитика4 мин чтения

Обновлено 1 августа 2026 г.

Потеря postback редко начинается с нуля событий. Чаще исчезает часть одного типа, GEO или часа, а общий график выглядит правдоподобно. Контрольные суммы позволяют заметить нарушение полноты раньше финансовой сверки: отправитель и получатель независимо считают один и тот же закрытый набор и сравнивают результат.

Какие контрольные значения нужны

• Количество строк и уникальных event_id
• Количество по event_type и status_version
• Сумма amount_minor по каждой валюте
• Минимальное и максимальное occurred_at
• Количество событий без click_id
• Число дублей и конфликтов payload hash
• Распределение задержки доставки

Один count недостаточен. Если два события потерялись, а два задвоились, количество совпадёт. Уникальные ID, суммы и сегменты покажут противоречие.

Закрытый интервал

Сверять текущий час сразу нельзя: события ещё едут. Выберите водяной знак — например, occurred_at раньше момента, для которого прошло достаточно времени по фактическому p99 задержки плюс резерв. Интервал задают полуоткрытым: start включительно, end исключительно. Это исключает двойной учёт границы.

Лестница локализации

1. Сравнить сутки целиком.
2. Разбить расхождение по часу occurred_at.
3. В проблемном часу разделить event_type и GEO.
4. Затем проверить sender_id, campaign и status_version.
5. Получить конкретное множество missing и extra event_id.
6. Сопоставить логи доставки только для найденного множества.

Так команда не ищет одну пропавшую конверсию среди миллионов запросов. Каждый шаг уменьшает область и сохраняет воспроизводимый след.

Обезличенный пример

Отправитель сообщает за зрелый час 12 480 событий и 12 470 уникальных event_id. Получатель — 12 462 строки и 12 460 уникальных ID. Общая разница строк равна 18, но по уникальным ID — 10. Разрез показывает: 20 ID отсутствуют у получателя, 10 лишних являются повторами одного старого status_version. Значит, одновременно произошли потеря доставки и ошибка применения версий; просто «дослать 18 событий» было бы неверно.

Суммы в нескольких валютах

Нельзя складывать EUR, USD и RUB в одну контрольную сумму до пересчёта. Сверяйте amount_minor по валюте в исходном виде. Нулевое расхождение суммы не гарантирует полный набор, но быстро обнаруживает ошибку знака, единиц или пропуск денежного события.

Hash-наборы и приватность

Для больших наборов можно сравнивать отсортированные hash идентификаторов или блоки по префиксу. Это сокращает передачу, но не заменяет защищённый процесс: hash предсказуемого персонального значения не делает его безопасным. Используйте случайные event_id и не включайте пользовательские реквизиты.

Сверка статусов

Событие может присутствовать в обеих системах, но иметь разный статус. Сравнивайте пару event_id + status_version и текущую максимальную версию. Старый rejected, доставленный после нового approved, не должен откатывать состояние. При этом обе версии остаются в истории.

Алерт без ложной тревоги

Порог задают относительно исторической вариативности и объёма. Полезно сочетать абсолютный минимум и относительную долю: десять потерянных событий критичны при ста событиях, но могут быть шумом при миллионе — в зависимости от денежной ценности. Алерт должен указывать интервал и первый сегмент расхождения.

Операционный результат

• Файл missing event_id для безопасной повторной доставки
• Файл extra/duplicate для проверки идемпотентности
• Список status mismatch
• Оценка затронутой суммы по валюте
• Время начала и окончания нарушения
• Причина и защитная мера после исправления

Вывод

Контрольные суммы не заменяют поштучную сверку, а направляют её. Хорошая система сначала доказывает полноту закрытого набора, затем ищет конкретные различия и только после этого повторяет доставку. Это защищает одновременно от потерь и дублей.