เหตุใด PWA จึงเป็นกรณีขอบเขตของความยินยอม

Progressive Web App ทำงานเหมือนแอปเนทีฟ — ติดตั้งลงบนหน้าจอหลัก ทำงานออฟไลน์ และแคชอย่างหนัก — แต่ก็ยังถูกให้บริการจากเบราว์เซอร์ ดังนั้นกฎเกี่ยวกับคุกกี้และที่จัดเก็บข้อมูลบนเว็บจึงมีผลบังคับใช้ ธรรมชาติแบบลูกผสมนี้เองที่ทำให้ผู้เผยแพร่สะดุด: มีภาระผูกพันด้านความยินยอมตาม GDPR เช่นเดียวกับเว็บไซต์ใดๆ โดยซ้อนทับอยู่บน service worker และแคชถาวรที่สามารถเก็บข้อมูลและสคริปต์ไว้อย่างเงียบๆ หลังจากที่ผู้ใช้ปฏิเสธไปแล้ว

PWA จัดเก็บสิ่งต่างๆ ไว้ที่ไหน

ก่อนที่คุณจะควบคุมการจัดเก็บตามความยินยอมได้ คุณต้องรู้ทุกที่ที่ PWA สามารถเก็บข้อมูลถาวร:

• คุกกี้ — พื้นผิวแบบดั้งเดิม ควบคุมด้วยความยินยอมเช่นเคย
• LocalStorage / IndexedDB — มักใช้สำหรับสถานะแอป แต่ก็ใช้สำหรับการวิเคราะห์และตัวระบุโฆษณาด้วย
• Cache Storage — service worker สามารถแคชสคริปต์บุคคลที่สาม (การวิเคราะห์, SDK โฆษณา) เพื่อให้ทำงานได้แม้ออฟไลน์
• ตัว service worker เอง — คงอยู่ข้ามเซสชันและสามารถลงทะเบียนการติดตามใหม่ในการเปิดครั้งถัดไป

ความยินยอมต้องควบคุมทั้งหมดนี้ ไม่ใช่แค่ document.cookie

รูปแบบ Service Worker ที่ยึดความยินยอมเป็นหลัก

หลักการสำคัญ: service worker ต้องอ่านสถานะความยินยอมก่อนที่จะแคชหรือเรียกใช้ทรัพยากรบุคคลที่สามที่ไม่จำเป็นใดๆ รูปแบบที่สะอาดมีลักษณะดังนี้:

• จัดเก็บสัญญาณความยินยอมไว้ในที่ที่ service worker อ่านได้ — IndexedDB หรือรายการแคชที่ CMP อัปเดตทุกครั้งที่มีการเลือก
• ใน handler fetch ของ service worker ให้ปฏิเสธการแคชปลายทางของการวิเคราะห์/โฆษณา เว้นแต่จะมีความยินยอมสำหรับวัตถุประสงค์นั้น
• เมื่อผู้ใช้เพิกถอนความยินยอม ให้ส่งข้อความไปยัง service worker เพื่อล้างสคริปต์ติดตามที่แคชไว้และล้างที่จัดเก็บ IndexedDB ที่เกี่ยวข้อง

การข้ามขั้นตอนสุดท้ายนั้นเป็นช่องว่างการปฏิบัติตามข้อกำหนดของ PWA ที่พบบ่อยที่สุด: แบนเนอร์บอกว่า “ปฏิเสธแล้ว” แต่สคริปต์การวิเคราะห์ที่แคชไว้ยังคงทำงานจาก service worker ในการเปิดออฟไลน์ครั้งถัดไป

UX ความยินยอมแบบออฟไลน์

PWA สามารถเปิดได้โดยไม่มีเครือข่าย แบนเนอร์ความยินยอมของคุณและตัวเลือกที่จัดเก็บไว้ของผู้ใช้ทั้งคู่ต้องทำงานออฟไลน์ได้ — ให้แคช UI ของ 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 ตามความยินยอม — ไม่ใช่แค่คุกกี้
• เมื่อมีการเพิกถอน ให้ล้างสคริปต์ติดตามที่แคชไว้และล้างตัวระบุที่จัดเก็บไว้
• รักษาสถานะความยินยอมให้สดและปลอดภัยแบบออฟไลน์ เพื่อให้รายได้โฆษณาไม่ติดอยู่ที่อัตราที่ไม่ปรับให้เป็นส่วนตัว