Настройка Conversions API Meta: дедупликация event_id и EMQ

Что такое Conversions API и чем он отличается от пикселя?

Conversions API (API конверсий, CAPI) отправляет события — покупку, добавление в корзину, заявку — не из браузера посетителя, а с вашего сервера или платформы магазина напрямую в Meta. Пиксель работает в браузере, и событие может потеряться из-за блокировщика рекламы, ограничений cookie или медленной загрузки страницы. Запрос «сервер — сервер» браузерные блокировщики остановить не могут.

Частая ошибка — считать CAPI заменой пикселя. Meta рекомендует резервную схему: одно и то же событие приходит и от пикселя, и с сервера, а Meta склеивает их в одно. Если браузер событие потерял, его закрывает сервер; если серверному событию не хватает данных, помогают cookie fbp и fbc, которые несёт пиксель.

Если цифры Meta после настройки всё равно расходятся с данными магазина или GA4, разберитесь в причинах по статье о том, почему не сходятся цифры Shopify, Meta и GA4.

Какой способ подключения CAPI выбрать?

Если сайт на готовой платформе (Shopify, Tilda, WooCommerce) или вы используете Google Tag Manager, начните со встроенной интеграции; для самописных сайтов подойдут Conversions API Gateway или прямая интеграция. Выбор зависит от того, есть ли у вас разработчик и насколько гибко нужно управлять событиями.

Простое правило: если в админке магазина есть поле для токена доступа Meta или пункт «Conversions API» — начинайте оттуда. Если такого поля нет и нет разработчика — смотрите в сторону Gateway. Если у вас нестандартная оплата, подписки с автопродлением или офлайн-продажи, прямая интеграция в долгосрочной перспективе даст самые точные данные.

Как включить Conversions API в Shopify и Tilda?

В Shopify CAPI включается уровнем передачи данных в приложении Facebook & Instagram, в Tilda — вводом ID пикселя и токена доступа в настройках форм. В обоих случаях задача одна: выбрать правильную настройку и проверить результат в «Тестовых событиях».

Shopify

В админке пройдите Sales channels > Facebook & Instagram > Settings > Data sharing settings и выберите уровень в блоке Customer data sharing. По справке Shopify, уровень Standard использует только пиксель, а Enhanced и Maximum добавляют Conversions API и передают для сопоставления персональные данные клиента. Значит, для CAPI нужен как минимум Enhanced — и обновлённая политика конфиденциальности магазина.

Tilda

Tilda — частый выбор для лендингов и небольших магазинов в русскоязычном сегменте. Сначала в Events Manager (Менеджере событий) откройте свой пиксель, перейдите в настройки и сгенерируйте токен доступа в разделе Conversions API. Затем в Tilda откройте Настройки сайта > Формы > Facebook Conversion API, укажите ID пикселя и токен, а в контенте нужных форм отметьте галочку отправки в Conversions API. Согласно справке Tilda, серверно передаются события Lead (отправка формы), Purchase (успешная оплата картой) и InitiateCheckout. Про event_id справка ничего не говорит, поэтому после подключения обязательно посмотрите в «Тестовых событиях», склеиваются ли браузерные и серверные события.

WooCommerce, GTM и другие платформы

Логика та же: токен доступа из Events Manager плюс ID пикселя вводятся в официальный плагин, серверный контейнер GTM или модуль интеграции. Названия пунктов меню меняются от версии к версии, поэтому ориентируйтесь на актуальную справку своей платформы и после установки проходите проверку, описанную ниже.

Как работает дедупликация пикселя и CAPI по event_id?

Meta считает два события одним, если eventID в пикселе совпадает с event_id на сервере, а названия событий (event и event_name) одинаковы. По документации Meta, дубли удаляются, только если приходят в течение 48 часов после получения первого события с этим event_id; при одинаковом содержании обычно сохраняется то, что пришло первым.

Надёжнее всего строить идентификатор покупки из номера заказа. Например, для заказа 10482 в браузере отправляется fbq('track', 'Purchase', {value: 25000, currency: 'KZT'}, {eventID: 'order_10482'}), а в серверном событии — "event_name": "Purchase" и "event_id": "order_10482". Обе стороны берут значение из одного источника, поэтому расхождения не возникает.

Почему это критично, видно на условном примере: за неделю было 120 реальных заказов, пиксель поймал 95, CAPI — 118. Без дедупликации Events Manager покажет до 213 покупок, число покупок и ROAS окажутся примерно в 1,8 раза выше реальных, а алгоритм начнёт оптимизироваться на ложный сигнал. С рабочей дедупликацией цифра останется около 120.

У Meta есть и второй способ — передавать вместо event_id то же название события вместе с fbp и/или external_id. Но документация уточняет: он работает, только если событие сначала пришло из браузера, а потом с сервера, и бесполезен, когда источник один (только браузер или только сервер). Поэтому event_id — основной механизм, а fbp и external_id — вспомогательные сигналы.

Как нормализовать и хешировать данные клиента?

Email, телефон, имя, фамилию, город и индекс сначала приводят к формату Meta, а затем хешируют SHA-256; IP-адрес, user agent, fbc и fbp отправляются без хеширования. Если очистка до хеширования сделана неправильно, хеш тоже будет неправильным и сопоставления не произойдёт.

Почему номера +7 и +998 так часто ломают сопоставление?

Правило Meta звучит так: убрать символы и ведущие нули, номер должен содержать код страны. В Казахстане номера часто хранятся как 8 701 123 45 67, +7 (701) 123-45-67 или 7011234567. Ведущая «8» — это не ноль, и автоматически она не исчезнет: её нужно заменить на код страны вручную, чтобы все три варианта до хеширования превратились в 77011234567. В Узбекистане номер +998 90 123 45 67 или 90 123 45 67 должен стать 998901234567. Номер с «+», с «8» в начале или без кода страны даёт другой хеш, и поле просто не участвует в сопоставлении. Если код страны собирается отдельным полем формы, проверьте, не дублируется ли он при склейке.

• SHA-256 считается от уже нормализованного значения
• Телефон содержит только цифры и начинается с кода страны (7, 998 и т. д.)
• Email переведён в нижний регистр, пробелы убраны
• client_ip_address и client_user_agent уходят в исходном виде
• Cookie fbc и fbp добавляются и в серверное событие
• Для авторизованных клиентов передаётся постоянный external_id

Что такое качество сопоставления событий (EMQ) и как его повысить?

Качество сопоставления событий (Event Match Quality) по шкале от 0 до 10 показывает, насколько хорошо переданные данные клиента позволяют связать событие с аккаунтом Meta. Оценку видно в Events Manager отдельно по каждому событию вашего набора данных.

EMQ обычно растёт не от новых инструментов, а от заполнения недостающих полей. При покупке email и телефон у вас почти всегда есть — если они не уходят в Meta, начинайте с этого. Дальше добавляйте fbc (идентификатор клика по рекламе), fbp, IP и user agent. У событий верхней воронки вроде PageView персональных данных нет, и низкая оценка там — норма; следить стоит прежде всего за Purchase, InitiateCheckout и Lead.

1. Измерьте Запишите оценку EMQ для Purchase и рекомендации по недостающим параметрам.
2. Найдите пробелы Посмотрите, какой ключ передаётся реже всего — чаще всего телефон или fbc.
3. Исправьте Поправьте правила нормализации в коде или настройках платформы.
4. Проверьте Убедитесь в «Тестовых событиях», что новые события несут нужные параметры.
5. Подождите и сравните Дайте оценке несколько дней на обновление и зафиксируйте дату изменения.

Как проверить настройку через «Тестовые события»?

Откройте набор данных в Events Manager, вкладку Test Events («Тестовые события»), передайте выданный код в серверных событиях как test_event_code и убедитесь, что одно и то же событие видно с источниками «Браузер» и «Сервер», а одно из них помечено как дедуплицированное. Самая надёжная проверка — реальный тестовый заказ.

1. Получите тестовый код Скопируйте его в блоке проверки серверных событий на вкладке Test Events.
2. Вызовите события Откройте товар, добавьте его в корзину и оформите тестовый заказ.
3. Сравните источники Посмотрите браузерную и серверную строки Purchase и их event_id.
4. Проверьте параметры В серверном событии должны быть хешированные em/ph, а также fbc, fbp, IP и user agent.
5. Уберите тестовый код После проверки удалите test_event_code из боевой отправки.

За чем следить после запуска?

Первые две недели раз в неделю сверяйте число Purchase с заказами в магазине, оценку EMQ и предупреждения в Events Manager. Задача CAPI — не увеличить цифру, а приблизить её к реальности: если покупок в Meta заметно больше, чем заказов, снова проверьте дедупликацию.

Не забывайте о согласии пользователей. Серверные события не зависят от браузерных блокировок, но в политике конфиденциальности нужно прямо указать, какие данные и зачем вы передаёте рекламным платформам — с учётом закона о персональных данных страны, где работает магазин. Связь согласия на cookie и измерений разобрана в статье о Consent Mode v2 и приватности.

Сравнивать конверсии Meta, Google Ads и GA4 на одном экране — самый практичный способ вовремя заметить расхождение между платформами. Экран анализа конверсий в Marpany ставит эти источники рядом с данными магазина, так что после запуска CAPI видно, приблизились ли покупки к реальному числу заказов. Какие метрики отслеживать, подскажет гид по KPI рекламы, а как поднять конверсию на стороне сайта — статья об оптимизации конверсии интернет-магазина.

Что сделать дальше

• Выберите способ: интеграция платформы, Gateway или прямой API
• Удалите дублирующие коды пикселя из шаблона и GTM
• Для Purchase используйте общий event_id на основе номера заказа
• Приведите телефоны к формату «только цифры с кодом страны» и захешируйте
• Проверьте браузерные и серверные события тестовым заказом в Test Events
• Названия меню на сентябрь 2026 года могут меняться — раз в неделю смотрите EMQ и предупреждения