Miért különleges eset a PWA a hozzájárulás szempontjából

Egy Progresszív Webalkalmazás úgy viselkedik, mint egy natív alkalmazás — települ a kezdőképernyőre, offline fut és agresszíven gyorsítótáraz — de továbbra is böngészőből szolgálják ki, így a cookie- és webtárolási szabályok érvényesek rá. Pontosan ez a hibrid természet az, ami megzavarja a kiadókat: ugyanazok a GDPR-hozzájárulási kötelezettségek, mint bármely webhelynél, megfejelve service workerekkel és tartós gyorsítótárakkal, amelyek csendben megőrizhetik az adatokat és szkripteket, miután a felhasználó nemet mondott.

Hová tárolnak a PWA-k

Mielőtt a tárolást a hozzájáruláshoz köthetné, ismernie kell minden helyet, ahol egy PWA adatokat tarthat fenn:

• Cookie-k — a klasszikus felület, a hozzájárulás által szabályozva, mint mindig.
• LocalStorage / IndexedDB — gyakran az alkalmazás állapotához használják, de analitikához és hirdetési azonosítókhoz is.
• Cache Storage — a service worker gyorsítótárazhat harmadik féltől származó szkripteket (analitika, hirdetési SDK-k), így azok offline is futnak.
• Maga a service worker — munkamenetek között is fennmarad, és a következő indításkor újraregisztrálhatja a követést.

A hozzájárulásnak mindezt szabályoznia kell, nem csak a document.cookie-t.

A hozzájárulás-első service worker minta

Az alapelv: a service workernek el kell olvasnia a hozzájárulási állapotot, mielőtt bármilyen nem nélkülözhetetlen harmadik féltől származó erőforrást gyorsítótárazna vagy futtatna. Egy letisztult minta így néz ki:

• Tárolja a hozzájárulási jelet olyan helyen, ahol a service worker el tudja olvasni — IndexedDB vagy egy gyorsítótár-bejegyzés, amelyet a CMP minden választáskor frissít.
• A service worker fetch kezelőjében utasítsa el az analitikai/hirdetési végpontok gyorsítótárazását, hacsak nincs jelen az adott célra vonatkozó hozzájárulás.
• Amikor a felhasználó visszavonja a hozzájárulást, küldjön üzenetet a service workernek, hogy törölje a gyorsítótárazott követőszkripteket és ürítse ki a megfelelő IndexedDB tárolókat.

Ennek az utolsó lépésnek a kihagyása a leggyakoribb PWA-megfelelőségi hiányosság: a banner azt mondja, “elutasítva”, de egy gyorsítótárazott analitikai szkript továbbra is fut a service workerből a következő offline indításkor.

Offline hozzájárulási UX

A PWA-k hálózat nélkül is elindulhatnak. A hozzájárulási bannernek és a felhasználó tárolt választásának egyaránt működnie kell offline — gyorsítótárazza magát a CMP felületét, és soha ne álljon vissza “megadva” állapotra csak azért, mert a hozzájárulási szerver nem elérhető. Ha nem tudja megerősíteni egy korábbi választást, kezelje a felhasználót hozzá nem járulóként, és csak nélkülözhetetlen funkciókat szolgáltasson, amíg meg nem tudja.

Hirdetési bevételi következmények

A hirdetéstámogatott PWA-knál a hozzájárulási állapotnak el kell érnie a hirdetési SDK-t a kérés időpontjában, online vagy offline. Egy helyesen bekötött PWA átadja az IAB TCF stringet és a Consent Mode v2 jeleket a kereslet-partnereknek, akárcsak egy normál webhely; egy rosszul konfigurált egy elavult “nincs hozzájárulás” állapotot gyorsítótáraz, és határozatlan időre nem-személyre szabott árszintekre zuhantja az eCPM-et. Kezelje a hozzájárulás frissességét bevételi mutatóként.

Hogyan segít a FlexyConsent

A FlexyConsent a választást hozzájárulási cookie-kban és a böngésző tárhelyén őrzi, és minden változásról, a visszavonásról is, értesíti a kódodat a(z) __fcapi consentChanged eseményén keresztül, amelyet a gyorsítótár törléséhez köthetsz.

Legfontosabb tanulságok

• A PWA-k teljes GDPR-hozzájárulási kötelezettségekkel néznek szembe, plusz service worker és gyorsítótár bonyodalmakkal.
• Kösse a cookie-kat, LocalStorage-t, IndexedDB-t és Cache Storage-t a hozzájáruláshoz — ne csak a cookie-kat.
• Visszavonáskor törölje a gyorsítótárazott követőszkripteket és ürítse a tárolt azonosítókat.
• Tartsa frissen és offline-biztosan a hozzájárulási állapotot, hogy a hirdetési bevétel ne ragadjon be nem-személyre szabott árszinteken.