Платформа лидогенерации через партнёров | Recca
Компания подключает партнёров — агентства, вебмастеров, блогеров с аудиторией — и те присылают заявки. Дальше начинается работа, для которой таблица в Excel и переписка в мессенджере не годятся: нужно понять, какая заявка настоящая, кому и сколько за неё причитается, и как не потерять ни один лид между кликом партнёра и деньгами на его счету. Платформа лидогенерации — это система, которая берёт эту бухгалтерию на себя: считает лиды, ведёт их статусы, держит холд перед оплатой и запускает выплаты, когда заявка подтверждена.
Что такое платформа лидогенерации
Формы на сайте и квизы решают другую задачу — они собирают заявки от своих посетителей, и вопрос «откуда пришёл человек» здесь второстепенен. Платформа лидогенерации нужна в другом случае: заявки приходят не с вашего сайта, а от внешних партнёров — агентств, вебмастеров, площадок, — и вы платите не за клик и не за показ, а за результат: заявку, звонок, оформленную анкету. На рынке эту модель называют по-разному — сервис лидогенерации, система лидогенерации, а по сути это просто лидогенерация оплатой за подтверждённый лид, а не за трафик. Такую схему обычно называют CPA или CPL: cost per action, cost per lead — рекламодатель фиксирует цену за действие заранее и платит именно за него, а не за попытку.
Технически это означает как минимум четыре вещи. Во-первых, каждый переход по партнёрской ссылке нужно однозначно связать с конкретным партнёром — обычно через уникальный идентификатор в ссылке, который сохраняется до момента заявки, иначе непонятно, кому платить. Во-вторых, факт заявки должен долетать от вашей CRM или лендинга обратно в систему учёта — это делают S2S-постбэки, то есть сервер сам сообщает серверу о конверсии, без участия браузера пользователя и без потерь при блокировке рекламных скриптов, антидетект-браузерах или отключённых куках у клиента. В-третьих, у заявки должна быть история: кто её прислал, когда, в каком она сейчас статусе и когда изменился последний раз — без этого невозможно ни разобрать спор с партнёром, ни отчитаться перед рекламодателем. В-четвёртых, ставки и правила должны быть заданы до того, как пошёл трафик, а не переписываться задним числом под конкретную заявку.
К этому стоит добавить ещё один момент: постбэк может не долететь с первого раза — сеть партнёра моргнула, сервер рекламодателя на секунду ответил ошибкой, адрес приёма поменялся и никто не предупредил. Система должна повторить отправку по расписанию и хранить историю попыток, а не считать конверсию потерянной после одной неудачной отправки — иначе платформа теряет именно те лиды, за которые дороже всего платить.
У части таких систем есть исторически сложившийся формат постбэков — конвенция Affise, с которой совместимы многие трекеры и CPA-сети. Recca поддерживает такой же формат S2S-постбэков, поэтому партнёра, который уже настроил постбэки под Affise, не нужно переучивать: меняются только адрес и токен, а не логика интеграции.
Без всего этого «платформа» — это просто таблица, в которую кто-то раз в неделю переносит данные руками, сверяя цифры из писем и переписки в мессенджерах. С этим — сервис лидогенерации, на который можно положиться при масштабе в сотни и тысячи заявок в месяц, потому что каждая цифра в отчёте объясняется конкретным событием, а не памятью менеджера.
Лиды и статусы
Лид проходит по системе не сразу — сначала он попадает в очередь, потом кто-то (или правило) решает, засчитывать его или нет. Обычно так:
- Новый — лид зарегистрирован, пришёл постбэк или клик привёл к заявке; на этом шаге ещё не известно, реальная это заявка или технический шум;
- На проверке — рекламодатель или менеджер сети смотрит: заполнены ли обязательные поля, не дубль ли это уже принятой заявки, отвечает ли человек на звонок;
- Подтверждён — заявка принята, партнёр заработал вознаграждение по своей ставке, но деньги ещё не выплачены — начинается холд;
- Отклонён — заявка не прошла проверку: дубль, некорректные данные, отказ клиента, признаки накрутки; у отклонения обычно должна быть причина, а не просто статус;
- Оплачен — после холда деньги ушли партнёру, и этот статус уже не меняется.
Смысл в том, что каждый переход между статусами фиксируется отдельно, с датой и временем, а не перезаписывает предыдущее значение. Если рекламодатель через месяц спросит, почему лид от 14-го числа отклонили, в системе должен быть ответ — кто и когда это сделал, — а не «наверное, менеджер посчитал его некачественным». Это тот же принцип, что и в S2S-постбэках: статус лида — это событие, а не просто поле в таблице, и о нём можно уведомить внешнюю систему тем же способом, каким она сообщила о самой заявке — например, чтобы CRM рекламодателя сама обновляла карточку клиента при подтверждении или отклонении.

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

Кроме прямых партнёров, в схему часто добавляются агенты и рекрутёры: человек привёл на площадку не клиента, а другого партнёра, и получает долю с его будущих выплат. В Recca такая цепочка может идти до пяти уровней вниз — каждый агент видит, сколько приносят приведённые им партнёры, и получает процент автоматически, без ручного пересчёта в конце месяца.
Ещё один вопрос, который встаёт почти сразу, — что происходит с персональными данными клиентов, которых приводят партнёры. По 152-ФЗ «О персональных данных» обмен обезличенными идентификаторами не приравнивается к передаче персональных данных — то есть партнёру и рекламодателю не обязательно видеть телефон и имя клиента целиком, если для сверки заявок достаточно непрозрачного идентификатора. Recca работает именно так: серверы в России, а личные данные клиентов сети можно не передавать партнёрам и агентам — только идентификаторы, по которым сверяются заявки.
Управление командой — тоже часть работы с партнёрами, только внутри самой компании: роли для сотрудников, журнал действий (кто изменил ставку или подтвердил лид) и уведомления о ключевых событиях в вашу систему. Это особенно важно, когда с партнёрской сетью работает не один человек, а отдел: без ролей и журнала любое расхождение в цифрах превращается в вопрос без ответа — кто именно поменял ставку в четверг вечером.
Отдельно стоит вопрос доступа к данным для самих партнёров и внешних систем. Recca поддерживает до 10 API-ключей на аккаунт — можно выдать разным партнёрам или интеграциям свой ключ и в любой момент отозвать один, не трогая остальные, если, например, площадка перестала быть партнёром или её ключ засветился в чужом коде.
Уведомления о ключевых событиях — новый лид, смена статуса, завершение холда, выплата — можно направить не только в интерфейс, но и во внешнюю систему компании: почту, мессенджер команды или туда же, откуда рекламодатель следит за выплатами и балансом. Тогда менеджеру не нужно заходить в кабинет Recca, чтобы узнать, что изменилось со вчерашнего дня, — событие приходит туда, где он и так уже работает.
Холд и выплаты
Между статусом «подтверждён» и реальной выплатой почти всегда стоит холд — период, в течение которого рекламодатель ещё может оспорить лид: клиент передумал, данные не подтвердились при звонке, обнаружился дубль. Холд защищает рекламодателя от преждевременных выплат за заявки, которые распадутся через день-два, а сеть — от споров с партнёрами задним числом, потому что срок и условия холда известны заранее, а не придумываются постфактум.
Партнёру холд обычно не нравится — он хочет получить деньги за уже подтверждённую заявку сразу. Здесь важна прозрачность: если партнёр видит точную дату окончания холда по каждому лиду, а не общую фразу «выплаты по графику», претензий и обращений в поддержку становится меньше — человек сам понимает, сколько ещё ждать и когда именно деньги должны были прийти.
Срок холда логично привязывать не к платформе, а к самому продукту рекламодателя: для короткой сделки хватает нескольких дней на звонок и проверку, для длинного цикла согласования — недель. Здесь работает тот же принцип, что и со ставками: правила холда и подтверждения стоит зафиксировать в системе до старта трафика, а не держать в переписке или в голове у одного менеджера, который однажды может уйти в отпуск или уволиться.

После холда включается биллинг: с баланса рекламодателя списывается сумма за подтверждённые лиды, а партнёру начисляется его часть с учётом ставки и, если применимо, доли агента в цепочке. Recca ведёт это как биллинг рекламодателей и выплаты вебмастерам в одной системе, а не как два независимых процесса, которые потом приходится сверять вручную. Отдельно стоит защита от накрутки: часть отклонённых на проверке заявок — это не ошибка менеджера, а типичная для таких систем попытка сдать фиктивный лид ради выплаты, и антифрод-правила должны отсекать это до того, как деньги спишутся с баланса рекламодателя, а не после.
Сами выплаты обычно объединяют в пакет, а не проводят по одной заявке сразу после холда: система собирает всё, что накопилось у партнёра на дату выплаты, и формирует одну сумму вместо десятков разрозненных операций. Так меньше ручной работы у бухгалтерии сети и меньше шанс пропустить кого-то из партнёров — не нужно вручную проверять каждого по отдельности, кому уже пора платить, а кому ещё рано.
Из практических деталей: список постбэков и логи по каждому из них стоит хранить отдельно от самих лидов — если рекламодатель жалуется, что не получил уведомление о новой заявке, это первое место, куда нужно посмотреть: пришёл ли постбэк вообще, с каким кодом ответа, не изменился ли адрес приёма на стороне рекламодателя. Разбираться в этом должно быть можно самостоятельно, по логам, а не через обращение в поддержку с вопросом «а вы точно нам отправляли».
Для агентств
Если вы не рекламодатель с одним продуктом, а агентство, которое ведёт несколько клиентов и работает с общим пулом партнёров, задача усложняется: нужен не один список лидов, а кабинет CPA-агентства — с рекламодателями, вебмастерами и договорами по каждому, плюс сводная статистика по кликам и конверсиям в разрезе всей сети, а не одной кампании. Один и тот же вебмастер может вести трафик сразу на нескольких клиентов агентства — и тогда важно, чтобы отчёт по каждому клиенту показывал только его цифры, а сводный отчёт для самого агентства — общую картину по всем сразу.
По сути, это и есть переход от разовой лидогенерации к своей CPA-сети: агентство перестаёт быть посредником, который вручную сверяет отчёты каждого клиента, и получает инфраструктуру, через которую заявки, статусы и выплаты идут одним потоком. Recca даёт для этого готовые кабинеты вебмастера и рекламодателя на поддомене сети — можно запустить сеть под своим брендом без разработки интерфейса с нуля, либо забрать данные через API и Go-SDK и встроить их в уже существующий кабинет агентства.
Здесь же пригождается многоуровневая схема с агентами: агентство может не искать каждого вебмастера само, а дать эту работу существующим партнёрам-рекрутёрам, которые приводят новых и получают долю с их выплат. Это тот же переход, о котором писали в материале «От партнёрки к CPA-сети» — только здесь речь именно про учёт лидов, а не про модель монетизации в целом.
Для клиентов агентства технический слой можно вообще не показывать: рекламодатель заходит в свой кабинет на поддомене сети и видит только свои заявки, свою статистику и свой баланс — без доступа к данным других клиентов и без необходимости объяснять, что за незнакомый интерфейс он открыл. Это снимает с агентства часть вопросов поддержки: рекламодатель сам смотрит статус своих лидов, вместо того чтобы писать менеджеру и ждать выгрузку в таблице.
Recca позиционируется как российский аналог Affise: логика настройки похожая, но сервера — в России, оплата — в рублях, и не нужно решать, как переводить деньги на зарубежный аккаунт для оплаты подписки.
Это же разделение ролей работает и в обратную сторону: если у одного из клиентов агентства есть свой отдел, которому нужно видеть заявки и статистику, не дёргая каждый раз менеджера агентства, доступ можно выдать точечно — через отдельный кабинет на поддомене сети или через API-ключ, который отвечает только за данные этого рекламодателя, не открывая остальную сеть.
Цена
Начать можно бесплатно: тариф Free — 0 ₽, с ограниченным набором функций для одной небольшой партнёрской программы — этого достаточно, чтобы проверить саму идею платной лидогенерации через партнёров, не считая заранее объём трафика. Дальше — Pro за 3 000 ₽/мес и Бизнес за 15 000 ₽/мес: оба уровня растут по возможностям и подходят компании с растущим, но ещё не разветвлённым пулом партнёров — без агентской структуры и без десятков рекламодателей одновременно.
Для этого есть отдельный тариф — «CPA-сеть»: 50 000 ₽/мес, то есть 1 667 ₽/сутки при посуточном списании и пополнении баланса в рублях. Он включает кабинет CPA-агентства, S2S-постбэки, холды и биллинг рекламодателей, выплаты вебмастерам, многоуровневых агентов, готовые кабинеты на поддомене или доступ через API, до 10 API-ключей и ролевую модель для команды. Подключение — по заявке, а перейти на этот тариф можно с любого из младших без переноса данных на другую платформу: заявки, партнёры и история выплат остаются на месте.
Разница между тарифами — не только в цене, но и в модели работы. На младших тарифах партнёров можно пересчитать по пальцам, и решения по ставкам принимает один человек — этого достаточно для старта. «CPA-сеть» нужна там, где партнёров и агентов уже много: без ролей, журнала действий и нескольких API-ключей команда быстро теряет, кто и когда поменял ставку или подтвердил спорный лид. Если единственный вопрос — холды и выплаты для небольшого пула партнёров, может хватить и младшего тарифа; если к этому добавляются агентская цепочка, несколько рекламодателей и своя команда с ролями — это уже повод перейти на «CPA-сеть».
Если пока рано считать, сколько заявок в месяц вы готовы обрабатывать через партнёров, разумно начать с изучения тарифов на странице цен и посчитать, при каком объёме лидов подписка на «CPA-сеть» окупается за счёт маржи между ставками рекламодателя и вебмастера. Если объём уже понятен — оставьте заявку на подключение «CPA-сети».