Kodėl PWA yra sutikimo kraštinis atvejis

Progresyvioji žiniatinklio programa elgiasi kaip vietinė programa — ji įsidiegia į pradinį ekraną, veikia neprisijungus ir agresyviai talpina į talpyklą — bet ji vis tiek pateikiama iš naršyklės, todėl taikomos slapukų ir žiniatinklio saugojimo taisyklės. Būtent ši hibridinė prigimtis suklaidina leidėjus: tos pačios BDAR sutikimo prievolės kaip ir bet kuriai svetainei, uždėtos ant service workers ir nuolatinių talpyklų, kurios gali tyliai išlaikyti duomenis ir scenarijus po to, kai vartotojas pasakė ne.

Kur PWA saugo duomenis

Prieš galėdami susieti saugojimą su sutikimu, turite žinoti kiekvieną vietą, kurioje PWA gali išsaugoti duomenis:

• Slapukai — klasikinis paviršius, kaip visada valdomas sutikimo.
• LocalStorage / IndexedDB — dažnai naudojami programos būsenai, bet taip pat analitikai ir reklamos identifikatoriams.
• Cache Storage — service worker gali talpinti trečiųjų šalių scenarijus (analitiką, reklamos SDK), kad jie veiktų net neprisijungus.
• Pats service worker — išlieka tarp seansų ir gali iš naujo užregistruoti sekimą per kitą paleidimą.

Sutikimas turi valdyti visa tai, ne tik document.cookie.

Sutikimo-pirmiausia service worker modelis

Pagrindinis principas: service worker turi perskaityti sutikimo būseną prieš talpindamas ar vykdydamas bet kokį nebūtiną trečiosios šalies išteklių. Tvarkingas modelis atrodo taip:

• Saugokite sutikimo signalą kur nors, kur service worker gali jį perskaityti — IndexedDB arba talpyklos įraše, kurį CMP atnaujina kiekvieną pasirinkimą.
• Service worker fetch tvarkytuve atsisakykite talpinti analitikos/reklamos galinius taškus, nebent yra sutikimas tam tikslui.
• Kai vartotojas atšaukia sutikimą, nusiųskite žinutę service worker, kad išvalytų talpykloje saugomus sekimo scenarijus ir išvalytų atitinkamas IndexedDB saugyklas.

To paskutinio žingsnio praleidimas yra dažniausia PWA atitikties spraga: reklamjuostė sako “atmesta,” bet talpykloje saugomas analitikos scenarijus toliau veikia iš service worker per kitą neprisijungus paleidimą.

Neprisijungus veikiantis sutikimo UX

PWA gali būti paleidžiamos be tinklo. Tiek jūsų sutikimo reklamjuostė, tiek vartotojo išsaugotas pasirinkimas turi veikti neprisijungus — talpinkite patį CMP sąsają ir niekada nenustatykite numatytojo “suteikta” vien todėl, kad sutikimo serveris nepasiekiamas. Jei negalite patvirtinti ankstesnio pasirinkimo, traktuokite vartotoją kaip nesutikusį ir teikite tik būtiną funkcionalumą, kol galėsite.

Pasekmės reklamos pajamoms

Reklamomis palaikomoms PWA sutikimo būsena turi pasiekti jūsų reklamos SDK užklausos metu, prisijungus ar ne. Tinkamai sujungta PWA perduoda IAB TCF eilutę ir Consent Mode v2 signalus paklausos partneriams lygiai taip pat kaip įprasta svetainė; netinkamai sukonfigūruota talpina pasenusią “nėra sutikimo” būseną ir neribotam laikui sumažina jūsų eCPM iki nepersonalizuotų tarifų. Traktuokite sutikimo šviežumą kaip pajamų rodiklį.

Kaip padeda FlexyConsent

FlexyConsent saugo sutikimo įrašą service worker skaitomoje saugykloje, siunčia TCF ir Consent Mode v2 signalus, kurie išgyvena neprisijungus paleidimus, ir atskleidžia atšaukimo kabliuką, kurį galite susieti su talpyklos valymu — kad jūsų PWA liktų atitinkanti reikalavimus ir jūsų reklamos krūva išlaikytų kuo šviežesnį sutikimo signalą kiekviename paviršiuje.

Pagrindinės išvados

• PWA susiduria su visomis BDAR sutikimo prievolėmis ir service worker bei talpyklos komplikacijomis.
• Susiekite slapukus, LocalStorage, IndexedDB ir Cache Storage su sutikimu — ne tik slapukus.
• Atšaukus, išvalykite talpykloje saugomus sekimo scenarijus ir pašalinkite išsaugotus identifikatorius.
• Išlaikykite sutikimo būseną šviežią ir saugią neprisijungus, kad reklamos pajamos neįstrigtų nepersonalizuotuose tarifuose.