Дзве розныя задачы

Калі наведвальнік робіць выбар згоды, павінны адбыцца дзве асобныя рэчы. Па-першае, браўзер павінен запомніць выбар, каб банер не з’яўляўся на кожнай старонцы, а тэгі ведалі, што ім дазволена. Па-другое, пазней вам можа спатрэбіцца даказаць, што выбар быў зроблены, што менавіта бачыў наведвальнік і калі. Гэтыя задачы часта вырашаюцца рознымі механізмамі захоўвання, і іх змешванне стварае рэальныя праблемы: банеры, якія працягваюць з’яўляцца, выбары, што знікаюць у некаторых браўзерах, або адсутнасць запісу, калі пра яго пытаюцца.

У гэтым параўнанні разгледжаны тры распаўсюджаныя варыянты — уласныя 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, неабавязковае сховішча браўзера і серверныя запісы.