Apa yang sebenarnya dilakukan Zaraz di pinggir

Zaraz ialah pengurus tag sisi pelayan yang dilaksanakan di dalam Cloudflare Workers. Apabila pengunjung memuatkan halaman, HTML penerbit menyertakan skrip permulaan Zaraz yang kecil — biasanya beberapa kilobait — yang mengumpulkan muatan peristiwa berstruktur dari pelayar (paparan halaman, klik, peristiwa tersuai) dan POST ke titik akhir Cloudflare pada domain penerbit sendiri. Workers menerima muatan tersebut dan menjalankan alat Zaraz yang dikonfigurasi terhadapnya: integrasi Google Analytics 4 menghantar hit Measurement Protocol, integrasi Meta Pixel menghantar peristiwa Conversions API, integrasi Mixpanel menghantar panggilan HTTP API. JavaScript pihak ketiga vendor tidak pernah dimuatkan dalam pelayar, kuki vendor sama ada tidak ditetapkan langsung atau ditulis melalui domain pihak pertama Cloudflare melalui Workers, dan vendor hanya menerima data yang dikonfigurasi Zaraz penerbit untuk diteruskan secara eksplisit.

Itulah cadangan nilai seni bina. Itulah juga sebab gambaran persetujuan berbeza daripada mana-mana pengurus tag sisi klien. Dengan persediaan tradisional, soalan persetujuan adalah sama ada JavaScript vendor dimuatkan atau tidak. Dengan Zaraz, JavaScript tidak pernah dimuatkan dalam mana-mana kes — soalannya menjadi sama ada muatan sisi pelayan dihantar atau ditahan, dan sama ada muatan mengandungi pengecam yang diperlukan vendor untuk menjejaki pengguna. Kedua-dua soalan mempunyai jawapan yang jelas dalam Zaraz Consent API; tugas penerbit adalah untuk memetakannya dengan betul.

Zaraz Consent API dan cara ia berbeza daripada CMP sisi klien

Zaraz dihantar dengan modul persetujuan terbina dalam — Zaraz Consent Tools — yang mengekalkan keadaan persetujuan setiap pengunjung dan mengawal alat yang dikonfigurasi untuk diaktifkan. Keadaan didedahkan melalui API JavaScript kecil: zaraz.consent.set({ analytics: true, marketing: false }) untuk merekod pilihan pengguna, zaraz.consent.get('analytics') untuk membacanya, zaraz.consent.getAll() untuk peta penuh, zaraz.consent.modal() untuk membuka UI persetujuan, dan pendengar peristiwa pada zaraz.consent.onModalShown dan peristiwa berkaitan untuk tingkah laku UI tersuai. Setiap alat Zaraz dalam papan pemuka dikonfigurasi dengan satu atau lebih ID tujuan, dan Workers hanya melaksanakan alat apabila tujuan yang relevan diberikan dalam keadaan persetujuan pengunjung.

Pilihan integrasi adalah sama ada menggunakan modal persetujuan terbina dalam Zaraz atau mengikat Zaraz kepada CMP luaran. Modal terbina dalam adalah laluan paling mudah: aktifkan Consent Tools, tentukan tujuan, konfigurasikan setiap alat dengan tujuan yang betul, dan hantar. Laluan CMP luaran adalah pilihan yang betul untuk organisasi yang sudah menyeragamkan Cookiebot, OneTrust, Usercentrics, atau CMP tersuai — Zaraz kemudian beroperasi di hiliran CMP, dengan CMP memanggil zaraz.consent.set() apabila pengguna melalui sepanduk. Kedua-dua laluan berakhir di titik penguatkuasaan yang sama: Workers menyemak keadaan persetujuan sebelum setiap alat dilaksanakan, dan alat yang tujuannya tidak diberikan tidak akan berjalan.

Sokongan IAB TCF dan rejim serantau

Zaraz menambah sokongan IAB TCF v2 pada 2023 dan telah mengikuti kerangka kerja sejak itu. Untuk penerbit yang beroperasi di EEA dan UK di bawah perkongsian iklan berasaskan TCF, integrasi menterjemahkan rentetan persetujuan TCF ke dalam keadaan tujuan Zaraz secara automatik apabila penerbit memilih masuk. Untuk rantau bukan TCF, penerbit memetakan tujuan tersuai — biasanya analytics, marketing, personalization, functional — ke alat Zaraz yang relevan secara langsung. Workers yang sama menguatkuasakan kedua-duanya, yang bermakna satu konfigurasi Zaraz boleh melayani pengunjung EEA melalui TCF dan pengunjung California melalui gerbang tujuan pemasaran tersuai tanpa dua saluran selari.

Mengapa Zaraz mengubah gambaran GDPR dan ePrivacy

Pendirian undang-undang di bawah GDPR, ePrivacy, dan CCPA tidak dikecualikan oleh pelaksanaan sisi pelayan — asas undang-undang mengikut data, bukan pengangkutan — tetapi permukaan pematuhan praktikal berubah. Tiga peralihan penting.

• Permukaan kuki menyusut. Kebanyakan kuki vendor tidak pernah ditulis kerana JavaScript vendor tidak pernah berjalan dalam pelayar. Kuki yang tinggal biasanya ialah pengecam sesi sendiri Zaraz dan sebarang pengecam pihak pertama yang sengaja disebarkan oleh penerbit. Permukaan kuki bukan penting yang perlu dihalang oleh sepanduk oleh itu jauh lebih kecil — kadangkala hanya satu atau dua kuki berbanding selusin atau lebih yang biasanya dihasilkan oleh tindanan sisi klien.
• Pendedahan pemindahan pihak ketiga berubah. Kerana Workers menghantar data kepada vendor melalui panggilan pelayan ke pelayan, laluan data dari pelayar pengunjung adalah ke pinggir Cloudflare dan dari sana ke vendor yang dikonfigurasi. Notis privasi mesti mencerminkan ini — Cloudflare adalah pemproses dan setiap alat Zaraz adalah penerima hiliran — tetapi pendedahan dalam banyak cara adalah lebih bersih daripada laluan sisi klien yang setara kerana penerbit mempunyai kawalan penuh ke atas apa yang diteruskan.
• Jejak audit lebih terpusat. Kerana setiap peristiwa vendor melalui Workers, penerbit mempunyai satu titik di mana keadaan persetujuan, muatan peristiwa, dan penerima hiliran boleh dilog. Pengawal selia yang mengharapkan log persetujuan yang boleh ditanya mendapat jawapan yang lebih jelas dengan Zaraz berbanding dengan tag sisi klien yang berserak.

Corak integrasi yang berfungsi

Penempatan rujukan mempunyai empat bahagian yang bergerak. Yang pertama ialah permulaan Zaraz dalam halaman, dimuatkan dari domain penerbit melalui proksi Cloudflare. Yang kedua ialah sama ada modal Consent Tools terbina dalam atau CMP luaran yang memanggil zaraz.consent.set() apabila pengguna membuat pilihan. Yang ketiga ialah konfigurasi papan pemuka Zaraz yang memetakan setiap alat kepada tujuan yang betul — alat analitik kepada tujuan analitik, alat pengiklanan kepada tujuan pemasaran, alat ulang main sesi kepada tujuan fungsi atau penyelidikan yang lebih ketat, dan mana-mana alat bergantung pemindahan rentas sempadan kepada tujuan pemindahan rentas sempadan jika notis privasi penerbit mendedahkan itu sebagai pilihan berasingan. Yang keempat ialah log sisi pelayan — sama ada Cloudflare Analytics, Logpush ke tasik data penerbit, atau Workers tersuai yang menulis keputusan persetujuan ke stor yang boleh ditanya — supaya rekod persetujuan boleh dihasilkan atas permintaan pengawal selia.

Langkah pengesahan adalah jujukan empat semakan yang sama yang berlaku untuk mana-mana integrasi persetujuan tetapi dengan kelainan khusus Zaraz. Sesi pelayar yang bersih dengan sepanduk ditunjukkan tetapi tiada pilihan dibuat sepatutnya menghasilkan sifar permintaan dari pelayar pengunjung ke mana-mana domain vendor dan sifar kuki bukan penting — kedua-duanya lebih mudah disahkan dengan Zaraz berbanding dengan tindanan sisi klien kerana ketiadaan permintaan pihak ketiga adalah lalai dan bukannya pengecualian yang dikonfigurasi. Lawatan tolak sepatutnya mengekalkan keadaan itu. Lawatan terima sepatutnya menghasilkan POST titik akhir Zaraz yang membawa hanya peristiwa yang dipersetujui pengguna, dan log Workers sepatutnya menunjukkan aktivasi alat hiliran. Penarikan balik sepatutnya dengan segera menghentikan pelaksanaan alat Workers selanjutnya, menamatkan tempoh kuki yang ditetapkan Zaraz, dan mencetuskan isyarat pemadaman atau keluar yang sesuai kepada vendor hiliran yang dikonfigurasi.

Di mana Zaraz masih memerlukan pengendalian yang teliti

Zaraz bukan penyelesaian persetujuan mengikut seni bina yang menghapuskan keperluan untuk berfikir. Tiga kawasan memerlukan pengendalian yang disengajakan. Benam klik untuk muatkan — video YouTube, Twitter, Instagram, TikTok — masih memerlukan corak pemegang tempat yang sama yang digunakan oleh mana-mana penempatan yang mengutamakan persetujuan, kerana Zaraz pada masa ini tidak memproksikan iframe video yang ditempatkan. Pengecam sisi klien yang dipilih oleh penerbit untuk ditetapkan dalam pelayar bagi tujuan pihak pertama — ID pengguna yang log masuk, token sesi, baldi ujian A/B — kekal di sisi penerbit sempadan persetujuan dan memerlukan logik penghalauan mereka sendiri. Dan notis privasi mesti menggambarkan dengan tepat model pemindahan sisi pelayan, termasuk peranan Cloudflare sebagai pemproses dan lokasi geografi Workers yang mengendalikan data, kerana pinggir Cloudflare beroperasi di pelbagai rantau dan trafik pengunjung mungkin diproses di rantau yang bukan milik mereka sendiri. Dengan perkara-perkara itu ditangani, penempatan Zaraz pada 2026 bertukar dari produk pengurusan tag kepada salah satu seni bina persetujuan yang paling bersih yang boleh dijalankan oleh penerbit: permukaan kuki yang lebih kecil, lebih sedikit permintaan pihak ketiga, penguatkuasaan terpusat, dan jejak audit yang sebenarnya boleh dibaca oleh pengawal selia.