Трекеры трафика: что нужно CPA-сети

Вопрос «нужен ли нам трекер» одинаково часто встаёт и у CPA-сети, и у рекламодателя, который присматривается к партнёрской модели. У вебмастера, которого сеть привлекает в программу, обычно уже стоит свой трекер — он распределяет клики между офферами и площадками. У сети — своя платформа, которая считает деньги: сколько заплатить вебмастеру, сколько получить с рекламодателя и на чём сеть зарабатывает маржу. Это не конкурирующие инструменты и не взаимозаменяемые: трекер работает на стороне трафика, платформа CPA-сети — на стороне денег и договорных отношений. Путаница между ними обходится дорого в обе стороны: сеть, которая пытается встроить в себя функции трекера, тратит разработку на чужую задачу, а сеть, которая вообще не понимает, зачем вебмастеру трекер, не может внятно объяснить программе, что от неё требуется на входе. Дальше разбираем, какая задача у каждого инструмента, как они соединяются через постбэк и когда сети вообще не нужно требовать трекер от партнёров.

Что такое трекер

Трекер — инструмент вебмастера, а не сети. Он стоит на стороне того, кто покупает или привлекает трафик, и решает одну задачу: куда направить конкретный клик. Вебмастер заводит в трекере потоки — правила, по которым клик из одного источника попадает на одну посадочную страницу или оффер, а из другого источника — на другую. Внутри трекер считает клики по источнику: с какого объявления, площадки, ключевого слова или креатива пришёл человек, сколько таких кликов превратилось в конверсию и какая у источника цена клика против отдачи.

По каждому клику трекер обычно хранит не один идентификатор, а набор меток: источник и кампанию, до нескольких значений sub-id для площадки, объявления или ключевого слова, гео и тип устройства. По этим меткам вебмастер потом решает, какой источник отключить, а на какой добавить бюджет — без этого разбиения аналитика сводится к одной общей цифре «сколько заработали», в которой не видно, что именно сработало. Часть потоков в трекере настроена на сплит-тест: одна и та же ссылка ведёт на несколько посадочных страниц или офферов с заданным распределением трафика, а трекер сравнивает, какой вариант даёт больше конверсий на то же число кликов.

Это нужно тому, кто действительно работает с трафиком: закупает рекламу, ведёт несколько источников одновременно или тестирует посадочные страницы друг против друга. Один и тот же трекер вебмастер использует параллельно для офферов разных сетей и рекламодателей — трекер не привязан к конкретной CPA-сети и не знает, что происходит с кликом после того, как передал его дальше и получил постбэк с результатом. Вебмастеру, который ведёт трафик на несколько программ одновременно, трекер даёт единую точку, где видно всё сразу: сколько потрачено на источник и сколько с него пришло конверсий, независимо от того, к какой сети относится конкретный оффер.

CPA-сети такая детализация обычно не нужна и не должна быть видна: сеть работает с результатом — кликом, который довели до заявки, продажи или установки, — а не с тем, через какое объявление вебмастер этот клик получил. Смешивать две задачи в одном инструменте невыгодно обеим сторонам: вебмастер не обязан показывать сети источники трафика — это его конкурентное преимущество и его расходы на закупку, — а сеть не обязана вникать в устройство чужих рекламных кампаний и тратить на это разработку.

Технически поток в трекере — это правило редиректа: короткая ссылка, которую вебмастер публикует в рекламе или рассылке, ведёт не напрямую на оффер, а на домен трекера, который на лету решает, куда отправить конкретный переход, и уже потом делает редирект дальше. Домены для таких ссылок вебмастер обычно арендует или регистрирует отдельно от домена самого трекера — это защищает поток от блокировки, если один из доменов попадёт в чей-то бан-лист. Часть кликов трекер отсекает ещё до редиректа: ботов, повторные заходы с того же устройства, клики с датацентровых IP. Эта фильтрация работает на стороне вебмастера и не имеет отношения к антифроду сети, который проверяет уже сами конверсии, а не сырой трафик до них.

Задачи вебмастера и задачи сети

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

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

Платформа CPA-сети начинается там, где трекер закончил свою часть работы: она фиксирует конверсию, ведёт биллинг рекламодателя и вебмастера по разным ставкам в одной и той же конверсии — разница между ними и есть маржа сети, — держит холд до подтверждения, начисляет долю агентам и рекрутёрам в цепочке до пяти уровней и в конце проводит выплату. Холд существует не для того, чтобы придержать деньги вебмастера без причины: рекламодателю обычно нужно время, чтобы подтвердить качество заявки, дождаться окончания периода возврата или сверить конверсию со своей внутренней системой, и только после этого сеть переводит статус из «в ожидании» в «подтверждено» и включает сумму в ближайшую выплату. Агентская цепочка работает похожим образом: если вебмастера в программу привёл рекрутёр, а того — ещё один агент уровнем выше, каждый уровень получает свою долю от той же конверсии, и платформа должна развести эти доли автоматически, а не вручную по каждой заявке.

У этой части есть обязанность, которой у трекера нет. Сеть выступает стороной договора с рекламодателями и вебмастерами и обрабатывает их персональные данные как оператор персональных данных по 152-ФЗ — с обязанностями по хранению, согласиям и передаче третьим лицам. Трекер, который работает с обезличенными идентификаторами клика, а не с реквизитами человека, под такие требования в большинстве случаев не подпадает. Поэтому платформы сетей всё чаще устроены так, чтобы не хранить реквизиты клиентов сети напрямую, а обмениваться с внешними системами непрозрачными идентификаторами — это согласуется и с методами обезличивания, которые Роскомнадзор закрепил приказом №140: замена прямых данных клиента идентификатором признана одним из допустимых способов их обезличивания.

Есть и третья обязанность на стороне сети: реклама, которую рекламодатель размещает через программу, должна соответствовать 38-ФЗ «О рекламе» — маркировке, ограничениям по категориям товаров и услугам. Трекер просто перенаправляет клик и к содержанию креатива отношения не имеет: за соответствие закону отвечают рекламодатель и сеть, которая его подключила, а не инструмент, через который партнёр вёл трафик.

На практике спор о конкретной конверсии почти всегда начинается с вопроса «а был ли клик» — рекламодатель может усомниться в качестве заявки уже после того, как сеть перевела её в статус «подтверждено». Платформа сети должна хранить не только текущий статус, но и историю: когда пришёл постбэк, какие параметры в нём были, менялся ли статус и кто его менял, — без этой истории спор решается на словах, а не на данных. Трекер к этому спору отношения не имеет: он давно передал клик дальше и не хранит, что с ним случилось после перехода по ссылке оффера. Похожая логика и у агентской цепочки: рекрутёр видит долю от конверсий своих вебмастеров, а не сами клики, и это разделение специально устроено так, чтобы агент не мог реконструировать источники трафика партнёра из отчёта о выплатах.

Популярные трекеры

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

Облачные трекеры — SaaS: регистрация, готовый интерфейс, оплата обычно привязана к объёму кликов или числу активных потоков. Такой трекер не требует своего сервера и обновляется поставщиком, но данные о трафике лежат у третьей стороны, а тарификация растёт вместе с объёмом кликов — вебмастеру с большим объёмом трафика в какой-то момент становится выгоднее перейти на собственный сервер, чем платить за каждую тысячу кликов сверху.

Самостоятельно устанавливаемые трекеры — self-hosted: ставятся на собственный сервер вебмастера, без верхнего предела по кликам и без передачи данных о трафике внешнему сервису, но требуют настройки, обновлений и антифрод-правил своими силами. Здесь же встаёт вопрос физического расположения сервера: если сервер трекера размещён за рубежом, а сеть и рекламодатель работают в России, разбор спорной конверсии или потребность быстро поднять упавший поток может упираться в задержки на стороне зарубежной инфраструктуры — для вебмастера это его собственный риск, но для сети это повод не завязывать свою работу на конкретное расположение чужого сервера.

У обоих типов один и тот же базовый набор возможностей: конструктор потоков, сплит-тест посадочных страниц и креативов, приём кликов по прямой ссылке и отправка результата дальше по постбэку. Разница — в том, кто отвечает за инфраструктуру и куда уходят данные о трафике: к поставщику облачного трекера или никуда, если сервер свой. Для платформы CPA-сети тип трекера, которым пользуется вебмастер, значения не имеет: она получает от него один и тот же постбэк независимо от того, стоит трекер в облаке или на собственном сервере, и не должна разбираться в устройстве чужой инфраструктуры, чтобы принять результат клика.

Стоимость облачного трекера обычно ступенчатая: чем больше кликов или активных потоков, тем выше тариф, и переход на следующую ступень происходит без предупреждения — просто в какой-то месяц объём трафика превышает лимит прошлого тарифа. У self-hosted трекера тарифа как такового нет, но есть постоянные расходы на сервер и время на обновления, а сбой в настройке антифрод-правил вебмастер разбирает сам, без поддержки поставщика. Переход с одного типа на другой не бесплатен ни в деньгах, ни во времени: настройки потоков, доменов и правил приходится переносить вручную, поэтому вебмастеры обычно выбирают тип трекера один раз и меняют его редко — только когда объём трафика вырастает или падает на порядок.

Связка трекера и сети через постбэк

Трекер и платформа сети технически не связаны напрямую — между ними нет общей базы данных, только один HTTP-вызов, постбэк. Связка строится в четыре шага.

Во-первых, вебмастер получает от сети ссылку с идентификатором клика (обычно параметр вроде click_id) и прописывает её в трекере как оффер или пункт потока. Во-вторых, приводит на неё трафик: клик проходит через трекер, который решает, на какой поток его направить, и уходит по ссылке оффера к рекламодателю с тем же идентификатором. В-третьих, когда у рекламодателя происходит конверсия — заявка, продажа, установка, — его сервер отправляет S2S-постбэк на сторону сети с этим же click_id. В-четвёртых, сеть сопоставляет значение с конкретным вебмастером, источником и оффером и заводит запись в биллинге — с этого момента конверсией управляет уже не трекер, а платформа сети.

С этого момента трафик как таковой сети больше не интересен — она видит только конверсию и её статус: сырую заявку, подтверждённую после холда или отклонённую. Никакой информации об исходном клике — объявление, площадка, ключевое слово, — которая осталась в трекере, сеть не получает и не должна получать: это данные вебмастера. Такой постбэк отличается от пиксельной отметки на самой странице тем, что идёт напрямую от сервера рекламодателя к серверу сети в обход браузера пользователя — это надёжнее, потому что не зависит от блокировщиков рекламы и от того, дождался ли человек полной загрузки страницы после конверсии.

На практике интеграция редко проходит без сбоев с первого раза, и здесь важны две вещи. Первая — идемпотентность: если сервер рекламодателя из-за сетевой ошибки отправит один и тот же постбэк повторно, платформа сети должна опознать его по click_id и не начислить выплату дважды. Вторая — проверка перед запуском: прежде чем подключать поток вживую, вебмастер и рекламодатель обычно прогоняют один тестовый клик с заведомо тестовым идентификатором и смотрят, дошёл ли постбэк и правильно ли считался статус, — так ошибку в параметрах находят до того, как через неё пройдёт реальный трафик.

Формат постбэка — по сути общий набор параметров: click_id, статус, сумма, валюта, — поэтому подключение обычно занимает настройку одной ссылки и одного URL для приёма ответа, а не интеграцию двух систем целиком. Recca принимает и отправляет постбэки в формате, совместимом с конвенцией Affise, и хранит логи по каждому вызову — вебмастеру не нужно переписывать шаблон под сеть, если он уже настраивал такие постбэки раньше, а у сети есть что показать рекламодателю при споре о конкретной конверсии: время каждого вызова, переданные параметры и то, как менялся статус. Подробнее о формате — на странице S2S-постбэков.

Постбэк технически — это обычный HTTP-запрос, GET или POST, с набором параметров в адресе или теле; сервер сети должен ответить кодом успеха, иначе сервер рекламодателя по своим правилам повторит попытку через какое-то время. Если в момент первого вызова сеть была недоступна — обновлялась или испытывала нагрузку, — повторный вызов принесёт тот же результат только тогда, когда на стороне сети реализована идемпотентность по click_id, о которой уже шла речь: иначе вебмастеру начислят выплату дважды или не начислят вовсе. Логи по каждому вызову — не техническая деталь для разработчика, а инструмент разбора конкретного спора: по ним видно, в какой момент пришёл постбэк, с каким статусом и что сеть с ним сделала, — и это ровно те данные, которые нужны, чтобы ответить рекламодателю на вопрос «почему эта заявка не подтверждена», не поднимая логи трекера, которого сеть даже не видит.

Когда трекер не нужен

Для CPA-сети вопрос звучит не «нужен ли нам трекер», а «нужно ли требовать трекер от вебмастера» — и ответ не всегда «да».

Если в программе несколько десятков вебмастеров, а не тысячи, и каждый ведёт один-два источника трафика, детальная оптимизация по площадкам и креативам не критична: партнёру достаточно собственной ссылки с click_id и личного кабинета, где видно клики, конверсии и статус выплаты. Именно так устроены готовые кабинеты вебмастера и рекламодателя, которые сеть выдаёт на своём поддомене, — трекер в этом случае избыточен, потому что не оптимизирует то, что и так идёт одним направлением.

Похожая картина у программ, устроенных вокруг рекомендаций, а не медийной закупки: если вебмастер приводит клиентов через личные контакты, чат или один канал, а не покупает трафик на нескольких площадках одновременно, ему нечего распределять между потоками — весь смысл трекера в том, чтобы сравнивать источники между собой, а сравнивать здесь попросту не с чем. Требовать в такой программе трекер «для порядка» — значит нагружать партнёра инструментом под задачу, которой у него нет.

Трекер становится нужен ровно тогда, когда вебмастер начинает вести несколько источников одновременно и должен сравнивать их между собой — сеть или конкретный рекламодатель этого решения за него не принимают и не должны: оно относится к его трафику, а не к её конверсиям. Обычно это заметно по косвенным признакам: партнёр просит несколько ссылок на один и тот же оффер, задаёт вопросы про передачу sub-id или сравнивает конверсию по разным площадкам в переписке с менеджером программы — в этот момент имеет смысл предложить ему подключить трекер, а не раньше. Требовать трекер от каждого партнёра «для порядка» смысла не имеет: сеть получает один и тот же постбэк вне зависимости от того, стоит за ссылкой сложная связка потоков или прямой редирект.

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

Выбор

Для CPA-сети или рекламодателя, который решает, во что вкладываться, вопрос не «трекер или платформа», а что из перечисленного уже есть, а что нужно достроить:

• нужен ли партнёрам инструмент распределения трафика — или им хватает прямой ссылки и личного кабинета, потому что у программы нет медийной закупки на несколько источников;
• считает ли что-то внутри разные ставки для рекламодателя и вебмастера в одной конверсии — маржу сети без этого не увидеть и не подтвердить перед рекламодателем;
• где хранятся реквизиты и персональные данные вебмастеров и рекламодателей и кто отвечает за них как оператор по 152-ФЗ;
• принимает ли платформа S2S-постбэки в стандартном формате, чтобы рекламодатель не дорабатывал интеграцию под каждую сеть отдельно и не собирал отдельный шаблон под нового партнёра;
• кто держит холд и правило подтверждения конверсии — сразу, до утверждения рекламодателем или до наступления события вроде окончания периода возврата;
• как считаются и выплачиваются агентские, если в программе есть цепочка рекрутёров, а не только вебмастера напрямую.

Большая часть этого списка не про трекер вообще: пять из шести пунктов решает платформа, на которой стоит CPA-сеть, а не инструмент на стороне партнёра. Поэтому вопрос «какой трекер посоветовать вебмастерам» на практике вторичен по отношению к вопросу «на чём считать деньги между рекламодателем, сетью и цепочкой агентов» — с этого стоит начинать, а трекер партнёры в большинстве случаев выбирают сами, без участия сети.

Трекер закрывает первый пункт и только его — это инструмент вебмастера, и требовать его от партнёра стоит только тогда, когда его задача действительно есть. Остальные пять пунктов — задача платформы сети: холды и подтверждение конверсий, выплаты и учёт, приём постбэков и биллинг по разным ставкам. Recca закрывает эту часть на тарифе «CPA-сеть» — 50 000 ₽ в месяц с посуточным списанием и пополнением в рублях, без привязки к тому, каким трекером пользуются партнёры. Оставить заявку на подключение можно на странице CPA-сети, сравнить тарифы — на странице цен.