CAPI ломается не на сервере, а на грязной логике событий и дублях

CAPI ломается не на сервере, а на грязной логике событий и дублях

Если пиксель и CAPI отправляют одно и то же событие без event_id, алгоритм видит двойной сигнал. Если у события плавают value, currency или source_url, атрибуция начинает ехать. Базовая схема одна: браузерный и серверный event должны совпадать по имени, времени и идентификатору.

Проверьте три слоя:
— deduplication через event_id на стороне сайта и сервера;
— передача fbp/fbc, когда это возможно;
— одинаковые параметры для Purchase, Lead, InitiateCheckout, без самодеятельности в названиях и валютах.

Обход ограничений браузеров строится не на «магии», а на снижении зависимости от клиента. Критичные события дублируются через сервер, а первичный сбор лучше держать в first-party: формы, checkout, postback, CRM. Если страница режет скрипты, не пытайтесь спасать всё пикселем — отправляйте конверсии с сервера, где есть статус лида и факт оплаты.

Отдельно смотрите на matching quality: без нормальных user_data CAPI превращается в шумный канал. Анализ данных говорит сам за себя. Если дедуп есть, а расход не бьётся с конверсиями, сначала ищите разрыв между фронтом, трекером и CRM, а не вините аукцион.