CAPI в арбитраже 2026: серверный пиксель, one-click от Meta и ловушка дедупликации

Если у вас есть рабочий пиксель Meta и вы не трогали его настройки с весны, серверная передача конверсий у вас, скорее всего, уже включена. 15 апреля 2026 года Meta запустила one-click CAPI и разослала владельцам пикселей уведомление с окном на тридцать дней — не на согласие, а на ознакомление. У тех, кто за это время ничего не сделал, функцию включили автоматически. Окно закрылось в середине мая.

Для команды без технического специалиста это подарок: серверный трекинг без сервера и разработчика. Для байера с настроенным постбеком из Keitaro или Binom — повод открыть Events Manager и посмотреть, что там сейчас происходит с дедупликацией.

Разбираем, как устроен Conversions API в арбитраже, каким связкам он обязателен, каким хватит пикселя и как убедиться, что конверсии не считаются дважды.

Почему в 2026-м пикселя уже не хватает

Браузерный пиксель теряет данные сразу с нескольких сторон. ATT (App Tracking Transparency — запрос разрешения на отслеживание, который iOS показывает пользователю) режет трекинг на устройствах Apple. Блокировщики рекламы перехватывают пиксельные запросы до того, как они уходят. VPN сбивает атрибуцию по IP.

Safari добивает остатки механизмом ITP (Intelligent Tracking Prevention). Куку, поставленную по ссылке с меткой, он держит сутки — а именно так к вам и приходит трафик из Meta, с хвостом fbclid. Обычные куки, выставленные через JavaScript, живут до семи дней бездействия. Если между кликом и конверсией прошло больше, пиксель уже не свяжет эти два события. Подробнее о том, как работают куки в арбитраже, — в отдельном разборе.

Сколько именно теряется, зависит от вертикали и доли мобильного трафика. Отраслевые замеры 2026 года дают вилку: без CAPI пиксель доносит до Meta 40–60% реальных конверсий, на мобильном трафике с iOS-аудиторией — меньше. Точную цифру по своей связке не назовет никто, кроме вас: сверьте за одни сутки конверсии в кабинете с конверсиями в трекере, разница и будет вашей потерей.

Для байера это выглядит не как потеря данных, а как рост CPL. Алгоритм видит меньше конверсий, чем происходит в реальности, обучается на неполной выборке и закупает нецелевой трафик. Кабинет при этом выглядит нормально: кажется, что рынок просто подорожал.

По данным анонса Meta от 15 апреля 2026 года аккаунты с настроенным CAPI для веб-событий показывают в среднем на 17,8% более низкий cost per result, чем те, где работает только пиксель. Это агрегированная статистика по всем рекламным аккаунтам платформы, а не кейс одной команды.

Если пиксель Meta вы еще не ставили, начинать все равно нужно с него: CAPI не заменяет браузерный сигнал, а дополняет его.

Что такое CAPI и как он устроен

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

Серверный и браузерный пиксель — в чем разница

Классический пиксель — это JavaScript-код на странице. Когда пользователь совершает действие на лендинге, браузер отправляет запрос на серверы Meta. Путь короткий: браузер пользователя → Meta. И вся цепочка зависит от того, что происходит на стороне клиента: поставил блокировщик, отключил куки, зашел через Safari — событие не долетело, атрибуция потеряна.

Conversions API отправляет данные в обход браузера. Путь другой: ваш сервер → Meta. Блокировщику тут нечего перехватывать, отключенные куки не мешают отправке, и кабинет получает событие независимо от того, что творится в браузере.

Сравнение пикселя и CAPI

Схема передачи данных: от конверсии до оптимизации

Воронка передачи данных через CAPI работает как непрерывная цепочка S2S-запросов (server-to-server — обмен между серверами напрямую, без участия браузера).

1. Пользователь кликает по крео. Meta присваивает клику уникальный идентификатор — fb_click_id. Трекер его фиксирует и сохраняет.
2. Пользователь оставляет заявку или вносит депозит на лендинге.
3. Лид фиксируется на стороне партнерской программы.
4. ПП отбивает постбек о конверсии в трекер.
5. Трекер подтягивает к конверсии сохраненный fb_click_id и через серверный запрос отдает событие в API Meta.
6. Meta получает событие, связывает его с конкретным показом рекламы и засчитывает конверсию объявлению.

Алгоритм видит полную картину и обучается на реальных данных: кто конвертит, в какое время, с каких площадок. Именно это дает снижение CPL.

Ключевой параметр в цепочке — fb_click_id. Без него событие дойдет до Meta, но она не свяжет его с конкретным кликом по объявлению: конверсия попадет в неатрибутированные и на оптимизацию не повлияет. Проверяется просто — если в трекере у конверсии пустой fbclid, событие уходит в никуда.

Когда CAPI нужен, а когда хватит пикселя

Решает не вертикаль, а устройство воронки: где происходит целевое действие и сколько до него шагов. По этому признаку связки делятся на три группы.

Без CAPI не обойтись

Есть два случая, когда серверная передача — не улучшение трекинга, а единственный способ вернуть данные о конверсии в рекламный кабинет.

Редирект на сайт рекламодателя. Пользователь проходит через ваш лендинг и уходит на домен партнерки или оффера, регистрация и депозит происходят уже там. Пиксель на чужой домен не поставить. CAPI получает событие через постбек от партнерки в трекер и передает его в Meta. Так устроено большинство криптоофферов: крипта как вертикаль почти целиком работает через редирект на брокера.

Переход на платежный шлюз. Страница оплаты технически принадлежит банку или платежному агрегатору — оплата SS-нутры, инфопродукты с подпиской, депозит в гемблинге. Без серверной интеграции алгоритм не увидит финальное целевое действие, будет оптимизироваться по регистрациям вместо депозитов и в итоге остановит открут как убыточный.

CAPI заметно добавит

Многошаговые воронки и отложенные конверсии — здесь прирост атрибуции самый ощутимый.

• Товарка со сложным флоу. Пользователь кликает по объявлению, проходит через прелендинг, лендинг, форму заказа — и только потом происходит покупка. Пиксель теряет цепочку на каждом редиректе. CAPI передает итоговое событие напрямую с сервера независимо от того, сколько шагов было до него.
• Серые ниши и SS-товарка. Пиксель на клоакированном лендинге живет до первого бана домена, и бан пикселя обнуляет накопленные данные. Постбек летит с сервера и не зависит от того, что происходит со страницей.

На больших спендах потеря становится ощутимее всего: чем шире охват, тем больше конверсий не доезжает до кабинета. CAPI возвращает их, стабилизирует цену закупки и помогает алгоритму быстрее выходить из фазы обучения.

Хватит пикселя

Не каждая связка требует серверной интеграции. Если конверсия происходит в один шаг прямо на том лендинге, куда пришел пользователь, усложнять сетап незачем — это касается вертикалей с линейной воронкой: дейтинг по CPL-модели, нутра с одношаговой формой заявки.

При небольших объемах трафика стандартного пикселя на странице достаточно. CAPI в таких связках не даст ощутимой разницы в ROI, зато потребует времени на настройку.

Пошаговая настройка CAPI через Events Manager

Интерфейс Events Manager регулярно обновляется. Скриншоты ниже сняты в июне 2026 года — перед настройкой сверьтесь с тем, что видите в своем кабинете.

Шаг 1. Открываем Events Manager и создаем датасет

Откройте Ads Manager. В левом меню найдите раздел Events Manager — он в нижней части навигации — и перейдите в него. Если рекламный кабинет еще не разложен по полкам, начните с настройки кабинета.

Нажмите «Подключить источники данных». В открывшемся окне выберите «Интернет» и нажмите «Далее».

На следующем шаге Meta предложит создать датасет — объект, к которому будут привязаны и пиксель, и серверные события CAPI. Назовите его понятно: по имени домена или оффера. Категорию бизнеса указывать необязательно. Нажмите «Создать».

Шаг 2. Выбираем способ подключения

После создания датасета Meta перейдет к экрану выбора способа подключения. Здесь четыре варианта — для байера с трекером нужен только один.

• Настройка через Stape. Платное решение: Stape разворачивает серверную инфраструктуру за вас. Для байера с трекером избыточно — постбек из Keitaro или Binom закрывает ту же задачу без дополнительных затрат. Пометка «Рекомендовано» на скриншоте — не повод выбирать этот вариант: Meta подбирает ее по данным о компании, и у вас она может стоять у другого варианта.
• Настройка с помощью Meta (one-click, бесплатно). Работает только со стандартными веб-событиями. Если у вас уже идет S2S-постбек из трекера, сначала прочитайте следующий раздел — там разбор того, что при этом происходит с дедупликацией.
• Настройка с партнерской интеграцией. Подключение через платформы-партнеры Meta: Shopify, WooCommerce и другие CMS. Для арбитража нерелевантно.
• Настройка вручную. Прямые запросы к Meta Graph API. Для байера с трекером это рабочий путь: Keitaro или Binom самостоятельно формируют и отправляют серверные запросы в API Meta. Выбирайте этот вариант.

Шаг 3. Выбираем события и получаем доступы

После выбора «Настройка вручную» Meta предложит отметить события, которые будут передаваться через CAPI.

Отмечайте только те, которые реально происходят в вашей воронке и которые трекер может передать через постбек. Для гемблинга и нутры это «Лид» и «Завершенная регистрация», для товарки — «Покупка» и «Начало оформления заказа». Лишние события без данных снижают качество датасета.

Дальше Meta перейдет к генерации токена доступа. Нажмите «Сгенерировать маркер доступа», скопируйте его и сохраните в надежном месте: повторно он не отображается. Это ключ, который авторизует ваш сервер отправлять события в Meta.

Второй доступ, который понадобится, — Pixel ID (в новом интерфейсе он же идентификатор датасета). Отдельным экраном при создании он не выводится: откройте в Events Manager созданный датасет → вкладка «Настройки» → идентификатор указан в верхней части страницы.

Шаг 4. Вставляем доступы в трекер и проверяем передачу

Токен и Pixel ID вставляются в настройки интеграции на стороне трекера — порядок для Keitaro и Binom разобран ниже, в разделе про интеграцию.

После этого проверьте передачу в Events Manager, во вкладке «Тестирование событий»: отправьте тестовый постбек из трекера и убедитесь, что событие появилось в реальном времени и с корректными параметрами.

One-click CAPI от Meta — что изменилось в апреле 2026

15 апреля 2026 года Meta запустила Meta-enabled Conversions API — бесплатное подключение серверного трекинга прямо из Events Manager. Не нужен сервер, технический специалист и правка кода лендинга: инфраструктуру Meta держит у себя.

Деталь запуска, о которой в анонсе сказано вскользь: владельцам действующих пикселей Meta разослала уведомление с окном на тридцать дней, и это было окно на ознакомление, а не на согласие. У тех, кто за это время ничего не сделал, функция включилась сама. Окно закрылось в середине мая 2026 года.

Отсюда практический вывод. Вопрос не в том, включать ли one-click, а в том, включен ли он у вас уже. Отключить можно в любой момент в том же Events Manager, и отключение держится — обратно само не встает.

Кому one-click действительно нужен

Порог входа он снижает почти до нуля: раньше требовался сервер, доступ к коду и понимание S2S-интеграции, теперь достаточно одной кнопки. Ценность это дает:

• командам без технического специалиста, которые раньше работали только на браузерном пикселе;
• товарке и e-commerce на стандартных событиях — Purchase, Lead, AddToCart, InitiateCheckout;
• тем, кому нужен базовый серверный сигнал быстро и без разработки.

Ограничение одно, но существенное: one-click работает только со стандартными веб-событиями. Кастомные события, офлайн-конверсии и multi-platform routing (раздача одного события сразу в несколько источников — сайт, приложение, офлайн) не покрываются. Для арбитражных связок, где конверсия приходит постбеком с кастомными параметрами, этого мало.

Что происходит, если one-click включился поверх трекера

Позиция Meta такая: для тех, у кого уже настроена собственная серверная интеграция или интеграция через партнера, новая опция аддитивна и менять ничего не нужно. One-click зеркалит то, что уже отправляет пиксель, и дедуплицирует эти события сам.

Тонкость в другом. Дедупликация Meta срабатывает по совпадению двух параметров — event_id и event_name. Трекер генерирует свой event_id, и это не тот идентификатор, который стоит в пикселе на лендинге. Если у вас идентификаторы не сквозные, серверные события из трекера и события пиксельного потока Meta считает разными конверсиями. С включенным one-click пиксельный поток удваивается на серверную сторону, и расхождение становится заметнее.

Проверяется это не на слово, а сверкой. Возьмите одни сутки и сравните число конверсий в кабинете с числом в трекере. Заметно больше в кабинете — дедупликация не работает, и алгоритм учится на завышенном сигнале, закупая мусорный трафик. Кабинет при этом выглядит отлично, проблема вскрывается только при сверке. Как сделать идентификатор сквозным — в следующем разделе.

CAPI и пиксель одновременно — как не получить дубли

Когда CAPI и браузерный пиксель работают параллельно, одно и то же событие летит в Meta дважды: первый раз из браузера пользователя, второй — с вашего сервера. Без настройки Meta засчитает их как две отдельные конверсии.

Механизм, который это предотвращает, называется дедупликацией. Meta склеивает браузерное и серверное событие в одну конверсию, если совпали два параметра: event_id и event_name. Есть и временные рамки — события склеиваются, только если пришли в пределах 48 часов друг от друга, после этого считаются разными. Если серверное и браузерное пришли почти одновременно, в пределах пяти минут, приоритет отдается браузерному.

48 часов — не формальность. Постбек от партнерки может прийти и через сутки, и через трое: во втором случае склейки не будет, даже если идентификаторы совпали.

Схема выглядит так:

• JS-пиксель отправляет конверсию: Lead, event_id «888».
• Трекер через CAPI отправляет конверсию: Lead, event_id «888».
• Совпали и название события, и идентификатор — Meta засчитывает одну конверсию.

Чтобы это работало, event_id генерируется на стороне лендинга и передается одновременно в пиксель через JavaScript и в CAPI через постбек. Надежнее всего генерировать идентификатор в момент клика и сохранять его в куки или прокидывать в параметрах URL вместе с fb_click_id.

Проверить дедупликацию можно в Events Manager: вкладка «Обзор событий», пометка «Дедуплицировано» рядом с событием. Если пометки нет, а объем событий вдвое выше ожидаемого, склейка не настроена.

Интеграция CAPI через трекер

Для байера с трекером CAPI — не отдельная система, а еще одна точка, куда трекер отправляет конверсию, получив постбек от партнерки. Ниже — Keitaro, Binom и набор параметров, общий для любого трекера.

Keitaro — S2S-постбек с fb_click_id и пикселем

Keitaro поддерживает нативную интеграцию с Meta CAPI: трекер принимает постбек от партнерки, подтягивает к нему сохраненные параметры клика и отправляет серверное событие в Meta.

Что должно быть настроено до начала работы:

• в параметрах кампании прописан макрос для захвата fbclid из URL — он сохраняется как отдельный параметр клика;
• в настройках интеграции с Facebook указаны Pixel ID и токен доступа из Events Manager;
• в URL постбека к партнерке передается {fbclid} — иначе при получении конверсии трекер не сможет подтянуть идентификатор клика.

Главный параметр — fb_click_id, он же fbclid, он же fbc. При клике по крео Meta автоматически дописывает этот хвост к ссылке. Получив постбек о конверсии, Keitaro берет сохраненный fb_click_id и включает его в серверный запрос к Meta Graph API.

Binom — схема передачи конверсий

В Binom логика та же, но настройка идет через API-интеграцию с рекламным аккаунтом. В разделе Traffic Sources выберите Facebook из шаблонов — трекер подставит нужные параметры для передачи {{ad.id}}. Что умеет трекер Binom помимо этого, разбирали отдельно.

Отдельно про расходы: раз в тридцать минут Binom обращается к Facebook API и обновляет данные по затратам в разрезе объявлений. Это синхронизация расходов, к передаче конверсий она отношения не имеет.

Конверсии идут своим механизмом. В настройках кампании укажите access_token из Events Manager и Pixel ID — Binom сформирует серверный запрос при получении постбека от партнерки. В запрос включаются event_name, event_time, event_id и fb_click_id, если параметр был захвачен при клике.

Общая логика для любого трекера

Какой бы трекер вы ни использовали — Keitaro, Binom, BeMob или другой, — состав S2S-постбека в Meta одинаковый. Минимальный набор параметров, без которых серверная передача либо не работает, либо работает вхолостую:

Хешированные email и phone передавайте только если партнерка отдает эти данные в постбеке. Meta требует хешировать их по алгоритму SHA-256 — это необратимое преобразование: из полученной строки исходную почту или телефон восстановить нельзя, поэтому отдавать хеш безопасно. Переданные контакты заметно вытягивают качество атрибуции.

Event Match Quality — почему это важнее, чем просто «подключить»

Сам факт настройки серверной передачи не гарантирует снижения цены лида. Алгоритму мало получить сигнал о том, что конверсия произошла, — ему нужно понять, кто именно ее совершил. За это отвечает Event Match Quality (EMQ) — оценка качества переданных данных по шкале от 0 до 10.

Чем выше оценка, тем точнее алгоритм связывает серверные лиды с профилями реальных пользователей. Базового постбека, где есть только IP-адрес и User-Agent, для этого мало.

Что поднимает EMQ:

• База для атрибуции — параметры fbp (идентификатор браузера) и fbc, он же fb_click_id. Без них серверный трекинг работает вхолостую.
• Контакты пользователя — если на лендинге он вводит телефон или почту, трекер должен перехватить их, захешировать и отправить в массиве user_data. Это и дает верхнюю часть шкалы.

Смотреть здесь: Events Manager → датасет → вкладка «Обзор событий». Зеленая зона, в которой оптимизация работает корректно, начинается с шести баллов. От семи и выше — хороший результат. От четырех до шести означает, что часть конверсий теряется на матчинге. Ниже четырех — серверный трекинг технически работает, но прироста атрибуции по сравнению с пикселем вы не получаете.

Чек-лист — готов ли ваш CAPI к работе

Проверьте сетап по этим девяти пунктам перед заливом трафика, чтобы не слить бюджет на кривую оптимизацию.

• Токен и Pixel ID. Access token и идентификатор датасета скопированы из Events Manager без лишних пробелов и прописаны в настройках трекера.
• One-click проверен. В Events Manager открыт датасет и проверено, включен ли Meta-enabled CAPI. Если включен, а серверная передача уже идет из трекера, — выключить.
• Дедупликация включена. Браузерный скрипт и серверный постбек отправляют идентичные event_id и event_name для каждого целевого действия.
• Клик привязан. Трекер перехватывает fb_click_id (fbc) из ссылки и отдает его обратно в Meta.
• База пользователя передается. В теле запроса уходят реальный IP-адрес клиента, не сервера, и его User-Agent.
• Контакты захешированы. Если воронка собирает email или номера телефонов, данные хешируются по алгоритму SHA-256.
• События совпадают. Название события в S2S-запросе точно соответствует стандартным событиям Meta.
• Тест пройден. Интеграция проверена во вкладке «Тестирование событий» с передачей test_event_code, ошибок в кабинете нет.
• EMQ в норме. Оценка качества сопоставления событий в зеленой зоне — от шести баллов.

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

Сначала откройте Events Manager и посмотрите, не включен ли one-click: это займет минуту и закрывает главный риск.

Потом сверьте за одни сутки конверсии в кабинете с конверсиями в трекере. Расхождение вверх означает задвоение, вниз — потерю данных, и лечатся эти два случая по-разному.

И только после этого лезьте в EMQ и параметры. Поднимать качество матчинга имеет смысл на потоке, который уже считается правильно.