Две разные задачи

Когда посетитель делает выбор согласия, должны произойти две отдельные вещи. Во-первых, браузер должен запомнить выбор, чтобы баннер не появлялся на каждой странице, а теги знали, что им разрешено. Во-вторых, позже вам может понадобиться доказать, что выбор был сделан, что именно видел посетитель и когда. Эти задачи часто решаются разными механизмами хранения, и их смешение создаёт реальные проблемы: баннеры, которые продолжают появляться, выборы, исчезающие в некоторых браузерах, или отсутствие записи, когда о ней спрашивают.

В этом сравнении рассматриваются три распространённых варианта — собственные 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, необязательное хранилище браузера и серверные записи.