Conversions API Meta нужен даже при установленном пикселе, потому что пиксель видит только то, что происходит в браузере, а браузер теряет часть событий и ничего не знает о том, что случилось с заявкой дальше. Серверная передача возвращает потерянные события и позволяет отдать в Meta данные из CRM: какая заявка стала квалифицированной, какая превратилась в продажу. Сама Meta рекомендует использовать пиксель и Conversions API вместе.
Обычно разговор о Conversions API начинается с одной и той же сверки. Руководитель смотрит в рекламный кабинет, видит 120 заявок за месяц, открывает CRM и насчитывает 150. Или наоборот: в кабинете всё красиво, цена лида падает, а отдел продаж жалуется, что половина заявок с таргета не берёт трубку. В обоих случаях пиксель работает ровно так, как его настроили. Проблема в том, что ему не хватает данных.
Что такое Conversions API Meta простыми словами
Conversions API — это способ передавать события в Meta не из браузера посетителя, а с вашего сервера, сайта или CRM напрямую. Пиксель срабатывает на странице, когда человек отправил форму или открыл страницу «спасибо». Conversions API отправляет то же событие со стороны сервера, где данные о заявке уже лежат.
Для Meta оба канала сходятся в одном месте. Серверные события привязываются к идентификатору набора данных (dataset) и обрабатываются так же, как события пикселя. Это сказано в документации Meta о Conversions API. Для рекламного алгоритма нет разницы, откуда пришла заявка, если он может понять, что это одна и та же заявка.
Отсюда главный практический вывод, который часто упускают: Conversions API не заменяет пиксель. В руководстве Meta по дедупликации событий прямо написано, что для лучших результатов рекламы Conversions API стоит внедрять вместе с пикселем. Каналы страхуют друг друга.
Почему пиксель теряет заявки
Пиксель теряет события, потому что зависит от браузера посетителя. Если браузер не загрузил код пикселя или не отправил запрос в Meta, событие пропадает, и восстановить его задним числом нельзя.
Причин несколько, и почти все они не зависят от качества настройки:
- блокировщики рекламы и трекеров в браузерах и на уровне сети;
- встроенные настройки приватности браузеров, которые ограничивают сторонние скрипты;
- человек закрыл вкладку сразу после отправки формы, и страница «спасибо» не успела загрузиться;
- форма на сайте отправляет данные без перехода на новую страницу, а событие висит на загрузке страницы;
- разработчик обновил тему или конструктор перевёл формы на новый движок, и событие перестало срабатывать.
Сервер от всего этого не зависит. Заявка в любом случае дошла до сайта или CRM, иначе её бы не было в отделе продаж. Если в этот момент сервер отправит событие в Meta, оно дойдёт, даже когда браузерный пиксель промолчал.
Посчитаем на условном примере. Компания в Алматы тратит на таргет 600 000 тг в месяц и получает 150 заявок, то есть по 4 000 тг за заявку. Если пиксель потерял пятую часть событий, кабинет покажет 120 заявок и цену 5 000 тг. Маркетолог отключит пару объявлений, которые на самом деле работали, потому что по отчёту они выглядят дорогими. Цифры здесь иллюстративные, но механика именно такая.
Для рекламного кабинета потерянные события означают две вещи. Первая: отчёты показывают меньше заявок, чем было, и цена лида выглядит выше реальной. Вторая, более дорогая: алгоритм обучается на неполной выборке и хуже понимает, какие люди оставляют заявки. Установку и проверку самого пикселя мы подробно описывали в статье о пикселе Meta и проверке событий, здесь речь о том, что надстраивается поверх него.
Чем Conversions API отличается от пикселя
Главное отличие в том, откуда берутся данные: пиксель знает только о действиях на странице, сервер знает о заявке всё, что записано в вашей системе, включая то, что произошло через дни и недели после клика.
| Параметр | Пиксель Meta | Conversions API |
|---|---|---|
| Откуда отправляется событие | Из браузера посетителя | С сервера, сайта или CRM |
| Зависит от блокировщиков и настроек браузера | Да | Нет |
| Видит события после ухода с сайта | Нет | Да: звонок, квалификация, оплата |
| Источники событий (action_source) | Сайт | Сайт, телефонный звонок, чат, магазин, приложение, переписка и другие |
| Кто настраивает | Маркетолог или разработчик сайта | Разработчик, интегратор CRM или готовая интеграция платформы |
Строка про источники важнее, чем кажется. В спецификации серверных событий параметр action_source принимает значения email, website, app, phone_call, chat, physical_store, system_generated, business_messaging и other. Это значит, что через Conversions API в Meta можно передать продажу, которая случилась по телефону или в переписке, а не только заявку с формы. Пиксель такую продажу не увидит никогда.
Какие данные передаются через Conversions API
Каждое серверное событие содержит название, время, источник и данные о человеке, по которым Meta сопоставляет событие с аккаунтом. Обязательные параметры по спецификации серверных событий Meta: event_name, event_time, user_data и action_source.
Два ограничения стоит знать до начала работ. Время события передаётся в формате Unix в секундах и не может быть старше 7 дней на момент отправки: если в запросе окажется событие старше, Meta отклонит весь запрос. Поэтому передавать события лучше сразу, а не раз в неделю пачкой.
Второе касается персональных данных. Согласно описанию параметров клиента, почта, телефон, имя, фамилия, город, страна и внешний идентификатор клиента перед отправкой хэшируются алгоритмом SHA-256. А вот IP-адрес, user agent браузера и идентификаторы fbp и fbc отправляются как есть, без хэширования. Телефон перед хэшированием нормализуют: убирают символы, буквы и ведущие нули и обязательно добавляют код страны, даже если все клиенты из одной страны. Для Казахстана это значит, что номер 8 701 123 45 67 из формы нужно привести к виду 77011234567, иначе совпадений почти не будет.
На проектах B2BPRO.KZ мы чаще всего видим именно эту ошибку: Conversions API подключён, события идут, но телефон уходит в том виде, в котором его ввёл посетитель, с восьмёркой, пробелами и скобками. Технически интеграция работает, а сопоставление с аккаунтами слабое.
Как пиксель и сервер не задваивают заявки
Дубли не появляются, если у одного и того же события совпадают идентификатор и название в браузере и на сервере. Этот механизм называется дедупликацией.
Правила Meta такие. eventID в пикселе должен совпасть с event_id на сервере, а название события в пикселе с event_name на сервере. Склейка работает, если события пришли в течение 48 часов после получения первого события с этим идентификатором. Из двух дублей Meta, как правило, оставляет то, которое пришло первым. В качестве идентификатора документация советует брать то, что однозначно определяет операцию, например номер заказа или транзакции. Для сайта услуг это номер заявки.
Есть запасной способ для тех, кто не может передавать идентификатор события: если параметры external_id и fbp уходят и из браузера, и с сервера, Meta постарается убрать дубли сама. Но у него есть ограничения. Он надёжно работает, когда браузерное событие приходит раньше серверного, и не отбрасывает серверное событие, если браузерного не было в последние 48 часов. Поэтому основным вариантом остаётся общий идентификатор.
Если дедупликацию забыли, результат виден сразу: заявок в кабинете становится почти вдвое больше, чем в CRM, цена лида падает, и кажется, что реклама резко подешевела. Такой сбой опаснее потерь: цифры выглядят лучше реальных, и никто не спешит их проверять.
Как передать в Meta качество заявок из CRM
Самая ценная часть Conversions API для бизнеса с отделом продаж — передача стадий сделки из CRM. Реклама перестаёт оптимизироваться на любые заявки и начинает искать людей, похожих на тех, кто дошёл до квалификации или оплаты.
У Meta для этого есть отдельная интеграция: Conversions API для CRM и цель эффективности Conversion Leads. Требования в документации конкретные:
- Не меньше 200 лидов в месяц.
- Загрузка данных из CRM регулярно, не реже раза в день.
- В CRM хранится идентификатор лида Meta длиной 15-17 цифр.
- Конверсия в стадию, под которую оптимизируется реклама, от 1% до 40%.
- Эта стадия наступает в пределах 28 дней после заявки.
Есть важное ограничение: цель Conversion Leads совместима только с лид-формами Facebook и Instagram (Instant Forms). Для заявок с сайта логика другая: события отправляются как обычные серверные события с источником website, а стадии сделки можно передавать отдельными событиями.
Для казахстанского бизнеса, у которого заявки из рекламы попадают в Битрикс24 или другую CRM, это самый ощутимый эффект Conversions API. Пока алгоритм учится на факте заявки, он приводит тех, кто охотно заполняет формы. Когда он видит, какие заявки стали сделками, он начинает приводить тех, кто покупает.
Как проверить, что Conversions API работает правильно
Проверять нужно не только факт прихода событий, но и качество сопоставления. Для этого у Meta есть оценка качества сопоставления событий (Event Match Quality) в Events Manager.
Event Match Quality — это оценка по шкале до 10, которая показывает, насколько данные о клиенте, отправленные с сервера, помогают сопоставить событие с аккаунтом Meta. Она учитывает, какие параметры клиента пришли, насколько они качественные и какой процент событий удалось сопоставить. По описанию Dataset Quality API, сейчас оценка доступна только для веб-событий.
Рядом с ней стоит смотреть ещё три показателя:
- покрытие событий: средний за 7 дней процент событий пикселя, которые продублированы через Conversions API и имеют общие ключи дедупликации;
- свежесть данных: задержка между моментом события и моментом, когда Meta его получила;
- дедупликация: доля событий пикселя и сервера, пришедших с каждым ключом дедупликации.
Практическая проверка после запуска занимает неделю. Сначала тестовые события: отправить заявку с сайта и убедиться, что в Events Manager она пришла и из браузера, и с сервера, и отмечена как дубль. Потом ежедневная сверка числа заявок в кабинете и в CRM. Расхождение в пару десятков процентов объяснимо разной логикой атрибуции, расхождение в разы означает поломку.
Как подключают Conversions API: три варианта
Подключить Conversions API можно тремя путями: через готовую интеграцию вашей платформы, через промежуточный сервис или собственной разработкой, когда сервер сайта или CRM сам отправляет события на эндпоинт Meta. Выбор зависит от того, где живут заявки и насколько точные данные вы хотите передавать.
Готовая интеграция платформы подходит, если сайт работает на конструкторе или CMS, где подключение Conversions API встроено или ставится плагином. Это быстро, но возможности ограничены тем, что заложил разработчик интеграции. Чаще всего такие решения передают события с сайта и не знают ничего о стадиях сделки в CRM.
Промежуточный сервис (сервер тегов или коннектор между CRM и Meta) даёт больше гибкости без глубокой разработки. Им удобно пользоваться, когда заявки приходят из нескольких источников: сайт, лид-формы, мессенджеры. Минус в том, что появляется ещё одно звено, за которым нужно следить и за которое, как правило, нужно платить.
Собственная интеграция — самый трудоёмкий, но самый точный вариант. Сервер сайта или CRM сам формирует событие, нормализует и хэширует данные клиента, подставляет номер заявки в качестве идентификатора и отправляет всё в Meta в момент, когда заявка создана или сменила стадию. Именно так мы обычно делаем для компаний, у которых заявки собираются в Битрикс24.
Что подготовить в CRM и на сайте до подключения
До начала работ стоит убедиться, что сайт и CRM сохраняют данные, без которых серверное событие получится слепым. Обычно это пять пунктов:
- Каждая заявка получает уникальный номер, который одинаково известен и странице с пикселем, и серверу.
- Форма сохраняет вместе с заявкой значения cookie
_fbpи_fbc, чтобы сервер мог отправить их какfbpиfbc. - Телефон хранится в одном формате с кодом страны, а не так, как его ввёл посетитель.
- Для лид-форм в карточке сделки сохраняется идентификатор лида Meta.
- В политике обработки персональных данных на сайте упомянута передача данных рекламным платформам: этот вопрос лучше заранее обсудить с юристом.
Если хотя бы одного пункта нет, интеграция всё равно заработает, но качество сопоставления будет ниже, а часть событий не склеится с браузерными.
Когда Conversions API нужен, а когда можно подождать
Conversions API окупается, когда решения по рекламе принимаются по цене заявки или продажи, а бюджет достаточно велик, чтобы потерянные события искажали картину. Небольшому бизнесу с одним лендингом и десятком заявок в неделю разумнее начать с аккуратно настроенного пикселя.
| Ситуация | Что делать |
|---|---|
| Один лендинг, мало заявок, бюджет на тесте | Настроить пиксель с событием на успешной отправке формы, Conversions API отложить |
| Заявки в кабинете заметно расходятся с CRM | Подключить Conversions API с дедупликацией для заявок с сайта |
| Много заявок, но низкое качество лидов | Передавать в Meta стадии сделки из CRM |
| Лид-формы Instagram и Facebook, от 200 лидов в месяц | Рассмотреть Conversions API для CRM и цель Conversion Leads |
По срокам ориентир такой. Если сайт на платформе с готовой интеграцией, базовое подключение занимает дни. Если нужна связка сайта, CRM и Meta с нормализацией телефонов, общими идентификаторами и передачей стадий сделки, это проект на пару недель с участием разработчика. Сама Meta оценивает время до первого эффекта от интеграции с CRM примерно в месяц, и этот срок может меняться.
Если вы уже тратите на таргет заметные деньги и не уверены, на чём учится алгоритм, начните со сверки кабинета и CRM за последний месяц. Мы делаем такую сверку в начале каждого проекта, когда нас просят заказать таргетированную рекламу или разобраться с уже работающими кампаниями: смотрим, какие события получает Meta, откуда, с какими данными, и сколько заявок теряется по дороге.
Частые вопросы
Нужен ли Conversions API, если пиксель Meta уже установлен?
Да, если реклама оптимизируется на заявки или продажи и бюджет заметный. Пиксель теряет события из-за блокировщиков и настроек браузеров и не видит, что стало с заявкой после сайта. Meta сама рекомендует использовать Conversions API вместе с пикселем, настроив дедупликацию, чтобы одна заявка не считалась дважды.
Можно ли заменить пиксель на Conversions API полностью?
Можно, но не рекомендуется. По рекомендации Meta лучший результат дают оба канала вместе: браузер передаёт данные о поведении на странице, сервер страхует от потерь и добавляет данные из CRM. Чтобы события не задваивались, у пикселя и сервера должны совпадать идентификатор события и его название.
Почему после подключения Conversions API заявок стало вдвое больше?
Почти всегда это отсутствие дедупликации: одна заявка приходит и из браузера, и с сервера, и Meta считает её дважды. Нужно передавать одинаковый eventID в пикселе и event_id на сервере вместе с одинаковым названием события. Склейка работает в окне 48 часов после первого события.
Какие данные клиента нужно хэшировать для Conversions API?
Почту, телефон, имя, фамилию, город, страну и внешний идентификатор клиента хэшируют алгоритмом SHA-256. IP-адрес, user agent браузера и идентификаторы fbp и fbc передают без хэширования. Телефон перед хэшированием приводят к формату с кодом страны, для Казахстана без восьмёрки и пробелов: 77011234567.
Можно ли передать в Meta продажи из Битрикс24?
Да, через Conversions API можно передавать события из CRM, в том числе стадии сделки и оплату. Для лид-форм Facebook и Instagram у Meta есть отдельная интеграция с CRM и цель Conversion Leads, для неё нужно от 200 лидов в месяц, ежедневная загрузка данных и хранение идентификатора лида Meta в CRM.