Dua Tugas yang Berbeza

Apabila pelawat membuat pilihan persetujuan, dua perkara berasingan perlu berlaku. Pertama, pelayar mesti mengingati pilihan itu supaya sepanduk tidak muncul semula pada setiap halaman dan tag tahu apa yang dibenarkan. Kedua, anda mungkin perlu membuktikan kemudian bahawa pilihan itu dibuat, apa yang ditunjukkan kepada pelawat dan bila. Tugas ini sering dikendalikan oleh mekanisme storan berbeza, dan mengelirukan keduanya menyebabkan masalah sebenar: sepanduk yang terus muncul semula, pilihan yang hilang pada sesetengah pelayar, atau tiada rekod untuk ditunjukkan apabila ada yang bertanya.

Perbandingan ini meneliti tiga pilihan biasa — kuki pihak pertama, storan pelayar seperti localStorage dan rekod persetujuan sebelah pelayan — serta di mana setiap satu sesuai.

Pilihan 1: Kuki Pihak Pertama

Kuki ialah tempat tradisional bagi keadaan persetujuan. CMP TCF lazimnya menyimpan rentetan persetujuan dalam kuki pihak pertama, dan banyak CMP menyimpan data keutamaan mereka sendiri di dalamnya juga.

Kekuatan

• Boleh dibaca pelayan. Kuki dihantar bersama setiap permintaan, jadi kod sebelah pelayan, logik edge dan server-side tagging boleh membaca pilihan tanpa menunggu JavaScript.
• Boleh dikongsi merentas subdomain. Kuki yang ditetapkan pada domain berdaftar anda boleh meliputi subdomain www, blog dan kedai.
• Dijangka secara meluas. Banyak integrasi ad tech mencari persetujuan dalam kuki.

Kelemahan

• Had saiz. Pelayar mengehadkan saiz kuki sekitar 4 KB, dan rentetan TCF dengan banyak vendor serta nilai lain boleh menghampirinya.
• Overhed permintaan. Setiap permintaan ke domain anda membawa kuki, termasuk permintaan imej dan skrip.
• Had hayat dalam sesetengah pelayar. Intelligent Tracking Prevention Safari mengehadkan kuki yang dicipta melalui JavaScript kepada hayat maksimum tujuh hari. Kuki yang ditetapkan oleh pelayan anda sendiri dalam respons HTTP umumnya dilayan dengan lebih murah hati, walaupun ada pengecualian.

Pilihan 2: localStorage dan Storan Pelayar Lain

Sesetengah CMP menyimpan keutamaan terperinci dalam localStorage, kadangkala bersama kuki yang lebih kecil.

Kekuatan

• Lebih banyak ruang. Beberapa megabait bagi setiap origin, cukup untuk pilihan terperinci peringkat vendor.
• Tiada overhed permintaan. Tiada apa-apa dihantar ke pelayan secara automatik.

Kelemahan

• Tidak kelihatan kepada pelayan. Kod sebelah pelayan dan logik edge tidak dapat membacanya, jadi sebarang keputusan sebelah pelayan mesti menunggu pelayar.
• Terikat kepada satu origin. Storan pada www.example.com tidak tersedia pada shop.example.com, jadi pelawat mungkin melihat sepanduk lagi pada setiap subdomain.
• Tertakluk kepada pemadaman. Safari boleh membuang storan yang boleh ditulis skrip, termasuk localStorage, bagi tapak yang tidak berinteraksi dengan pengguna selama tujuh hari penggunaan pelayar, dan mod pelayaran peribadi biasanya mengosongkannya apabila sesi tamat.

Pilihan 3: Rekod Persetujuan Sebelah Pelayan

Rekod sebelah pelayan ialah entri yang disimpan oleh anda atau pembekal CMP anda setiap kali pilihan dibuat. Ia biasanya mengandungi pengecam nama samaran, cap masa, pilihan, versi sepanduk atau dasar yang ditunjukkan, dan konteks seperti wilayah.

Kekuatan

• Bukti tahan lama. Ia kekal walaupun kuki dikosongkan dan ada sekatan pelayar, menjadikannya alat yang tepat untuk menunjukkan persetujuan telah diperoleh.
• Boleh diaudit. Anda boleh melaporkan pilihan dari semasa ke semasa dan menjawab soalan tentang peristiwa tertentu.
• Potensi merentas peranti. Bagi pembaca yang log masuk, rekod pelayan boleh menyegerakkan pilihan antara peranti, jika anda menerangkannya kepada mereka.

Kelemahan

• Bukan pengganti keadaan setempat. Tag dalam pelayar masih memerlukan isyarat setempat yang pantas; memanggil pelayan pada setiap paparan halaman untuk mencari persetujuan menambah kependaman.
• Ia sendiri ialah data peribadi. Rekod memerlukan tempoh pengekalan, kawalan akses dan tempat dalam notis privasi anda.
• Kebergantungan pada pengecam. Pelawat tanpa nama hanya boleh dipadankan dengan rekod melalui pengecam yang disimpan pada peranti mereka, yang membawa anda kembali kepada storan setempat.

Ringkasan Bersebelahan

• Terbaik untuk mengingati pilihan di web: kuki pihak pertama, sebaiknya ditetapkan oleh pelayan anda untuk hayat yang stabil.
• Terbaik untuk data keutamaan terperinci dalam pelayar: localStorage, dipasangkan dengan kuki yang boleh dibaca pelayan.
• Terbaik untuk membuktikan pilihan: rekod sebelah pelayan.
• Pilihan tunggal terburuk: bergantung pada localStorage sahaja, yang membuat pelayan buta dan pilihan rapuh pada sesetengah pelayar.

Pendekatan Gabungan yang Praktikal

1. Simpan isyarat setempat yang berwibawa — contohnya rentetan TCF dan rekod keutamaan padat — dalam kuki pihak pertama yang skopnya domain berdaftar anda.
2. Gunakan localStorage hanya untuk data tambahan yang tidak perlu sampai ke pelayan.
3. Tulis rekod sebelah pelayan bagi setiap pilihan, termasuk versi sepanduk dan dasar yang ditunjukkan.
4. Jika pilihan yang disimpan hilang, tunjukkan sepanduk semula dan bukannya mengandaikan jawapan terdahulu.
5. Tetapkan tempoh gesaan semula bagi pilihan yang disimpan dan rekodkannya dalam dasar anda.

Menyimpan pilihan persetujuan pelawat itu sendiri umumnya dianggap perlu untuk menyampaikan perkhidmatan yang diminta pelawat — mengingati keputusan mereka — tetapi semak panduan yang terpakai di pasaran utama anda.

Perkara Utama

• Mengingati pilihan dan membuktikan pilihan ialah tugas berbeza yang memerlukan storan berbeza.
• Kuki boleh dibaca pelayan dan dikongsi merentas subdomain tetapi terhad saiznya dan, dalam Safari, hayatnya apabila ditetapkan oleh skrip.
• localStorage menawarkan ruang tetapi tidak kelihatan kepada pelayan dan boleh dikosongkan oleh pelayar.
• Rekod sebelah pelayan ialah lapisan bukti, bukan pengganti isyarat setempat.
• Gabungkan kuki pihak pertama yang ditetapkan pelayan, storan pelayar pilihan dan rekod pelayan.