Два 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 - это гранулярнее, чем стандартный набор событий рекламных платформ; по каждому статусу - в сопоставлении статусов Keitaro.
Как работает 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) живёт на стороне постбека, а платформы не дают эквивалента отката уже посчитанного события, кроме отправки новых. Поэтому зрелые связки держат оба канала и соблюдают дисциплину дедупликации и сопоставления статусов между ними.