Postback vs Conversions API: два серверных канала с разными задачами
Два server-to-server канала, два разных получателя
Вопрос "postback vs Conversions API" звучит как выбор между двумя конкурирующими технологиями, и именно эта рамка ломает настройку. Оба канала работают server-to-server: без браузера, кук и JavaScript. Разница - кто с кем разговаривает. Постбек - это HTTP-запрос, который улетает с сервера рекламодателя или партнёрской сети на сервер вашего трекера, чтобы сообщить о факте конверсии; документация Keitaro определяет его ровно так. Conversions API - канал в обратную сторону: ваш сервер (трекер, мост или инструмент доставки) отправляет конверсию рекламной платформе, чтобы её собственная атрибуция увидела событие.
В воронке, где живут оба канала, конверсия делает два серверных хопа: сеть стреляет постбеком в трекер, а сторона трекера доставляет Conversions API-событие дальше - в Meta, TikTok, Reddit или другую платформу, которая купила трафик. Общий контекст, зачем нужны оба хопа, - в server-side tracking.
Как работает постбек
Документация Keitaro даёт точную референс-реализацию. Postback URL собирается из адреса трекера, postback key для аутентификации и параметров конверсии - шаблон выглядит как http://IP/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE. Когда запрос приезжает, трекер находит клик по subid и проверяет status; запрос без статуса или с неизвестным статусом без маппинга молча игнорируется. Именно эта тишина объясняет, почему диагностика постбеков начинается с двух вопросов: долетел ли клик-ID до URL и совпадает ли имя статуса с тем, что ждёт трекер.
Набор параметров нарочно компактный. Обязательные: subid (какому клику засчитать конверсию) и status. Опциональные: tid - ID транзакции, чтобы повторные конверсии складывались, а не перезаписывали друг друга; payout с суммой выплаты; cost, currency, до тридцати дополнительных sub_id-параметров и return для тела ответа. Статусы отображают этапы воронки - Lead, Sale, Rejected, Registration, Deposit, Trash - это гранулярнее, чем стандартный набор событий рекламных платформ.
Как работает Conversions API
У Conversions API роль приёмника серверных событий на стороне платформы. Референс - версия Meta: сервер отправляет payload с Pixel ID и access token, событие несёт имя, таймстамп не старше семи дней, хэшированные SHA-256 user data и event_id, чтобы одна конверсия, приехавшая и с пикселя, и с сервера, не посчиталась дважды. Платформа использует эти события для атрибуции и оптимизации - и именно эту часть постбек никогда не закрывает, потому что база трекера для рекламной платформы невидима.
Требования к payload жёстче, чем у постбека. Постбек терпит голую query-string с двумя параметрами; CAPI-событию нужны нормализованные, хэшированные идентификаторы и консистентный нейминг событий, а качество payload напрямую видно в match rate и event match quality. Отказы задокументированы по каждой сети - начиная с кодов ошибок Meta.
Где каждый канал стоит в аффилей-воронке
Стандартная цепочка выглядит так: оффер-страница или партнёрская сеть стреляет постбеком в трекер (хоп один), трекер записывает конверсию на клик, и слой доставки превращает постбек в Conversions API-событие для рекламной платформы (хоп два). Хопы не делят протокол: хоп один говорит на диалекте постбеков трекера (subid, status, payout), хоп два - на диалекте API платформы (event_name, хэшированные user_data, event_id). Идентификаторы требуют явного перевода: клик-ID трекера маппится на клик-идентификатор платформы (вроде fbclid), пойманный в момент клика, а ID транзакции становится ключом защиты от повторной отправки того же события.
Слой маппинга - это и есть архитектура server-side доставки конверсий: свой скрипт, эндпоинт tag-сервера или делегирование. MOST делает ровно эту работу - принимает постбеки трекера и доставляет корректно сформированные, дедуплицированные события в Meta, TikTok, Reddit, Pinterest, Snapchat и OpenAI; для одного лендинга с ручным потоком бесплатный Pixel Activator закрывает тот же путь доставки.
Когда хватает постбека - а когда нужен CAPI
Постбек сам по себе закрывает одну задачу: учёт. Выплаты оседают в трекере, отчёты сходятся с цифрами сети - больше ничего не требуется. Канал ломается в момент, когда ожидание меняется с "видеть конверсии" на "заставить платформу находить похожие": оптимизация кампаний, наполнение lookalike и точная внутриплатформенная отчётность строятся на платформенных событиях, и база трекера не поставляет данные ни в одну из этих систем.
Работает и обратное: Conversions API-событие без постбека означает, что платформа слышит о конверсиях, которых ваш трекер не записал, и сверка превращается в угадывание. Воронки, пропустившие хоп один, теряют возможность оспорить или скорректировать конверсию задним числом - модель статусов (Lead, Sale, Rejected) живёт на стороне постбека, а платформы не дают эквивалента отката уже посчитанного события, кроме отправки новых. Поэтому зрелые связки держат оба канала и соблюдают дисциплину дедупликации и маппинга статусов между ними.