RedTrack conversions API: одна конверсия, несколько площадок

Настройка RedTrack conversions API отвечает на вопрос, который рано или поздно задаёт каждый байер: одна воронка производит одну конверсию, но три площадки продали клики - как все три услышат о ней, не превратив события в кашу? Ответ RedTrack - конфигурация: S2S-постбеки заводят конверсии внутрь, CAPI-интеграции отправляют их наружу по площадкам, а токен clickid гарантирует, что каждая конверсия останется единственным сматченным фактом. Гайд проходит мультиплатформенную настройку с документированными полями, правилами матчинга и ловушками дублей.

Общий контур - постбек сети на входе, серверное событие на выходе - описан в гайде от постбека до CAPI; здесь - реализация RedTrack, площадка за площадкой.

Токен, на котором всё держится: clickid

RedTrack назначает «новый уникальный ID для этой сессии» каждому клику. URL оффера несёт макрос - &affsub={clickid} в документированном примере, - поэтому сеть сохраняет click ID RedTrack и возвращает его постбеком при конверсии (документация постбеков RedTrack).

Принимающая сторона - настройка offer source, ключуемая click ID: с шаблоном сети вы копируете сгенерированный URL постбека в настройки сети; с нуля - создаёте кастомный offer source и «уточняете правильные макросы CLICKID и SUM, критичные для трекинга». URL постбека тогда несёт идентификатор (clickid), опционально тип события (&type=conversion event name) и сумму конверсии через макрос SUM. Примечательно, RedTrack документирует S2S как свободный от кук - «does not rely on cookies», - что делает контур устойчивым на мусорных браузерах.

Вход: S2S-постбеки от сети

Настройка делится по возможностям сети:

1. С шаблоном: добавьте шаблон offer source, скопируйте URL постбека из настроек, вставьте в поле постбеков сети - макросы смапплены заранее.
2. Кастом с нуля: определите макросы CLICKID и SUM под имена параметров сети, затем вставьте сгенерированный URL.

Типы конверсий, зарегистрированные через параметр type, становятся отчётными колонками - и это сырьё для платформенных интеграций: каждое событие, которое RedTrack отправляет площадке, строится из сматченной конверсии заданного типа.

Выход: CAPI-интеграции по площадкам

Интеграция Meta документирует набор полей, которому следуют все платформенные варианты: Pixel ID, API key (CAPI access token), имя события по умолчанию - пустое означает отправку как Purchase, - Event URL по умолчанию и Action source, который документация помечает как обязательный, «иначе conversions fail». Опционально: Data Quality API Token для оценок Event Match Quality, Custom Conversion Matching (маппинг типов конверсий RedTrack в имена событий Meta), кастомизация выплат и postback-фильтры по порогам выплаты (интеграция RedTrack и Meta).

Мультиплатформенность означает, что этот раздел повторяется: TikTok-интеграция из TikTok-шаблона несёт свои креденшелы и свой маппинг событий (интеграция TikTok), и каждая новая площадка добавляет свою строку. Одна конверсия, сматченная однажды, доставляется каждой настроенной площадке - в её собственном словаре событий.

Meta-требования, формирующие настройку

Требования Meta дотягиваются до лендинг-настройки, и RedTrack документирует их точно:

1. Кастомный трекинг-домен (CNAME, Free SSL включён) с no-redirect трекингом - редиректы на Meta-трафике по умолчанию запрещены.
2. Если редирект необходим: toggle Redirect for Meta плюс скрипт clickupd_fbp_fbc.js - документированная комбинация для проноса браузерных идентификаторов через редирект.
3. Роли параметров: fbclid «требуется для отправки данных конверсии обратно в Meta» и обязан быть последним параметром в URL объявления; sub 19 и sub 20 захардкожены на fbp и fbc и не подлежат правке, «since CAPI requires them in exact format»; макросы Meta несут обязательные роли - {{ad.id}}→Aid, {{adset.id}}→Gid, {{campaign.id}}→Cid; роль External ID передаёт значение дедупликации (по умолчанию - clickid RedTrack).
4. Обслуживание подключения: авторизация через Connect Meta и переподключение каждые 2-3 месяца - Meta рвёт соединения.

Каждый пункт - документированная настройка, а не workaround; механика идентификаторов за ними разобрана в гайдах про click ID.

Дедуп: правило одного дома для пикселя

Самое острое место мультиплатформенной настройки - двойное назначение. Документация RedTrack проговаривает это прямо: пиксель назначается либо каналу трафика, либо офферу/магазину - «both causes duplicate events». Тот же класс проблемы есть в каждом трекере: одна конверсия с двумя маршрутами доставки становится двумя событиями площадки, если только платформенный межканальный дедуп не поймает их - а межканальный дедуп работает при общей идентичности обеих копий.

Роль external ID - оставшаяся защита: со стабильным external ID на конверсию Meta способна дедуплицировать пары «браузер плюс сервер»; внутри серверной доставки честность счёта держит именно правило маршрутизации.

RedTrack conversions API: частые вопросы

Источники