Как настроить SubID и postback для адалт-офферов

Коротко: как работает трекинг в арбитраже

Упрощённо цепочка выглядит так:

источник трафика → трекер или ваш сайт → партнёрская ссылка → оффер → конверсия → postback → трекер

Для платного трафика часто добавляется ещё один шаг:

трекер → postback в рекламную сеть

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

Главная идея:

SubID часто помогает понять сегмент, а click ID связывает конверсию с конкретным кликом. Но названия полей зависят от платформы: некоторые трекеры называют свой click ID именно subid. Postback возвращает результат обратно без необходимости выполнять код в браузере пользователя.

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

SubID, click ID и postback — это разные вещи

Термины часто смешиваются, потому что одна платформа может использовать слово subid для уникального click ID, а другая — для обычной пользовательской метки. Поэтому важнее не название поля, а его функция.

Что такое SubID

SubID — дополнительный параметр, который вы передаёте вместе с партнёрской ссылкой, чтобы потом разделять статистику.

Например, одна и та же программа может стоять:

• в основной таблице подборки;
• в CTA после обзора;
• в боковом блоке;
• на нескольких сайтах;
• в разных рекламных кампаниях.

Если все переходы идут через одну ссылку без меток, в кабинете партнёрки они могут выглядеть как один общий поток.

С SubID можно передавать, например:

Одна SubID-метка может повторяться у тысяч кликов. Это нормально: её задача — обозначить группу.

Что такое click ID

Click ID — уникальный идентификатор отдельного перехода.

Условно:

клик №1 → abc123
клик №2 → def456
клик №3 → ghi789

Трекер сохраняет click ID вместе с известными ему данными: кампанией, источником, placement, GEO, устройством, стоимостью и другими параметрами.

Затем этот ID нужно передать дальше — в партнёрскую сеть или рекламодателю. Когда пользователь совершит целевое действие, партнёрская система возвращает тот же ID в postback. По нему трекер находит исходный клик и записывает конверсию в правильную строку статистики.

У разных систем поле для tracker click ID может называться по-разному:

• clickid;
• click_id;
• subid;
• sub1;
• aff_sub;
• externalid;
• другим техническим параметром.

Не угадывайте имя макроса. Его нужно брать из документации конкретной партнёрской сети или уточнять у менеджера. transaction_id обычно относится уже к самой конверсии или транзакции, а не к исходному клику, поэтому подставлять его вместо click ID без прямого указания документации не следует.

Что такое S2S postback

Postback — HTTP-запрос, который одна система отправляет другой после события.

В типичной affiliate-схеме:

1. трекер получает клик и создаёт click ID;
2. click ID передаётся в партнёрскую систему;
3. пользователь совершает целевое действие;
4. сервер партнёрки вызывает ваш Postback URL;
5. обратно передаются click ID и, при наличии, payout, status, goal и другие данные;
6. трекер сопоставляет событие с исходным кликом.

Это называется server-to-server, или S2S, потому что уведомление отправляется между серверами. Оно не зависит от того, загрузился ли у пользователя пиксель на странице подтверждения.

Часто affiliate postback передаёт параметры через GET в самом URL, но это не универсальное правило: некоторые платформы поддерживают и POST-запросы. HTTP-метод и формат данных всегда нужно сверять с документацией конкретной системы.

Postback или tracking pixel?

Оба варианта могут сообщать о конверсии, но работают по-разному.

• S2S postback отправляется между серверами и обычно связывает событие с ранее сохранённым click ID.
• Tracking pixel срабатывает в браузере пользователя, например при загрузке thank-you page.

Pixel может быть достаточным, если партнёрская платформа или рекламная сеть не поддерживает нужную S2S-интеграцию. Но для affiliate/media-buying цепочки postback обычно удобнее, когда он доступен: он меньше зависит от загрузки страницы и browser-side скриптов. При этом S2S не исправит потерянный click ID — идентификатор всё равно должен корректно пройти через всю воронку.

Когда достаточно SubID, а когда нужен трекер

Отдельный tracker нужен не каждому сайту и не с первого дня.

Сценарий 1: собственный сайт и несколько партнёрских ссылок

Если вы монетизируете SEO или direct-трафик и хотите понять, какая страница или кнопка приносит доход, часто достаточно SubID.

Например:

страница → placement → SubID → партнёрка

Партнёрский кабинет затем показывает клики, действия и доход по каждой метке.

Такой вариант хорош, когда:

• источников немного;
• не нужен click-level анализ;
• трафик не надо автоматически распределять между офферами;
• статистики самой партнёрки достаточно для решения.

Сценарий 2: платный трафик и source-level оптимизация

При покупке трафика требования выше.

Вам обычно нужно знать:

• сколько стоил клик;
• из какого site/zone/placement он пришёл;
• на какой лендинг попал;
• какой оффер получил;
• случилась ли конверсия;
• сколько она принесла;
• какое событие стоит вернуть обратно в traffic source.

Здесь полноценный tracker становится значительно полезнее, особенно если рекламная сеть поддерживает conversion postback и оптимизацию по переданным событиям.

Сценарий 3: несколько источников и партнёрок

Tracker особенно полезен, если одновременно используются:

• несколько traffic sources;
• несколько CPA-сетей или прямых программ;
• split между офферами;
• разные лендинги;
• несколько conversion goals;
• динамический payout.

Трекер превращается в промежуточный слой, где данные из разных систем приводятся к одной схеме.

При выборе такого сервиса для адалт-арбитража важнее не слово «adult» в маркетинге продукта, а поддержка S2S postback, custom parameters, журналов запросов, маршрутизации трафика, нужного объёма кликов и интеграций с вашими источниками и партнёрками.

Как собрать цепочку трекинга пошагово

Интерфейсы Keitaro, Voluum, RedTrack, Binom и других систем отличаются, но логика почти всегда одна и та же.

Шаг 1. Решите, какие данные вам действительно нужны

Не начинайте с двадцати параметров.

Для первого платного теста обычно достаточно сохранить:

• campaign ID;
• site/zone/placement ID;
• creative ID;
• GEO;
• device;
• собственный variant/test ID;
• cost, если источник умеет его передавать.

Часть данных трекер определяет сам, поэтому их не обязательно дублировать в URL.

Главное — сохранить идентификатор источника, по которому потом можно отключить слабое размещение или собрать whitelist.

Шаг 2. Передайте параметры traffic source в трекер

Рекламные сети обычно подставляют динамические значения через macros/tokens.

Условная ссылка кампании может выглядеть так:

https://track.example/campaign?zone={zone_id}&creative={creative_id}&cost={cost}

Это только пример структуры. Реальные названия макросов нужно брать из документации конкретной рекламной сети.

После клика трекер должен сохранить подставленные значения в своей статистике.

Шаг 3. Создайте или получите уникальный click ID

Tracker обычно генерирует его автоматически.

Предположим, внутри трекера этот идентификатор доступен как:

{clickid}

Теперь нужно выяснить, в какой параметр партнёрская сеть готова его принять.

Например, сеть может ожидать:

sub1

Тогда offer URL внутри трекера строится по принципу:

https://offer.example/?sub1={clickid}

После реального клика {clickid} будет заменён уникальным значением.

Шаг 4. Не потеряйте click ID на prelander или собственном лендинге

Если между трекером и оффером есть промежуточная страница, она должна сохранить идентификатор.

Типичная ошибка:

трекер → prelander с click ID → кнопка с жёстко прописанной ссылкой без click ID → оффер

В таком случае партнёрка никогда не узнает идентификатор исходного клика, и вернуть его через postback уже невозможно.

Проверьте все редиректы, JavaScript-переходы, формы и CTA между первым кликом и оффером.

Шаг 5. Настройте postback партнёрка → tracker

Tracker даст вам Postback URL. Условно:

https://track.example/postback?clickid={NETWORK_CLICK_MACRO}&payout={NETWORK_PAYOUT_MACRO}&status={NETWORK_STATUS_MACRO}

Левая часть параметров относится к вашему трекеру. Значения в фигурных скобках — макросы партнёрской системы.

Самая важная часть — возврат того же click ID, который вы передали на шаге 3.

Если tracker отправил свой ID в sub1, а партнёрка возвращает значение sub2, цепочка не свяжется.

Шаг 6. При необходимости настройте tracker → traffic source

Для покупного трафика конверсию часто полезно вернуть ещё и в рекламную сеть.

Получается двухступенчатая схема:

affiliate network → tracker → traffic source

У traffic source обычно есть собственный идентификатор клика или conversion token. Tracker сохраняет его при исходном переходе и использует, когда получает конверсию от партнёрки.

Так рекламная сеть может:

• отображать конверсии в своей статистике;
• считать CPA/ROAS;
• использовать данные в автоматической оптимизации, если такая функция поддерживается.

Например, ExoClick документирует отдельные S2S-интеграции с Voluum, RedTrack, BeMob и другими трекерами. Конкретные параметры и Goal ID нужно настраивать по текущей инструкции самой сети.

Шаг 7. Передавайте только полезные conversion data

Обязательный набор зависит от трекера и типа интеграции. Для click-level атрибуции почти всегда нужен идентификатор клика, а некоторые системы дополнительно требуют тип или статус события. Например, в актуальной документации Keitaro для корректной обработки postback обязательны subid и status.

Дополнительно полезны:

• payout;
• currency;
• conversion status;
• goal/event type;
• transaction ID.

Не нужно отправлять обратно GEO, device и source ID, если tracker уже сохранил их в момент клика.

Пример 1: сайт или SEO-трафик без отдельного трекера

Допустим, на одном сайте есть три размещения партнёрской программы знакомств:

• основная сравнительная таблица;
• CTA внутри статьи;
• кнопка в конце страницы.

Можно использовать три стабильных SubID:

dating-table
dating-inline
dating-bottom

Логика:

посетитель → партнёрская ссылка с SubID → оффер

Дальше в кабинете партнёрки вы сравниваете:

• клики;
• регистрации;
• оплачиваемые действия;
• доход;
• EPC или другой доступный показатель

по каждой метке.

Это уже позволяет ответить на практический вопрос: какое размещение реально приносит доход?

Если партнёрская система поддерживает несколько SubID, можно разделить страницу и placement по разным полям вместо склеивания всего в одну строку.

Пример 2: покупной адалт-трафик через трекер

Предположим, вы покупаете pop-трафик и ведёте его на адалт dating offer.

Упрощённая цепочка:

adult ad network → tracker → prelander → affiliate network → advertiser

При клике:

1. рекламная сеть передаёт zone_id и свой conversion token;
2. tracker сохраняет эти значения и создаёт собственный click ID;
3. click ID передаётся через prelander в параметр партнёрской сети;
4. пользователь регистрируется или покупает продукт;
5. партнёрка отправляет postback с тем же click ID;
6. tracker записывает конверсию и payout;
7. при необходимости tracker отправляет conversion postback в рекламную сеть;
8. в отчёте можно увидеть доход и CPA по конкретной zone.

Именно эта схема позволяет перейти от:

«кампания потратила $100 и получила 12 конверсий»

к более полезному анализу:

«zone A потратила $18 и принесла $44, zone B потратила $21 и не дала подтверждённых действий».

После этого уже можно принимать решение о blacklist/whitelist. Подробнее сам процесс закупки и оптимизации разбирается в гайде о покупке адалт-трафика.

Как передавать payout, статусы и несколько событий

Одна техническая конверсия не всегда равна финальному доходу.

Dynamic payout

Если партнёрская сеть умеет передавать реальную сумму выплаты, лучше использовать dynamic payout вместо одной фиксированной цифры в tracker.

Это особенно важно, когда:

• payout отличается по GEO;
• разные действия оплачиваются по-разному;
• используется Hybrid;
• есть upsell или несколько типов sale;
• часть событий позже меняет статус.

Если tracker считает каждую конверсию по условным $5, а реальные выплаты составляют $2, $5 и $12, его ROI становится неточным даже при идеально настроенном click ID.

Несколько conversion goals

В адалт-вертикалях одна воронка может иметь несколько важных событий:

клик → регистрация → подтверждение → покупка / депозит / подписка

Не обязательно считать каждое событие одинаковой конверсией.

Полезно различать, например:

• registration;
• qualified_registration;
• sale;
• deposit;
• subscription.

Какие события доступны, зависит от конкретного оффера и партнёрской системы.

Pending, approved, rejected и chargeback

Если партнёрка возвращает статусы, tracker должен обрабатывать их так, чтобы отклонённое действие не оставалось в отчёте как окончательный доход.

Особенно осторожно сравнивайте офферы, если один показывает raw leads почти мгновенно, а другой — только подтверждённые действия.

Отдельная методика сравнения таких результатов есть в гайде как тестировать адалт-офферы и партнёрки.

Transaction ID и дубли

Некоторые системы повторяют postback при смене статуса или повторной попытке доставки.

Уникальный transaction/conversion ID помогает понять, относится ли запрос к новому действию или к уже известной конверсии. Но правила обработки дублей различаются: например, Keitaro использует tid, чтобы записывать повторные конверсии как отдельные события, а RedTrack позволяет настраивать режим обработки duplicate postbacks.

Не подставляйте tracker click ID и transaction ID друг вместо друга только потому, что оба выглядят как случайные строки: это разные сущности.

Как протестировать postback до запуска

Не отправляйте основной бюджет, пока не проверена вся цепочка.

Минимальный pre-flight test:

1. создайте тестовую кампанию;
2. сделайте реальный клик по tracking URL;
3. убедитесь, что tracker записал source/zone и другие нужные параметры;
4. проверьте, какой click ID создал tracker;
5. убедитесь, что этот ID дошёл до партнёрской системы в правильном поле;
6. используйте встроенный test postback партнёрки или согласуйте тестовую конверсию с менеджером;
7. проверьте postback log на стороне tracker;
8. убедитесь, что конверсия появилась у правильного click ID;
9. проверьте payout, currency, status и goal;
10. если конверсия должна уходить обратно в traffic source, проверьте и этот этап.

Почему лучше использовать реальный click: некоторые traffic sources и trackers создают часть нужных идентификаторов только на настоящем переходе, поэтому искусственный ID может проверить лишь половину цепочки.

Сделайте отдельный короткий чек-лист для каждой новой интеграции. Через несколько месяцев это сэкономит больше времени, чем попытки вспомнить, какой макрос использовался в старой кампании.

Почему конверсии теряются и как найти проблему

Если партнёрка показывает действие, а tracker — нет, проблема обычно находится в конкретном переходе данных.

Проверяйте цепочку слева направо.

Ошибка №1: потерянный click ID

Это самая фундаментальная проблема.

Если click ID не дошёл до партнёрки, postback не сможет восстановить связь задним числом.

Поэтому сначала проверяйте путь идентификатора вперёд, а уже потом сам callback назад.

Ошибка №2: перепутаны макросы двух систем

Например, tracker использует {clickid}, а affiliate network называет принимающее поле sub1.

Правильная логика:

offer URL: sub1={clickid}

postback: clickid={sub1}

Названия условные, но направление принципиально: сначала значение tracker записывается в поле network, затем значение этого же поля возвращается в tracker.

Ошибка №3: postback настроен, но на неправильное событие

Партнёрская сеть может иметь отдельные события для registration, deposit и sale.

Если callback привязан только к регистрации, tracker не узнает о последующей покупке даже при идеальном click ID.

Ошибка №4: смотрите разные даты

Одна система может группировать отчёт по дате клика, другая — по дате конверсии.

При delayed conversions одна и та же когорта тогда попадает в разные дни. Сначала убедитесь, что сравниваются одинаковые диапазоны и одинаковая логика дат.

Ошибка №5: делаете вывод до подтверждения статусов

Raw lead, pending action и approved conversion — не одно и то же.

Если конверсии есть, но экономика выглядит подозрительно, дополнительно используйте диагностику слабой конверсии адалт-трафика: проблема может быть уже не технической, а в качестве трафика, GEO, лендинге или самом оффере.

Безопасность и приватность

Tracking parameters — не место для персональных данных пользователя.

Особенно в адалт-тематике не стоит передавать в URL или SubID:

• email;
• телефон;
• имя пользователя;
• сексуальные предпочтения;
• содержимое профиля;
• другую информацию, которая прямо идентифицирует человека или раскрывает чувствительный контекст.

Для связи систем обычно достаточно случайного click ID и технических идентификаторов кампании.

Дополнительно полезно:

• использовать HTTPS;
• защищать postback уникальным key/token, если tracker это поддерживает;
• использовать whitelist IP, когда такая возможность есть у обеих сторон и она не ломает доставку;
• не публиковать рабочий Postback URL с секретным ключом в открытых материалах;
• хранить только те параметры, которые действительно нужны для атрибуции и оптимизации;
• понимать retention и доступ к данным в cloud tracker, если трафик чувствителен.

Серверный postback снижает зависимость от browser-side tracking, но сам по себе не отменяет требования к privacy, consent и законности обработки данных.

Частые вопросы

SubID и click ID — одно и то же?

Не обязательно. SubID обычно используется как дополнительная метка или свободное поле, а click ID — как уникальный идентификатор конкретного клика. Но некоторые trackers называют свой click ID subid, поэтому всегда смотрите на назначение параметра, а не только на название.

Можно ли работать без трекера?

Да. Для сайта с небольшим числом источников и хорошей статистикой партнёрской программы часто достаточно SubID. Tracker становится особенно полезен при покупном трафике, нескольких партнёрках, split-тестах, click-level attribution и необходимости возвращать conversions в traffic source.

Что обязательно должно быть в postback?

Это зависит от принимающей системы. Для click-level attribution нужен идентификатор, который tracker сможет сопоставить с исходным переходом; часть трекеров также требует status/event type. Например, Keitaro сейчас требует subid и status. Payout, currency, goal и transaction ID добавляются по необходимости и возможностям партнёрской системы.

Почему партнёрка видит конверсию, а tracker — нет?

Сначала проверьте, дошёл ли tracker click ID до партнёрки. Затем — какой именно макрос партнёрка возвращает в Postback URL и появляется ли запрос в postback log. Если исходный click ID потерялся до конверсии, исправление самого callback не поможет.

Нужно ли отправлять конверсию обратно в рекламную сеть?

Для простого учёта в tracker это не обязательно. Но при покупке трафика source postback полезен для отчётности и может быть нужен для автоматической оптимизации кампании. Используйте только те события и значения, которые соответствуют реальной конверсии.

Можно ли использовать один SubID для source, GEO и creative?

Можно склеить значения в одну строку, но при наличии нескольких SubID-полей удобнее хранить основные измерения отдельно. Главное — заранее выбрать стабильную схему, которую можно расшифровать без ручных заметок.

Источники и документация

Для настройки конкретной интеграции всегда сверяйтесь с текущими макросами обеих платформ. Общая логика выше подтверждается официальной документацией:

• Keitaro: affiliate networks и postback
• Keitaro: параметры и обработка postback
• Keitaro: troubleshooting postback
• RedTrack: настройка affiliate tracker
• RedTrack: payout/revenue sync
• RedTrack: conversion types и duplicate postbacks
• ExoClick: S2S tracking с Voluum
• ExoClick: S2S tracking с RedTrack
• Admitad: SubID в партнёрских ссылках
• Admitad: Postback вебмастера

Конкретные имена параметров, макросов и доступные conversion events могут меняться. Перед запуском кампании проверяйте актуальную документацию traffic source, tracker и affiliate network.