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

Когато посетителят направи избор за съгласие, трябва да се случат две отделни неща. Първо, браузърът трябва да запомни избора, за да не се появява банерът на всяка страница, а таговете да знаят какво им е позволено. Второ, по-късно може да се наложи да докажете, че изборът е направен, какво е било показано на посетителя и кога. Тези задачи често се обслужват от различни механизми за съхранение и смесването им създава реални проблеми: банери, които продължават да се появяват, избори, които изчезват в някои браузъри, или липса на запис, когато някой го поиска.

Това сравнение разглежда трите често срещани варианта — собствени бисквитки, съхранение в браузъра като localStorage и сървърни записи за съгласие — и къде пасва всеки от тях.

Вариант 1: собствени бисквитки

Бисквитките са традиционният дом на състоянието на съгласие. CMP по TCF обикновено съхраняват низа за съгласие в собствена бисквитка, а много CMP съхраняват в такава и собствените си данни за предпочитания.

Силни страни

• Четими от сървъра. Бисквитката се изпраща с всяка заявка, така че сървърният код, логиката на периферията и сървърното тагване могат да четат избора, без да чакат JavaScript.
• Споделяеми между поддомейни. Бисквитка, зададена за регистрируемия ви домейн, може да покрива поддомейните www, blog и shop.
• Широко очаквани. Много интеграции в рекламните технологии търсят съгласието в бисквитки.

Слаби страни

• Ограничения на размера. Браузърите ограничават размера на бисквитките до около 4 KB, а TCF низ с много вендори плюс други стойности може да се доближи до това.
• Натоварване на заявките. Всяка заявка към домейна ви носи бисквитката, включително заявките за изображения и скриптове.
• Ограничения на живота в някои браузъри. Intelligent Tracking Prevention на Safari ограничава максималния живот на бисквитките, създадени чрез JavaScript, до седем дни. Бисквитките, зададени от собствения ви сървър в HTTP отговор, обикновено се третират по-щедро, макар да има изключения.

Вариант 2: localStorage и друго съхранение в браузъра

Някои CMP съхраняват подробни предпочитания в localStorage, понякога наред с по-малка бисквитка.

Силни страни

• Повече място. Няколко мегабайта на произход, достатъчно за подробни избори на ниво вендор.
• Без натоварване на заявките. Нищо не се изпраща автоматично към сървъра.

Слаби страни

• Невидимо за сървъра. Сървърният код и логиката на периферията не могат да го прочетат, така че всяко сървърно решение трябва да изчаква браузъра.
• Обвързано с един произход. Хранилището на www.example.com не е достъпно на shop.example.com, така че посетителят може да види банера отново на всеки поддомейн.
• Подлежи на изтриване. Safari може да премахва хранилище, в което скриптове могат да пишат, включително localStorage, за сайтове, с които потребителят не е взаимодействал седем дни употреба на браузъра, а режимите за поверително сърфиране обикновено го изчистват при края на сесията.

Вариант 3: сървърни записи за съгласие

Сървърният запис е запис, който вие или вашият доставчик на CMP съхранявате при всеки избор. Обикновено съдържа псевдонимен идентификатор, времева отметка, избора, версията на показания банер или политика и контекст като региона.

Силни страни

• Траен документ. Оцелява при изчистване на бисквитките и ограничения на браузърите, което го прави правилния инструмент за доказване, че съгласието е получено.
• Подлежи на одит. Можете да отчитате изборите във времето и да отговаряте на въпроси за конкретни събития.
• Потенциал за няколко устройства. За влезли читатели сървърният запис може да синхронизира изборите между устройства, ако им го обясните.

Слаби страни

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

Обобщение отстрани

• Най-добро за запомняне на избора в мрежата: собствени бисквитки, в идеалния случай зададени от вашия сървър със стабилен живот.
• Най-добро за подробни данни за предпочитания в браузъра: localStorage, в комбинация с бисквитка, която сървърът може да чете.
• Най-добро за доказване на избора: сървърни записи.
• Най-лош избор с един вариант: разчитане само на localStorage, което оставя сървъра сляп, а избора — крехък в някои браузъри.

Практичен комбиниран подход

1. Съхранявайте основния локален сигнал — например TCF низа и компактен запис с предпочитания — в собствена бисквитка за регистрируемия ви домейн.
2. Използвайте localStorage само за допълнителни данни, които не е нужно да стигат до сървъра.
3. Записвайте сървърен запис за всеки избор, включително версията на показания банер и политика.
4. Ако запазеният избор изчезне, покажете банера отново, вместо да предполагате предишен отговор.
5. Определете период за повторно питане за запазените избори и го запишете в политиката си.

Съхраняването на самия избор на посетителя за съгласие обикновено се третира като необходимо за предоставяне на услугата, която посетителят е поискал — запомняне на решението му, — но проверете указанията, които важат на основните ви пазари.

Основни изводи

• Запомнянето на избор и доказването на избор са различни задачи, изискващи различно съхранение.
• Бисквитките се четат от сървъра и се споделят между поддомейни, но са ограничени по размер и, в Safari, по живот, когато са зададени от скрипт.
• localStorage предлага място, но е невидим за сървъра и може да бъде изчистен от браузърите.
• Сървърните записи са слоят за доказване, а не заместител на локалния сигнал.
• Комбинирайте зададена от сървъра собствена бисквитка, по избор хранилище в браузъра и сървърни записи.