Аналог HasOffers (TUNE) в России | Recca

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

HasOffers, TUNE и что изменилось

HasOffers запустили в 2009 году как white-label решение для управления офферами: рекламодатель заводил кампанию, партнёр получал уникальную ссылку, сервер считал конверсии. За несколько лет на этой платформе встали сотни сетей — она стала одним из самых распространённых движков для партнёрских и паблишер-сетей. Около 2016 года компания перевела продукт под бренд TUNE, а в 2019-м переименовала HasOffers в TUNE Partner Marketing Platform: позиционирование сместилось с трекинга офферов на управление партнёрскими программами шире. В 2020 году TUNE купила канадская Constellation Software и включила её в свою операционную группу Perseus — подразделение, которое занимается технологиями performance-маркетинга и трекинга и постоянно докупает похожие платформы.

Каждая такая смена — бренда, продукта, владельца — для сети на этой платформе означает не только новый логотип в кабинете, но и новый цикл согласований по любому изменению в тарифах или условиях API. Сами тарифы TUNE Partner Marketing Platform начинаются от 499 $ в месяц на плане Bootstrap при годовой оплате — и это без учёта конвертации и банковских комиссий, которые для российской сети добавляются сверху. Для сети на HasOffers или TUNE это означает: тарифы считаются в долларах, сервер стоит за рубежом, а решения о развитии продукта принимает уже не та команда, которая его строила. Для российской сети это оплата через посредников, задержки и данные, которые физически лежат не в её юрисдикции. Переезд в такой ситуации — не про моду на новую платформу, а про то, чтобы платить рублями и не зависеть от чужого биллинга.

Модель данных

Структура данных у HasOffers и TUNE строится на трёх сущностях: offer — кампания рекламодателя со ставкой и условиями, affiliate — партнёр с уникальным ID и набором ссылок, advertiser — рекламодатель со своими лимитами и офферами. В кабинете CPA-агентства Recca те же три сущности называются иначе, но устроены так же: рекламодатели, вебмастера и договоры между ними, а поверх — клики, конверсии и статистика по всей сети.

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

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

Постбэки

У TUNE постбэк собирается из параметров вроде affiliate_id или transaction_id, offer_id и payout: рекламодатель обращается по этому URL, когда засчитывает конверсию, и передаёт, за какого партнёра и по какому офферу платит. Часть интеграций добавляет к этому набору sale_amount и currency — сумму продажи и валюту, если оффер платит процентом, а не фиксированной ставкой. В Recca S2S-постбэки и логи построены в конвенции Affise — те же по смыслу параметры, но с другими именами.

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

Выплаты и холды

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

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

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

Кабинеты партнёров

У HasOffers и TUNE кабинет вебмастера и рекламодателя выглядит как часть общей платформы — партнёр логинится на домен трекера. Recca предлагает то же на поддомене самой сети: партнёр не замечает смены платформы, разве что новый адрес в закладках. Альтернатива — отдать API и Go-SDK, если сеть хочет собрать свой интерфейс с нуля вместо готового кабинета.

Выбор влияет на порядок переезда: готовый white label переключается быстрее, свой интерфейс на API даёт больше контроля, но требует времени на разработку до полного переключения. Часть сетей выбирает промежуточный вариант: запускает переезд на готовом кабинете, чтобы не тормозить партнёров, а свой интерфейс на API собирает параллельно и переключается на него уже после того, как данные и постбэки полностью перенесены и проверены.

Как переносим

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

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

План переезда

Порядок, который снимает большинство рисков:

1. Выгрузить с прежней платформы список офферов, ставок и активных вебмастеров — это опора для сверки, а не формальность.
2. Завести рекламодателей и офферы на новой платформе с теми же условиями и холдами.
3. Переписать постбэки и проверить их на логах, пока старая ссылка ещё работает.
4. Перенести вебмастеров и подключить кабинеты — white label или свой интерфейс на API.
5. Настроить антифрод и лимиты по каждому офферу отдельно, а не общим порогом на всю сеть.
6. Запустить обе платформы параллельно на несколько дней, сверяя конверсии по логам.
7. Переключить трафик и отключить прежнюю платформу только после того, как расхождений в статистике не осталось.

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

Если сеть уже готова считать варианты, тариф «CPA-сеть» подключается по заявке; сравнить его с остальными уровнями можно на странице тарифов.