Mengapa PWA Merupakan Kasus Tepi Persetujuan

Sebuah Progressive Web App berperilaku seperti aplikasi native — terpasang ke layar beranda, berjalan offline, dan melakukan caching secara agresif — tetapi masih disajikan dari peramban, sehingga aturan cookie dan penyimpanan web berlaku. Sifat hibrida itulah yang membuat penerbit tersandung: kewajiban persetujuan GDPR yang sama seperti situs web mana pun, dilapisi di atas service worker dan cache permanen yang dapat diam-diam menyimpan data dan skrip setelah pengguna mengatakan tidak.

Di Mana PWA Menyimpan Sesuatu

Sebelum Anda dapat membatasi penyimpanan berdasarkan persetujuan, Anda perlu mengetahui setiap tempat sebuah PWA dapat menyimpan data:

• Cookie — permukaan klasik, diatur oleh persetujuan seperti biasa.
• LocalStorage / IndexedDB — sering digunakan untuk status aplikasi, tetapi juga untuk analitik dan pengenal iklan.
• Cache Storage — service worker dapat menyimpan skrip pihak ketiga (analitik, SDK iklan) di cache sehingga mereka berjalan bahkan saat offline.
• Service worker itu sendiri — bertahan di antara sesi dan dapat mendaftarkan ulang pelacakan pada peluncuran berikutnya.

Persetujuan harus mengatur semua ini, bukan hanya document.cookie.

Pola Service Worker yang Mengutamakan Persetujuan

Prinsip intinya: service worker harus membaca status persetujuan sebelum melakukan caching atau menjalankan sumber daya pihak ketiga non-esensial apa pun. Pola yang bersih terlihat seperti ini:

• Simpan sinyal persetujuan di suatu tempat yang dapat dibaca service worker — IndexedDB atau entri cache yang diperbarui CMP pada setiap pilihan.
• Pada handler fetch service worker, tolak untuk melakukan caching endpoint analitik/iklan kecuali persetujuan untuk tujuan tersebut ada.
• Ketika pengguna menarik persetujuan, kirim pesan ke service worker untuk membersihkan skrip pelacakan yang di-cache dan menghapus penyimpanan IndexedDB yang relevan.

Melewatkan langkah terakhir itu adalah celah kepatuhan PWA yang paling umum: banner berkata “ditolak”, tetapi skrip analitik yang di-cache terus aktif dari service worker pada peluncuran offline berikutnya.

UX Persetujuan Offline

PWA dapat diluncurkan tanpa jaringan. Banner persetujuan Anda dan pilihan tersimpan pengguna keduanya harus berfungsi offline — cache UI CMP itu sendiri, dan jangan pernah menetapkan default ke “diberikan” hanya karena server persetujuan tidak dapat dijangkau. Jika Anda tidak dapat mengonfirmasi pilihan sebelumnya, perlakukan pengguna sebagai tidak menyetujui dan sajikan hanya fungsi esensial hingga Anda bisa.

Implikasi Pendapatan Iklan

Untuk PWA yang didukung iklan, status persetujuan harus mencapai SDK iklan Anda pada saat permintaan, online atau offline. PWA yang terhubung dengan benar meneruskan string IAB TCF dan sinyal Consent Mode v2 ke mitra permintaan persis seperti situs normal; PWA yang salah konfigurasi melakukan caching status “tanpa persetujuan” yang usang dan menurunkan eCPM Anda ke tarif non-personalisasi tanpa batas. Perlakukan kesegaran persetujuan sebagai metrik pendapatan.

Bagaimana FlexyConsent Membantu

FlexyConsent menyimpan catatan persetujuan dalam penyimpanan yang dapat dibaca service worker, memancarkan sinyal TCF dan Consent Mode v2 yang bertahan dari peluncuran offline, dan mengekspos hook penarikan yang dapat Anda hubungkan ke pembersihan cache — sehingga PWA Anda tetap patuh dan tumpukan iklan Anda mempertahankan sinyal persetujuan paling segar yang mungkin di setiap permukaan.

Poin-Poin Utama

• PWA menghadapi kewajiban persetujuan GDPR penuh ditambah komplikasi service worker dan cache.
• Batasi cookie, LocalStorage, IndexedDB, dan Cache Storage berdasarkan persetujuan — bukan hanya cookie.
• Saat penarikan, bersihkan skrip pelacakan yang di-cache dan hapus pengenal tersimpan.
• Jaga status persetujuan tetap segar dan aman offline agar pendapatan iklan tidak terjebak pada tarif non-personalisasi.