Elido
10 хв читанняВідповідність

Consent Mode v2 для відстеження посилань: що змінив DMA

Consent Mode v2 та DMA змінили правила аналітики коротких посилань — що означають чотири сигнали, як насправді працює відновлення даних на стороні сервера та що кажуть актуальні настанови EDPB та CJEU

Sasha Ehrlich
Compliance · EU residency
Чотири стекові сигнали згоди — ad_storage, ad_user_data, ad_personalization, analytics_storage — зі станами denied та granted та шляхами відновлення на стороні сервера поруч із кожним

Consent Mode v2 перестав бути необов'язковим 2024-03-06. З цієї дати трафік з ЄС та ЄЕЗ у рекламних продуктах Google має передавати два нові сигнали — ad_user_data та ad_personalization — разом з оригінальними ad_storage та analytics_storage. Ця зміна була продиктована не GDPR, а Digital Markets Act (Regulation (EU) 2022/1925), а саме Art. 5(2) DMA, який забороняє призначеним ґейткіперам комбінувати або перехресно використовувати персональні дані в різних сервісах без явної згоди.

Для сервісу скорочення посилань це перетинається з рівнем даних перенаправлення досить складним чином. Коротке посилання — це те, на що натиснув користувач; стан згоди на цільовій сторінці визначає, чи можна атрибутувати цей клік. Ці дві події відбуваються на різних доменах, у різних сховищах cookies, часто в різних сесіях. Розрив між ними — це місце, де зараз відбувається найбільша втрата атрибуції.

Цей допис — це погляд чинного юриста з комплаєнсу на те, що змінилося, що насправді означають ці чотири сигнали для сервісу перенаправлення, де відновлення на стороні сервера є законним згідно з поточними настановами EDPB, а де — ні. Більшість інженерної роботи для відстеження на стороні сервера через перенаправлення є нормальною з точки зору GDPR; деякі її частини — ні з точки зору DMA.

DMA за один абзац#

Digital Markets Act почав застосовуватися 2024-03-07. Він визначає «ґейткіперів» — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — і накладає на них зобов'язання ex ante. Art. 5(2) DMA — це те, що має значення для відстеження: ґейткіпер не повинен обробляти персональні дані кінцевих користувачів сторонніх сервісів для онлайн-реклами, а також комбінувати персональні дані у своїх сервісах без згоди.

Consent Mode v2 — це механізм відповідності Google вимогам Art. 5(2). Два нові сигнали — ad_user_data та ad_personalization — дозволяють ґейткіперу побачити, чи отримав видавець згоду рівня Art. 5(2) перед тим, як телеметрія кліків буде використана для реклами або персоналізації. Без цих сигналів у стані granted рекламні продукти Google повертаються до агрегованих або модельованих конверсій без атрибуції на рівні користувача.

DMA не замінює GDPR. Він стоїть зверху. Контролеру все ще потрібна правова підстава згідно з Art. 6 GDPR; Consent Mode v2 додає другі ворота, які закриваються для рекламних даних, що проходять через ґейткіперів, навіть коли ворота GDPR відчинені.

Чотири сигнали простою мовою#

Consent Mode v2 передає чотири булеві сигнали. Кожен може бути granted або denied. Значення за замовчуванням можна встановити для кожного регіону.

ad_storage — оригінальний сигнал v1. Контролює, чи записуються cookies або інші дані у сховище для реклами. Коли встановлено denied, теги Google спрацьовують без ідентифікаторів; вимірювання конверсій деградує до агрегованих моделей без cookies. Перенаправлення вирішує, які UTM та ідентифікатори кліків потраплять на сторінку, і саме до них прив'язується стан згоди. Документація згоди для тегових платформ є канонічним джерелом того, що кожен сигнал робить далі по ланцюжку.

ad_user_data — новий у v2. Контролює, чи можуть дані користувача надсилатися до Google для реклами взагалі. Це сигнал Art. 5(2) DMA. Коли встановлено denied, тег не може передавати дані користувача — включаючи хешовані ідентифікатори, IP, user-agent — до Google Ads. Тегування на стороні сервера не обходить це; сигнал подорожує разом із подією.

ad_personalization — також новий. Контролює, чи можуть передані дані використовуватися для персоналізованої реклами, включаючи ремаркетинг. Поширена конфігурація: ad_user_data=granted плюс ad_personalization=denied, що дозволяє атрибуцію, але блокує ремаркетинг.

analytics_storage — контролює, чи записуються дані у сховище для аналітики. Тег GA4 враховує це; коли встановлено denied, GA4 працює без cookies і використовує моделювання через consent mode для реконструкції атрибуції на агрегованому рівні. Моделювання потребує мінімального обсягу трафіку та 7-денного періоду навчання.

Жоден із чотирьох сигналів не визначається на рівні сервісу скорочення. Сервіс скорочення генерує клік; цільова сторінка зчитує сигнали; тег на цільовій сторінці вирішує, що з ними робити. Робота сервісу скорочення — доставити чистий стан (збережені UTM, збережений ідентифікатор кліку, швидке перенаправлення), щоб банер міг відобразитися до того, як спрацює тег.

Що йде не так на рівні даних перенаправлення#

Три режими відмови проявляються в кожному сервісі скорочення, який серйозно ставиться до шляху перенаправлення.

Ідентифікатор кліку зберігається, а сигнал згоди — ні. Клік по рекламі Meta потрапляє на s.elido.me/abc123?fbclid=… і перенаправляється на https://customer.example/landing?fbclid=…. fbclid збережено. Сторінка завантажується, з'являється банер, користувач відмовляє. Meta CAPI вже отримала клік, прив'язаний до цього fbclid, але користувач тепер заборонив використання для реклами. Сервіс скорочення не зробив нічого поганого; у контролера виникає проблема з дедуплікацією CAPI на їхньому боці.

Сервіс скорочення додає ідентифікатори, які цільова сторінка не розуміє. Деякі сервіси (Bitly з bitly_session, Rebrandly з _branch_match_id) додають специфічні параметри вендорів, які потребують видалення або спеціальної обробки у разі відмови в згоді. Elido передає лише UTM та власний ідентифікатор кліку клієнта.

Стан згоди на цільовій сторінці неможливо знати з точки зору перенаправлення. Сервіс скорочення не може бачити банер, який ще не завантажився. Рішення про резервне копіювання на стороні сервера не можуть залежати від стану згоди, якого ще не існує. Єдиний чесний варіант за замовчуванням: не запускати жодних серверних подій для рекламних цілей під час перенаправлення; дозволити банеру відобразитися, а потім дозволити сторінці або її проксі спрацювати з доданим станом згоди.

Вендори, які запускають події Measurement Protocol або CAPI безпосередньо з edge, роблять ставку на те, що користувач надасть згоду. Згідно з Art. 5(2) DMA, це не їхня ставка. Настанови EDPB 02/2023 щодо технічної сфери застосування статті 5(3) ePrivacy вказали на схожий момент щодо впровадження ідентифікаторів до отримання згоди: це обробка, вона потребує підстави, а відсутність банера не є підставою.

Легальні способи мінімізації наслідків на стороні сервера#

Нижче наведено методи, які витримують перевірку як GDPR, так і DMA. У них є спільна риса: стан згоди має бути зафіксований перед тим, як будь-які дані будуть передані ґейткіперу або використані для реклами.

Measurement Protocol із доданим станом згоди. GA4 Measurement Protocol приймає ті самі параметри consent, що і клієнт gtag. Патерн: цільова сторінка відображає банер, надсилає стан згоди на власний сервер клієнта, а власний сервер пересилає запит mp/collect до GA4 з параметрами consent.ad_user_data та consent.ad_personalization. На стороні сервера, але після отримання згоди. Форвардер Elido (описаний у відстеження на стороні сервера GA4 через перенаправлення) додає стан згоди до вихідних даних.

Conversion API зі стрінгами згоди. Meta CAPI приймає data_processing_options та opt_out; LinkedIn Conversions API приймає enlli; TikTok Events API приймає limited_data_use. Усі вони сигналізують про стан згоди платформі. Патерн ідентичний: цільова сторінка відображає банер, надсилає дані на власний сервер, власний сервер запускає подію з доданим станом згоди.

Агрегована звітність на стороні сервера. Там, де стан згоди забороняє використання для реклами або аналітики, звітність на стороні сервера, яка є справді агрегованою і не містить ідентифікаторів користувачів, загалом є прийнятною згідно з Art. 5(2) DMA та Art. 6 GDPR на основі легітимного інтересу. Настанови EDPB 04/2023 щодо анонімізації наголошують, що псевдонімізовані дані не є анонімними і що низька k-анонімність все одно дозволяє повторну ідентифікацію. Консервативна практика — публікувати кількість кліків на рівні робочого простору з порогом ≥10.

Первинна ідентифікація на цільовій сторінці. Найбільш стійкий підхід — ідентифікувати користувача за допомогою сигналу Art. 6(1)(b) GDPR (вони увійшли в систему, заповнили форму, натиснули на підтверджене посилання в email) і атрибутувати назад. Це взагалі не залежить від ad_storage або ad_user_data. Допис атрибуція кліків після Safari ITP описує цей патерн; це правильна відповідь і для світу після DMA.

Нелегальні способи мінімізації наслідків на стороні сервера#

Три патерни часто зустрічаються в пропозиціях вендорів інструментів, але їх не слід використовувати.

Запуск подій CAPI з edge до того, як буде отримано згоду на цільовій сторінці. Це той самий режим відмови, описаний вище. Немає стану згоди, який можна було б додати; запуск події означає, що контролер отримав згоду, якої він не має. Деякі вендори описують це як «детерміновану атрибуцію»; згідно з Art. 5(2) DMA — це операція комбінування даних, яку користувач не дозволяв.

Хешування IP та трактування хешу як анонімного. EDPB чітко заявляв ще у Висновку 4/2007 щодо концепції персональних даних і підтвердив у Настановах 04/2023, що хешовані ідентифікатори залишаються персональними даними, якщо хеш може бути дешифрований будь-ким, хто має доступ до вихідних даних. Хеші IP легко дешифруються в масштабі; хешування не змінює юридичний характер обробки.

Синхронізація ідентифікаторів із ґейткіперами на стороні сервера. Передача події кліку до Google або Meta з хешованим email або номером телефону та покладання на ґейткіпера у питанні зіставлення з його власним графом ідентифікаторів — це саме та операція, яку обмежує Art. 5(2) DMA. Зіставлення є міжсервісним комбінуванням даних ґейткіпером. Згода на це має бути явною і на рівні користувача. Наявність хешу не робить операцію законною; відсутність згоди робить її незаконною.

Останній контекст від CJEU та EDPB#

Два останні кроки регуляторів роблять картину чіткішою.

Рішення CJEU у справі C-621/22 (Royal Lichtervelde, 2024) підтвердило аналіз спільних контролерів зі справ Wirtschaftsakademie (C-210/16) та Fashion ID (C-40/17). Коли видавець інтегрує сторонній тег, і цей тег передає дані користувача третій стороні, видавець і третя сторона є спільними контролерами цієї обробки. Art. 26 GDPR вимагає прозорої домовленості між ними. Для клієнта Consent Mode v2 домовленість за Art. 26 з Google має бути на місці, а стан згоди має передаватися чесно. Фальсифікація ad_user_data=granted для відновлення атрибуції — це відповідальність спільного контролера для обох сторін.

Настанови EDPB 03/2024 щодо сигналів згоди в рекламному контексті (проєкт для консультацій, фінальна версія очікується у 3 кварталі 2026 року) прямо стосуються Consent Mode v2. Проєкт стверджує, що сигнал ad_user_data згідно з Art. 7(4) GDPR залежить від вільно наданої згоди, і що банери, які об'єднують ad_storage з ad_user_data без детального контролю, не проходять тест вільно наданої згоди за Art. 7. Більшість нинішніх банерів об'єднують їх. Редизайн — на боці клієнта; сервіс скорочення надає чистий стан, він не проєктує банер.

Для ширшої картини впливу на передачу даних — згода надана, але дані все одно залишають ЄС — допис Schrems II та рекламні пікселі охоплює аспект TIA. DMA не вирішує цю проблему; він додає ще одне обмеження.

Що Elido робить (і не робить) на рівні перенаправлення#

Elido є процесором; контролер визначає політику згоди та керує банером. Рівень даних перенаправлення робить мінімум:

  • Зберігає UTM та власний ідентифікатор кліку клієнта. Специфічні рекламні ідентифікатори вендорів (fbclid, gclid, msclkid, ttclid) передаються за замовчуванням, оскільки вони є поверхнею атрибуції контролера; доступна відмова на рівні робочого простору.
  • Не запускає жодних серверних рекламних подій під час перенаправлення. Внутрішня подія кліку, що записується в ClickHouse, має IP, урізаний до /24 або /48, і лише розпарсені поля пристрою, згідно з мінімізацією даних GDPR. Дані не передаються третім сторонам.
  • Підтримує серверне пересилання конверсій до GA4, Meta CAPI, LinkedIn, TikTok та Reddit з урахуванням згоди, обмежене станом згоди, який надає цільова сторінка. Форвардер знаходиться у /features/conversion-tracking; налаштування — у посібнику з відстеження конверсій у документації.
  • Вимагає передачі consent від цільової сторінки, коли ввімкнено пересилання з урахуванням згоди; за відсутності даних подія відхиляється, а не тихо запускається зі значеннями за замовчуванням.

Панель аналітики за адресою /features/analytics показує розподіл станів згоди для кожної кампанії — надано, відмовлено, не встановлено — щоб маркетингова команда могла бачити, скільки атрибуції втрачається через відмови.

Чого Elido не робить: не впроваджує банер, не визначає згоду заздалегідь і не поважає «надану» згоду для користувачів, які її насправді не надавали. Ці рішення залишаються за контролером, як того вимагають GDPR та DMA.

Питання закупівлі#

Для контролера, який оцінює сервіс скорочення в межах Art. 5(2) DMA, є три запитання.

Чи передає сервіс скорочення дані про кліки будь-якому сторонньому рекламному чи аналітичному сервісу під час перенаправлення незалежно від стану згоди на цільовій сторінці? Якщо так, то це ризик порушення Art. 5(2) DMA, який слід усунути.

Чи підтримує сервіс скорочення передачу стану згоди на свої серверні кінцеві точки конверсій? Якщо ні, контролеру знадобиться окремий серверний проксі для тегування (GTM server container, Stape, Snowplow) між цільовою сторінкою та API ґейткіперів.

Чи ділиться аналітичний шар сервісу скорочення агрегованими даними з будь-якою третьою стороною? Деякі сервіси, орієнтовані на маркетинг, публікують «галузеві бенчмарки», які виявляються даними про кліки клієнтів із підграфами, ідентифікованими за формою трафіку — яким є аналіз спільного контролерства згідно зі справами Wirtschaftsakademie та Fashion ID?

Сервіс скорочення, який ухиляється від цих питань, додає поверхню ризику DMA, яку контролеру доведеться захищати під час аудиту.

Підсумок#

Consent Mode v2 — це не маркетингова ініціатива. Це механізм забезпечення відповідності Art. 5(2) DMA, який працює через платформу тегів Google. Чотири сигнали чесно повідомляють про те, яка згода була отримана; заходи на стороні сервера працюють, коли стан згоди подорожує разом із подією; втрата атрибуції у світі з відмовою від згоди реальна, але менша, ніж здається, якщо впроваджено первинну ідентифікацію. Сервіс скорочення доставляє чистий стан через перенаправлення і надає можливість пересилання з урахуванням згоди, яку контролер підключає до свого банера.

Очікувані у 3 кварталі 2026 року настанови EDPB змінять правила гри. Проєктування лише під поточні вимоги є короткозорим; проєктування під наміри Art. 5(2) — явна, детальна, вільно надана згода для міжсервісного комбінування даних — це позиція, яка витримає наступний раунд правозастосування.

Що ще почитати#

Спробуйте Elido

URL-скорочувач із хостингом у ЄС: власні домени, глибока аналітика, відкритий API. Безкоштовний тариф — без кредитної картки.

Теги
consent mode v2
google consent mode
digital markets act
відповідність dma
ad_user_data
ad_personalization
відстеження на стороні сервера
measurement protocol

Читати далі