Compliance-чек-лист для b2b-сейл партнёрки: что должно быть в пакете

В b2b-сейл партнёрке compliance начинается не с креатива, а с набора обязательных документов и процессов.

Минимальный пакет:
— политика конфиденциальности и cookies;
— terms / оферта с описанием роли сторон;
— DPA или приложение по обработке данных, если партнёр передаёт лиды;
— список юрисдикций, где разрешён трафик;
— правила по источникам трафика, brand bidding, email, cold outreach;
— contact point для запросов по privacy и complaints.

Если есть обработка персональных данных в РФ, отдельно проверьте 149-ФЗ и локализацию: где хранится база, кто оператор, кто обработчик, кто получает доступ. Для EU-рынков — GDPR: правовое основание, сроки хранения, механизм удаления, порядок ответа на DSAR.

Для партнёрки критично, чтобы в договоре были зафиксированы:
— кто отвечает за согласие пользователя;
— кто и когда передаёт лид;
— какие поля считаются обязательными;
— что считается non-compliant lead;
— порядок аудита и приостановки выплат;
— запрет на подмену источника и скрытую маршрутизацию.

Технический слой не слабее юридического. Нужны логи согласий, UTM-цепочка, timestamp передачи лида, версия формы, источник и страна. Без этого спор по качеству лида обычно заканчивается не в пользу команды, которая не может показать цепочку данных.

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

Если у партнёрки нет хотя бы этого набора, она выглядит не как b2b-процесс, а как устная договорённость с риском по данным и выплатам.

Google Privacy Sandbox меняет трекинг: что проверять команде с собственным трекером

Если у команды есть свой трекер, Privacy Sandbox в экосистеме Google — это не про «когда-нибудь», а про архитектуру данных, consent и атрибуцию в Chrome/Android.

Базовый набор для проверки:
— разделение first-party и third-party контуров;
— работа с consent string и хранение статуса согласия отдельно от рекламных событий;
— серверная обработка конверсий и минимизация зависимости от client-side cookies;
— корректная деградация атрибуции, когда browser signals недоступны;
— журналирование источника события: web, app, server, postback.

Важный момент: Privacy Sandbox не отменяет требования к правовой базе обработки данных в EU и UK. Если в цепочке есть персональные данные, остаются актуальны GDPR, ePrivacy и локальные требования к согласиям. Технический стек не заменяет документацию по data flow и retention.

Для собственного трекера полезно заранее заложить:
— модуль consent management;
— версионирование схемы событий;
— mapping между campaign IDs и агрегированными отчётами;
— резервный канал атрибуции для loss of signal;
— контроль того, какие поля уходят в партнёрки, DSP и postback-цепочки.

Отдельная зона риска — идентификаторы и кросс-девайс связка. Чем больше попыток восстановить пользователя по косвенным признакам, тем выше регуляторная нагрузка на обработку. В EU это особенно чувствительно, если данные используются для профилирования.

Практический минимум для команды: сначала описать data flow, затем проверить consent, потом пересобрать атрибуцию под server-side. Трекер без этой ревизии будет считать, но всё хуже объяснять.

TikTok policy для рекламы: чем отличаются Tier-1 и Tier-3

У TikTok одна глобальная рекламная политика, но на практике модерация и риск-баланс по гео заметно отличаются между Tier-1 и Tier-3.

В Tier-1 выше чувствительность к claims, privacy и disclosure. Для США, UK, CA, EU чаще проверяют:
— недостоверные обещания результата;
— использование персональных атрибутов в крео;
— некорректные до/после;
— отсутствие маркировки рекламного характера, если она требуется по локальным правилам.

В Tier-3 обычно больше объём допуска по креативам и офферам, но это не означает «мягкую» политику. Там чаще всплывают другие причины отклонений:
— локальные ограничения по вертикали;
— языковые несоответствия лендинга и объявления;
— несостыковка страны, валюты, контактов и языка;
— подозрение на misleading flow или агрессивный редирект.

Для арбитражной команды практическая разница такая:
— Tier-1 требует более чистой юридической и визуальной упаковки;
— Tier-3 требует более аккуратной локализации и соответствия гео;
— одинаковый креатив в разных странах может проходить по-разному даже при одном и том же оффере.

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

В TikTok лучше исходить не из «гео попроще», а из того, насколько оффер и воронка выглядят прозрачными для модерации. Чем меньше разрыв между обещанием в крео и содержанием ленда, тем стабильнее открутка.

Empire Agency ищет 100 партнёров и даёт BM2500/BM10.000

Empire Agency объявила поиск 100 новых партнёров для масштабирования. В предложении указаны BM2500 и BM10.000, а также агентские аккаунты с лимитами от $250 до NoLimit. Комиссия на первый депозит — 0%.

Для арбитражных команд здесь важны не лозунги, а параметры входа: тип BM, диапазон лимитов и стоимость первого депозита. В таких офферах обычно смотрят на скорость выдачи, стабильность лимитов и то, как быстро меняется риск-профиль аккаунта после старта.

На фоне того, что средний срок жизни обычного аккаунта при заливе на «серые» вертикали сократился на 40–60% по сравнению с 2022 годом, условия по агентским аккаунтам становятся не маркетингом, а частью операционной модели.

Манифест PWA: какие поля проверять до запуска кампании

PWA в арбитраже часто оценивают не только по креативу и преленду, но и по базовой техструктуре. В манифесте должны быть перечислены имя приложения, short_name, start_url, display, icons и description. Если этих полей нет или они заполнены формально, у платформ и у проверяющих возникает вопрос к качеству продукта.

Отдельно смотрят на согласованность. Название в name и short_name должно совпадать с тем, что пользователь видит в интерфейсе, и не должно имитировать чужой бренд. start_url лучше вести на стабильный адрес, без цепочек редиректов и лишних параметров. display обычно используют в режимах standalone или fullscreen, но выбранный режим должен соответствовать реальному UX, а не маскировать сайт под «нативное» приложение.

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

В самом манифесте полезно проверить:
— scope: не уводит ли пользователя за пределы ожидаемого приложения;
— theme_color и background_color: не конфликтуют ли с интерфейсом;
— lang: соответствует ли гео и языку лендинга;
— id и orientation: не ломают ли предсказуемость установки и запуска.

Для команд, которые работают с EU и РФ, важно одно правило: манифест не должен вводить пользователя в заблуждение относительно того, кто стоит за продуктом и что именно он устанавливает. Если PWA выглядит как другое приложение, а ведёт на иной сервис, это уже плохой сигнал для модерации и для внутреннего review.

Перед заливом проверьте манифест вместе с UI, редиректами и favicon. В PWA несоответствие между декларацией и фактическим интерфейсом видно быстрее, чем в обычном web.

Privacy policy на лендинге: 9 пунктов, без которых документ выглядит пустым

Для арбитражного лендинга privacy policy — не декоративная страница, а базовый элемент комплаенса. В EU это обычно привязка к GDPR, в РФ — к 152-ФЗ и локализации требований к персональным данным, в US — к отраслевым и штатным disclosure-практикам.

Минимум, который должен быть в тексте:
— кто является controller / operator и как с ним связаться;
— какие данные собираются: формы, cookies, пиксели, device data, IP;
— для каких целей используется сбор: лиды, аналитика, ретаргетинг, антифрод;
— правовое основание обработки для каждой цели;
— кому данные передаются: CRM, трекеры, email-сервисы, платёжные провайдеры;
— сроки хранения и критерии удаления;
— права пользователя: доступ, исправление, удаление, возражение, отзыв согласия;
— cross-border transfer и механизм передачи;
— cookies policy и способ управления согласием.

Отдельно проверь, чтобы privacy policy совпадала с фактической архитектурой трафика. Если на лендинге стоят Meta Pixel, Google Tag, TikTok Pixel, server-side events или call-tracking, это должно быть отражено в тексте. Если форма ведёт в несколько систем, список получателей не должен быть «we may share with partners» без расшифровки.

Для EU важны ссылки на GDPR и право на подачу жалобы в надзорный орган. Для РФ — понятная идентификация оператора и описание обработки по 152-ФЗ. Для iGaming, Nutra, Dating особенно критично, чтобы disclosure не расходился с гео и источником трафика.

Проверка простая: если удалить одно предложение из privacy policy, и смысл пропадёт, документ слабый. Если же каждый пункт можно сопоставить с реальным трекингом и формой на лендинге, текст рабочий.

SPF, DKIM и DMARC в CPA-письмах — это не опция, а базовая гигиена домена

Для email-маркетинга в CPA важны не только креатив и база, но и то, как письмо выглядит для почтовых систем. Если домен не настроен, письмо чаще уходит в спам, а репутация отправителя падает быстрее, чем растёт open rate.

Минимальный набор для домена:
• SPF — список серверов, которым разрешено отправлять письма от имени домена
• DKIM — криптоподпись письма, подтверждающая, что его не подменили по дороге
• DMARC — политика, которая говорит, что делать, если SPF или DKIM не сошлись

Без этой тройки массовая рассылка в CPA превращается в нестабильный канал: доставляемость плавает, домен быстрее деградирует, жалобы и бounces бьют по репутации. Для арбитражных команд это уже не техническая мелочь, а часть compliance-процесса.

Что обычно проверяют перед запуском:
— отдельный домен или поддомен под рассылку
— корректный SPF без лишних include и дублирования
— DKIM на каждом отправляющем сервисе
— DMARC хотя бы в режиме p=none на этапе наблюдения, затем ужесточение политики
— выровненные From, домен подписи и домен отправки

Практика простая: сначала настраивается инфраструктура, потом масштабируется объём. Иначе команда получает не канал продаж, а постоянную работу по восстановлению доменной репутации.

Квартальный обзор GEO для iGaming: что проверять в регуляторике до масштабирования

Перед запуском в новое GEO не хватает не креатива, а сверки по трём слоям: лицензия, реклама, платежи. Для iGaming это разные режимы в зависимости от юрисдикции: EU, UK, LATAM, отдельные штаты US, а в ряде стран — полный запрет или работа через локального оператора.

Что смотреть в каждом GEO:
— статус азартных игр: разрешены, лицензируются, ограничены или запрещены;
— кто может рекламировать: оператор, аффилиат, медиабаинг-партнёр, influencer;
— допустимые каналы: search, social, display, email, push, in-app;
— требования к responsible gambling, возрастным дисклеймерам и гео-фильтрам;
— правила по KYC/AML для депозита, вывода и source of funds.

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

Третий слой — данные и трекинг. Если GEO затрагивает EU, нужно смотреть GDPR: правовое основание, cookies consent, retention, DPA с подрядчиками. Для UK и некоторых стран EEA требования по согласиям и рекламным формулировкам часто жестче, чем у самой платформы.

Квартальный цикл проверки простой:
— обновить таблицу GEO по лицензии и рекламе;
— сверить whitelist/blacklist каналов;
— проверить тексты офферов и лендингов;
— подтвердить платежные ограничения;
— пересмотреть KYC/AML и хранение данных.

Если GEO не проходит по одному из слоёв, масштабирование откладывают до фиксации именно этого блока, а не «в целом потом доработаем».

Договор с advertiser-стороной: 7 пунктов, которые читают до подписи

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

1. Предмет договора. Должно быть понятно, за что именно платят: source, GEO, vertical, модели оплаты, ограничения по placement и каналам. Если предмет описан общо, спор потом уходит в «не тот трафик».

2. Acceptance и hold. Смотрите, кто и в какой срок подтверждает лиды, что считается молчаливой приёмкой, когда начинается холд. Без этого advertiser может растягивать сверку бесконечно.

3. Rejection reasons. Основания для отклонения должны быть перечислены, а не спрятаны в «quality at advertiser’s discretion». Иначе почти любой отказ можно обосновать задним числом.

4. Fraud, traffic quality, chargeback. Важно, есть ли определение фрода, кто и как его доказывает, можно ли запросить отчёт или evidence pack. Формулировка «по усмотрению advertiser» — красный флаг.

5. Tracking и postback. В договоре должны сходиться окна атрибуции, источники данных и порядок споров по трекингу. Если у вас разные окна, спор по конверсии почти неизбежен.

6. Payment terms. Валюта, реквизиты, дата инвойса, срок оплаты, комиссии банка, право на netting. Отдельно проверяют, можно ли удерживать выплаты за спорные лиды без процедуры.

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

Минимум, который стоит иметь до запуска: подписанный договор, приложение с KPI и GEO, регламент споров по лид-статусу, порядок обмена отчётами. Чем меньше конкретики в тексте, тем больше её придётся собирать потом вручную.

Data retention policy: какие сроки хранения нужны CPA-команде и на чём их обосновать

Для CPA-команды политика хранения данных — это не «про запас», а про минимизацию риска. В EU логика строится вокруг GDPR: хранить персональные данные можно только столько, сколько нужно для цели обработки. В РФ ориентир — 152-ФЗ и локальные требования к обработке и хранению персональных данных.

Базовый набор сроков обычно выглядит так:
— лиды и формы до момента квалификации и передачи в партнёрку;
— неуспешные заявки — только на срок, нужный для антифрода, споров и аудита;
— выплаты, инвойсы, акты, KYC/AML-документы — по срокам бухгалтерского и финансового хранения;
— логи трекинга, доступы, события сервер-сайд — до срока, достаточного для расследования инцидентов и сверки атрибуции.

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

Критично разделять данные по классам. Платёжные и KYC-данные не должны жить столько же, сколько маркетинговые cookies или UTM-логи. Для каждого класса нужен свой срок, способ удаления и ответственный за исполнение. Если срок не определён, это почти всегда признак лишнего хранения.

Практический минимум: таблица data category → purpose → retention period → legal basis → deletion method. Это проще всего защищается перед юристом, DPO и партнёром по выплатам.

Cookie consent в собственном трекере: что должно быть в базовой схеме

Если трекер собирает идентификаторы, IP, user-agent, referrer, параметры клика и связывает их с пользователем, это уже не «технический мусор», а обработка данных. Для EU это обычно означает проверку на GDPR и ePrivacy; для РФ — связку с 152-ФЗ и локализацией, если есть данные российских пользователей.

Базовая логика простая:
— до установки необязательных cookie и маркетинговых идентификаторов нужен понятный consent;
— consent должен быть отдельным действием, без заранее отмеченных чекбоксов;
— пользователь должен видеть, какие категории cookie включены: necessary, analytics, marketing;
— отказ должен быть так же доступен, как согласие;
— текст политики должен совпадать с фактической настройкой трекера.

Для собственного трекера важно не только показывать баннер, но и хранить доказательство выбора: время, версия текста, страна/гео, набор включённых категорий. Без этого consent трудно подтвердить при споре или проверке. В EU это особенно чувствительно для marketing cookies и fingerprinting-подобных механизмов.

Отдельная зона риска — server-side tracking. Если на клиенте баннер есть, а сервер всё равно пишет идентификаторы до согласия, формально схема ломается. То же касается пикселей, postback-цепочек и скрытых скриптов, которые живут вне CMP.

Минимальный чек-лист:
— карта всех данных, которые собирает трекер;
— раздельные категории cookie;
— журнал согласий;
— политика retention;
— процедура обновления баннера при изменении логики сбора.

Если трекер используется в нескольких гео, consent нужно проектировать не «в среднем по рынку», а по самой строгой юрисдикции в вашей цепочке.