Проблема: согласия касаются все, но не отвечает никто

Спросите, кто отвечает за согласие в типичном издателе с рекламной моделью, и вы услышите несколько ответов. Юристы написали политику cookie. Рекламные операции добавили вендоров. Разработка установила баннер. Продукт изменил дизайн в прошлом квартале. Маркетинг добавил новый пиксель на прошлой неделе. Каждое из этих изменений было разумным само по себе, но никто не отвечал за то, как они сочетаются, — так на сайте появляются тег, срабатывающий до согласия, вендор, которого нет в баннере, или редизайн, незаметно снизивший уровень согласия.

В этой статье предлагается простая модель ответственности, чтобы у решений о согласии был понятный владелец, понятный утверждающий и понятный процесс.

Почему ответственность важна и для дохода, и для рисков

Согласие находится между двумя целями, которые тянут в разные стороны. Юристы и специалисты по приватности смотрят, уважает ли настройка выбор пользователей и применимые правила. Рекламные операции и команды дохода смотрят, какой объём инвентаря можно монетизировать по полной стоимости. Заботиться об этом правы обе стороны. Без определённого владельца разногласия решает тот, кто последним менял конфигурацию, а не решение, которое кто-либо сможет потом объяснить.

Роли

Большинство издателей могут свести работу над согласием к пяти ролям, даже если одному человеку принадлежит несколько из них:

• Приватность или юристы — толкуют правила, утверждают цели, правовые основания и формулировки баннера и отвечают за политику cookie.
• Рекламные операции или доход — управляют партнёрами по спросу и списками вендоров, следят за доходом, связанным с согласием, и запрашивают изменения, влияющие на монетизацию.
• Разработка — внедряет CMP, управляет загрузкой тегов и следит, чтобы скрипты учитывали сигналы согласия.
• Продукт и дизайн — отвечают за пользовательский опыт баннера в пределах, заданных юристами, и проводят тесты вёрстки и текста.
• Маркетинг и аналитика — запрашивают новые теги и инструменты измерения и полагаются на сигналы согласия в отчётности.

RACI для повторяющихся решений

RACI перечисляет, кто Responsible (выполняет работу), Accountable (принимает окончательное решение), Consulted (консультируется) и Informed (информируется). Вот отправная точка:

Добавление нового вендора или тега

• Responsible: рекламные операции или маркетинг (тот, кто запрашивает).
• Accountable: приватность или юристы.
• Consulted: разработка, по вопросу, как он будет блокироваться до согласия.
• Informed: продукт.

Изменение дизайна или текста баннера

• Responsible: продукт и дизайн.
• Accountable: приватность или юристы.
• Consulted: рекламные операции, по ожидаемому влиянию на доход.
• Informed: разработка и маркетинг.

Изменение целей или правовых оснований

• Responsible и accountable: приватность или юристы.
• Consulted: рекламные операции и разработка.
• Informed: все, кто опирается на данные о согласии.

Конфигурация CMP и релизы

• Responsible: разработка.
• Accountable: назначенный владелец согласия (см. ниже).
• Consulted: приватность и рекламные операции.
• Informed: продукт и маркетинг.

Мониторинг метрик согласия и дохода

• Responsible: рекламные операции.
• Accountable: владелец согласия.
• Consulted: продукт.
• Informed: приватность или юристы, особенно об аномалиях.

Назначьте единого владельца согласия

RACI работает лучше всего, когда один человек отвечает за настройку согласия в целом. Это не обязательно самый старший сотрудник; это человек, который согласует список вендоров, конфигурацию баннера, инвентаризацию тегов и политику cookie и собирает нужных людей, когда что-то меняется. В небольших командах это часто кто-то из рекламных операций или разработки с прямым выходом на юристов.

Процессы, благодаря которым модель работает

1. Маршрут запросов на новые теги. Каждый новый пиксель, SDK или партнёр проходит через единый приём заявок с короткой формой: что он делает, какие данные собирает, какие цели ему нужны, кто запросил.
2. Журнал изменений. Записывайте каждое изменение вендоров, целей, текста и дизайна баннера с датой и утверждающим. Это бесценно, когда меняется метрика или приходит вопрос от партнёра или регулятора.
3. Проверка релиза. Ни один релиз, затрагивающий теги или баннер, не выходит без теста согласия в чистом браузере.
4. Регулярный обзор. Раз в квартал владелец сверяет список вендоров с реальными тегами, метрики согласия с доходом, а политику cookie с обоими.
5. Путь эскалации. Когда юристы и доход расходятся во мнениях, решение принимает назначенный человек, а обоснование записывается.

Признаки того, что модели ответственности не хватает

• Никто не может сказать, когда в последний раз пересматривался список вендоров.
• На сайте появляются теги, которых нет в CMP.
• Изменения баннера выходят, и никто потом не проверяет уровень согласия.
• Разные команды дают разные ответы о том, какие партнёры получают TC string.
• Вопросы партнёров о сигналах согласия остаются без ответа днями.

Главные выводы

• Согласие затрагивает юристов, рекламные операции, разработку, продукт и маркетинг; ему нужен один ответственный владелец.
• Простой RACI превращает повторяющиеся решения в предсказуемый процесс.
• Пропускайте каждый новый тег через единый приём заявок с проверкой согласия.
• Ведите журнал изменений и пересматривайте настройку ежеквартально.
• Запишите, как разрешаются разногласия между доходом и приватностью.