Zaraz ทำอะไรบน edge จริงๆ

Zaraz เป็นตัวจัดการแท็กฝั่งเซิร์ฟเวอร์ที่รันภายใน Cloudflare Workers เมื่อผู้เยี่ยมชมโหลดหน้าเว็บ HTML ของผู้เผยแพร่จะรวมสคริปต์การเริ่มต้น Zaraz ขนาดเล็ก — โดยทั่วไปไม่กี่กิโลไบต์ — ที่รวบรวม payload ของเหตุการณ์ที่มีโครงสร้างจากเบราว์เซอร์ (การดูหน้า, การคลิก, เหตุการณ์กำหนดเอง) และ POST ไปยัง Cloudflare endpoint บนโดเมนของผู้เผยแพร่เอง Worker รับ payload นั้นและรันเครื่องมือ Zaraz ที่กำหนดค่าไว้กับมัน: การผสานรวม Google Analytics 4 ส่ง Measurement Protocol hit, การผสานรวม Meta Pixel ส่งเหตุการณ์ Conversions API, การผสานรวม Mixpanel ส่งการเรียก HTTP API JavaScript บุคคลที่สามของผู้ให้บริการไม่ถูกโหลดในเบราว์เซอร์เลย คุกกี้ของผู้ให้บริการไม่ถูกตั้งค่าเลยหรือถูกเขียนผ่านโดเมนบุคคลที่หนึ่งของ Cloudflare ผ่าน Worker และผู้ให้บริการรับเฉพาะข้อมูลที่การกำหนดค่า Zaraz ของผู้เผยแพร่ส่งต่ออย่างชัดเจน

นั่นคือข้อเสนอคุณค่าเชิงสถาปัตยกรรม นั่นเป็นเหตุผลด้วยว่าทำไมภาพความยินยอมจึงแตกต่างจากตัวจัดการแท็กฝั่งไคลเอนต์ใดๆ ด้วยการตั้งค่าแบบดั้งเดิม คำถามเรื่องความยินยอมคือ JavaScript ของผู้ให้บริการถูกโหลดหรือไม่ ด้วย Zaraz, JavaScript ไม่ถูกโหลดในทั้งสองกรณี — คำถามกลายเป็นว่า payload ฝั่งเซิร์ฟเวอร์ถูกส่งหรือถูกระงับ และ payload มีตัวระบุที่ผู้ให้บริการต้องการเพื่อติดตามผู้ใช้หรือไม่ คำถามทั้งสองมีคำตอบที่กำหนดไว้อย่างดีใน Zaraz Consent API งานของผู้เผยแพร่คือการแมปพวกมันอย่างถูกต้อง

Zaraz Consent API และความแตกต่างจาก CMP ฝั่งไคลเอนต์

Zaraz มาพร้อมกับโมดูลความยินยอมในตัว — Zaraz Consent Tools — ที่รักษาสถานะความยินยอมต่อผู้เยี่ยมชมและควบคุมเครื่องมือที่กำหนดค่าไว้ว่าจะทำงาน สถานะถูกเปิดเผยผ่าน JavaScript API ขนาดเล็ก: zaraz.consent.set({ analytics: true, marketing: false }) เพื่อบันทึกตัวเลือกของผู้ใช้, zaraz.consent.get('analytics') เพื่ออ่านมัน, zaraz.consent.getAll() สำหรับแผนที่ทั้งหมด, zaraz.consent.modal() เพื่อเปิด UI ความยินยอม และ event listener บน zaraz.consent.onModalShown และเหตุการณ์ที่เกี่ยวข้องสำหรับพฤติกรรม UI กำหนดเอง เครื่องมือ Zaraz แต่ละตัวในแดชบอร์ดถูกกำหนดค่าด้วย purpose ID หนึ่งตัวหรือมากกว่า และ Worker จะรันเครื่องมือเฉพาะเมื่อ purpose ที่เกี่ยวข้องได้รับอนุมัติในสถานะความยินยอมของผู้เยี่ยมชม

ตัวเลือกการผสานรวมคือจะใช้ modal ความยินยอมในตัวของ Zaraz หรือผูก Zaraz กับ CMP ภายนอก modal ในตัวเป็นเส้นทางที่ง่ายที่สุด: เปิดใช้งาน Consent Tools, กำหนด purpose, กำหนดค่าเครื่องมือแต่ละตัวด้วย purpose ที่ถูกต้อง และส่ง เส้นทาง CMP ภายนอกเป็นตัวเลือกที่ถูกต้องสำหรับองค์กรที่มาตรฐานกับ Cookiebot, OneTrust, Usercentrics หรือ CMP กำหนดเองอยู่แล้ว — Zaraz จะทำงานต้นน้ำจาก CMP โดยมี CMP เรียก zaraz.consent.set() เมื่อผู้ใช้ผ่านแบนเนอร์ ทั้งสองเส้นทางนำไปสู่จุดบังคับใช้เดียวกัน: Worker ตรวจสอบสถานะความยินยอมก่อนที่เครื่องมือแต่ละตัวจะรัน และเครื่องมือที่ purpose ไม่ได้รับอนุมัติก็ไม่รันเลย

การรองรับ IAB TCF และระบอบภูมิภาค

Zaraz เพิ่มการรองรับ IAB TCF v2 ในปี 2023 และติดตามกรอบงานต่อมาตั้งแต่นั้น สำหรับผู้เผยแพร่ที่ดำเนินงานใน EEA และ UK ภายใต้พันธมิตรโฆษณาที่ใช้ TCF การผสานรวมจะแปล TCF consent string เป็นสถานะ purpose ของ Zaraz โดยอัตโนมัติเมื่อผู้เผยแพร่เลือก opt-in สำหรับภูมิภาคที่ไม่ใช่ TCF ผู้เผยแพร่จะแมป purpose กำหนดเอง — โดยทั่วไปคือ analytics, marketing, personalization, functional — ไปยังเครื่องมือ Zaraz ที่เกี่ยวข้องโดยตรง Worker เดียวกันบังคับใช้ทั้งสองซึ่งหมายความว่าการกำหนดค่า Zaraz เดี่ยวสามารถให้บริการผู้เยี่ยมชม EEA ผ่าน TCF และผู้เยี่ยมชมแคลิฟอร์เนียผ่านประตู marketing-purpose กำหนดเองโดยไม่มีไปป์ไลน์คู่ขนานสอง

ทำไม Zaraz เปลี่ยนภาพ GDPR และ ePrivacy

ท่าทีทางกฎหมายภายใต้ GDPR, ePrivacy และ CCPA ไม่ได้รับการยกเว้นโดยการรันฝั่งเซิร์ฟเวอร์ — ฐานทางกฎหมายตามข้อมูล ไม่ใช่การขนส่ง — แต่พื้นที่ความสอดคล้องในทางปฏิบัติเปลี่ยนแปลง การเปลี่ยนแปลงสามอย่างมีความสำคัญ

• พื้นที่คุกกี้ลดลง คุกกี้ของผู้ให้บริการส่วนใหญ่ไม่ถูกเขียนเลยเพราะ JavaScript ของผู้ให้บริการไม่ถูกรันในเบราว์เซอร์เลย คุกกี้ที่เหลืออยู่โดยทั่วไปคือตัวระบุเซสชันของ Zaraz เองและตัวระบุบุคคลที่หนึ่งที่ผู้เผยแพร่เผยแพร่โดยตั้งใจ พื้นที่คุกกี้ที่ไม่จำเป็นที่แบนเนอร์ต้องควบคุมจึงเล็กลงอย่างมาก — บางครั้งมีเพียงหนึ่งหรือสองคุกกี้เทียบกับโหลขึ้นไปที่ stack ฝั่งไคลเอนต์ทั่วไปสร้าง
• การเปิดเผยการถ่ายโอนบุคคลที่สามเปลี่ยนแปลง เพราะ Worker ส่งข้อมูลให้ผู้ให้บริการผ่านการเรียก server-to-server เส้นทางข้อมูลจากเบราว์เซอร์ของผู้เยี่ยมชมคือไปยัง edge ของ Cloudflare และจากที่นั่นไปยังผู้ให้บริการที่กำหนดค่าไว้ นโยบายความเป็นส่วนตัวต้องสะท้อนสิ่งนี้ — Cloudflare เป็นผู้ประมวลผลและเครื่องมือ Zaraz แต่ละตัวเป็นผู้รับต้นน้ำ — แต่การเปิดเผยในหลายๆ ด้านชัดเจนกว่าเส้นทางฝั่งไคลเอนต์เทียบเท่าเพราะผู้เผยแพร่มีการควบคุมเต็มที่ว่าอะไรถูกส่งต่อ
• เส้นทางการตรวจสอบรวมศูนย์มากขึ้น เพราะเหตุการณ์ของผู้ให้บริการทุกตัวผ่าน Worker ผู้เผยแพร่มีจุดเดียวที่สถานะความยินยอม payload ของเหตุการณ์ และผู้รับต้นน้ำสามารถบันทึกได้ หน่วยงานกำกับดูแลที่คาดหวัง consent log ที่ค้นหาได้มีคำตอบที่ชัดเจนกว่าจาก Zaraz มากกว่าจากการกระจายแท็กฝั่งไคลเอนต์

รูปแบบการผสานรวมที่ได้ผล

การ deploy อ้างอิงมีสี่ส่วนที่เคลื่อนไหว ส่วนแรกคือการเริ่มต้น Zaraz ในหน้าเว็บ โหลดจากโดเมนของผู้เผยแพร่ผ่าน Cloudflare proxy ส่วนที่สองคือ modal Consent Tools ในตัวหรือ CMP ภายนอกที่เรียก zaraz.consent.set() เมื่อผู้ใช้ทำตัวเลือก ส่วนที่สามคือการกำหนดค่าแดชบอร์ด Zaraz ที่แมปเครื่องมือแต่ละตัวกับ purpose ที่ถูกต้อง — เครื่องมือ analytics กับ analytics purpose, เครื่องมือโฆษณากับ marketing purpose, เครื่องมือเล่นซ้ำเซสชันกับ functional หรือ research purpose ที่เข้มงวดกว่า และเครื่องมือที่ขึ้นอยู่กับการถ่ายโอนบุคคลที่สามกับ cross-border-transfer purpose ถ้านโยบายความเป็นส่วนตัวของผู้เผยแพร่เปิดเผยสิ่งนั้นเป็นตัวเลือกแยก ส่วนที่สี่คือ log ฝั่งเซิร์ฟเวอร์ — ไม่ว่าจะเป็น Cloudflare Analytics, Logpush ไปยัง data lake ของผู้เผยแพร่ หรือ Worker กำหนดเองที่เขียนการตัดสินใจความยินยอมไปยัง store ที่ค้นหาได้ — เพื่อให้บันทึกความยินยอมสามารถสร้างได้ตามคำขอของผู้กำกับดูแล

ขั้นตอนการตรวจสอบความถูกต้องเป็นลำดับตรวจสอบสี่ขั้นเดิมที่ใช้กับการผสานรวมความยินยอมใดๆ แต่มีเนื้อหาเฉพาะ Zaraz เซสชันเบราว์เซอร์ที่สะอาดโดยแสดงแบนเนอร์แต่ไม่มีตัวเลือกที่ทำควรสร้างคำขอศูนย์จากเบราว์เซอร์ของผู้เยี่ยมชมไปยังโดเมนผู้ให้บริการใดๆ และคุกกี้ที่ไม่จำเป็นศูนย์ — ทั้งสองยืนยันได้ง่ายกว่าด้วย Zaraz มากกว่า stack ฝั่งไคลเอนต์เพราะการไม่มีคำขอบุคคลที่สามเป็นค่าเริ่มต้นไม่ใช่ข้อยกเว้นที่กำหนดค่า การเยี่ยมชมที่ปฏิเสธควรรักษาสถานะนั้น การเยี่ยมชมที่ยอมรับควรสร้าง POST ของ Zaraz endpoint ที่บรรทุกเฉพาะเหตุการณ์ที่ผู้ใช้ยินยอม และ Worker log ควรแสดงเครื่องมือต้นน้ำที่ทำงาน การถอนควรหยุดการรันเครื่องมือ Worker เพิ่มเติมทันที หมดอายุคุกกี้ที่ Zaraz ตั้งไว้ และเรียกใช้สัญญาณการลบหรือ opt-out ที่เหมาะสมให้กับผู้ให้บริการต้นน้ำที่กำหนดค่าไว้

ที่ Zaraz ยังต้องการการจัดการอย่างระมัดระวัง

Zaraz ไม่ใช่โซลูชันความยินยอมตามสถาปัตยกรรมที่ลบความต้องการคิด สามพื้นที่ต้องการการจัดการโดยตั้งใจ การฝังแบบคลิก-เพื่อโหลด — YouTube, Twitter, Instagram, TikTok วิดีโอ — ยังต้องการรูปแบบ placeholder เดิมที่การ deploy ความยินยอม-ก่อนใดๆ ใช้ เพราะ Zaraz ปัจจุบันไม่ proxy iframe วิดีโอที่ฝัง ตัวระบุฝั่งไคลเอนต์ที่ผู้เผยแพร่เลือกตั้งค่าในเบราว์เซอร์สำหรับวัตถุประสงค์บุคคลที่หนึ่ง — ID ผู้ใช้ที่เข้าสู่ระบบ, session token, A/B test bucket — ยังคงอยู่ฝั่งผู้เผยแพร่ของขอบเขตความยินยอมและต้องการตรรกะการควบคุมของตัวเอง และนโยบายความเป็นส่วนตัวต้องอธิบายโมเดลการถ่ายโอนฝั่งเซิร์ฟเวอร์อย่างถูกต้อง รวมถึงบทบาทของ Cloudflare เป็นผู้ประมวลผลและที่ตั้งทางภูมิศาสตร์ของ Workers ที่จัดการข้อมูล เพราะ Cloudflare edge รันในหลายภูมิภาคและการรับส่งข้อมูลของผู้เยี่ยมชมอาจถูกประมวลผลในภูมิภาคที่ไม่ใช่ภูมิภาคของตัวเอง เมื่อจัดการสิ่งเหล่านั้นแล้ว การ deploy Zaraz ในปี 2026 เปลี่ยนจากผลิตภัณฑ์การจัดการแท็กไปเป็นหนึ่งในสถาปัตยกรรมความยินยอมที่สะอาดที่สุดที่ผู้เผยแพร่สามารถรัน: พื้นที่คุกกี้เล็กลง คำขอบุคคลที่สามน้อยลง การบังคับใช้รวมศูนย์ และเส้นทางการตรวจสอบที่ผู้กำกับดูแลสามารถอ่านได้จริง