Server side conversion delivery: путь конверсии от MMP и трекера до Meta и TikTok CAPI

Server side conversion delivery - это цепочка, которая доставляет конверсию от системы, измерившей ее, до рекламной платформы, оптимизирующей по ней, напрямую между серверами. В app-install воронке звена три: MMP атрибутирует инсталл, постбэк передает событие в трекер, а трекер или слой доставки отправляет его в Meta CAPI или TikTok Events API. На каждом хопе идентификаторы меняют хозяина, и каждый хоп - место, где сигнал может прийти неполным, поздним или задвоенным.

Разбор идет по хопам: какой ID рождается на каждом, как настраиваются постбеки между Keitaro, Binom, Voluum и RedTrack, и какие проверки сделать до масштабирования. За разделением ролей инструментов - в гайдах MMP vs affiliate-трекер и серверный трекинг против браузерного пикселя.

Что такое server side conversion delivery на самом деле

Браузерный пиксель держится на браузере: срабатывает тег, cookie опознает посетителя, страница фиксирует момент конверсии. У чистого инсталла приложения ничего этого нет: сигнал рождается внутри приложения, MMP измеряет его через SDK. Как только в воронке появляется веб-страница, к SDK добавляется пиксель - и оба события должны договориться. Поэтому server side conversion delivery для app-install кампаний - архитектура по умолчанию, а не апгрейд.

Та же логика двигает веб-воронки в сторону серверной доставки: cookie исчезают, блокировщики съедают теги, платформы доверяют событиям, которые можно проверить. Мотивация разобрана в атрибуции без cookie для аффилейт-маркетинга.

Три хопа: click ID туда, конверсия обратно

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

Клик       -> трекер генерирует уникальный click ID
Offer URL  -> ID едет с пользователем в оффер или апп-флоу
Конверсия  -> постбэк возвращает этот ID обратно
Доставка   -> трекер склеивает конверсию с кликом и отправляет событие в Meta CAPI или TikTok Events API

Voluum документирует шаблон напрямую: уникальный click ID на каждый клик едет в offer URL как s2=, сеть возвращает его постбеком, где #s2# подменяется макросом сети. Binom делает тот же обмен через и cnv_id.

Self-reporting сети ломают симметрию: Meta, Google Ads и TikTok сами атрибутируют инсталлы по device ID, когда MMP уведомляет их, и не передают клик-данные через атрибуционные ссылки. Цепочка click ID все равно важна: отчеты трекера и нога доставки держатся на идентификаторах, переживших предыдущие хопы.

Где живет click ID: ttclid, external_id, , #s2#

Названия меняются, работа остается: исходящий click ID должен вернуться в постбеке без изменений, иначе конверсию не склеить с кликом. Keitaro по умолчанию URL-энкодит значения плейсхолдеров; суффикс оставляет их сырыми. Потерянный ID не отменяет событие, но делает его анонимным: без sub-ID, без контекста лендинга, без ключа дедупликации.

Задокументированная пара Binom - ссылка оффера и ответный постбек:

Ссылка оффера в сеть:   your-network.example/offer?sub1={clickid}
Постбек сети в Binom:   your-binom.example/click.php?cnv_id={sub1}&payout={sum}&cnv_status={status}

Нога MMP: SRN-атрибуция и лимиты постбеков

Meta, Google Ads и TikTok - self-reporting сети: их клик-данные не едут к MMP через атрибуционные ссылки. Сеть сама атрибутирует событие, когда MMP уведомляет ее об инсталле, сверяя его со своими device-level логами кликов, а постбеки MMP живут в рамках partner data retention и лимитов SRN на user-level данные.

AppsFlyer держит click lookback window по умолчанию 7 дней: инсталлы внутри окна считаются неорганическими, после окна - органическими, и для SRN окно выравнивается по отчетности самой сети.

Adjust стреляет колбэком в момент триггера: ad engagement по ссылке или in-app событие через SDK. Колбэк несет advertising ID, атрибуцию и данные приложения в реальном времени; raw data Adjust не хранит, так что колбэки - единственный способ забрать сырые данные на свои серверы.

Режимы приватности режут ногу. С включенным Aggregated Advanced Privacy на уровне приложения или TikTok-партнера инсталл- и in-app постбеки уходят только по инсталлам, засчитанным рекламной сети; органика не постбэчится вовсе. Объем постбеков в TikTok настраивается на партнера: all media sources including organic или this partner only, а шаблон постбека следует за статусом согласия пользователя.

Нога трекера: прием и отправка S2S постбеков

Keitaro настраивает S2S постбеки на кампанию во вкладке S2S Postbacks: URL, метод GET или POST, статус конверсии, по которому уходит отправка. Пресет traffic source добавляет постбеки автоматически, возвращает click ID источника, а каждая исходящая отправка с ответом видна в Maintenance, затем Logs, затем S2S postbacks. Набор также закрывают , , и .

Маппинг статусов держит один URL валидным для нескольких статусов:

your-api.example/conversion?cid={external_id}&status={status:lead=0 sale=1 rejected=2}&revenue={revenue}

RedTrack принимает конверсии тремя способами с разной надежностью: прямая API-интеграция работает backend-to-backend и считается самой надежной; S2S постбэк не зависит от cookie, но требует поддержки со стороны сети, CRM или магазина; pixel или postback script - самый простой путь, который дублирует конверсии при рефреше thank-you страницы. В S2S-потоке каждая система хранит один уникальный click session ID, а тип конверсии едет как &type=event-name.

Binom показывает те же ручки с другой стороны: входящий постбек несет cnv_id, payout, cnv_status, cnv_currency и to_offer, а disable_postback=1 выключает исходящий постбек в traffic source. Правило Voluum: плейсхолдеры #s2# и #price# должны совпадать с макросами, которые реально поддерживает аффилиейт-сеть.

Нога Meta: требования CAPI к событию

Meta проверяет четыре поля каждого серверного события: event_name, стандартное или кастомное имя; event_time, unix-время в секундах; action_source, где произошло событие (website, app, email, phone_call, chat и другие, корректность на совести отправителя); и user_data, карта customer information.

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

Конкретная разводка этой ноги в Keitaro - в гайде Facebook CAPI через Keitaro.

Нога TikTok: Events API и матчинг ttclid

TikTok Events API работает по access token и живет в двух режимах: standalone или second channel рядом с Pixel. На каждый клик по рекламе TikTok добавляет ttclid, свой Click ID, в landing page URL и связывает его с кампанией. Веб-события, пришедшие через Pixel или Events API вместе с Click ID, матчятся для атрибуции, сбора аудиторий, оптимизации доставки и измерения.

Отсюда жесткое требование к ноге доставки: событие в сторону TikTok обязано нести ttclid, снятый в момент клика, иначе оно уйдет без матчинга. Настройка на стороне трекера, включая макросы токенов, - в гайде TikTok Events API для аффилейт-трекеров.

Дедупликация: одна дисциплина event_id на оба канала

Meta дедуплицирует браузерное событие против серверного по паре event_id и event_name (в браузерных терминах eventID и event) внутри одного пикселя. Совпавшая пара отбрасывает поздние копии, но только в пределах 48 часов от первого события с этим event_id. Из документации следуют два последствия: серверное событие не отбрасывается, если браузерное не приходило предыдущие 48 часов, даже если идентичное браузерное придет позже; а на единственном источнике дедупликации нет вовсе, и два одинаковых серверных события засчитаются оба. Meta также рекомендует передавать fbp, fbc или external_id одинаково в обоих типах каналов.

Правило TikTok шире: идентичные имя события плюс event_id в пределах 48 часов считаются дублями, причём дедупликация работает и внутри одного канала - и Pixel-Pixel, и Events API-Events API. Для пары Pixel и Events API она применяется к копиям, прибывшим после первых пяти минут внутри 48-часового окна. Разным событиям без пересечения дедуп не нужен.

Трекеры превращают дисциплину в конкретное поле: RedTrack шлет в Meta свой rtclickid или роль, назначенную параметру, как Event ID по обоим путям.

Бюджет задержек: латентность постбеков против дедлайнов API

Конверсия в этой цепочке опаздывает еще до отправки: случается инсталл, MMP атрибутирует его, постбэк доезжает до трекера, слой доставки форматирует и отправляет событие. Вся сумма упирается в жесткий дедлайн Meta: событие с event_time старше 7 дней падает, а в батче валит весь запрос.

Относитесь к бюджету как к инженерному вопросу. Когда события перестают приходить вовремя, порядок обхода - сама цепочка: очередь постбеков MMP, лог исходящих постбеков трекера, ретраи слоя доставки. Чек-лист диагностики - в гайде задержки Meta CAPI.

Типичные точки отказа

Одни и те же отказы всплывают в каждом аудите стека:

• Браузерные и серверные события без общего event_id: на Meta одиночный источник никогда не дедуплицируется; на TikTok дубль определяется парой event_id и event_name в любом сочетании каналов.
• Потерянный external_id на одном хопе: событие уходит, но не склеивается с кликом, теряя sub-ID и контекст лендинга.
• Органика, пропавшая из отчетов при Advanced Privacy: постбеки уходят только по инсталлам, засчитанным рекламной сети, разрыв заложен в дизайн.
• Pixel или postback скрипты, дублирующие конверсии при рефреше thank-you страницы, - задокументированная слабость самого простого способа приема RedTrack.
• Протухший event_time, травящий весь батч CAPI: одна старая запись валит запрос, и свежие конверсии внутри тоже не доезжают.
• Конверсионные события, выключенные посреди кампании: Meta может в любой момент отключить конверсионные события для отдельных вертикалей, и остановка приходит из политики платформы, а не трекера.

QA-чеклист перед масштабированием

Перед масштабированием server side conversion delivery прогоните одну тестовую конверсию через каждое звено и читайте логи по порядку:

1. Кликните живую рекламу и убедитесь, что click ID появился в трекере с правильными sub-ID.
2. Триггерьте конверсию и убедитесь, что входящий постбэк несет тот же ID.
3. Проверьте лог исходящих постбеков трекера (в Keitaro: Maintenance, затем Logs, затем S2S postbacks) на ушедшее событие и ответ эндпоинта.
4. В Meta Events Manager через Test Events убедитесь, что пришли ожидаемые имя, action_source и event_id.
5. Сравните event_id на браузерном и серверном путях; на обоих он должен быть идентичен.
6. Проверьте тайминги: в батч Meta не должно попадать ничего старше 7 дней, и оба канала должны лежать внутри 48-часового окна дедупликации.
7. Повторите тест после любого изменения статусов, макросов или шаблонов; переименованный макрос ломает все молча.

Источники