จะเก็บความยินยอมที่ไหน: เปรียบเทียบคุกกี้ localStorage และบันทึกฝั่งเซิร์ฟเวอร์
สองงานที่ต่างกัน
เมื่อผู้เข้าชมเลือกเรื่องความยินยอม มีสองสิ่งที่ต้องเกิดขึ้นแยกกัน ประการแรก เบราว์เซอร์ต้องจดจำตัวเลือกนั้น เพื่อไม่ให้แบนเนอร์กลับมาทุกหน้า และให้แท็กรู้ว่าตนทำอะไรได้บ้าง ประการที่สอง คุณอาจต้องพิสูจน์ในภายหลังว่ามีการเลือกเกิดขึ้น ผู้เข้าชมเห็นอะไร และเมื่อใด งานเหล่านี้มักใช้กลไกจัดเก็บที่ต่างกัน และการสับสนระหว่างสองงานทำให้เกิดปัญหาจริง: แบนเนอร์ที่ขึ้นซ้ำ ตัวเลือกที่หายไปในบางเบราว์เซอร์ หรือไม่มีบันทึกให้แสดงเมื่อมีคนถาม
การเปรียบเทียบนี้พิจารณาสามตัวเลือกที่พบบ่อย — คุกกี้ first-party ที่เก็บข้อมูลของเบราว์เซอร์อย่าง localStorage และบันทึกความยินยอมฝั่งเซิร์ฟเวอร์ — และว่าแต่ละอย่างเหมาะกับที่ใด
ตัวเลือกที่ 1: คุกกี้ first-party
คุกกี้เป็นที่อยู่ดั้งเดิมของสถานะความยินยอม CMP แบบ TCF มักเก็บสตริงความยินยอมในคุกกี้ first-party และ CMP จำนวนมากเก็บข้อมูลการตั้งค่าของตนเองในคุกกี้ด้วย
จุดแข็ง
- เซิร์ฟเวอร์อ่านได้ คุกกี้ถูกส่งไปกับทุกคำขอ โค้ดฝั่งเซิร์ฟเวอร์ ตรรกะ edge และ server-side tagging จึงอ่านตัวเลือกได้โดยไม่ต้องรอ JavaScript
- แชร์ข้ามซับโดเมนได้ คุกกี้ที่ตั้งบนโดเมนที่ลงทะเบียนของคุณครอบคลุมซับโดเมน www, blog และ shop ได้
- เป็นที่คาดหวังอย่างกว้างขวาง การเชื่อมต่อ ad tech จำนวนมากมองหาความยินยอมในคุกกี้
จุดอ่อน
- ข้อจำกัดด้านขนาด เบราว์เซอร์จำกัดขนาดคุกกี้ที่ประมาณ 4 KB และสตริง TCF ที่มีผู้ให้บริการจำนวนมากรวมกับค่าอื่นอาจเข้าใกล้ขีดจำกัดนั้น
- ภาระต่อคำขอ ทุกคำขอไปยังโดเมนของคุณพกคุกกี้ไปด้วย รวมถึงคำขอรูปภาพและสคริปต์
- ข้อจำกัดอายุในบางเบราว์เซอร์ Intelligent Tracking Prevention ของ Safari จำกัดอายุสูงสุดของคุกกี้ที่สร้างผ่าน JavaScript ไว้ที่เจ็ดวัน คุกกี้ที่เซิร์ฟเวอร์ของคุณเองตั้งในการตอบกลับ HTTP มักได้รับการปฏิบัติอย่างผ่อนปรนกว่า แม้จะมีข้อยกเว้น
ตัวเลือกที่ 2: localStorage และที่เก็บข้อมูลเบราว์เซอร์อื่น
CMP บางตัวเก็บการตั้งค่าโดยละเอียดใน localStorage บางครั้งควบคู่กับคุกกี้ขนาดเล็ก
จุดแข็ง
- พื้นที่มากกว่า หลายเมกะไบต์ต่อ origin เพียงพอสำหรับตัวเลือกระดับผู้ให้บริการโดยละเอียด
- ไม่มีภาระต่อคำขอ ไม่มีอะไรถูกส่งไปยังเซิร์ฟเวอร์โดยอัตโนมัติ
จุดอ่อน
- เซิร์ฟเวอร์มองไม่เห็น โค้ดฝั่งเซิร์ฟเวอร์และตรรกะ edge อ่านไม่ได้ การตัดสินใจฝั่งเซิร์ฟเวอร์ใด ๆ จึงต้องรอเบราว์เซอร์
- ผูกกับ origin เดียว ที่เก็บข้อมูลบน www.example.com ใช้บน shop.example.com ไม่ได้ ผู้เข้าชมจึงอาจเห็นแบนเนอร์อีกครั้งในแต่ละซับโดเมน
- อาจถูกลบ Safari อาจลบที่เก็บข้อมูลที่สคริปต์เขียนได้ รวมถึง localStorage สำหรับเว็บไซต์ที่ผู้ใช้ไม่ได้โต้ตอบเป็นเวลาเจ็ดวันของการใช้เบราว์เซอร์ และโหมดการท่องเว็บส่วนตัวมักล้างข้อมูลเมื่อสิ้นสุดเซสชัน
ตัวเลือกที่ 3: บันทึกความยินยอมฝั่งเซิร์ฟเวอร์
บันทึกฝั่งเซิร์ฟเวอร์คือรายการที่คุณหรือผู้ให้บริการ CMP เก็บไว้ทุกครั้งที่มีการเลือก โดยทั่วไปประกอบด้วยตัวระบุแบบนามแฝง เวลา ตัวเลือก เวอร์ชันแบนเนอร์หรือนโยบายที่แสดง และบริบท เช่น ภูมิภาค
จุดแข็ง
- หลักฐานที่คงทน อยู่รอดแม้ล้างคุกกี้และมีข้อจำกัดของเบราว์เซอร์ จึงเป็นเครื่องมือที่เหมาะในการแสดงว่าได้รับความยินยอมแล้ว
- ตรวจสอบได้ คุณสามารถรายงานตัวเลือกตามช่วงเวลาและตอบคำถามเกี่ยวกับเหตุการณ์เฉพาะได้
- ศักยภาพข้ามอุปกรณ์ สำหรับผู้อ่านที่ล็อกอิน บันทึกฝั่งเซิร์ฟเวอร์ซิงก์ตัวเลือกระหว่างอุปกรณ์ได้ หากคุณอธิบายเรื่องนี้ให้พวกเขาทราบ
จุดอ่อน
- ไม่ใช่สิ่งทดแทนสถานะในเครื่อง แท็กในเบราว์เซอร์ยังต้องการสัญญาณในเครื่องที่รวดเร็ว การเรียกเซิร์ฟเวอร์ทุกครั้งที่ดูหน้าเพื่อค้นหาความยินยอมเพิ่มความหน่วง
- ตัวมันเองเป็นข้อมูลส่วนบุคคล บันทึกต้องมีระยะเวลาเก็บรักษา การควบคุมการเข้าถึง และที่ทางในประกาศความเป็นส่วนตัวของคุณ
- พึ่งพาตัวระบุ ผู้เข้าชมนิรนามจับคู่กับบันทึกได้ผ่านตัวระบุที่เก็บในอุปกรณ์ของพวกเขาเท่านั้น ซึ่งพาคุณกลับไปที่การจัดเก็บในเครื่อง
สรุปเทียบกันทีละข้อ
- เหมาะที่สุดสำหรับการจดจำตัวเลือกบนเว็บ: คุกกี้ first-party ควรตั้งโดยเซิร์ฟเวอร์ของคุณด้วยอายุที่คงที่
- เหมาะที่สุดสำหรับข้อมูลการตั้งค่าโดยละเอียดในเบราว์เซอร์: localStorage จับคู่กับคุกกี้ที่เซิร์ฟเวอร์อ่านได้
- เหมาะที่สุดสำหรับการพิสูจน์ตัวเลือก: บันทึกฝั่งเซิร์ฟเวอร์
- ตัวเลือกเดี่ยวที่แย่ที่สุด: พึ่งพา localStorage เพียงอย่างเดียว ซึ่งทำให้เซิร์ฟเวอร์มองไม่เห็นและตัวเลือกเปราะบางในบางเบราว์เซอร์
แนวทางผสมผสานที่ใช้ได้จริง
- เก็บสัญญาณในเครื่องที่เป็นหลัก — เช่น สตริง TCF และบันทึกการตั้งค่าแบบกะทัดรัด — ในคุกกี้ first-party ที่กำหนดขอบเขตที่โดเมนที่ลงทะเบียนของคุณ
- ใช้ localStorage เฉพาะข้อมูลเสริมที่ไม่จำเป็นต้องไปถึงเซิร์ฟเวอร์
- เขียนบันทึกฝั่งเซิร์ฟเวอร์สำหรับแต่ละตัวเลือก รวมเวอร์ชันของแบนเนอร์และนโยบายที่แสดง
- หากตัวเลือกที่เก็บไว้หายไป ให้แสดงแบนเนอร์อีกครั้งแทนที่จะสันนิษฐานคำตอบก่อนหน้า
- กำหนดระยะเวลาสอบถามซ้ำสำหรับตัวเลือกที่เก็บไว้ และบันทึกไว้ในนโยบายของคุณ
การเก็บตัวเลือกความยินยอมของผู้เข้าชมเองโดยทั่วไปถือว่าจำเป็นต่อการให้บริการที่ผู้เข้าชมร้องขอ — การจดจำการตัดสินใจของพวกเขา — แต่ควรตรวจสอบแนวทางที่ใช้ในตลาดหลักของคุณ
ประเด็นสำคัญ
- การจดจำตัวเลือกและการพิสูจน์ตัวเลือกเป็นคนละงานที่ต้องใช้ที่เก็บข้อมูลต่างกัน
- คุกกี้เซิร์ฟเวอร์อ่านได้และแชร์ข้ามซับโดเมนได้ แต่จำกัดด้านขนาด และใน Safari จำกัดอายุเมื่อตั้งโดยสคริปต์
- localStorage ให้พื้นที่ แต่เซิร์ฟเวอร์มองไม่เห็นและเบราว์เซอร์อาจล้างได้
- บันทึกฝั่งเซิร์ฟเวอร์เป็นชั้นหลักฐาน ไม่ใช่สิ่งทดแทนสัญญาณในเครื่อง
- ผสานคุกกี้ first-party ที่ตั้งโดยเซิร์ฟเวอร์ ที่เก็บข้อมูลเบราว์เซอร์แบบเลือกได้ และบันทึกฝั่งเซิร์ฟเวอร์