Meta CAPI Gateway vs прямая интеграция: какая доставка подходит вашему стеку
Три способа доставлять серверные события в Meta
Каждая серверная конверсия Meta в итоге проходит через эндпоинт Conversions API (почему серверный путь выживает, см. серверный трекинг против браузерных пикселей). Вопрос в том, что стоит перед этим эндпоинтом в вашем стеке. Паттернов три.
Прямая интеграция: ваш бэкенд формирует payload и POST'ит его в Conversions API - до 1000 событий в батче, с дедупликацией по назначенному вами event_id. Meta CAPI Gateway - отдельный продукт Meta, который вы разворачиваете как серверный инстанс в собственном облачном аккаунте: ваш Meta Pixel форвардит браузерные события в Gateway, а Gateway переправляет всё в Meta по server-to-server соединению. Третий паттерн - делегирование: управляемый инструмент собирает и отправляет payload, и вы не поддерживаете ни код, ни облако.
Правильный выбор зависит не столько от фич, сколько от того, чем вы готовы владеть. Gateway даёт софт под управлением Meta на инфраструктуре, которую вы оплачиваете и обслуживаете. Прямая интеграция даёт полный контроль без инфраструктуры - и полную ответственность за ретраи, хэширование и дедупликацию. Делегирование меняет часть контроля на отсутствие эксплуатации как таковой.
Как устроен Meta CAPI Gateway
У архитектуры Gateway есть полезное свойство: ваш Meta Pixel конфигурируется с Gateway-эндпоинтом, поэтому каждый выстрел пикселя в браузере уходит и в Meta как обычно, и в Gateway по HTTPS. Дальше Gateway переправляет поток событий в эндпоинт Conversions API. Одна конверсия, два канала, ни строчки своего кода.
Дедупликация - то, где DIY-связки чаще всего ломаются, - здесь автоматическая. Gateway сам генерирует и пропагирует дедупликационный ключ event_id между каналами, поэтому браузерная и серверная копии конверсии схлопываются в одну без вашего дедуп-кода. При прямой интеграции этот ключ - ваша забота: один и тот же event_id должен ехать и с пиксельным событием, и с API-событием, см. дедупликацию Facebook Pixel и CAPI.
По деплою Gateway провижинится через Events Manager в облачный аккаунт вашего бизнеса - поддерживаются AWS (EKS и ECS Express через App Runner) и GCP. Один инстанс держит несколько доменов и несколько Meta Pixel - важно, если лендингов или брендов много. Для агентств и реселлеров Meta дополнительно документирует host management на много рекламных аккаунтов с маршрутизацией данных по аккаунтам через control plane.
Когда Gateway лучше прямой интеграции
Gateway окупает свою инфраструктуру в трёх ситуациях. Первая: несколько доменов или пикселей под одной крышей - один инстанс покрывает domain.com, domain.co.uk и все остальные свойства с настройкой на уровне пикселей вместо правки кода на каждом лендинге. Вторая: агентские операции - host management позволяет одному деплою обслуживать много рекламных аккаунтов с управляемой маршрутизацией данных; прямая интеграция даёт это только через собственную мультиарендную обвязку. Третья: команды, которым нужна пара браузер+сервер без строчки кода доставки - пиксельное дублирование и дедуп, которые DIY-интеграции пишут руками, встроены.
Есть и аргумент про расположение данных. Инстанс Gateway живёт в вашем облачном аккаунте, в вашем регионе, под вашими биллингом и политиками доступа - некоторые procurement- и compliance-процессы про это спрашивают. Meta позиционирует предсказуемую стоимость стороннего облачного инстанса как фичу; в гайде по App Runner есть отдельная страница cost monitoring - правильное место, чтобы посчитать инстанс под свой объём событий, вместо доверия цифрам из чужих блогов.
Когда прямая интеграция лучше Gateway
Прямая интеграция выигрывает всюду, где браузерный пиксель не центр вашего потока. Арбитраж и перфоманс собирают конверсии постбеками трекера: пиксель на странице благодарности не стреляет, дублировать нечего - а главное удобство Gateway, автоматическое пиксельное дублирование, здесь нечего и включать. Ваш сервер уже знает о конверсии; кратчайший путь - сформировать payload и POST'ить его в Conversions API с event_id, который назначил трекер.
Прямой интеграции не нужна отдельная инфраструктура доставки: нечего патчить, нечего обновлять, когда Meta выпускает новую версию Gateway, нет отдельной строчки в облачном счёте и настроек скейлинга под всплески трафика. Хост трекера и его очередь продолжают делать свою работу - вы не надстраиваете второй, меташный стек. Для одиночного лендинга или горстки кампаний это решает вопрос само: поднимать Kubernetes- или App Runner-стек ради форварда событий, которые можно отправить напрямую, - тратить операционный бюджет на решённую задачу.
Расплата - инженерная собственность. Прямая значит, что форматирование payload, SHA-256-хэширование, ретрай-политика и дисциплина event_id, на которой держится дедуп, - ваши. Если это работа, которую команда сделает за неделю, прямой путь дешевле; если её некому делать - читайте дальше.
Управляемая середина для трекерного трафика
Между self-hosted Gateway и самописными прямыми вызовами лежит вариант, который трекерным командам нужен чаще всего: делегировать доставку. MOST подключает постбеки трекеров к Conversions API Meta (а также TikTok, Snapchat, Pinterest, Reddit и OpenAI), централизованно делая форматирование payload, ретраи и дедупликацию - ровно те обязанности, что прямая интеграция кладёт на вас, без облачного инстанса, которого требует Gateway. Для одиночного лендинга и ручного воркфлоу тот же путь доставки бесплатно закрывает Pixel Activator.
Если вы пришли к этому сравнению, выбирая server-side tag manager, отметьте родство: sGTM - тоже self-hosted инфраструктура, которую вы эксплуатируете ради маршрутизации событий, - механика миграции и цены в гайде по миграции с server-side GTM. Логика решения та же: каждый self-hosted хоп покупает контроль и стоит эксплуатации.
Путь выбора за пять минут
Ответьте на четыре вопроса по порядку. Конверсии рождаются постбеками трекера, а не браузерными сессиями? Начинайте с прямой или управляемой доставки: документированный вход Gateway - браузерный пиксель-скрипт, открытого эндпоинта для приёма трекерных постбеков у него нет, серверные события идут напрямую в Conversions API. Под одной командой много доменов, пикселей или клиентских аккаунтов? Это design-case Gateway, и host management - его главный аргумент. Команда уже эксплуатирует облака и держит on-call? Тогда Gateway ляжет в существующую практику; если владельца облачной эксплуатации нет, кластер ради форварда событий превратит интеграцию в вечную нагрузку. И последнее: страшнее всего дедупликация? Gateway автоматизирует её, managed-инструменты забирают себе, прямая интеграция делает проблемой вашего тестового прогона - механика в дедупликации по event ID.
Куда бы вы ни повернули, валидируйте до масштабирования: Meta Test Events показывает доставку на уровне полей для пикселя и сервера, а кластер целиком собирает полный гайд по Meta Conversions API.