Маркировка рекламы в CPA-сетях: кто отвечает
Обязательная маркировка рекламы в сети касается не только рекламодателя, который завёл оффер: реклама в CPA проходит через сеть и вебмастера, и закон не делает исключений ни для посредников, ни для тех, кто просто «поставил баннер». Каждый, кто участвует в размещении, обязан убедиться, что реклама помечена и данные о ней дошли до Роскомнадзора. Для сети это не абстрактная тема, а условие работы с рекламодателями, которые сами обязаны маркировать свои офферы, и с вебмастерами, которые формально становятся рекламораспространителями в момент публикации креатива. Дальше — кто в цепочке за что отвечает, какие данные для маркировки рекламы нужны, в какой момент их собирать и что из этого делает платформа, а что нет.
Цепочка участников
Закон «О рекламе» различает несколько ролей, и в CPA все они заняты постоянно, просто под другими названиями, привычными для партнёрского маркетинга.
Рекламодатель — тот, кто определяет объект рекламирования: бизнес, который завёл оффер в сети и платит за целевое действие, будь то заявка, продажа или установка приложения. Рекламораспространитель — тот, кто показывает рекламу аудитории: в CPA это вебмастер, который ставит баннер, публикует пост, размещает интеграцию у блогера или отправляет письмо по своей базе. Между ними стоит посредник — агентство или платформа, через которую заключаются договоры и проходят деньги. CPA-сеть в этой роли выступает почти всегда: она сводит рекламодателя и вебмастера, ведёт договоры с обеими сторонами и начисляет вознаграждение по итогам подтверждённых действий.
Важная деталь: одна и та же компания в разных офферах может быть то рекламодателем, то рекламораспространителем. Крупный вебмастер иногда сам заводит суб-оффер для команды подрядчиков — и тогда по отношению к ним он уже рекламодатель, хотя для сети остаётся вебмастером. Роль определяется не статусом компании, а тем, что именно она делает с конкретным договором и конкретным креативом, поэтому одна и та же организация может нести обязанности сразу в двух ролях по разным цепочкам.
С точки зрения закона у посредника нет освобождения от обязанностей просто потому, что он не рекламодатель и сам ничего не показывает. Каждый участник цепочки, у которого есть договор, связанный с размещением рекламы, обязан передать сведения об этом договоре оператору рекламных данных (ОРД). Сеть в этом смысле — полноценное звено, а не техническая прокладка между двумя сторонами: у неё есть собственный договор и с рекламодателем, и с вебмастером, и по каждому из них нужно отчитаться отдельно.
На практике распределение обычно такое: рекламодатель отвечает за то, что оффер вообще подан на маркировку и по нему получен токен на исходный креатив; сеть — за то, что данные о её договорах с вебмастерами дошли до ОРД; вебмастер — за то, что в опубликованном материале стоит пометка «Реклама» и токен, выданный именно на этот креатив и именно на эту площадку. Если один из участников не передал свои данные, штраф получает он, а не вся цепочка сразу: закон не вводит солидарную ответственность за чужой договор. Но именно поэтому в договорах есть смысл сразу прописывать, кто и как передаёт данные, а не выяснять это после проверки, когда времени на исправление уже не остаётся.
Отдельно стоит агентская цепочка внутри самой сети: если у сети есть рекрутёры или суб-агенты, которые приводят вебмастеров и получают долю от их выплат, у каждого уровня такой цепочки — свой договор, и, значит, своя точка ответственности. Чем длиннее цепочка, тем важнее, чтобы на каждом её звене было явно написано, кто отвечает за пометку рекламы и передачу данных именно по этому звену, а не по цепочке в целом.
Разберём это на условном примере, чтобы разница между ролями стала конкретной. Рекламодатель — сервис доставки — заводит в сети оффер с оплатой за установку приложения. Сеть подписывает с ним договор на этот оффер и подключает к нему десять вебмастеров через свою оферту. Один из вебмастеров — блогер с телеграм-каналом — публикует интеграцию с промокодом. В этой цепочке три точки ответственности за маркировку: сервис доставки отвечает за то, что оффер как таковой подан на маркировку; сеть — за то, что её договор с этим конкретным блогером передан в ОРД; блогер — за то, что в самом посте стоит токен и пометка «Реклама». Если проверка найдёт непомеченный пост, вопрос будет не «кто из всей цепочки виноват», а предметно: кто из троих не выполнил свою часть — и это, как правило, видно по тому, чьих данных не хватает в реестре.
Что считается рекламой у партнёра
Не всякий материал, который публикует вебмастер, — реклама, подлежащая маркировке. Закон определяет её через два признака: адресована ли она неопределённому кругу лиц и направлена ли на привлечение внимания к конкретному объекту — товару, услуге, бренду, самому рекламодателю. Формат при этом не имеет значения: под определение попадают баннер на сайте, пост в соцсети со ссылкой на оффер, рекламная интеграция у блогера, Stories с промокодом, объявление в контекстной или таргетированной рекламе, push-уведомление и рассылка по базе подписчиков.
Для вебмастера это значит: реферальная ссылка сама по себе — не реклама, а вот пост, баннер или письмо, которые эту ссылку продвигают и обращены к аудитории, — реклама в юридическом смысле, и её нужно маркировать так же, как рекламодатель маркирует собственный баннер. Разница между «я просто поделился ссылкой» и «я разместил рекламу» — не в намерении, а в том, видит ли материал неопределённый круг людей и продвигает ли он конкретный объект. Личное сообщение конкретному человеку в мессенджере с советом купить конкретный товар формально не подпадает под определение — оно адресовано одному человеку, а не неопределённому кругу. Но как только тот же текст публикуется в открытом канале, статусе или посте, он перестаёт быть личным и становится рекламой на общих основаниях.
Отдельный случай — рассылки по собственной базе вебмастера: несмотря на то что аудитория здесь как будто определена — это подписчики, которые сами дали согласие на письма, — такие письма считаются рекламой, если в них продвигается конкретный оффер, а не отправляется персональный ответ на обращение конкретного человека. Закон смотрит не на то, знает ли отправитель имена подписчиков, а на то, обращён ли текст к кругу людей как к аудитории. То же с публикациями в каналах и чатах: если доступ в них не ограничен узким кругом лично знакомых людей — то есть в канал может зайти любой по ссылке, — материал маркируется на общих основаниях, даже если формально это «закрытая» группа с ограниченным входом.
Граница между обзором и рекламой на практике смещается от того, как устроен текст, а не от того, как автор сам называет свой материал. Пост, который называется «честным обзором», но заканчивается персональным промокодом и призывом «жду вас по ссылке в шапке профиля», по содержанию продвигает конкретный объект, и то, что автор в начале написал «это не реклама», ничего не меняет: маркировка определяется признаками текста, а не заявлением о жанре. Обратная ситуация тоже встречается: материал с пометкой «#реклама» в хэштегах, но без токена и без сведений о рекламодателе — не выполняет требование только потому, что автор добросовестно попытался обозначить рекламный характер поста словом, а не через установленный механизм.
Исключение — справочно-информационные материалы без признаков продвижения: например, нейтральное сравнение характеристик товаров без выделения конкретного бренда как лучшего варианта. Ещё одно исключение — сведения о товаре на собственном ресурсе того, кто его продаёт: карточка товара в интернет-магазине рекламодателя не считается рекламой на этой же странице, потому что покупатель сам пришёл искать информацию о товаре. Для CPA-партнёра такие исключения почти не применимы: сам смысл партнёрской ссылки — в продвижении чужого оффера конкретной аудитории, а не в справочном описании товара на его собственной витрине.
Отдельно стоит реклама, которая размещается через автоматические системы закупки показов в реальном времени: правила маркировки распространяются и на неё, но применяются с учётом того, кто в цепочке технически инициирует показ и кто заключает договор на размещение. Для CPA-сети это редкий случай — большинство офферов идёт не через RTB-закупку, а через прямое размещение вебмастером, — но если сеть выступает посредником и в таких схемах, разбираться, кто подаёт данные по конкретному показу, нужно так же внимательно, как и по обычному баннеру.
На практике вебмастера в CPA чаще всего работают в нескольких форматах одновременно, и стоит заранее решить для каждого, нужна ли маркировка. Пост в личном блоге с прямой ссылкой на оффер и призывом «оформите по моей ссылке» — реклама почти всегда. Обзорное видео на YouTube, где среди десяти сервисов упомянут и оффер сети без выделения его как рекомендуемого, — пограничный случай, который зависит от того, есть ли в ролике акцент на конкретном объекте. Контекстная реклама, которую вебмастер сам настраивает в рекламном кабинете на свою партнёрскую ссылку, — реклама вебмастера как рекламораспространителя, даже если рекламный кабинет технически принадлежит площадке, а не сети. А вот справка на собственном сайте вебмастера о том, чем один сервис отличается от другого, без прямого продвижения конкретного бренда как лучшего варианта, обычно в маркировке не нуждается — но такая справка на практике редко остаётся нейтральной дольше одного абзаца.
Данные для маркировки
Чтобы получить токен на креатив, ОРД нужен не сам текст поста, а пакет данных о том, кто, что и на каких условиях рекламирует. Базовый состав такой:
- сведения о рекламодателе — ИНН и наименование того, чей оффер продвигается;
- сведения о посреднике — в CPA это сеть: её реквизиты и роль в цепочке;
- данные о договоре — номер, дата, предмет, сумма, срок действия, включён ли НДС;
- сам креатив — текст, изображение или ссылка на то, что увидит аудитория;
- сведения о площадке размещения — где именно выйдет материал: сайт, соцсеть, конкретный канал или рассылка.
Токен erid выдаётся на конкретный креатив и конкретное размещение, а не на весь оффер разом: если вебмастер публикует один и тот же баннер на трёх площадках, это три отдельных акта размещения, и для каждого нужен свой токен — данные о договоре и рекламодателе при этом одни и те же, меняется только площадка. На практике токен добавляется в сам креатив или в ссылку, по которой переходит пользователь, — так, чтобы при проверке можно было однозначно связать конкретный показ с конкретной записью в реестре.
Собрать этот пакет данных заранее проще, чем кажется, потому что почти всё это уже есть в договоре между сетью и стороной размещения: номер, дата, стороны, сумма и предмет — стандартные реквизиты любого договора или публичной оферты. Не хватает обычно одного — самого креатива в финальном виде и точного описания площадки, потому что вебмастер часто дорабатывает материал перед публикацией, а токен нужен именно на итоговую версию, которую увидит аудитория, а не на черновик, согласованный на этапе постановки задачи.
Отдельно стоит вопрос точности самих данных: если рекламодатель передал сети ИНН или наименование с ошибкой, а сеть транслировала эту ошибку дальше в ОРД без проверки, формально данные всё равно считаются переданными неверно, и вопрос, кто виноват — тот, кто ошибся в исходных сведениях, или тот, кто их передал без сверки, — решается по тому же принципу договорной ответственности: за свои сведения отвечает тот, кто их предоставил, а за корректную передачу того, что предоставлено, — тот, кто её выполнял.
Для CPA-сети практическое следствие простое: данные о договоре с рекламодателем и с вебмастером должны быть готовы к передаче в ОРД ещё до того, как вебмастер опубликует первый креатив, — иначе токен получить не из чего, а первый показ уже нарушает требование. Разумный порядок действий — включить получение токена в чек-лист запуска оффера: подписали договор, согласовали креатив, получили токен, только после этого публикация. Если менять этот порядок и публиковать первым, а маркировать вторым, формально нарушение уже произошло в момент показа, и последующее получение токена его не отменяет.
Отдельный нюанс — правки уже опубликованного креатива. Если вебмастер меняет текст поста, добавляет новый визуал или переносит материал на другую площадку, это новое размещение, и старый токен на него не переносится: нужен новый акт передачи данных и, как правило, новый токен, привязанный к обновлённой версии.
Проверить, что токен действительно зарегистрирован, можно не только по факту его получения: сведения о промаркированной рекламе попадают в Единый реестр интернет-рекламы, и по номеру токена или по стороне договора можно посмотреть, что запись там есть. Для сети это удобный способ снять с себя часть риска — не просто верить вебмастеру на слово, что токен получен, а сверяться с реестром до того, как оффер массово раздаётся на публикацию. Особенно это касается офферов с десятками вебмастеров: выборочная проверка нескольких размещений в месяц обходится дешевле, чем разбирательство по каждому непомеченному посту после жалобы или проверки.
Кто передаёт данные
Закон не требует, чтобы каждый участник цепочки лично заводил кабинет в ОРД и сам отправлял данные, — отчитаться можно через посредника. Но кто бы технически ни отправлял данные, ответственность за то, что они переданы полностью, верно и в срок, остаётся на стороне, которая заключила договор.
Применительно к CPA это значит: если сеть по договору с рекламодателем берёт на себя передачу данных об этом договоре, то за качество передачи всё равно в первую очередь спрашивают с рекламодателя — он просто поручил техническую часть сети. Симметрично: если сеть передаёт данные о своих договорах с вебмастерами, ответственность за договор рекламодатель–сеть с сети не снимается, даже если саму отправку выполняет CPA-платформа. Поручение технической стороны не равно передаче ответственности — это разные вещи, и стоит различать их в переговорах с юристами обеих сторон.
Данные передаются не разово при получении токена, а ещё и по итогам показов: статистику размещения нужно подать в ЕРИР не позднее 30-го числа месяца, следующего за тем, в котором реклама вышла. Токен получают заранее, до начала показа, а отчёт о том, что показ состоялся, уходит позже и отдельно. Например, если баннер провисел на сайте вебмастера весь март, отчёт о фактическом показе должен уйти в реестр не позднее 30 апреля — и это отдельное действие от получения токена в начале месяца.
Отсюда практическое правило для сети: в договоре с рекламодателем и в оферте для вебмастера должно быть явно написано, кто подаёт данные в ОРД — сеть от имени стороны или сторона сама. Если это не прописано, при проверке выясняется постфактум, и обычно не в пользу того, кто промолчал. Отдельно стоит вебмастер, который работает с несколькими сетями и рекламодателями одновременно: для каждого договора данные подаются отдельно, и договорённость «сеть передаёт за меня» в одном договоре не действует в другом — вебмастеру придётся держать в голове или в таблице, по какому договору и через какую сеть он отчитывается.
На практике сети, которые берут передачу данных на себя, выбирают одного аккредитованного ОРД и работают через него по всем офферам сразу — это проще, чем заводить отдельные интеграции под каждого рекламодателя. Список аккредитованных операторов рекламных данных публикует сам Роскомнадзор, и выбор оператора не влияет на то, какие данные нужно собрать: состав пакета — договор, стороны, суммы, креатив, площадка — одинаковый независимо от того, через какого ОРД идёт отправка.
Ещё один практический вопрос — что делать, если рекламодатель уже работает с одним ОРД напрямую, а сеть хочет подавать данные о своих договорах с вебмастерами через другого. Закон это не запрещает: у каждой стороны договора может быть свой ОРД, лишь бы данные в итоге попали в единый реестр. Неудобство здесь чисто организационное — придётся дважды настраивать выгрузку данных, а не техническое или юридическое препятствие.
Разумный минимум для сети, которая не хочет разбирать конфликтные ситуации постфактум, — простой чек-лист перед запуском каждого нового оффера: договор с рекламодателем подписан и содержит нужные для ОРД реквизиты; договор или оферта с вебмастером явно называет, кто подаёт данные по его размещениям; токен на исходный креатив рекламодателя получен до первой публикации; в календаре стоит напоминание про отчёт по показам к 30-му числу следующего месяца. Такой список закрывает большинство ситуаций, которые на практике приводят к спорам о том, кто виноват в конкретном нарушении.
Договоры в цепочке
У классической рекламной кампании обычно один договор: рекламодатель — агентство. В CPA-сети договоров минимум два, и оба должны нести реквизиты, которых требует ОРД.
Первый — договор или публичная оферта между сетью и рекламодателем: здесь фиксируется, какой оффер запускается, какая модель оплаты действует, кто отвечает за маркировку самого оффера и кто передаёт данные об этом договоре в ОРД. Второй — договор или оферта между сетью и вебмастером: в ней стоит прописать не только условия выплат и холдов, но и обязанность вебмастера маркировать материалы, которые он публикует, и что произойдёт, если он этого не сделает и штраф придёт на сеть или рекламодателя. Формулировка про перекладывание ответственности работает только если она прямо прописана в тексте, а не подразумевается по умолчанию.
Отдельный пункт — агентские цепочки с рекрутёрами и суб-партнёрами: если вебмастер привлекает под себя других распространителей рекламы, у каждого уровня цепочки должен быть свой договор с понятной ролью, иначе неясно, чьи данные передавать в ОРД при проверке. Это особенно заметно в многоуровневых партнёрских программах, где вознаграждение делится между несколькими уровнями цепочки: юридическая обязанность маркировать материалы и передавать данные не зависит от того, сколько уровней стоит между рекламодателем и человеком, который фактически показал баннер аудитории, — она закреплена за конкретным договором на конкретном уровне.
Отдельно стоит правило про валюту и форму оплаты: сумма договора для целей ОРД — это то, что зафиксировано в самом договоре или оферте, а не то, сколько фактически заработал вебмастер по итогам холдов и корректировок конверсий. Если ставка меняется динамически или зависит от объёма, в договоре разумно закрепить формулу расчёта, а не единственное число — тогда данные, переданные в ОРД на старте оффера, не расходятся с тем, что подтверждает сеть внутри своего кабинета.
Договоры не обязаны быть длинными, чтобы быть рабочими: для ОРД достаточно, чтобы в них в явном виде были предмет, стороны, сумма и срок, а не отсылка «по прайс-листу на сайте». Это тот случай, где типовая оферта, один раз прогнанная через юриста, экономит разбирательства на каждом отдельном размещении. Стоит также заранее решить, как оформляются изменения условий — например, продление срока действия оффера или смена ставки: если это делается через дополнительное соглашение с датой и номером, данные для ОРД остаются актуальными автоматически; если через устную договорённость в переписке, при проверке возникает разрыв между тем, что реально происходит, и тем, что зафиксировано в договоре.
Отдельно стоит продумать момент прекращения размещения: когда рекламодатель останавливает оффер, а вебмастер не успел вовремя снять баннер или пост, формально размещение продолжается, и обязанность подавать по нему данные — тоже. Разумная практика — фиксировать в оферте срок, в течение которого вебмастер обязан снять материалы после команды на остановку оффера, и относиться к этому сроку так же серьёзно, как к срокам выплат.
Стоит также заранее решить, кто хранит архив креативов и токенов по каждому размещению — не только на момент публикации, а на весь срок, в течение которого проверка может запросить подтверждение. Практика показывает, что удобнее, если это делает сеть централизованно: у неё уже есть кабинет с историей договоров и начислений по каждому вебмастеру, и добавить туда же архив креативов с токенами — не отдельная система, а расширение того, что уже ведётся. Вебмастеру в этом случае достаточно один раз опубликовать материал с правильным токеном, а не держать у себя собственный архив на случай будущей проверки.
Что делает платформа, а что ОРД
Платформа для CPA-сети и оператор рекламных данных решают разные задачи, и разница между ними — источник половины путаницы в этой теме.
Кабинет сети на Recca ведёт рекламодателей, вебмастеров и договоры с обеими сторонами, считает клики и конверсии, применяет холды и подтверждение конверсий, начисляет и проводит выплаты, шлёт постбэки в формате, совместимом с конвенцией Affise, поддерживает агентские цепочки с распределением доли между уровнями и уведомляет о событиях внешние системы через API. Это данные о том, как работает партнёрская программа: кто с кем в каких отношениях, сколько заработал, когда деньги стали доступны к выплате.
ОРД решает другую задачу: выдаёт токен на конкретный рекламный креатив и передаёт в Единый реестр интернет-рекламы сведения о том, что реклама показана, — договор, площадку, сам материал. Recca таким оператором не является и токены не выдаёт: получать их сеть или рекламодатель должны напрямую у аккредитованного Роскомнадзором ОРД, выбранного отдельно от платформы. Это разделение не техническая прихоть, а прямое следствие того, что закон описывает две разные функции — учёт хозяйственных отношений между сторонами и учёт самой рекламы как явления, которое видит аудитория.
Связка простая: данные, которые нужны для передачи в ОРД — реквизиты договоров, стороны, суммы, сроки, — у сети и так есть в кабинете, потому что это те же данные, на которых строятся холды и выплаты. Их можно выгрузить или прокинуть через API в выбранный ОРД, но саму отправку и получение токена делает ОРД, а не платформа сети. Практический порядок обычно такой: сеть заводит договор и оффер в своём кабинете, экспортирует нужные поля в интерфейс или API выбранного ОРД, получает токен, передаёт его вебмастеру для размещения в креативе, а по итогам месяца отправляет отчёт о показах — снова через ОРД, а не через платформу сети.
Такое разделение удобно ещё и потому, что оно не привязывает сеть к одному ОРД навсегда: если условия у выбранного оператора перестают устраивать, можно перейти к другому, не меняя саму платформу и не переделывая структуру договоров и кабинетов рекламодателей и вебмастеров, которые остаются на прежнем месте вне зависимости от того, кто выдаёт токены.
Для крупной сети с большим числом рекламодателей разделение платформы и ОРД устроено проще, чем кажется на старте: рекламодатели могут приходить со своими предпочтениями по оператору рекламных данных, а сеть при этом ведёт их всех в одном кабинете и просто передаёт им нужные для маркировки реквизиты в удобном виде — вручную, через выгрузку или через API. Кабинет сети в этом смысле остаётся источником истины о договорах и деньгах независимо от того, сколько разных ОРД используют её рекламодатели по своим офферам.
Частые вопросы
Нужно ли маркировать пост вебмастера, если в нём просто реферальная ссылка без описания оффера? Если пост не продвигает конкретный товар или услугу, а только содержит ссылку без рекламного посыла, формально это не реклама. На практике такой пост в CPA встречается редко — обычно в нём есть описание, призыв или оценка оффера, а это уже признак рекламы.
Кто платит штраф, если вебмастер забыл поставить токен на баннер? Отвечает тот, кто не передал данные о своём размещении, — в этом случае вебмастер или сторона, которая по договору отвечала за его материалы. Договор с сетью не переносит ответственность автоматически: она перекладывается только тем пунктом, который стороны прямо в нём прописали.
Меняется ли что-то для white label кабинета сети? Нет: обязанность маркировать рекламу и передавать данные в ОРД не зависит от того, на каком домене открывается кабинет вебмастера или рекламодателя. Это требование к самой рекламе, а не к интерфейсу, через который её размещают.
Нужно ли маркировать рассылку по собственной базе вебмастера? Да, если в письме продвигается конкретный оффер, а не отправляется персональный ответ на обращение. Рассылка по базе адресована неопределённому в юридическом смысле кругу подписчиков, поэтому подпадает под общие требования маркировки.
Что будет, если рекламодатель уже промаркировал оффер сам, а вебмастер публикует его без токена? Токен на общий оффер не покрывает конкретное размещение конкретного вебмастера: у каждого материала, который реально увидела аудитория, должен быть свой токен, привязанный именно к этому размещению. Токен, который рекламодатель получил на баннер для сети, не освобождает вебмастера от получения токена на его собственный пост.
Нужен ли отдельный токен каждому уровню в агентской цепочке, если рекрутёр просто приводит вебмастеров и сам ничего не публикует? Нет, если рекрутёр не размещает рекламные материалы, а только привлекает вебмастеров и получает долю от их выплат: у него нет рекламораспространения, значит, и токен получать не из чего. Но договор между сетью и рекрутёром всё равно должен ясно описывать его роль, чтобы при проверке не возникало вопроса, почему в цепочке есть сторона без данных в ОРД.
Есть ли наказание за то, что данные передали с опозданием, а не за то, что не передали вовсе? Закон не делит нарушения на «опоздал» и «не сделал» — формально это одно и то же основание: данные не переданы в срок. На практике риск растёт с длительностью просрочки и с тем, попал ли конкретный показ в проверку до того, как данные всё-таки отправили, но рассчитывать на разницу в подходе не стоит — правильнее закрывать вопрос до, а не после публикации.
Что делать, если сеть работает и с российскими, и с зарубежными рекламодателями по одному офферу? Требование маркировки привязано не к тому, где зарегистрирован рекламодатель, а к тому, что реклама показывается аудитории в российском интернет-пространстве. Если показ адресован пользователям в России, данные о нём нужно передавать в ОРД независимо от юрисдикции рекламодателя, а конкретный порядок оформления договора с иностранной стороной — вопрос отдельно к юристам сети.
Один вебмастер продвигает в одном посте сразу несколько офферов разных рекламодателей — сколько нужно токенов? Столько, сколько офферов реально продвигается в материале: у каждого рекламодателя свой договор, и данные о размещении для каждого из них подаются отдельно, даже если физически это один пост с несколькими ссылками. Токен привязан к конкретному договору и конкретному объекту рекламирования, а не к посту как единице контента.
Что грозит сети и вебмастеру, если данные о рекламе так и не переданы в ОРД? Ответственность за отсутствие пометки и за непередачу данных предусмотрена статьёй 14.3 КоАП РФ отдельно для граждан, должностных и юридических лиц, и для юридических лиц штраф ощутимо выше, чем для граждан. Дальше всё зависит от того, кто по договору отвечал за конкретное размещение: разбирательство идёт не по всей цепочке сразу, а по тому звену, чьих данных не хватает в реестре.
Меняется ли что-то, если вебмастер зарегистрирован как самозанятый, а не как ИП или ООО? Нет: обязанность маркировать рекламу и передавать данные о размещении привязана к тому, что человек или организация выступает рекламораспространителем, а не к налоговому статусу. Самозанятый вебмастер обязан получить токен на свой креатив и поставить пометку «Реклама» точно так же, как ИП или юридическое лицо в этой же роли.
Если цепочка договоров и данные для ОРД уже понятны, дальше — техническая часть: кабинет, который ведёт договоры, холды и начисления в одном месте. Оставить заявку на подключение CPA-сети или сначала посмотреть тарифы.
