Conversions API Meta — это прямая передача маркетинговых событий с сервера, сайта, приложения или CRM в Meta для измерения и оптимизации рекламы.
Одна покупка может уйти в Meta двумя дорогами. Pixel сообщает о ней из браузера. Сервер отправляет то же событие через CAPI. Это не две покупки, а два свидетельства одного действия. Если не научить их узнавать друг друга, резервный канал превратится в двойной подсчёт.
Поэтому главный вопрос при настройке — не «видим ли мы Server», а «сохраняется ли идентичность события от бизнес-действия до обоих каналов».
Pixel, зеркало и настоящее серверное событие
Под названием CAPI скрываются разные реализации. Они отличаются не логотипом интеграции, а местом, где рождается серверное событие.
Событие от Pixel
- возникает в браузере
- видит контекст страницы
- зависит от выполнения клиентского кода
- удобно для быстрой диагностики
Событие от сервера
- возникает в бэкенде или CRM
- может подтверждать результат бизнеса
- не требует повторной загрузки страницы
- требует явного сопоставления и контроля доступа
Простейшая интеграция может взять браузерный сигнал и переслать его серверным маршрутом. Это полезно для быстрого старта, но такой маршрут не вернёт событие, которого браузер вообще не создал. Партнёрская интеграция платформы уже может опираться на оформленный заказ. Собственное соединение с бэкендом или CRM даёт больше контроля и больше ответственности за данные.
Документация Meta охватывает не только сайт: источником могут быть приложение, переписка с бизнесом или офлайн-результат. Значит, CAPI стоит проектировать от факта, который бизнес может подтвердить, а не от набора событий, уже существующих в Pixel.
Дедупликация: одно действие, один идентификатор
Meta рекомендует отправлять важные события сайта через Pixel и CAPI как резервную пару. Для каждого действия оба канала должны получить одинаковое название и единый уникальный идентификатор.
В браузерном вызове параметр называется eventID, в серверном — event_id. Написание отличается, значение — нет. Так же должно совпадать event_name. Если браузер отправляет Purchase, а сервер — собственное название того же действия, у системы нет рекомендованной пары для дедупликации.
Идентификатор должен обозначать событие, а не пользователя. Номер заказа часто подходит для покупки, если он уникален и доступен обоим маршрутам. Для лида нужен другой стабильный ключ. Использовать электронный адрес как event_id не следует: один человек может совершить несколько разных действий, а персональные данные имеют отдельные правила передачи.
Meta описывает и альтернативное сопоставление через external_id и fbp, но одинаковые название события и event_id — рекомендованный и самый прозрачный маршрут. Простота здесь важна: ошибку можно воспроизвести на одном контрольном действии.
Какие поля несут смысл, а не просто проходят проверку
Серверный запрос должен ответить на несколько отдельных вопросов: что произошло, когда, откуда пришло действие, как его узнать и какую ценность оно имело. Формально принятый запрос всё ещё может быть слабым сигналом.
| Критерий | Что проверить | Что ломается |
|---|---|---|
| Идентичность | event_name и event_id | дубль или отдельное событие |
| Время | фактическое время действия | ложная последовательность пути |
| Источник | action_source и URL для сайта | неверный контекст |
| Сопоставление | допустимые данные клиента | слабая связь с взаимодействием |
| Ценность | сумма и валюта из бизнес-системы | неверная окупаемость |
| Согласие | разрешённый объём данных | нарушение выбора пользователя |
Meta требует action_source для серверных событий, а для событий сайта — также event_source_url. Обязательность поля не гарантирует правильности его значения.
Данные клиента используются для сопоставления, но больше полей не всегда означает лучше. Передавать следует только то, что законно получено, уместно для события и правильно нормализовано. CAPI — не обход согласия. Серверная природа маршрута не меняет решения человека об использовании его данных.
Ценность тоже должна поступать из надёжного места. Если браузер берёт сумму со страницы благодарности, а сервер — из заказа после скидки, расхождение нужно решать на уровне определения события. Событие Purchase должно означать одно и то же бизнес-действие в обоих каналах.
Проверка после запуска
В Events Manager можно увидеть способ подключения, свежесть событий и состояние дедупликации. Проверку проводят не на случайном трафике, а на контрольном действии с известными параметрами.
Сначала подтвердите получение браузерной и серверной версий. Затем найдите общий идентификатор. Убедитесь, что после обработки они считаются одним событием. Проверьте задержку: событие, пришедшее слишком поздно, может быть технически принято, но менее полезно для оперативной оптимизации. Наконец, сверьте сумму, валюту и источник действия.
Не оценивайте запуск только по общему росту количества конверсий. Внезапный рост может быть не возвращением сигнала, а дублированием. Сначала нужна правильность на уровне отдельного события, затем стабильность потока и только после этого оценка влияния на кампании.
Общая последовательность проверки аналитики до запуска рекламы собрана в чек-листе аналитики, но для CAPI критерием приёмки всегда остаётся пара «одно действие — одна итоговая запись».
Если у серверного события нет собственного подтверждённого источника, общего event_id и проверенной дедупликации, отметка Server в кабинете ещё не означает, что CAPI выполняет свою работу.