Как выяснить причину расхождений между числом конверсий в рекламе Facebook и данными в панели управления сайтом

В рекламном кабинете отображаются конверсии, но в административной панели сайта соответствующих заказов нет; или сайт уже получил заявку, а в отчётах рекламы Facebook по-прежнему ноль. Если вы столкнулись с расхождениями конверсий Facebook (conversionunterschiede facebook), не спешите переустанавливать пиксель. Возможно, системы учитывают разные действия или используют разные окна атрибуции и правила определения дат. Но также нельзя исключать реальные пропуски или дублирование событий.

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

Сначала согласуйте методику учёта, затем оценивайте расхождения

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

На сайтах для привлечения экспортных B2B-заявок особенно легко спутать «нажатие кнопки отправки» и «заявку, зарегистрированную в системе». Например, при продвижении такой страницы с материалами, как Исследование путей оптимизации системы управления банковским благосостоянием, просмотр подробной информации, скачивание материалов и отправка запроса — это разные действия, и не все их следует учитывать как качественные заявки.

Если рекламных конверсий больше: в первую очередь проверьте окно атрибуции и дублирование событий

Атрибуция по просмотру не обязательно оставляет на сайте маркер источника

Пользователь увидел рекламу в Facebook, не нажал на неё, а на следующий день перешёл на сайт из поиска и совершил покупку. При соблюдении текущих настроек атрибуции и других условий Meta может отнести эту покупку к рекламе, тогда как в административной панели сайта источником будет указан поиск.

Проверьте фактические настройки атрибуции на уровне группы объявлений и сравните атрибуцию по кликам и просмотрам с помощью функций отчётности, доступных в аккаунте. Не считайте, что во всех рекламных кампаниях используется одно и то же окно атрибуции. UTM-параметры помогают определять посещения после клика, но не позволяют полностью объяснить атрибуцию по просмотрам.

Не учитываются ли события Pixel и серверные события дважды

Если одновременно установлены Meta Pixel и Conversion API (CAPI), одно и то же бизнес-событие может быть отправлено дважды — из браузера и с сервера. Для соответствующих событий на обеих сторонах должны использоваться одинаковые event_name и event_id, чтобы платформа могла распознать дубликаты и исключить их из подсчёта.

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

Если конверсий на сайте больше: проследите путь одной реальной отправки

Не ограничивайтесь общими дневными показателями. Выберите тестовую заявку или заказ, для проверки которых получено разрешение и которые можно отследить, пройдите весь путь от входа на страницу до регистрации в системе и запишите время, номер заказа или заявки, а также ID события. Затем проверьте цепочку с помощью инструментов отладки браузера и функции тестирования событий Meta.

• Отправка завершилась успешно, но событие не зарегистрировано: проверьте, не рассчитаны ли условия срабатывания только на старую версию страницы, не отсутствует ли у асинхронной формы обработчик успешной отправки и добавлен ли код на страницы на всех языках.
• Браузерное событие работает, но серверной записи нет: проверьте журналы запросов CAPI, ответы API, сбои в очереди и механизм повторных попыток.
• Событие получено, но рекламная конверсия не отображается: дополнительно проверьте взаимодействия с рекламой, окно атрибуции и условия сопоставления, а не переустанавливайте пиксель снова и снова.

Ограничения браузера, блокировщики рекламы и отказ пользователя от маркетингового отслеживания могут уменьшить количество наблюдаемых событий. Потеря параметров источника при переходе между доменами, оформлении заказа или перенаправлении на стороннюю платёжную систему также затрудняет отслеживание цепочки. CAPI может дополнить сигналы с сервера, но не позволяет обходить требования к согласию пользователя и не гарантирует атрибуцию всех конверсий.

Если качество сопоставления низкое, проверьте, правильно ли нормализуются законно полученные данные клиентов и корректно ли передаются доступные параметры, такие как fbp и fbc. Не подделывайте идентификаторы кликов и не собирайте лишние данные ради повышения оценки сопоставления.

Если расхождения приходятся на отдельные дни, проверьте даты и статусы бизнес-событий

Если в рекламном аккаунте и административной панели сайта используются разные часовые пояса, один и тот же ночной заказ может попасть в разные даты. В некоторых рекламных отчётах атрибутированные результаты также отображаются по дате взаимодействия с рекламой, тогда как в бизнес-системе учёт обычно ведётся по дате заказа, оплаты или отправки заявки. Проверьте, по каким правилам сформирован текущий отчёт.

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

Превратите расхождения в понятную сверочную запись

Рекомендуется вести минимальную таблицу для сверки: идентификатор бизнес-события, время и часовой пояс, статус, название события, ID события, способ передачи и параметры источника. Не размещайте открытые персональные данные клиентов в таблицах с общим доступом. Сначала проверьте реальные бизнес-события, затем — передачу событий и только после этого анализируйте рекламную атрибуцию. Такой порядок обычно упрощает поиск причины по сравнению с одновременным изменением нескольких настроек.

Компаниям, использующим комплексные услуги по созданию сайтов и маркетингу, например 易营宝, разработчики сайта, специалисты по рекламе и администраторы могут совместно работать с этой записью, согласовав критерии успешной отправки формы, статусы заказов и правила регистрации событий. После каждого обновления сайта, замены плагина или добавления страницы на новом языке следует повторно проверить всю цепочку.

Универсального «нормального процента расхождений», подходящего для всех аккаунтов, не существует. Поводом для беспокойства должны стать резкий рост разницы, обнуление определённого типа событий или несколько событий покупки после одной отправки. Чтобы устранить расхождения конверсий Facebook (conversionunterschiede facebook), важно не добиваться красивых цифр, а обеспечить обоснованность данных на каждом этапе. Только тогда рекламный бюджет можно будет оценивать надёжно.