Meta Conversions API: почему одного пикселя уже мало и как внедрить без дублей

Пиксель Meta работает в браузере посетителя и поэтому от него зависит. Если в браузере включён блокировщик рекламы, файл пикселя не загружается, и покупка до Meta так и не доходит — хотя деньги уже на вашем счёте. Conversions API (дальше — CAPI) отправляет то же событие с вашего сервера, где блокировщиков нет.

Этот текст — о том, когда CAPI стоит внедрять, как связать его с пикселем, чтобы покупки не удваивались, и как обращаться с персональными данными. Пишем из практики: недавно мы внедряли CAPI на сайте WordPress с плагином бронирования и оплатой картой.

Почему одного пикселя уже мало

Первый признак обычно виден при сравнении отчётов: покупка есть в Google Analytics, а в Meta её нет. Одна из причин — заблокированный в браузере файл пикселя fbevents.js. Такую покупку Meta не видит, не приписывает рекламе и на ней не учится.

После запуска CAPI мы видели в журнале именно такие случаи: пиксель в браузере был заблокирован, а сервер покупку отправил. Без серверной части Meta этих покупок не получила бы.

Сразу две оговорки:

• CAPI не обходит согласие на cookie. Если посетитель не согласился на маркетинговые cookie, сервер не должен отправлять ничего — так же, как и пиксель.
• CAPI не исправляет ошибки на стороне браузера. Если пиксель отправляет дубли или Purchase ещё до оплаты, сервер эти ошибки только повторит. Сначала приведите в порядок пиксель, потом беритесь за сервер.

Как это работает

1. Посетитель платит, платёжная система подтверждает оплату.
2. В браузере пиксель отправляет Purchase с уникальным номером события (event_id).
3. Ваш сервер отправляет тот же Purchase с тем же event_id на адрес Meta Graph API /<pixel_id>/events.
4. Meta объединяет оба сообщения в одну покупку. Если пиксель был заблокирован, остаётся сообщение сервера.

Запрос сервера выглядит примерно так (в сокращении; ключ доступа передаётся параметром access_token):

POST https://graph.facebook.com/<версия>/<pixel_id>/events
{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1760000000,
    "event_id": "purchase-a1b2c3",
    "action_source": "website",
    "event_source_url": "https://example.com/spasibo",
    "user_data": {
      "em": ["<SHA-256 e-mail>"],
      "ph": ["<SHA-256 телефона>"],
      "client_ip_address": "…",
      "client_user_agent": "…"
    },
    "custom_data": { "value": 45.00, "currency": "EUR" }
  }]
}

Дублей не будет, если совпадает event_id

Когда событие приходит и из браузера, и с сервера, Meta должна понять, что это одна и та же покупка. Для этого у обоих сообщений должны совпадать event_name и event_id. В коде пикселя он передаётся четвёртым параметром:

fbq('track', 'Purchase', { value: 45.00, currency: 'EUR' }, { eventID: 'purchase-a1b2c3' });

Обратите внимание: в коде пикселя параметр называется eventID, а в запросе сервера — event_id. Их легко перепутать.

event_id лучше всего строить из данных самого заказа — например, из внутреннего номера заказа и названия события. Тогда браузер и сервер знают его независимо друг от друга. Случайный номер, созданный только в браузере, серверу неизвестен — и дедупликация не сработает. Если event_id не совпадает или его нет, одна покупка может быть засчитана дважды, и вы возвращаетесь к проблеме, от которой уходили.

Персональные данные: хеш до отправки

Чтобы Meta могла связать событие с человеком, сервер отправляет вместе с ним e-mail и телефон. Но не открытым текстом: оба значения хешируются SHA-256 до отправки. Перед хешированием данные обязательно нормализуют, иначе они не совпадут с тем, что есть у Meta:

• e-mail — строчными буквами, без пробелов в начале и в конце;
• телефон — в международном формате, только цифры, без «+» и пробелов: 8 6xx xxxxx превращается в 3706xxxxxxx.

Нехешированные данные мы нигде не храним — ни в журнале, ни в дополнительных таблицах. В журнале остаётся только то, отправлено ли событие и что ответила Meta. IP-адрес и идентификатор браузера (user agent) Meta принимает без хеширования.

Поскольку данные уходят с вашего сервера в Meta, это должно быть описано в политике конфиденциальности. Обновите её до запуска, а не после.

Согласие действует и для сервера

В браузере пиксель ждёт согласия сам — его придерживает плагин cookie. Сервер об этом не знает, поэтому должен проверить согласие сам: прочитать cookie плагина согласия (например, Complianz) и отправлять событие, только если посетитель согласился на маркетинговые cookie. Без согласия сервер не отправляет ничего, даже хешированные данные.

Ключ доступа и тестовый код

Ключ доступа CAPI генерируется в настройках Events Manager. Он хранится в конфигурации сервера — на WordPress, например, константой в файле wp-config.php, — а не в базе данных и не в письмах. Если ключ пересылали по e-mail, после запуска сгенерируйте новый.

При тестировании в разделе Events Manager «Test events» вы получаете test_event_code. Пока он добавляется к запросам сервера, события идут как тестовые и показываются в разделе «Test events». Meta указывает использовать это поле только для тестов, поэтому после проверки его обязательно нужно очистить. Удобнее всего держать его отдельной настройкой: вписали — тестируете, стёрли — работает вживую. Забытый тестовый код — ошибка, которую легко допустить и трудно заметить.

Meta отвечает на каждый запрос — в ответе есть поле events_received, сколько событий принято. Ошибочный ответ стоит записывать в журнал и сразу сообщать ответственному человеку, а не оставлять ошибки лежать молча.

Почему цифры всё равно не совпадут

Даже с CAPI Meta, GA4 и ваша система будут показывать разные цифры. Главная причина — окна атрибуции. Meta по умолчанию приписывает покупку рекламе, если она случилась в течение 7 дней после клика или 1 дня после просмотра. GA4 может смотреть назад до 90 дней. Это нормально: сравнивайте тенденции, а не точные цифры, а единственной правдой считайте оплаченные заказы в своей системе.

Сколько это стоит

У некоторых платформ и плагинов есть интеграция CAPI через партнёров Meta — сначала проверьте свою. У плагинов бронирования и собственных систем её может не быть, или она может отправлять не те события; тогда пишется собственный поток. В нашем прайсе такие интеграции попадают в диапазон 500–2 000 €, точную цену называем, увидев вашу систему. Подробнее — на странице услуги автоматизации.

Если заказываете работу другому программисту, впишите в техническое задание как минимум: формат event_id, нормализацию и хеширование данных, проверку согласия на сервере, место хранения ключа доступа и журнал ошибок. Как составить такое задание, мы писали в статье о техническом задании для программиста.

Что сделать завтра

1. Сравните оплаченные заказы за прошлый месяц: сколько их в вашей системе, сколько в GA4 и сколько в Meta.
2. Проверьте, нет ли у вашей платформы или плагина готовой интеграции Conversions API.
3. До внедрения решите, из чего будет строиться event_id и как сервер будет проверять согласие.

Частые вопросы

Обходит ли Conversions API согласие на cookie?

Нет. Сервер должен проверять то же согласие, что и пиксель. Без согласия на маркетинговые cookie он не отправляет ничего.

Можно ли использовать только Conversions API, без пикселя?

Можно, но Meta рекомендует использовать их вместе. Пиксель создаёт cookie _fbp, которое сервер может передать вместе с событием, — так Meta проще связать событие с человеком. А сервер защищает от блокировщиков.

Как понять, хорошо ли сопоставляются данные?

Events Manager показывает для серверных событий оценку качества сопоставления (Event Match Quality). Если она низкая, сначала проверьте, отправляются ли e-mail и телефон и нормализованы ли они перед хешированием.