Хто відповідає за згоду? Проста модель відповідальності для команд видавців
Проблема: згоди торкаються всі, але не відповідає ніхто
Запитайте, хто відповідає за згоду в типовому видавця з рекламною моделлю, і ви почуєте кілька відповідей. Юристи написали політику 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 та збирає потрібних людей, коли щось змінюється. У невеликих командах це часто хтось із рекламних операцій чи розробки з прямим виходом на юристів.
Процеси, завдяки яким модель працює
- Маршрут запитів на нові теги. Кожен новий піксель, SDK чи партнер проходить через єдиний прийом заявок із короткою формою: що він робить, які дані збирає, які цілі йому потрібні, хто запросив.
- Журнал змін. Записуйте кожну зміну вендорів, цілей, тексту й дизайну банера з датою та затверджувачем. Це безцінно, коли змінюється метрика або надходить запитання від партнера чи регулятора.
- Перевірка релізу. Жоден реліз, що торкається тегів чи банера, не виходить без тесту згоди в чистому браузері.
- Регулярний огляд. Раз на квартал власник звіряє список вендорів із реальними тегами, метрики згоди з доходом, а політику cookie з обома.
- Шлях ескалації. Коли юристи та дохід розходяться в думках, рішення ухвалює призначена людина, а обґрунтування записується.
Ознаки того, що моделі відповідальності бракує
- Ніхто не може сказати, коли востаннє переглядався список вендорів.
- На сайті з’являються теги, яких немає в CMP.
- Зміни банера виходять, і ніхто потім не перевіряє рівень згоди.
- Різні команди дають різні відповіді щодо того, які партнери отримують TC string.
- Запитання партнерів про сигнали згоди лишаються без відповіді днями.
Головні висновки
- Згода торкається юристів, рекламних операцій, розробки, продукту й маркетингу; їй потрібен один відповідальний власник.
- Простий RACI перетворює рішення, що повторюються, на передбачуваний процес.
- Пропускайте кожен новий тег через єдиний прийом заявок із перевіркою згоди.
- Ведіть журнал змін і переглядайте налаштування щокварталу.
- Запишіть, як вирішуються розбіжності між доходом і приватністю.