Conversion API ломается не в кабинете, а в схеме передачи событий

Conversion API ломается не в кабинете, а в схеме передачи событий

Пиксель и CAPI должны дублировать друг друга, а не спорить между собой. Если event_id не совпадает, серверные события будут считаться отдельными и атрибуция разъедется. База простая: одинаковые названия событий, единый формат user_data, корректный timestamp и обязательная проверка дедупликации.

Дальше смотри на качество матчинга. Хешируй только нормализованные данные: email в lowercase, телефон в E.164, без лишних пробелов и символов. Чем шире набор параметров — fbp, fbc, external_id, client_ip_address, client_user_agent — тем выше match rate, но только если данные не мусорные. Пустой параметр лучше не отправлять, чем отправлять кривой.

Отдельный риск — задержка между кликом и отправкой события. Для лида или покупки сервер должен уходить быстро, иначе окно атрибуции начнет резать ценность события. Если используешь офлайн-цепочку или промежуточный бэкенд, логируй все точки: где событие создано, где обогащено, где отправлено. Пиксель не ошибается, ошибается тот, кто его настраивал.

Проверка должна быть системной: тестовые события, сопоставление event_id, валидность payload, процент matched events, доля дублей и расхождений по времени. Если сервер дает больше данных, но хуже матчит аудиторию, это не оптимизация, а технический шум.

Сегментируй или сливай бюджет в пустоту: сначала добейся чистой передачи событий, потом уже масштабируй ретаргетинг.