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

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

Pixel должен собирать поведение на клиенте, а CAPI — подтверждать его сервером. Если оба канала отправляют одно и то же событие без event_id, вы получаете двойной учёт. Если сервер шлёт «Purchase», а браузер теряет «InitiateCheckout», воронка выглядит рваной и решения принимаются по искажённой картине.

Проверяем базу:
— одинаковые названия событий и одинаковую структуру параметров;
— event_id для дедупликации между Pixel и CAPI;
— корректный match quality: email, phone, external_id, но только в нормализованном виде;
— передача value, currency, content_ids и content_type без пустых полей.

Дальше смотрим не на «есть ли конверсия», а на расхождения между источниками. Если браузер даёт меньше событий, ищем блокировку скрипта, потери cookie и ошибки триггеров. Если сервер даёт больше — проверяем, не отправляете ли вы события повторно из backend-очереди или при ретраях без защиты от дублей. Аналитика — это не гадание, а интерпретация метрик.

Настройка пикселя завершена, переходим к валидации входящего потока данных. Логика простая: одно событие — один идентификатор — одна бизнес-сущность. Когда это соблюдено, Pixel и CAPI начинают дополнять друг друга, а не спорить в отчётах.