Постбек CPA сети в Conversions API: где рвётся цепочка

Прежде чем площадка засчитает деньги, постбек CPA сети должен пережить два этапа: сначала из сети в ваш трекер, потом из трекера в Conversions API площадки. Каждый этап живёт по письменному контракту обязательных параметров, и у каждого есть документированный набор способов порваться. Этот гайд проходит оба контракта этап за этапом, каталогизирует точки разрыва с точными симптомами и показывает, как тестировать и чинить цепочку, когда конверсия перестаёт доходить до площадки.

Ситуация, из-за которой эта цепочка вообще понадобилась, - работа с офферами на страницах, которые нельзя тегировать, - разобрана в гайде серверная отправка конверсий без доступа. Здесь в фокусе сама механика передачи.

Два этапа, одна конверсия

Конверсия - один факт: купленный вами пользователь сделал действие, стоящее денег. Но на пути к оптимизации площадки он пересекает две организационные границы:

1. Первый этап: постбек сети в трекер. Сервер сети обращается к URL постбека вашего трекера, возвращая обещанный идентификатор клика и объявляя статус. Трекер сопоставляет вызов с сохранённым кликом.
2. Второй этап: трекер в Conversions API. Трекер (или автоматизация, действующая от его имени) собирает из сопоставленной конверсии событие площадки и POST-ом отправляет его на серверный эндпоинт.

Этапы говорят на разных языках. Первый - на языке трекера: subid, статус, выплата. Второй - на языке площадки: имя события, время события, хешированные данные пользователя, источник действия. Работа трекера - перевод, а любой перевод молча теряет то, что одна из сторон не умеет выразить. Именно с этого аудит начинается.

Знаний о Conversions API по кластеру разложено много; эта страница - про цепочку, без которой до площадки ничего не доходит.

Первый этап: контракт постбека сети

Документация Keitaro определяет входящий URL постбека точно: адрес сервера трекера, postback key - «уникальный идентификатор для безопасности и аутентификации запросов» - и параметры конверсии; всё это берётся в Settings, Postback URL. Канонический вид:

http://your-tracker.example/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE

Вы копируете этот URL в кабинет партнёрской сети и подставляете вместо плейсхолдеров собственные макросы сети. Параметр, который решает всё, - первый:

Нестандартные имена параметров у сети решаются алиасами: настройки Postback URL у Keitaro принимают замены, поэтому сеть, которая шлёт clickid=...&profit=..., попадает в те же поля (документация постбеков Keitaro). Постбек v2 у Binom устроен так же, только имена токенов другие (доки Binom).

Ещё одно правило контракта важно при масштабировании: повторная отправка постбека с тем же subid, но изменёнными параметрами перезаписывает предыдущую конверсию, а идентичный повтор не перезапускает исходящий S2S трекера - собственный дедуп трекера, задокументированный в гайде по S2S постбекам.

Где рвётся первый этап

Страница поиска неисправностей Keitaro перечисляет режимы отказа по точным записям лога (Maintenance, Logs, Postbacks):

Разрыв subid заслуживает отдельного предупреждения: он обычно рождается выше трекера, в ссылке оффера. Чеклист Keitaro велит проверить, что параметр клика subid корректно передаётся в оффер сети, - для редиректных офферов через параметры оффера в шаблоне сети, для локальных скрытым инпутом вроде <input type="hidden" name="sub1" value="{subid}" />, - а если подстановка верна и конверсии всё равно приходят ни с чем не сопоставленными, «написать партнёрской сети, почему корректное значение subid не передаётся» (postback troubleshooting).

Тестирование ловит ту же ловушку с другой стороны: «партнёрские сети не шлют настоящий subid в тестовых постбеках», поэтому кнопка теста в кабинете сети не доказывает ничего про сопоставление. Единственный валидный тест - реальная конверсия через вашу собственную ссылку кампании.

Второй этап: от трекера до Conversions API

После успешного сопоставления трекер собирает событие площадки. Перевод идёт по обеим сторонам постбека: subid становится якорем идентичности события, статус - именем события, выплата - value, а сохранённый контекст клика - IP, user agent, click ID - данными для сопоставления.

Что требует принимающая сторона, документировано по каждой площадке. Meta требует action_source, event_source_url и client_user_agent на website-событиях, принимает event_time до семи дней в прошлое и валит весь запрос из-за одного протухшего события (Conversions API parameters, using the API). Conversions API v3 Reddit принимает прямые серверные события со своими требованиями к ключам сопоставления (direct integration) и дедуплицирует пиксель с серверными событиями по conversion ID (event deduplication). Events API TikTok занимает в воронке TikTok то же место, обвязка на стороне трекера - в интеграции TikTok у Keitaro.

У обвязки по площадкам есть собственные гайды: Keitaro и Facebook CAPI для Meta, постбеки Keitaro для Facebook и TikTok для связки двух площадок, настройка Reddit Conversions API для Reddit.

Что теряется между этапами

Даже когда оба этапа технически работают, потери перевода копятся:

1. Несовпадение моделей статусов. Сети носят богатые статусы (lead, sale, rejected, rebill, trash); площадки ждут короткий список стандартных имён событий. Решение о том, какой статус сети в какое событие превращается, определяет, чему учится ваш пиксель, а неверное соответствие задним числом не чинится: площадка уже оптимизировалась на него.
2. Сроки. Первый этап почти мгновенен; второй наследует его задержку плюс окно приёма площадки. Сеть, подтверждающая продажи через дни после клика, тратит семидневный бюджет площадки на собственную медлительность.
3. Идентичность. Первый этап хорош настолько, насколько хорошо эхо subid; второй - насколько хорош сохранённый контекст клика. Конверсия может идеально пройти первый этап и всё равно попасть на площадку с тощим ключом сопоставления - потери без доступа посчитаны в плейбуке без доступа.
4. Value. Валюта выплаты и соглашения сети о знаке (отрицательные выплаты за ребиллы и чарджбеки) переводятся в поля value и currency события - или тихо исчезают, если слой доставки их роняет.

Ни одно из этих расхождений не вызывает явных ошибок. Они просто разводят цифры Ads Manager с балансом сети - это территория дедупликации и расхождений: правила подсчёта, а не порванные трубы.

Починка порванной цепочки

Рабочая процедура починки:

1. Найдите границу разрыва. Лог постбеков пуст - цепочка порвана на входе первого этапа. Запись в логе есть, а на площадке пусто - разрыв на втором этапе.
2. Примените соответствующую правку из таблиц выше: переопределить подстановку макроса subid, добавить недостающий статус, перекопировать postback key, пересохранить URL в кабинете сети.
3. Осознанно закройте потери перевода: явно решите, какой статус во какое событие превращается и как считается value, вместо того чтобы наследовать значения по умолчанию.
4. Перепроверьте реальной конверсией через ссылку кампании - никогда кнопкой теста сети - и смотрите на оба конца: лог трекера и тестовый инструмент площадки.
5. Проходите всю цепочку ежемесячно; чеклист поиска неисправностей постбеков превращает это в печатную рутину.

Постбек CPA сети в CAPI: частые вопросы

Источники