Kāpēc PWA ir piekrišanas robežgadījums

Progresīvā tīmekļa lietotne uzvedas kā vietējā lietotne — tā instalējas sākuma ekrānā, darbojas bezsaistē un agresīvi saglabā kešatmiņā — bet tā joprojām tiek apkalpota no pārlūkprogrammas, tāpēc tiek piemēroti sīkdatņu un tīmekļa krātuves noteikumi. Tieši šī hibrīdā daba ir tas, kas pieviļ izdevējus: tie paši GDPR piekrišanas pienākumi kā jebkurai tīmekļa vietnei, uzslāņoti virs service worker un pastāvīgām kešatmiņām, kas var klusi saglabāt datus un skriptus pēc tam, kad lietotājs ir teicis nē.

Kur PWA glabā lietas

Pirms varat ierobežot krātuvi atkarībā no piekrišanas, jums jāzina katra vieta, kur PWA var saglabāt datus:

• Sīkdatnes — klasiskā virsma, ko regulē piekrišana kā vienmēr.
• LocalStorage / IndexedDB — bieži izmanto lietotnes stāvoklim, bet arī analītikai un reklāmas identifikatoriem.
• Cache Storage — service worker var saglabāt kešatmiņā trešo pušu skriptus (analītika, reklāmas SDK), lai tie darbotos pat bezsaistē.
• Pats service worker — saglabājas starp sesijām un nākamajā palaišanā var atkārtoti reģistrēt izsekošanu.

Piekrišanai jāregulē tas viss, ne tikai document.cookie.

Piekrišana-vispirms service worker modelis

Pamatprincips: service worker jānolasa piekrišanas stāvoklis pirms tas saglabā kešatmiņā vai izpilda jebkuru neobligātu trešo pušu resursu. Tīrs modelis izskatās šādi:

• Saglabājiet piekrišanas signālu vietā, ko service worker var nolasīt — IndexedDB vai kešatmiņas ierakstā, ko CMP atjaunina katrā izvēlē.
• Service worker fetch apstrādātājā atsakieties saglabāt kešatmiņā analītikas/reklāmas galapunktus, ja vien nav klāt piekrišana šim nolūkam.
• Kad lietotājs atsauc piekrišanu, nosūtiet ziņojumu service worker, lai iztīrītu kešatmiņā saglabātos izsekošanas skriptus un notīrītu attiecīgās IndexedDB krātuves.

Šī pēdējā soļa izlaišana ir visizplatītākā PWA atbilstības nepilnība: baneris saka “noraidīts,” bet kešatmiņā saglabāts analītikas skripts turpina darboties no service worker nākamajā bezsaistes palaišanā.

Bezsaistes piekrišanas UX

PWA var palaisties bez tīkla. Jūsu piekrišanas baneris un lietotāja saglabātā izvēle abiem jādarbojas bezsaistē — saglabājiet kešatmiņā pašu CMP saskarni un nekad pēc noklusējuma neiestatiet “piešķirts” tikai tāpēc, ka piekrišanas serveris nav sasniedzams. Ja nevarat apstiprināt iepriekšēju izvēli, izturieties pret lietotāju kā pret nepiekritušu un apkalpojiet tikai būtisko funkcionalitāti, līdz varat.

Ietekme uz reklāmas ieņēmumiem

Ar reklāmu atbalstītām PWA piekrišanas stāvoklim jāsasniedz jūsu reklāmas SDK pieprasījuma laikā, tiešsaistē vai bezsaistē. Pareizi savadota PWA nodod IAB TCF virkni un Consent Mode v2 signālus pieprasījuma partneriem tāpat kā parasta vietne; nepareizi konfigurēta saglabā kešatmiņā novecojušu “nav piekrišanas” stāvokli un sabrūk jūsu eCPM līdz nepersonalizētām likmēm uz nenoteiktu laiku. Izturieties pret piekrišanas svaigumu kā pret ieņēmumu metriku.

Kā FlexyConsent palīdz

FlexyConsent saglabā piekrišanas ierakstu service worker nolasāmā krātuvē, izstaro TCF un Consent Mode v2 signālus, kas izdzīvo bezsaistes palaišanas, un atklāj atsaukšanas āķi, ko varat savienot ar kešatmiņas iztīrīšanu — tāpēc jūsu PWA paliek atbilstoša un jūsu reklāmas kaudze saglabā pēc iespējas svaigāku piekrišanas signālu katrā virsmā.

Galvenās atziņas

• PWA saskaras ar pilniem GDPR piekrišanas pienākumiem plus service worker un kešatmiņas sarežģījumiem.
• Ierobežojiet sīkdatnes, LocalStorage, IndexedDB un Cache Storage atkarībā no piekrišanas — ne tikai sīkdatnes.
• Atsaukšanas gadījumā iztīriet kešatmiņā saglabātos izsekošanas skriptus un notīriet saglabātos identifikatorus.
• Saglabājiet piekrišanas stāvokli svaigu un bezsaistē drošu, lai reklāmas ieņēmumi neiestrēgtu nepersonalizētās likmēs.