Meta CAPI батчинг и лимиты: правила доставки

Дисциплина Meta CAPI батчинг - это разница между системой доставки и рулеткой доставки: Conversions API принимает несколько событий одним запросом через свой массив data, что делает эффективную доставку возможной - и делает одно плохое событие способным провалить всё вокруг. Разбираем документированную структуру батчинга, правила приёма, решающие, выживет ли запрос, смысл отклонённого батча для логики ретраев и дисциплину доставки, удерживающую загруженную воронку в пределах лимитов площадки.

По-событийные требования - поля, идентичность, хеширование - одинаковы, едет ли событие одиноко или в группе, и документированы в полном гайде Meta CAPI; эта страница - о самой группе.

Массив data: несколько событий, один запрос

Запрос Conversions API несёт массив - параметр data, - и каждый элемент является полным событием: собственные event_name, event_time, event_id, user_data и custom_data. Батчинг структурен, а не является особым режимом: запрос из одного события - это просто массив из одного.

Что меняет массив - гранулярность отказа. Один запрос, много событий - значит, правила приёма применяются к группе. Самое весомое из правил - тайминг: event_time может отстоять максимум на семь дней в прошлое, и единственное протухшее событие валит весь запрос, не обрабатывая ни одного из его событий (документации using the API). В батче одна старая запись из пере-импорта CRM держит в заложниках очередь свежих конверсий.

Этот риск - причина, по которой дисциплина батчинга является заботой слоя доставки, а не переключателем: кто попадает в батч и насколько стары их таймстампы, решает, приземлится ли запрос.

Правила приёма, под которыми живёт батч

Каждое событие массива сохраняет собственные обязательства:

1. Обязательные поля на событие. Website-событиям нужны action_source, event_source_url и client_user_agent; поля документированы на событие, а не на запрос (параметры Conversions API).
2. Идентичность на событие. Хешированные контактные данные, fbp/fbc там, где они существуют, и стабильный event_id - каждое событие несёт собственный материал матчинга.
3. Тайминг на группу. Семидневное правило event_time - убийца батчей: массив выживает, только если выживает каждый его член.

Полезная ментальная модель: площадка читает массив как набор независимых событий в одном конверте. Конверт принимается или отвергается целиком - значит, планку для всего груза задаёт самое старое, самое грязное событие.

Когда батч проваливается: логика ретраев

Проваленный запрос говорит, что в батче была проблема, - документированные поверхности ошибок указывают, какое правило сработало. Слепой ретрай идентичного батча воспроизводит идентичный провал. Документированно-безопасный паттерн:

1. Разделите батч. Разрежьте массив пополам и ретрайте половины; член-виновник изолируется за несколько раундов.
2. Почините или карантиньте члена. Протухший таймстамп не стареет лучше от ретрая - чините источник или убирайте запись в карантинную очередь (механика задержек объясняет, как события протухают изначально).
3. redeliver здоровый остаток. Пережившие события несут собственные идентичности, поэтому повторная доставка не задваивает их.
4. Верните причину наверх. Регулярный провал из-за протухшего события - проблема выше по течению (бэкфилл CRM или пере-синк трекера) и принадлежит чеклисту поиска неисправностей постбеков, а не циклам ретраев.

Ретрай с backoff применяется к транзиентным транспортным сбоям; ретрай без разбора отклонённого батча просто умножает отклонение.

Дисциплина доставки: оставаться в пределах

Meta не публикует числовую таблицу рейт-лимитов доставки Conversions API в гайде по батчингу, поэтому дисциплина структурная, а не числовая:

1. Батчите по таймингу источника, а не по амбициям размера. Группируйте события, естественно прибывающие вместе, - проход постбеков, синк CRM, - а не копите искусственные мега-батчи, где один протухший рекорд держит свежие события в заложниках.
2. Держите идентичности стабильными между батчами. Повторная доставка после отказа использует те же значения event_id, так что правила площадки - а не ваш ретрай - решают, что считается.
3. Мониторьте оба конца. Собственные логи слоя доставки показывают отправленное; Events Manager показывает прибывшее в документированном окне видимости (get started). Растущая щель между ними - самый ранний симптом троттлинга.

Тот же подход «сначала мониторинг», что гайд мониторинга доставки применяет к отвалам, здесь применяется к троттлингу: измеряйте щель прибытия, алартьте на её рост и только потом трогайте форму батча.

Meta CAPI батчинг: частые вопросы

Источники