Зашто су PWA гранични случај сагласности

Прогресивна веб апликација се понаша као нативна апликација — инсталира се на почетни екран, ради офлајн и агресивно кешира — али се и даље испоручује из претраживача, па важе правила за колачиће и веб складиштење. Управо та хибридна природа је оно што саплиће издаваче: исте GDPR обавезе сагласности као и сваки веб-сајт, наслагане на service worker-е и трајне кешеве који могу тихо да задрже податке и скрипте након што је корисник рекао не.

Где PWA складиште ствари

Пре него што можете да условите складиштење сагласношћу, морате знати свако место где PWA може да задржи податке:

• Колачићи — класична површина, регулисана сагласношћу као и увек.
• LocalStorage / IndexedDB — често се користе за стање апликације, али и за аналитику и рекламне идентификаторе.
• Cache Storage — service worker може да кешира скрипте трећих страна (аналитика, рекламни SDK-ови) тако да се извршавају чак и офлајн.
• Сам service worker — опстаје између сесија и може поново да региструје праћење при следећем покретању.

Сагласност мора да регулише све ово, не само document.cookie.

Образац service worker-а са приоритетом сагласности

Основни принцип: service worker мора да прочита стање сагласности пре него што кешира или изврши било који небитан ресурс треће стране. Чист образац изгледа овако:

• Чувајте сигнал сагласности негде где service worker може да га прочита — IndexedDB или унос у кешу који CMP ажурира при сваком избору.
• У fetch руковаоцу service worker-а, одбијте да кеширате крајње тачке аналитике/реклама осим ако постоји сагласност за ту сврху.
• Када корисник повуче сагласност, пошаљите поруку service worker-у да очисти кеширане скрипте за праћење и обрише релевантна IndexedDB складишта.

Прескакање тог последњег корака је најчешћи пропуст у усклађености PWA: банер каже “одбијено”, али кеширана аналитичка скрипта наставља да се покреће из service worker-а при следећем офлајн покретању.

UX сагласности офлајн

PWA могу да се покрену без мреже. Ваш банер сагласности и сачувани избор корисника морају оба да раде офлајн — кеширајте сам UI CMP-а и никада немојте подразумевано постављати на “одобрено” само зато што је сервер сагласности недоступан. Ако не можете да потврдите претходни избор, третирајте корисника као несагласног и испоручујте само битну функционалност док не будете могли.

Импликације на приходе од реклама

За PWA које подржавају рекламе, стање сагласности мора да стигне до вашег рекламног SDK-а у тренутку захтева, онлајн или офлајн. Исправно повезана PWA прослеђује IAB TCF стринг и Consent Mode v2 сигнале партнерима потражње баш као нормалан сајт; погрешно конфигурисана кешира застарело стање “без сагласности” и обара ваш eCPM на неперсонализоване стопе на неодређено време. Третирајте свежину сагласности као метрику прихода.

Како FlexyConsent помаже

FlexyConsent чува запис о сагласности у складишту читљивом за service worker, емитује TCF и Consent Mode v2 сигнале који преживљавају офлајн покретања и излаже hook за повлачење који можете повезати са чишћењем кеша — тако да ваша PWA остаје усклађена, а ваш рекламни стек задржава најсвежији могући сигнал сагласности на свакој површини.

Кључни закључци

• PWA се суочавају са пуним GDPR обавезама сагласности плус компликацијама service worker-а и кеша.
• Условите колачиће, LocalStorage, IndexedDB и Cache Storage сагласношћу — не само колачиће.
• Приликом повлачења, очистите кеширане скрипте за праћење и обришите сачуване идентификаторе.
• Одржавајте стање сагласности свежим и безбедним офлајн тако да приходи од реклама не остану заглављени на неперсонализованим стопама.