Два різні завдання

Коли відвідувач робить вибір згоди, мають відбутися дві окремі речі. По-перше, браузер повинен запам’ятати вибір, щоб банер не з’являвся на кожній сторінці, а теги знали, що їм дозволено. По-друге, згодом вам може знадобитися довести, що вибір було зроблено, що саме бачив відвідувач і коли. Ці завдання часто розв’язуються різними механізмами зберігання, і їх змішування створює реальні проблеми: банери, що продовжують з’являтися, вибори, які зникають у деяких браузерах, або відсутність запису, коли про нього питають.

У цьому порівнянні розглянуто три поширені варіанти — власні cookie, сховище браузера на кшталт localStorage і серверні записи про згоду — та те, де доречний кожен із них.

Варіант 1: власні cookie

Cookie — традиційне місце для стану згоди. CMP за TCF зазвичай зберігають рядок згоди у власному cookie, і багато CMP зберігають у ньому також свої дані про уподобання.

Сильні сторони

• Читаються сервером. Cookie надсилається з кожним запитом, тож серверний код, логіка на межі мережі та серверна розмітка тегами можуть читати вибір, не чекаючи JavaScript.
• Спільні для піддоменів. Cookie, встановлений на основний домен, може охоплювати піддомени www, blog і shop.
• Широко очікувані. Багато рекламних інтеграцій шукають згоду саме в cookie.

Слабкі сторони

• Обмеження за розміром. Браузери обмежують розмір cookie приблизно 4 КБ, і рядок TCF із багатьма вендорами плюс інші значення можуть наблизитися до цієї межі.
• Навантаження на запити. Кожен запит до вашого домену несе cookie, зокрема запити зображень і скриптів.
• Обмеження строку в деяких браузерах. Intelligent Tracking Prevention у Safari обмежує максимальний строк життя cookie, створених через JavaScript, сімома днями. До cookie, встановлених вашим власним сервером у HTTP-відповіді, зазвичай ставляться м’якше, хоча є винятки.

Варіант 2: localStorage та інше сховище браузера

Деякі CMP зберігають докладні уподобання в localStorage, іноді разом із невеликим cookie.

Сильні сторони

• Більше місця. Кілька мегабайтів на джерело, достатньо для докладних виборів на рівні вендорів.
• Немає навантаження на запити. Нічого не надсилається на сервер автоматично.

Слабкі сторони

• Невидиме для сервера. Серверний код і логіка на межі мережі не можуть його прочитати, тож будь-яке серверне рішення змушене чекати браузер.
• Прив’язане до одного джерела. Сховище на www.example.com недоступне на shop.example.com, тому відвідувач може знову побачити банер на кожному піддомені.
• Може бути видалене. Safari може видаляти сховище, доступне для запису скриптами, зокрема localStorage, для сайтів, з якими користувач не взаємодіяв сім днів використання браузера, а режими приватного перегляду зазвичай очищують його наприкінці сесії.

Варіант 3: серверні записи про згоду

Серверний запис — це запис, який ви або ваш провайдер CMP зберігаєте під час кожного вибору. Зазвичай він містить псевдонімний ідентифікатор, мітку часу, вибір, версію показаного банера чи політики та контекст, наприклад регіон.

Сильні сторони

• Довговічний доказ. Він переживає очищення cookie та обмеження браузерів, тому це правильний інструмент для підтвердження того, що згоду отримано.
• Піддається аудиту. Ви можете складати звіти про вибори в часі й відповідати на запитання про конкретні події.
• Потенціал для кількох пристроїв. Для авторизованих читачів серверний запис може синхронізувати вибір між пристроями, якщо ви їм про це повідомите.

Слабкі сторони

• Не замінює локальний стан. Теги в браузері й надалі потребують швидкого локального сигналу; звернення до сервера під час кожного перегляду сторінки для пошуку згоди додає затримку.
• Це самі по собі персональні дані. Записам потрібні строк зберігання, контроль доступу та місце у вашому повідомленні про конфіденційність.
• Залежність від ідентифікатора. Анонімних відвідувачів можна зіставити із записом лише через ідентифікатор, що зберігається на їхньому пристрої, а це повертає вас до локального сховища.

Коротке порівняння

• Найкраще для запам’ятовування вибору у вебі: власні cookie, в ідеалі встановлені вашим сервером на стабільний строк.
• Найкраще для докладних даних про уподобання в браузері: localStorage у парі з cookie, який може прочитати сервер.
• Найкраще для доведення вибору: серверні записи.
• Найгірший варіант з одного механізму: покладатися лише на localStorage, що робить сервер сліпим, а вибір крихким у деяких браузерах.

Практичний комбінований підхід

1. Зберігайте основний локальний сигнал — наприклад, рядок TCF і компактний запис уподобань — у власному cookie, прив’язаному до вашого основного домену.
2. Використовуйте localStorage лише для додаткових даних, яким не потрібно потрапляти на сервер.
3. Записуйте на сервері запис для кожного вибору, зокрема версію показаного банера й політики.
4. Якщо збережений вибір зник, покажіть банер знову, а не припускайте попередню відповідь.
5. Задайте період повторного запиту для збережених виборів і зафіксуйте його у своїй політиці.

Збереження самого вибору згоди відвідувача зазвичай вважається необхідним для надання послуги, про яку попросив відвідувач, — запам’ятовування його рішення, — але звірте це з рекомендаціями, чинними на ваших основних ринках.

Ключові висновки

• Запам’ятати вибір і довести вибір — різні завдання, що потребують різного зберігання.
• Cookie читаються сервером і спільні для піддоменів, але обмежені за розміром і, у Safari, за строком життя, якщо встановлені скриптом.
• localStorage дає місце, але невидимий для сервера й може бути очищений браузерами.
• Серверні записи — шар доказів, а не заміна локальному сигналу.
• Поєднуйте встановлений сервером власний cookie, необов’язкове сховище браузера й серверні записи.