Masalah Sepanduk Berganda

Banyak aplikasi sebahagiannya natif dan sebahagiannya web. Sebuah permainan memaparkan kedai, berita atau halaman bantuannya dalam WebView; aplikasi utiliti memaparkan artikel daripada tapak webnya; aplikasi hibrid membungkus kebanyakan antara mukanya dalam kandungan web. Setiap pihak mempunyai mekanisme persetujuannya sendiri: aplikasi natif menggunakan CMP atau SDK dalam aplikasi, dan halaman web memuatkan CMP web. Melainkan keduanya disambungkan, pengguna ditanya dua kali, pilihan yang dibuat di satu tempat diabaikan di tempat lain, dan permintaan iklan dari dalam WebView keluar dengan isyarat yang salah.

Panduan ini merangkumi cara menjadikan persetujuan natif dan web selaras, supaya pengguna menjawab sekali dan setiap permintaan iklan membawa keputusan yang sama.

Tempat Setiap Pihak Menyimpan Persetujuan

Natif

IAB TCF menetapkan cara CMP dalam aplikasi menyimpan persetujuan: dalam NSUserDefaults pada iOS dan SharedPreferences pada Android, menggunakan kunci piawai seperti IABTCF_TCString, IABTCF_gdprApplies dan IABTCF_PurposeConsents. SDK iklan membaca kunci ini secara langsung. IAB GPP mentakrifkan kunci serupa dengan awalan IABGPP_, seperti IABGPP_HDR_GppString.

Web

CMP web lazimnya menyimpan keputusannya dalam kuki pihak pertama atau storan setempat untuk domain tapak, dan mendedahkannya melalui fungsi JavaScript __tcfapi dan __gpp. Tag iklan dalam halaman memanggil fungsi tersebut, bukan storan natif.

Jurangnya

WebView mempunyai ruang kuki dan storan sendiri, berasingan daripada pelayar peranti dan berasingan daripada keutamaan natif aplikasi. Pada iOS, WKWebView yang menggunakan stor data tidak berterusan melupakan segala-galanya apabila ditutup. Tiada apa yang mengalir antara kedua-dua pihak kecuali anda membinanya.

Pilih Satu Sumber Kebenaran

Keputusan pertama ialah pihak mana yang memiliki persetujuan. Bagi kebanyakan aplikasi jawapannya ialah CMP natif, kerana:

• Ia berjalan dahulu, sebelum sebarang WebView dibuka.
• SDK iklan natif, yang biasanya menjana kebanyakan hasil, membaca storan natif.
• Pada iOS, ia boleh diselaraskan dengan gesaan App Tracking Transparency.

Pendekatan web dahulu boleh masuk akal bagi aplikasi hibrid yang seluruh antara mukanya ialah kandungan web, tetapi anda mesti menulis semula keputusan itu ke storan natif untuk SDK natif.

Menghantar Persetujuan Natif ke dalam WebView

Dengan natif sebagai sumber kebenaran, WebView perlu melihat keputusan yang sama. Corak lazim:

1. Suntik pelaksanaan __tcfapi. Sebelum skrip halaman berjalan, suntik skrip kecil yang mentakrifkan __tcfapi (dan __gpp jika perlu) dan menjawab panggilan dengan rentetan TC serta nilai yang dibaca daripada storan natif. Tag iklan dalam halaman kemudian mendapat keputusan natif melalui API piawai.
2. Sembunyikan sepanduk web. Konfigurasikan CMP web supaya kekal tersembunyi apabila halaman dimuatkan di dalam aplikasi anda, contohnya berdasarkan parameter pertanyaan atau token ejen pengguna tersuai yang anda kawal. Jika tidak, pengguna melihat sepanduk kedua.
3. Hantar rentetan semasa pemuatan. Sesetengah CMP web boleh menerima rentetan persetujuan sedia ada semasa permulaan dan menerimanya. Semak dokumentasi CMP web anda untuk kaedah yang disokong.

Apa pun corak yang anda gunakan, pastikan nilai yang disuntik dikemas kini apabila pengguna menukar pilihan mereka pada skrin tetapan natif, bukan hanya pada pelancaran aplikasi seterusnya.

Menghantar Persetujuan Web Kembali ke Natif

Jika pengguna boleh menukar persetujuan di dalam WebView, contohnya melalui halaman tetapan privasi, aplikasi mesti mengetahuinya. Gunakan jambatan JavaScript: pengendali mesej pada iOS atau antara muka JavaScript pada Android. Pihak web mendengar dengan __tcfapi('addEventListener', ...) dan menghantar rentetan baharu kepada kod natif, yang menulis kunci piawai. Sahkan input daripada WebView sebelum menulisnya; terima mesej daripada kandungan anda sendiri sahaja.

Iklan di dalam WebView

Iklan yang dirender dalam WebView ialah iklan web. Ia membaca persetujuan daripada halaman, bukan daripada storan natif, melainkan SDK iklan menyediakan cara untuk memautkan keduanya. Mobile Ads SDK Google, contohnya, menawarkan API untuk mendaftarkan WebView supaya iklan di dalamnya boleh menggunakan isyarat daripada aplikasi; semak dokumentasi semasa untuk SDK anda. Walau apa pun, sahkan melalui ujian bahawa permintaan iklan daripada WebView membawa rentetan TC atau GPP yang sama dengan permintaan iklan natif.

Senarai Semak Pengujian

• Pemasangan baharu: satu gesaan persetujuan, bukan dua.
• Tolak semua dalam CMP natif, buka WebView, periksa permintaan iklan: rentetan harus mencerminkan penolakan.
• Tukar persetujuan dalam tetapan natif, kembali ke WebView yang terbuka: halaman harus melihat keputusan baharu.
• Jika tetapan web wujud, tukar persetujuan di situ dan sahkan kunci natif dikemas kini.
• Matikan paksa dan lancarkan semula aplikasi: keputusan kekal pada kedua-dua pihak.
• Uji pada iOS dan Android, kerana storan WebView berfungsi secara berbeza pada setiap satu.

Perkara Utama

• Persetujuan natif dan WebView berada dalam stor yang berasingan dan tidak disegerakkan secara lalai.
• Pilih satu sumber kebenaran; bagi kebanyakan aplikasi ia ialah CMP natif.
• Dedahkan persetujuan natif kepada kandungan web melalui __tcfapi atau __gpp yang disuntik dan sembunyikan sepanduk web.
• Gunakan jambatan JavaScript untuk menghantar perubahan web kembali ke storan natif.
• Pastikan permintaan iklan daripada WebView membawa rentetan persetujuan yang sama dengan permintaan natif.