Постбек 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: частые вопросы

Источники