Офлайн-конверсии Meta CAPI: статусы лидов из CRM и трекера
Почему датасеты сменили старый офлайн-маршрут
Офлайн-история Meta сменила форму, и интеграции, спроектированные под старые названия, ломаются тихо. Бизнес-справка Meta говорит прямо: Offline Conversions API - тот, что загружал события в отдельные офлайн event sets, - закрыт в мае 2025, и рекомендуемая замена - загрузка событий в датасеты через Conversions API. Существующие интеграции могли продолжать работать, но в момент, когда офлайн-данные нужно связать с событиями сайта или приложения, датасеты - единственный путь. Для воронки с трекером, которая хочет и веб-сигналы, и поздние обновления статусов в одном месте, это ровно главная точка - общая механика доставки в conversions API.
Датасеты создаются в Events Manager, и Meta перечисляет несколько точек входа в зависимости от стартовых условий - включая создание офлайн event set или существующее мобильное приложение. Для app-воронок важно одно правило связывания: датасет должен быть связан с приложением до отправки мобильных app-событий, и только одно приложение связывается с датасетом. У рекламодателей без ресурсов на прямую интеграцию есть фолбэки - партнёрские интеграции с оговоркой, что не все поддерживают офлайн-события.
Юзкейс статусов лидов
В аффилей- или лидоген-воронке конверсия - не один момент. Сеть стреляет первым постбеком при появлении лида, а поздние постбеки обновляют его - подтверждён, оплачен, отклонён. Офлайн-конверсии Meta CAPI дают этому пути документированный канал: каждое обновление статуса может уехать в Meta как серверное событие, с выбранными вами именем события и таймстампом. Естественный источник правды здесь - трекер, ведь он уже обрабатывает постбеки со статусами.
Так настройка начинает оптимизироваться на качество лида, а не на сырой счётчик: дешёвый лид, который никогда не подтвердится, становится для Meta данными, а не только догадкой в колонке выплат трекера. Путь доставки тот же, что у веб-конверсий, - MOST принимает постбеки трекера и доставляет в Conversions API Meta вместе с другими сетями, а бесплатный Pixel Activator закрывает один лендинг вручную.
Соберите офлайн-событие: обязательные поля
Референс офлайн-событий Meta фиксирует обязательные поля. event_name обязателен и берётся из документированного набора - стандартные веб-имена вроде Purchase и Lead валидны, плюс Other для всего вне списка; именно так чаще всего едут обновления статусов. Далее event_time несёт UNIX-таймстамп конверсии - момент самой конверсии, а не момент загрузки. Параметр action_source должен быть physical_store для всех офлайн-событий; Meta требует этот параметр на каждом серверном событии и заявляет, что, пользуясь API, вы подтверждаете точность значения.
Вместе с ними передаются параметры данных клиента (customer information parameters) - хэшированные идентификаторы вроде email и телефона, - и нужны они дважды: атрибутировать событие правильному человеку и питать дедупликацию по пользователю, описанную ниже. order_id опционален, но практичен: уникальный идентификатор транзакции, в ритейле - ID чека, а в воронке с трекером - естественно ID транзакции трекера. Дисциплина хэширования та же, что в хэшировании user data для CAPI.
Двое часов: 62 дня для офлайна, 7 - для всего остального
Окна Meta различаются по классу событий, и их путаница даёт жёсткие ошибки. Для обычных серверных событий event_time может быть не старше 7 дней на момент отправки; всё, что старше, валит весь запрос без обработки единого события, - механика этого лимита подробно описана в гайде по ошибке 2804003. Офлайн-события и события магазинов живут по другим часам: рекомендация Meta - загружать транзакции в течение 62 дней с конверсии. Этот запас и делает воронки со статусами практичными: подтверждение или отказ, приехавшие через два месяца после лида, всё ещё доезжают до Meta.
Третий таймер работает внутри загрузки: максимальное окно дедупликации - 7 дней. Две копии события с разницей больше 7 дней в одну не сворачиваются - значит, ретраи и коррекции нужно отправлять оперативно, не откладывая в архив.
Дедупликация: по order_id или по данным пользователя
Дедупликация офлайна - отдельная подсистема. Meta отмечает, что офлайн-события дедуплицируются только против других офлайн-событий, а не против пиксельных или веб-серверных, и поддерживает два метода. Метод order_id считает дубликатами события с одинаковыми event_time, event_name и одним order_id. Без order_id работает метод по пользователю, и сравнивает одинаковый набор customer information parameters. Оба оценивают комбинацию полей - dataset_id, event_time, event_name, item_number и ключ метода, - а при обнаружении дубликатов остаётся первое событие.
Практическое правило для воронки со статусами следует из этого напрямую: дайте транзакции каждого лида стабильный order_id с самого начала и делайте каждое обновление осознанно различимым - другое event_name под другой статус или таймстамп момента, когда статус фактически случился. Дедупликация срабатывает, только когда совпадают event_time, event_name и ключ идентичности - один order_id или идентичные customer information без него, - и тогда до отчётности Meta доезжает только первое событие.