Event time обозначает момент действия. Время получения показывает, когда сервис узнал о нём, а время отправки показывает, когда передал событие дальше. Эти три значения позволяют измерить задержку. Если заменить исходный момент текущим временем сервера, проверить задержку уже не получится.
Для интеграции через conversions API нужны правила конкретного приёмника и типа события. Ниже ограничения Meta используются только в своей области, а не как общий договор для всех платформ.
Разделите три отметки времени
Возьмите одну транзакцию и сравните запись источника, задачу в очереди и исходящий запрос. На каждом этапе уточните единицу измерения. Если источник прислал локальную дату, сохраните сведения о её часовом поясе.
| Значение | На какой вопрос отвечает | Типичная ошибка |
|---|---|---|
| Время действия | Когда оно произошло? | Подменено временем прихода вебхука |
| Время получения | Когда сервис получил сообщение? | Выдано за момент действия |
| Время отправки | Когда запрос ушёл приёмнику? | Использовано, чтобы старое событие выглядело свежим |
| Дата отчёта | По какой дате сгруппирована строка? | Превращена в выдуманную точную отметку события |
Если осталась только дата отчёта, не придумывайте час и смещение. Отметьте момент действия как неизвестный и запросите исходную запись. Более широкая проверка доставки описана в гайде о задержках событий.
Применяйте ограничение Meta к нужному типу события
Meta определяет event_time как реальный момент события в Unix-секундах. Гайд API допускает время до семи дней перед отправкой. По этому правилу более старое значение в массиве data приводит к отказу всего запроса.
В том же фрагменте отдельно указана загрузка офлайн-транзакций и транзакций физических магазинов с physical_store в action_source в течение 62 дней после конверсии. Это условие нельзя смешивать с правилом семи дней. Оно не разрешает объявить событие сайта событием магазина: Meta требует точного значения action_source.
Перед загрузкой истории разделите события по настоящему источнику и проверьте применимое ограничение. Сомнительные записи обрабатывайте отдельно, чтобы одна старая запись не остановила подходящую группу. Разделение запросов само по себе не гарантирует приём, поэтому проверяйте ответы. Связанный разбор есть в гайде об ошибке возраста события.
Переводите локальное время без смены момента
Локальная дата без смещения может быть неоднозначной. При переходах на летнее и зимнее время некоторые локальные часы повторяются, а другие пропускаются. Часовой пояс сервера не доказывает, какой пояс использовал источник.
По возможности получайте однозначную отметку сразу из источника. Если преобразование необходимо, используйте его часовой пояс и правило, действовавшее в день события. Сохраните входное и полученное значения. Единицы, секунды или миллисекунды, проверяйте отдельно от часового пояса.
Для диагностики возьмите обычный день, дату рядом со сменой сезонного времени, если она применима, и задержанное событие. Совпадения календарной даты недостаточно: сравните сам момент. Если единственное время приходит от партнёрской сети, договорённость с источником поможет уточнить гайд о CPA-постбеках.
Разделите приём, дедупликацию и атрибуцию
Гайд Meta о дедупликации описывает соответствующие браузерные и серверные события. Рекомендуемый способ сопоставляет eventID и имя события Pixel с event_id и event_name CAPI. Для этих копий из браузера и сервера документ описывает границу в 48 часов между получениями.
Альтернативный способ использует имя события вместе с fbp и/или external_id. У него свои ограничения: браузерное событие должно прийти раньше, а копии только из браузера или только с сервера этим способом не удаляются. Из этих правил нельзя выводить, что любой серверный повтор до 48 часов безопасен, а поздний обязательно станет новой конверсией. Политику повторов интеграции проверяют отдельно; см. повторы и идемпотентность.
Для офлайн-импорта Google Ads действуют другие проверки: срок загрузки после связанного клика и отдельно настроенное окно конверсии. Столбец по времени конверсии также отличается от отчётов с другой группировкой дат. Ни одно из этих условий не даёт основания восстановить или переписать реальный event time.
Проверьте исправление по одной транзакции
Зафиксируйте исходное значение, пояс или смещение, значение в очереди, значение в запросе и результат приёмника. При повторной отправке исходный момент действия должен оставаться доступным. Если отметка изменилась, укажите преобразование, которое её изменило.
Для TikTok и других приёмников сначала проверьте схему, единицы и возраст событий именно в нужной процедуре. Числа семь дней и 48 часов из документации Meta переносить нельзя. Если применимое правило не установлено, оставьте вопрос открытым.
После исправления часового пояса решите, как обрабатывать затронутую историю, до повторной загрузки. Правильное время само по себе не подтверждает допустимость события, дедупликацию или атрибуцию. Сохраните первоначальную запись и причину исправления, чтобы объяснить последующие расхождения отчётов.
Почему event time в запросе отличается от источника?
Не отправляйте токены и пароли.
Источники
Sources
Обсудите обработку времени событий в вашей интеграции CAPI