Как трекать конверсии Facebook-рекламы для партнерских офферов

Медиабайер, который льёт гемблинг-оффер в LATAM, в понедельник утром открывает Ads Manager: за выходные залогировано 40 покупок. Его CRM, которую питают постбеки партнёрской сети, показывает 71 депозит по той же кампании за тот же период. Никто не «украл» 31 конверсию — Facebook их просто не увидел. Депозит случился через два дня после клика, на домене рекламодателя, в сессии, где пиксель Meta вообще не грузился. Если вы пытаетесь трекать конверсии Facebook-рекламы для партнерских офферов и цифры не сходятся — причина почти всегда именно в этом, и лечится это правильным наслоением сигнала, а не увеличением бюджета.

Почему Facebook занижает конверсии партнерских офферов

Стандартный Facebook Pixel построен на допущении «тот же домен, та же сессия»: юзер кликает по рекламе, попадает на ваш сайт, конвертится на вашем сайте, пиксель срабатывает на вашем сайте. Партнёрские воронки ломают каждое звено этой цепочки. Клик происходит на вашем прелендинге или трекинговом домене с фильтрацией трафика, пиксель (если он там вообще есть) срабатывает там же, а затем юзера редиректит на домен рекламодателя — казино, дейтинг-платформу, брокера — где и происходит реальное конверсионное событие (депозит, FTD, подтверждённая регистрация) без какого-либо трекинга Meta. У Facebook нет ни строчки кода на чекауте рекламодателя, в форме депозита или в KYC-флоу, поэтому структурно он не может увидеть событие, которое на самом деле для вас важно.

Добавьте к этому стандартную деградацию браузерного трекинга, с которой все и так борются: Safari ITP обрезает время жизни кук, адблокеры глушат запросы пикселя напрямую, юзеры конвертятся с другого устройства, чем то, с которого кликнули. По отраслевым оценкам, потеря браузерного сигнала обычно составляет 10–40% в зависимости от ГЕО и вертикали — и это до учёта кросс-доменного разрыва, специфичного именно для партнёрской модели. Сложите обе проблемы — и вполне типична картина, когда конверсии, заявленные Facebook, составляют половину или меньше от того, что реально зафиксировала ваша CRM.

Последствие — это не просто неудобство в отчётности. Алгоритм Facebook оптимизируется под тот сигнал, который получает. Если он видит только 40 из 71 депозита, он оптимизирует ваш бюджет под ту аудиторию, которая принесла именно эти 40 — а это может быть совсем не ваш лучший по конверсии сегмент. В итоге вы платите за масштабирование неправильных lookalike-аудиторий, пока ваш реальный трафик с самым высоким LTV не получает никакого алгоритмического признания.

Три уровня трекинга, которые вам нужны

Чтобы это исправить, нужно принять, что ни один отдельный источник сигнала сам по себе не полон. Три уровня, каждый из которых ловит то, что упускают остальные:

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

CAPI и постбек решают разные половины проблемы. CAPI восстанавливает события, которые ваш собственный трекинговый домен мог бы увидеть, но браузер их потерял. Постбек репортит о событиях, при которых ваш трекинговый домен вообще не присутствовал, потому что они случились дальше по воронке, в системе рекламодателя. Именно для арбитража трафика постбек закрывает разрыв, который реально стоит вам денег — депозиты, FTD, подтверждённые аккаунты, — пока CAPI убирает шум вокруг стандартных событий.

Если хотите глубже разобраться в механике того, как каждый уровень ведёт себя под давлением адблокеров и ограничений на куки, смотрите Pixel против Conversions API против S2S Postback.

Построение цепочки сигнала: от click_id до конверсионного события

Механизм, который связывает все три уровня воедино, — это единый устойчивый идентификатор, который выживает на протяжении всего пути: клик, редирект, домен рекламодателя, конверсия и возврат к Facebook. Вот этот путь:

Клик попадает на ваш трекинговый домен. Ваш трекер генерирует click_id (или эквивалент, производный от fbclid) и логирует клик с кампанией, группой объявлений, объявлением и любыми сабпараметрами, нужными для сегментации.
click_id передаётся рекламодателю. Он едет как URL-параметр через всю цепочку редиректов до лендинга оффера, а затем переносится через их флоу регистрации/депозита — обычно через скрытое поле, subid-параметр или партнёрский токен трекинга, который система рекламодателя уже поддерживает.
Рекламодатель стреляет постбеком при конверсии. В момент, когда депозит проходит или лид квалифицируется, бэкенд рекламодателя вызывает ваш postback URL с click_id и статусом.
Ваш трекер сопоставляет click_id с исходным кликом, восстанавливая полную цепочку атрибуции: какое объявление, какой креатив, какое ГЕО, какой плейсмент реально принесли этот депозит.
Facebook получает событие CAPI, помеченное тем же event_id, который используется для дедапа, и несёт любой сигнал идентификации, который у вас есть (хешированный email, external ID, fbc/fbp на момент клика, если они зафиксированы), чтобы движок сопоставления Meta смог привязать её обратно к исходному показу рекламы.

Пример postback URL с макросами, которые ваш трекер ожидает заполненными системой рекламодателя:

https://track.yourdomain.com/postback?click_id={click_id}&status=deposit&payout={payout}&currency={currency}&event_id={click_id}_deposit

А вот CAPI payload, который ваш бэкенд отправляет сразу после прихода постбека, используя тот же event_id для дедапа против всего, что ещё может выстрелить браузерный пиксель:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1751980800,
      "event_id": "abc123click_deposit",
      "action_source": "website",
      "user_data": {
        "em": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
        "external_id": "abc123click"
      },
      "custom_data": {
        "currency": "USD",
        "value": 45.00
      }
    }
  ]
}

Именно event_id предотвращает двойной подсчёт, если браузерный пиксель тоже успел поймать более лёгкий сигнал раньше в той же сессии — Facebook дедапит любое событие с одинаковым ID между отправками пикселя и CAPI.

Маппинг статусов конверсии на события Facebook

В партнёрских вертикалях редко бывает одна конверсия — там есть целая воронка статусов, и каждый из них может как заслуживать, так и не заслуживать того, чтобы попасть в Facebook как отдельное оптимизационное событие. Регистрация — это не депозит, а депозит — это не ребилл. Отправка всех их в Facebook как общих событий Purchase убивает способность алгоритма отличить лид за $2 от FTD за $200.

Статус воронки	Типичное событие Facebook	Отправлять в Facebook?
Просмотр лендинга	`PageView`	Опционально — низкая ценность, большой объём
Сабмит формы / регистрация	`Lead` или `CompleteRegistration`	Да — ранний сигнал для оптимизации
Первый депозит (FTD)	`Purchase`	Да — основная цель оптимизации
Ребилл / повторный депозит	Кастомное событие, напр. `Rebill`	Иногда — полезно для биддинга с учётом LTV, но не путайте с FTD
Чарджбек / рефанд	Не отправляется, либо сверяется только через CRM	Нет — у Facebook нет нативного флоу для негативных событий

Этот маппинг должен жить как конфигурация, а не как код — каждый новый статус, который вводит ваша вертикаль (статус KYC-verified, веха второго депозита), должен назначаться на имя события Facebook без тикета инженеру. Именно этот разрыв закрывает настройка пикселей DarkCore: маппинг событий настраивается по статусу, по пикселю, так что deposit может маппиться на Purchase для одного оффера и на кастомное событие для другого — без правок постбек-темплейта каждый раз, когда запускается новая вертикаль.

Типичные ошибки

Отправка каждого статуса постбека как Purchase. Это сводит регистрации, депозиты и ребиллы в один сигнал, что ломает способность Facebook оптимизироваться именно на ценных юзеров. В итоге алгоритм гонится за объёмом вместо качества депозитов.
Пропуск дедапа event_id между пикселем и CAPI. Без общего event ID та же самая конверсия считается дважды — раз от того сигнала, который выстрелил в браузере, и раз от серверного события — это раздувает отчётные конверсии и незаметно портит математику ROAS.
Потеря click_id при редиректе на домен рекламодателя. Если партнёрская сеть или рекламодатель не переносят надёжно ваш идентификатор клика через собственный флоу регистрации/депозита, то постбек, который в итоге прилетит, не с чем сопоставить, и конверсия остаётся без атрибуции, хотя технически ваш бэкенд её получил.
Восприятие CAPI как замены постбеку. CAPI восстанавливает только события, при которых присутствовал ваш собственный домен. Он не может отчитаться о депозите, который случился полностью внутри системы рекламодателя спустя несколько дней — этот разрыв закрывается только реальным S2S-постбеком от рекламодателя или сети.
Отправка событий CAPI без учёта задержки. Депозит, который случился через 3 дня после клика, всё равно должен атрибутироваться к исходному показу рекламы. Если ваша логика таймстемпа события или окна атрибуции предполагает конверсию в той же сессии, Facebook может отклонить событие как низкокачественное или вообще не сопоставить его с исходным кликом.

Настройка структуры рекламного кабинета под отложенный сигнал

Когда цепочка постбек-CAPI уже запущена, возникает проблема второго порядка: структура вашего рекламного кабинета должна выдерживать задержку между расходами и подтверждённым сигналом. Если депозиты приходят через 2-5 дней после клика, кампании, оптимизированные на однодневное окно атрибуции, всегда будут выглядеть хуже, чем есть на самом деле, а автоматические правила Facebook — которые видят только пиксельные данные на стороне FB — могут поставить на паузу или придержать кампанию, которая на самом деле хорошо работает по вашей CRM.

Практические корректировки:

Устанавливайте окна атрибуции в Ads Manager в соответствии с вашим реальным медианным временем до депозита, а не дефолтом платформы.
Не позволяйте собственным автоматическим правилам Facebook принимать бюджетные решения только на основе пиксельных данных, если ваше реальное конверсионное событие находится глубоко в воронке и задерживается — эти правила не видят того, что уже подтвердила ваша CRM.
Держите достаточно исторических расходов в каждой группе объявлений перед тем, как оценивать результативность; кампания, которая выглядит холодной в первый день, потому что депозиты ещё не пришли, может выглядеть совершенно иначе на четвёртый день, когда постбеки догонят.

Именно здесь автоматизация, построенная вокруг ваших реальных бэкенд-данных, окупается — настройка стрима и пикселя DarkCore позволяет авто-правилам действовать на основе подтверждённых CRM-депозитов и дохода, а не любого частичного сигнала, который в этот момент случайно имеет собственный дашборд Facebook, — а это важнее всего именно в том сценарии отложенной конверсии, который партнёрские офферы создают по умолчанию.

Как проверить, что настройка реально работает

Прежде чем доверять цифрам, проверьте каждое звено цепочки отдельно:

Сделайте тестовый клик через свою трекинговую ссылку и убедитесь, что click_id залогирован с правильными ID кампании/группы объявлений/объявления.
Вручную инициируйте (или дождитесь) тестовый постбек от рекламодателя/сети и проверьте, что ваш трекер сопоставляет его с исходным кликом, а не со случайной или несопоставленной конверсией.
Проверьте Events Manager Facebook на предмет соответствующего события CAPI — убедитесь, что имя события, значение и event_id пришли как ожидалось, и что качество сопоставления (покрытие email/external ID) не помечено как низкое.
Сравните заявленные Ads Manager конверсии за определённый день с подтверждёнными конверсиями вашей CRM для той же когорты несколько дней спустя, когда отложенные события успеют прийти. Устойчивый большой разрыв после этого окна означает, что какое-то звено цепочки — обычно передача click_id — всё ещё сломано.

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

Заменяет ли CAPI Facebook Pixel полностью?

Нет. CAPI предназначен работать параллельно с пикселем, с дедапом на основе event_id, чтобы пересекающиеся события не считались дважды. Пиксель по-прежнему ценен для дешёвых, высокообъёмных сигналов на ранних этапах воронки; задача CAPI — восстанавливать то, что теряет браузер, а не заменять браузерный уровень.

Могу ли я отправлять события депозита в Facebook, если рекламодатель не поддерживает S2S-постбек?

Только частично, и только если вы сами контролируете какую-то часть конверсионного флоу — например, если ваш прелендинг редиректит через домен, который вы можете инструментировать, или рекламодатель предоставляет какой-то API/вебхук. Если система рекламодателя — это чистый чёрный ящик без постбека и без API, надёжного способа вернуть это конкретное событие в Facebook не существует, и стоит честно признать, что ваш сигнал для оптимизации этого оффера всегда будет неполным.

Каким должно быть окно атрибуции Facebook для партнерских офферов с отложенными депозитами?

Установите его так, чтобы покрывать ваш реальный медианный срок до депозита, который можно взять прямо из таймстемпов «клик-конверсия» вашего трекера. Однодневное окно клика на оффере, где депозиты обычно приходят на 2-3 день, будет систематически недоатрибутировать — независимо от того, насколько хорошо настроены ваши CAPI и постбек.

Какие минимальные данные идентификации нужны CAPI, чтобы хорошо сопоставить событие?

Как минимум — хешированный email или external ID, привязанный к исходному клику. Добавление IP, user agent и браузерных ID fbc/fbp, зафиксированных на момент клика (если у вас вообще было какое-то браузерное присутствие), существенно улучшает уровень сопоставления, особенно для событий, которые срабатывают спустя несколько дней после завершения исходной сессии.

Как вернуть себе полную картину

Всё это не требует экзотической инфраструктуры — нужно лишь принять, что дашборд Facebook никогда не увидел бы вашу полную воронку самостоятельно, потому что конверсия, которая приносит вам деньги, происходит там, куда пиксель Facebook никогда не приглашали. Постбек восстанавливает событие, CAPI возвращает его в Meta с сохранённым дедапом, а маппинг статусов держит алгоритм в оптимизации именно на те депозиты, которые реально важны, вместо сведённой общей «purchase». Стрим и настройка пикселя DarkCore обрабатывают эту цепочку по умолчанию — передача click_id, роутинг постбеков по статусам и дедап CAPI сшиты вместе, а не вручную. Если цифры вашего Ads Manager и CRM давно не сходятся, стоит сначала проверить цепочку, а уже потом бюджет — пишите нам в Telegram.