Защо 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 могат да стартират без мрежа. Вашият банер за съгласие и съхраненият избор на потребителя трябва да работят офлайн — кеширайте самия интерфейс на 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 със съгласие — не само бисквитки.
• При оттегляне изчистете кешираните скриптове за проследяване и изтрийте съхранените идентификатори.
• Поддържайте състоянието на съгласието свежо и безопасно офлайн, така че рекламните приходи да не остават блокирани на неперсонализирани нива.