ОРД и CPA-сеть: кто передаёт данные
Оператор CPA-сети настраивает работу с ОРД не потому, что это интересно, а потому что без этого офферы рекламодателей нельзя законно продвигать через вебмастеров: каждый баннер, пост у блогера или объявление в рассылке, которое приводит трафик на оффер, обязано нести токен и пометку «реклама» ещё до публикации. Для сети это не разовая настройка, а процесс на каждый новый договор, каждого нового вебмастера и каждый новый креатив — и завязан он не на маркетинг, а на те же данные, которые сеть и так собирает для биллинга. Дальше — по шагам: что такое ОРД, где в цепочке стоит сеть, какие договоры и ИНН нужны, кто получает токен, что и куда отчитывать и какие данные для всего этого уже лежат в кабинете сети. Правило одинаково действует и для крупной сети с сотнями вебмастеров, и для небольшой команды, которая только запускает свою CPA-программу: закон не делает исключений по объёму рекламного бюджета или числу площадок.
Что такое ОРД
С 1 сентября 2022 года действует статья 18.1 закона «О рекламе» (38-ФЗ): рекламодатели, рекламораспространители и операторы рекламных систем, чья реклама в интернете нацелена на пользователей в России, обязаны передавать сведения о ней в Роскомнадзор. Напрямую в реестр ничего не загружается — только через оператора рекламных данных, ОРД.
ОРД — аккредитованный Роскомнадзором посредник между участниками рекламного рынка и ведомством. Сейчас в реестре семь операторов: «Лаборатория разработки» (Сбер), «Яндекс ОРД», «ВК Рекламные Технологии», «ОЗОН ОРД», «МедиаСкаут» (МТС), «Первый ОРД» (Вымпелком) и «ОРД-А» (Амбердата). Закон не привязывает участника рынка к конкретному оператору: сеть вправе выбрать любого из семи, ориентируясь на условия подключения и удобство интеграции, а не на то, кто из контрагентов уже с ним работает.
Под действие статьи 18.1 попадает практически любой формат, который встречается в работе CPA-сети: баннер на сайте, пост у блогера-вебмастера, объявление в рассылке или мессенджере, карточка в каталоге. Закон отдельно выводит из-под маркировки ряд случаев — например, собственную рекламу продавца на его же ресурсе без посредников или социальные публикации, за которые никто не платит, — но для сети это скорее исключение, которое приходится доказывать, чем удобный способ обойти процедуру: раз оффер размещает вебмастер за вознаграждение, признаки рекламораспространения, как правило, уже есть.
Через ОРД в единый реестр интернет-рекламы (ЕРИР) уходят три вида сведений: реквизиты договоров между участниками цепочки, данные о самом креативе и статистика его показов. В ответ ОРД присваивает креативу уникальный код — токен erid, без которого объявление формально остаётся немаркированным, даже если на баннере честно написано слово «реклама».
Отсутствие маркировки — это не абстрактный риск. По части 1 статьи 14.3 КоАП штраф для юридического лица составляет от 100 000 до 500 000 ₽, и каждое немаркированное объявление считается отдельным эпизодом: десять постов без erid — это потенциально десять штрафов, а не один. Закон не сосредотачивает ответственность на одном участнике цепочки: рекламодатель, посредник и рекламораспространитель отвечают каждый за свою часть данных, поэтому сети недостаточно переложить обязанность на вебмастера в оферте — при проверке контролирующий орган смотрит, чьих именно сведений не хватает в конкретной записи ЕРИР.
Реестр интернет-рекламы устроен как база, доступная для проверки: по номеру erid можно посмотреть, зарегистрирован ли конкретный креатив и на кого. Это работает и как способ самопроверки для сети — прежде чем спорить с рекламодателем или вебмастером о том, был ли получен токен, проще свериться с самим реестром, чем поднимать переписку.
Роль сети
CPA-сеть в этой цепочке — не рекламодатель и обычно не оператор рекламной системы в смысле закона. Её место — посредник между рекламодателем, который платит за целевое действие, и вебмастером, который эту рекламу фактически размещает и в этом смысле выступает рекламораспространителем.
Закон описывает движение данных именно как цепочку передачи ИНН: рекламодатель передаёт свой ИНН посреднику, посредник — сети — передаёт дальше рекламораспространителю уже два ИНН, свой и рекламодателя, а рекламораспространитель отправляет в ОРД все три: свой, посредника и рекламодателя. Сеть в этой схеме не сторонний наблюдатель — она обязательное звено, через которое должны пройти реквизиты обеих сторон.
Эта же схема работает и тогда, когда рекламодатель размещает офферы через сеть впервые: неважно, регистрировал ли он ранее рекламу в ОРД по другим каналам, — для конкретной цепочки «рекламодатель — сеть — вебмастер» реквизиты нужно передать заново, потому что ОРД связывает данные с конкретным договором и конкретным креативом, а не с рекламодателем вообще.
Отдельный вопрос — вебмастера, которых сеть привлекает не напрямую, а через агентов и рекрутёров: в партнёрских сетях с многоуровневой структурой встречается цепочка до пяти уровней, где верхний уровень получает долю от выплат нижнего. На обязанности по ОРД это не влияет: рекламораспространителем перед законом остаётся тот, кто фактически опубликовал креатив, — конкретный вебмастер, а не агент, который его привёл. Уровни агентской структуры — это механика распределения вознаграждения внутри сети, а не дополнительное звено в цепочке передачи данных в ЕРИР. Но сети всё равно нужно знать, у кого из вебмастеров есть ИНН в профиле, независимо от того, через какого агента он пришёл, — иначе часть площадок в структуре останется без возможности законно публиковать маркированную рекламу.
Из этого вытекает практическое следствие: если сеть не собирает ИНН рекламодателей и вебмастеров или собирает с ошибками, разрывается вся цепочка передачи данных. Отвечает за это не только вебмастер, который в итоге публикует немаркированный креатив, — проверка может дойти и до посредника, который не обеспечил передачу нужных сведений.
Отдельно стоит отличать роль посредника в цепочке ОРД от роли оператора рекламной системы в смысле закона: последний — это тот, кто управляет технологией показа и таргетинга рекламы, а не просто сводит рекламодателя и площадку. Большинство CPA-сетей в эту категорию не попадают — они передают данные о показах, которые формирует и учитывает сама площадка вебмастера, а не управляют рекламной выдачей напрямую. Но если сеть предоставляет вебмастерам собственный виджет или скрипт показа баннеров, стоит отдельно уточнить у выбранного ОРД, не меняет ли это её роль в цепочке.
Кабинет CPA-агентства строится вокруг того же списка участников, что и требует закон: рекламодатели, вебмастера и договоры между ними в одном месте, а не в переписке и разрозненных файлах. Это не отменяет саму процедуру маркировки, но снимает первую и самую частую причину сбоя — потерянные или не собранные реквизиты контрагентов. Когда в кабинете уже есть карточка вебмастера с указанным ИНН и принятой офертой, сети не нужно поднимать переписку каждый раз, когда рекламодатель запускает новый оффер, — реквизиты уже на месте, остаётся передать их оператору рекламных данных.
Договоры и ИНН
В ЕРИР передаются не сами товары или офферы, а реквизиты договора: стороны, их ИНН, номер и дата. Это значит, что до всякой маркировки у сети должны быть закрыты два вопроса — оформлен ли договор с рекламодателем и оформлен ли договор или публичная оферта с вебмастером, и указан ли в обоих ИНН стороны.
Для рекламодателя это обычно юридическое лицо или ИП с ИНН по умолчанию. С вебмастерами сложнее: часть работает как самозанятые, часть — как физлица без статуса, и у сети должен быть процесс, который не даёт вебмастеру начать лить трафик на офферы без указанного ИНН в профиле. Из всех данных, которые нужны для запуска маркировки, ИНН чаще всего оказывается узким местом: без него маркировка рекламы через ОРД не пройдёт ни для рекламодателя, ни для вебмастера, и цепочка остановится на этапе регистрации договора.
Публичная оферта, которую вебмастер принимает при регистрации в кабинете, юридически выполняет ту же роль, что и подписанный договор с рекламодателем, — но только если в ней прямо зафиксирован момент согласия и есть поле для ИНН, а не просто чекбокс «согласен с условиями». Дата и время принятия оферты — часть тех же реквизитов, которые в итоге уходят в ЕРИР вместе с номером договора, поэтому кабинет, который фиксирует такую отметку автоматически, избавляет сеть от отдельного архива подписанных PDF-файлов.
Отдельный практический момент — один и тот же рекламодатель обычно запускает через сеть не один оффер, а несколько, с разными вебмастерами и в разное время. Реквизиты договора при этом не нужно собирать заново под каждый новый оффер: ИНН и данные договора закреплены за карточкой контрагента один раз, а в ОРД уходят применительно к конкретному креативу и площадке. Ошибка, которая встречается на практике, — считать, что достаточно указать ИНН один раз «где-то в CRM»: если эти данные не связаны с конкретным договором и конкретной парой рекламодатель — вебмастер, при подготовке данных для ЕРИР их всё равно придётся собирать вручную заново.
Отдельно стоит сверить сами формулировки в шаблонах договоров и оферты: если в документе не зафиксировано, кто есть рекламодатель, а кто — рекламораспространитель, ОРД получит реквизиты, но не сможет однозначно сопоставить роли сторон в цепочке. Это тот случай, где юридический шаблон и техническая настройка кабинета — один и тот же процесс, а не два независимых.
Практическая деталь, которая стоит внимания при первом запуске, — формат самого ИНН: у юридических лиц он состоит из 10 цифр, у индивидуальных предпринимателей и физлиц — из 12. Если поле в кабинете не различает эти форматы или допускает произвольную длину, часть карточек контрагентов рискует уйти в ОРД с опечаткой, которую заметят только на этапе сверки отчёта, а не сразу при вводе данных.
Токен
Erid — буквенно-цифровой код, который ОРД присваивает конкретному креативу до его публикации. Токен получает тот, кто загрузил в ОРД договор и материалы, — на практике это рекламодатель или посредник, действующий по договору. Для сети реалистичный сценарий обычно один: либо сеть требует от вебмастера получить токен самостоятельно, передав ему данные о рекламодателе и договоре, либо берёт получение токена на себя как часть сервиса для крупных рекламодателей.
Токен привязан не к рекламной кампании и не к рекламодателю вообще, а к конкретной паре «креатив — площадка размещения»: один и тот же баннер, который вебмастер ставит на двух разных сайтах, формально требует двух токенов, а не одного. Это резко умножает количество erid, которые нужно получить и отследить, как только у сети больше одного вебмастера на оффер. Если материал креатива меняется — новый текст, другая картинка, другая ссылка — токен нужно получать заново: старый erid относится к прежней версии и после изменения формально не покрывает новый вариант.
Правило простое и без исключений: на каждом креативе — баннере, посте, объявлении в мессенджере — должны одновременно стоять пометка «реклама» и токен. Наличие только одного из двух элементов юридически равнозначно отсутствию маркировки вообще. Для текстовых форматов токен принято указывать пометкой вида «erid: …» рядом с текстом или в самой ссылке перехода, для баннеров — в подписи под изображением; конкретный способ выбирает рекламодатель или сеть, но не сам вебмастер: у него обычно нет данных, чтобы решить это самостоятельно.
Отдельно стоит логика для RTB-рекламы — автоматических закупок показов через биржи и рекламные сети: там токен, как правило, присваивается и передаётся на уровне рекламной системы, которая управляет закупкой, а не силами каждого отдельного вебмастера. Для CPA-сети это редкий случай — большинство офферов размещаются вебмастером вручную, — но если в сети есть интеграции с programmatic-закупкой, эту часть цепочки стоит сверить отдельно.
Хранить стоит не только сам код erid, но и то, к какому именно креативу и площадке он относится: набор из одних кодов без привязки бесполезен, если через несколько месяцев рекламодатель или проверяющий спросит, какой токен стоит на конкретном баннере у конкретного вебмастера.
Токен выдаётся не на рекламодателя и не на кампанию целиком, а на конкретный креатив. При работе с десятками вебмастеров и несколькими вариантами баннеров под один оффер количество токенов быстро растёт: пять вебмастеров и три варианта баннера — это уже пятнадцать отдельных erid, которые нужно получить, сопоставить с площадкой и не перепутать при следующем обновлении креатива. Это тот момент, где выгружать данные о договорах и площадках вручную из таблиц уже не получается — нужен процесс, завязанный на кабинет сети, а не на переписку с каждым вебмастером.
Отчёт
После публикации обязанности не заканчиваются: ОРД ежемесячно передаёт в ЕРИР статистику показов и сведения об исполнении договоров — акты между сторонами. Эти данные подтверждают, что реклама действительно была показана и оплачена так, как записано в договоре.
Статистика показов, которая нужна ЕРИР, и статистика кликов и конверсий, на которой строится CPA-модель, — не одно и то же: показ фиксирует сам факт демонстрации креатива, а конверсия — целевое действие пользователя, за которое сеть платит вебмастеру. Для отчёта в ОРД важен именно факт показа, а не то, привёл ли он к оплаченному действию. Но источник для обеих метрик у сети общий — трекинг размещений по каждому офферу, — поэтому вести их разными процессами избыточно: одна и та же выгрузка по площадке закрывает оба назначения, если в кабинете изначально фиксируется не только конверсия, но и факт показа или клика.
Здесь же встаёт вопрос времени: холды и подтверждение конверсий в CPA-модели устроены так, что конверсия подтверждается не сразу, а после проверки на фрод и возвраты. Акт с рекламодателем при этом стоит формировать по подтверждённым, а не по всем заявленным конверсиям — иначе цифры в акте разойдутся с тем, что сеть реально выплатит вебмастеру и выставит рекламодателю, и это ровно то расхождение, которое поднимает вопросы при сверке отчёта.
Для сети это означает, что акты по выплатам вебмастерам и биллингу рекламодателей должны существовать в проверяемом виде — с суммами и периодом, за который они выставлены, — а не только как итоговая цифра к перечислению. Выплаты вебмастерам и учёт по рекламодателям, которые сеть в любом случае ведёт для собственного биллинга, оказываются той же фактурой, которая нужна для отчёта в ЕРИР: разница не в данных, а в том, что их нужно регулярно доводить до ОРД, а не только сверять внутри кабинета.
Если отчёт не сдан или сдан с расхождением между фактическими показами и тем, что заявлено в договоре, вопросы у контролирующего органа возникают к тому звену цепочки, чьи данные не сходятся. Для сети это ещё один довод в пользу того, чтобы статистика по конверсиям и биллинг велись в одном месте, а не собирались перед отчётом заново.
Опыт показывает, что вопросы у ОРД или у самого рекламодателя чаще возникают не в момент публикации, а спустя месяц-два — при сверке ежемесячного отчёта или при внутреннем аудите со стороны рекламодателя. Если к этому моменту связка «договор — креатив — токен — акт» рассыпана по разным системам, восстановить её задним числом заметно дольше, чем один раз внести данные в кабинет при запуске оффера. Обмен данными о показах и конверсиях с рекламодателем при этом часто идёт не вручную, а автоматически: S2S-постбэки сообщают о событии в момент, когда оно произошло, и та же цепочка событий, которая формирует биллинг, становится источником для будущей сверки с отчётом в ЕРИР — без повторного экспорта таблиц перед каждой подачей данных.
Где взять данные в кабинете сети
Разбирать цепочку ОРД проще, когда понятно, какие данные для неё в принципе уже должны быть в кабинете сети — просто под другими названиями.
Договоры с рекламодателями и вебмастерами, включая ИНН каждой стороны, — это карточки контрагентов, которые сеть и так ведёт для биллинга и выплат. Статистика кликов и конверсий по каждому офферу — основа для отчёта о показах, который ОРД передаёт в ЕРИР, только собранная для внутренней аналитики, а не для ЕРИР напрямую. Акты и суммы выплат — тот же журнал, что подтверждает исполнение договора перед контролирующим органом.
Отдельно стоит развести два учёта, которые в кабинете сети могут пересекаться, но для ОРД должны остаться раздельными: ставка, которую сеть платит вебмастеру, и ставка, которую с рекламодателя получает сеть, — обычно разные, в этом и состоит маржа сети на конверсии. Для отчёта в ЕРИР имеет значение факт и сумма исполнения договора с рекламодателем, а не то, какую часть из неё сеть в итоге передаёт вебмастеру: смешивать эти две цифры в одном акте не нужно, даже если оба значения хранятся в одной таблице кабинета.
Дальше — вопрос выгрузки, а не сбора заново. Вебмастер и рекламодатель не обязаны присылать реквизиты сети напрямую: готовые кабинеты на поддомене сети позволяют каждому внести свой ИНН и данные договора самостоятельно, а сеть получает уже заполненную карточку, а не набор писем и вложений, которые нужно сверять вручную. У сети, которая ведёт учёт в одном кабинете, есть и другой путь — API и Go-SDK для собственных интеграций, до 10 API-ключей на аккаунт и уведомления о событиях: новый договор, подтверждённая конверсия, выплата. Это не делает ОРД частью кабинета сети: выбор оператора рекламных данных и загрузка креативов туда остаются отдельным шагом, который выполняет сеть или рекламодатель. Но именно эти выгрузки избавляют от повторного сбора одних и тех же реквизитов вручную каждый раз, когда нужно передать данные оператору рекламных данных. Журнал действий команды в кабинете — кто добавил договор, кто изменил ИНН контрагента, кто подтвердил конверсию — здесь же становится полезен не только для внутреннего контроля: если при сверке с ОРД всплывает расхождение, по журналу можно быстро найти, на каком шаге и кем были внесены конкретные данные, а не разбирать вопрос заново с нуля.
Отдельный практический момент — персональные данные вебмастеров. Сеть обязана передавать в цепочку ИНН и реквизиты договора, но не обязана выгружать во внешние системы личные данные людей сверх этого: сервер и структура кабинета могут хранить такие данные в России и отдавать наружу только то, что действительно нужно для маркировки, — без лишнего пути для утечки.
Перед тем как включать маркировку в постоянный процесс сети, стоит свести в одном месте четыре вещи: ИНН и договор каждого рекламодателя, ИНН и принятую оферту каждого вебмастера, статистику показов по офферам и акты выплат за период. Если хотя бы один из этих пунктов до сих пор ведётся вне кабинета — в почте, в мессенджере или в отдельной таблице, — это и есть точка, с которой стоит начать наведение порядка перед подключением ОРД.
Если сейчас данные о рекламодателях, вебмастерах и выплатах разбросаны по нескольким системам, до запуска маркировки стоит сначала свести их в один кабинет — посмотреть тариф «CPA-сеть» и оценить, каких полей и выгрузок не хватает именно для передачи данных в ОРД.
