Backfill после сбоя трекинга: как восстановить события и не создать дубли

Редакция mevrica

Рекламные технологии4 мин чтения

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

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

Основное правило

Повторно доставляется тот же event_id и исходное occurred_at. Время восстановления не должно превращать старое событие в новое.

Сначала остановите распространение ошибки

До загрузки убедитесь, что причина потери исправлена. Иначе новые и восстановленные события снова попадут в неисправный маршрут. Заморозьте автоматические решения, которые используют неполный период, и сохраните snapshot текущих статусов.

Определите точную границу

Используйте последний известный хороший час, первый подтверждённый плохой час и момент устойчивого восстановления. Затем сравните первичный count, очередь, принятые события и downstream. Интервал «примерно вчера» слишком широк и почти гарантирует лишние повторы.

Создайте манифест восстановления

• Идентификатор backfill
• Причина и ссылка на инцидент
• Точный временной интервал
• Источник записей
• Число уникальных event_id
• Версия схемы
• Ожидаемые суммы по валютам
• Владелец и критерий остановки

Проверьте идентификаторы

Один бизнес-факт должен сохранять прежний ID во всех каналах. Google Ads также использует комбинации идентификаторов и параметров события для дедупликации offline imports. Если ключ нельзя воспроизвести, неоднозначные строки отправляют в quarantine, а не создают из текущего времени.

Начните с контрольной партии

Выберите небольшую воспроизводимую выборку разных источников, версий и статусов. Загрузите её и проверьте: не увеличилось ли число бизнес-фактов, обновились ли нужные статусы, сохранились ли occurred_at и валюта, появился ли ожидаемый audit trail.

Увеличивайте партии постепенно

После успешной выборки переходите к ограниченным batch. Между ними сверяйте accepted, duplicate, rejected и unknown. Пауза между партиями нужна не для формальности: некоторые downstream обновляются с задержкой и способны скрыть проблему в первой минуте.

Не перезаписывайте поздний статус ранним

Если конверсия уже получила approved или reversed, повтор старого pending не должен стать текущим состоянием. Обработчик сравнивает status version или бизнес-время и сохраняет историю решений.

Финальная сверка

1. Сопоставить уникальные event_id источника и назначения
2. Проверить контрольные суммы по часам
3. Сверить статусы и reason codes
4. Сравнить суммы отдельно по валютам
5. Проверить журнал дублей
6. Обновить затронутые отчёты новой версией
7. Закрыть временные ограничения

После восстановления

Postmortem должен объяснить не только причину потери, но и почему backfill был возможен. Надёжность обеспечивают неизменяемый сырой слой, стабильный ID, идемпотентный consumer и регулярная сверка, а не героическая ручная работа после каждого сбоя.

Не маскируйте backfill под исходные данные

В отчёте сохраняйте ingestion time и backfill_id. Пользовательский occurred_at остаётся прежним, но история восстановления должна быть видна.

Источники и границы применимости

Google Ads offline conversion imports FAQ: https://support.google.com/google-ads/answer/10029210?hl=ru

Вывод

Безопасный backfill восстанавливает прежние факты, а не создаёт новые. Точная граница, манифест, стабильные ID, контрольная партия и финальная сверка защищают от дублей и неверных статусов. Если запись неоднозначна, карантин лучше уверенной ошибки.