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

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

Почти всегда проблема не в самом пикселе, а в том, как события доходят до Meta. Если браузер режет cookies, а сервер шлёт мусор без дедупликации, атрибуция расползается: в кабинете один объём, в трекере другой.

Базовый чек-лист:
— browser и server event_name должны совпадать;
— event_id нужен в обоих каналах, иначе дубликаты не схлопнутся;
— event_time передавайте без задержек и в одной временной логике;
— user_data собирайте максимально полно: email, phone, external_id, fbp, fbc;
— не полагайтесь только на IP и user agent, их точность ограничена.

Дальше смотрим не на «подключено/не подключено», а на качество матчинга. Если Event Match Quality низкий, режем сплит по источникам: часть трафика может терять fbc из-за редиректов, часть — user_data из-за формы без хеша. Анализ данных говорит сам за себя.

Для обхода браузерных ограничений работает простое правило: максимум идентификаторов собираем на сервере, минимум логики оставляем в клиенте. Иначе Safari, adblock и кривые редиректы съедают часть сигналов до того, как они попадают в отчёт.

Если CAPI настроен, но ROI не сходится, сначала проверь дедуп, совпадение event_name и полноту user_data, а уже потом трогай креативы и аудитории.