ข้ามไปเนื้อหาหลัก

First-Party Data คุกกี้​ของ​เว็บ​เอง​ก็​หมด​อายุ​ใน 7 วัน​ได้

อัปเดตล่าสุด 6 ตุลาคม 2569
เวลาอ่านประมาณ 11 นาที
First-Party Data คุกกี้​ของ​เว็บ​เอง​ก็​หมด​อายุ​ใน 7 วัน​ได้

KEY TAKEAWAYS

3 ประเด็น

WebKit ซึ่ง​เป็น​เอน​จิ​นข​อง Safari จำกัด​อายุ​คุกกี้​ถาวร​ที่​สร้าง​ผ่าน document.cookie ไว้​ที่ 7 วัน​ตั้งแต่ ITP 2.1

ข้อ​จำกัด​นี้​ใช้​กับ​คุกกี้​ที่​สคริปต์​บน​เว็บ​ของ​ธุรกิจ​เอง​สร้าง​ด้วย ไม่​ได้​ใช้​เฉพาะ​คุกกี้​บุคคล​ที่​สาม

WebKit อธิบาย​เหตุผล​ว่า​สคริปต์​ติดตาม​ข้าม​เว็บ​เริ่ม​ใช้​โถ​คุกกี้​ของ​เว็บ​เจ้าของ​เอง​เพื่อ​ติดตาม​ผู้​ใช้

ข้อมูล​ที่​ธุรกิจ​คิด​ว่า​เป็น​ของ​ตัว​เอง​จึง​ถูก​จำกัด​ไป​ด้วย เมื่อ​เก็บ​ด้วย​วิธี​เดียว​กับ​สคริปต์​ติดตาม

คุกกี้​ที่​ตั้ง​ผ่าน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์​ไม่​อยู่​ใต้​ข้อ​จำกัด​นี้

และ WebKit แนะนำ​ให้​คุกกี้​ยืนยัน​ตัว​ตน​ตั้ง​ผ่าน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์​พร้อม​ค่า Secure และ HttpOnly

WebKit ITP 2.1 จำกัด​คุกกี้​ที่​สคริปต์​บน​เว็บ​สร้าง​เอง​ไว้ 7 วัน​ใน Safari ข้อมูล​ของ​ตัว​เอง​ส่วน​ไหน​หาย​ได้ และ​ควร​เก็บ​ด้วย​วิธี​ใด​ให้​มั่นคง โดย PHYGITAL AGENCY

ธุรกิจ​ที่​เตรียม​รับ​ยุค​หลัง​คุกกี้​บุคคล​ที่​สาม​หัน​มา​ให้​น้ำ​หนัก​กับ First-Party Data หรือ​ข้อมูล​ที่​เก็บ​จาก​เว็บ​และ​ช่อง​ทาง​ของ​ตัว​เอง แต่​ลูกค้า​เก่า​ที่​กลับ​มา​เว็บ​หลัง​ผ่าน​ไป​สอง​สัปดาห์​อาจ​ถูก​นับ​เป็น​ผู้​เข้า​ชม​ใหม่ ถ้า​เข้า​ผ่าน Safari และ​เว็บ​จำ​ลูกค้า​ด้วย​คุกกี้​ที่​สคริปต์​สร้าง​ขึ้น บท​นี้​อธิบาย​กติกา​ของ Intelligent Tracking Prevention รุ่น 2.1 ใน WebKit ว่า​จำกัด​คุกกี้​แบบ​ไหน เหตุผล​ที่ WebKit ให้​ไว้ และ​ข้อมูล​แบบ​ไหน​ที่​ธุรกิจ​เก็บ​ได้​โดย​ไม่​ต้อง​พึ่ง​อายุ​ของ​คุกกี้ เพื่อ​ให้​ธุรกิจ​วางแผน​เก็บ​ข้อมูล​ของ​ตัว​เอง​ได้​ตรง​กับ​การ​ทำงาน​จริง​ของ​เบราว์เซอร์

กติกา​ใน​บท​นี้​มา​จากบทความ Intelligent Tracking Prevention 2.1 บน​บล็อก​ของ WebKit ที่ John Wilander เผย​แพร่​เมื่อ 21 กุมภาพันธ์ 2019 ข้อความ​ถูก​อ่าน​เมื่อ 27 ก.ย. 2569 WebKit ออก​รุ่น​ปรับปรุง​ของ ITP ต่อ​มา​อีก​หลาย​ครั้ง บท​นี้​อ้าง​เฉพาะ​สิ่ง​ที่​อยู่​ใน​บทความ​รุ่น 2.1 ส่วน​การ​จับ​คู่​ลูกค้า​คน​เดียวกัน​จาก​หลาย​ช่อง​ทาง บท​นี้​ไม่​ได้​ลง​ราย​ละเอียด

หน้า​นี้​ฉบับ​ก่อน​หน้า​พูด​ถึง First-Party Data ใน​ภาพ​กว้าง​โดย​ไม่​ได้​อ้าง​แหล่ง​ใด ฉบับ​นี้​เลือก​เรื่อง​ที่​ทำให้​ข้อมูล​ของ​ตัว​เอง​หาย​ได้​โดย​เจ้าของ​เว็บ​ไม่รู้​ตัว เพราะ​เป็นก​ติ​กา​ที่​ผู้​พัฒนา​เบราว์เซอร์​เขียน​ไว้​ชัด

First-Party Data ไม่​ได้​แปล​ว่า​อยู่​รอด​ทุก​เบราว์เซอร์

คำ​ว่า First-Party หมาย​ถึง​ข้อมูล​ที่​ธุรกิจ​เก็บ​จาก​ช่อง​ทาง​ของ​ตัว​เอง เช่น​เว็บไซต์ ระบบ​สมาชิก หรือ​แอป ต่าง​จาก​ข้อมูล​บุคคล​ที่​สาม​ที่​เก็บ​ผ่าน​โดเมน​ของ​ผู้​ให้​บริการ​ภายนอก แต่​ใน​ทาง​เทคนิค ข้อมูล​ที่​เก็บ​บน​เว็บไซต์​ของ​ธุรกิจ​เอง​ก็​ยัง​ต้อง​พึ่ง​กลไก​ของ​เบราว์เซอร์ เช่น​คุกกี้​ใน​การ​จำ​ว่า​ผู้​เข้า​ชม​คน​นี้​เคย​มา​แล้ว

แผน​ของ Chrome เรื่อง​คุกกี้​บุคคล​ที่​สาม​เปลี่ยน​ไป​หลาย​รอบ ราย​ละเอียด​ว่า​ทำไม​คุกกี้​บุคคล​ที่​สาม​ยัง​ไม่​หาย​ไป​อย่าง​ที่​เคย​คาด อยู่​ในPDPA อัปเดต 2567-2569 คำ​สั่ง​ปรับ 6 เรื่อง กับ​คุกกี้ Chrome บท​นี้​มอง​อีก​ด้าน คือ​คุกกี้​ที่​เว็บ​ของ​ธุรกิจ​สร้าง​เอง​ก็​มี​ข้อ​จำกัด​ใน​เบราว์เซอร์​บาง​ตัว​อยู่​แล้ว

ธุรกิจ​ที่​ลูกค้า​ส่วน​ใหญ่​ใช้ Android ต้อง​สนใจ​เรื่อง​นี้​ไหม

ข้อ​จำกัด​ใน​บท​นี้​เป็น​ของ WebKit ซึ่ง​เป็น​เอน​จิ​นข​อง Safari ธุรกิจ​ควร​เปิด​รายงาน​เบราว์เซอร์​ของ​ผู้​เข้า​ชม​ใน​เครื่อง​มือ​วิเคราะห์​เว็บ​ของ​ตัว​เอง​ก่อน ถ้า​มี​สัดส่วน Safari มาก ข้อ​จำกัด​นี้​กระทบ​ข้อมูล​ของ​ธุรกิจ​โดยตรง ถ้า​มี​น้อย ผลก​ระ​ทบ​ก็​น้อย​ตาม​สัดส่วน การ​ตัดสิน​จาก​ตัวเลข​ของ​เว็บ​ตัว​เอง​แม่น​กว่า​การ​เดา​จาก​ภาพ​รวม​ของ​ตลาด

ITP 2.1 จำกัด​อะไร

บทความ​ของ WebKit อธิบาย​ว่า​คุกกี้​ตั้ง​ได้​สอง​ทาง ทาง​หนึ่ง​ตั้ง​ใน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์ (HTTP response) อีก​ทาง​ตั้ง​ผ่าน document.cookie API ซึ่ง​บาง​ครั้ง​เรียก​ว่า​คุกกี้​ฝั่ง​ไคล​เอน​ต์ ตั้งแต่ ITP 2.1 คุกกี้​ถาวร​ทุก​ตัว​ที่​สร้าง​ผ่าน document.cookie ถูก​จำกัด​อายุ​ไว้​ที่​เจ็ด​วัน

ราย​ละเอียด​การ​ทำงาน​ที่​บทความ​ระบุ

  1. ใช้​เฉพาะ​คุกกี้​ที่​สร้าง​ผ่าน document.cookie
  2. ใช้​ทั้ง​ใน​บริบท​ของ​เว็บ​เจ้าของ​เอง และ​ใน iframe ของ​บุคคล​ที่​สาม
  3. คุกกี้​แบบ session ไม่​ได้​รับ​ผล ยัง​คง​เป็น​คุกกี้​แบบ session ตาม​เดิม
  4. คุกกี้​ถาวร​ที่​ตั้ง​อายุ​ไว้​สั้น​กว่า​เจ็ด​วัน​อยู่​ตาม​อายุ​เดิม

ผล​ใน​ทาง​ปฏิบัติ​คือ เครื่อง​มือ​ที่​จำ​ผู้​เข้า​ชม​ด้วย​คุกกี้​ที่​สคริปต์​สร้าง​บน​หน้า​เว็บ อาจ​จำ​ผู้​เข้า​ชม​ที่​ใช้ Safari ได้​ไม่​เกิน​เจ็ด​วัน​หลัง​การ​ตั้ง​คุกกี้​ครั้ง​ล่าสุด ลูกค้า​ที่​กลับ​มา​หลัง​จาก​นั้น​อาจ​ถูก​นับ​เป็น​ผู้​เข้า​ชม​ใหม่

รายงาน​ผู้​เข้า​ชม​ใหม่​ที่​สูง​ผิด​ปกติ​เกี่ยว​กับ​เรื่อง​นี้​ไหม

อาจ​เกี่ยว ถ้า​เครื่อง​มือ​วิเคราะห์​เว็บ​ที่​ใช้​จำ​ผู้​เข้า​ชม​ด้วย​คุกกี้​ฝั่ง​ไคล​เอน​ต์ และ​ผู้​เข้า​ชม​จำนวน​มาก​ใช้ Safari ลูกค้า​เดิม​ที่​กลับ​มา​ห่าง​กัน​เกิน​เจ็ด​วัน​อาจ​ถูก​นับ​ซ้ำ​เป็น​คน​ใหม่ ธุรกิจ​ตรวจ​ได้​ด้วย​การ​เทียบ​สัดส่วน​ผู้​เข้า​ชม​ใหม่​แยก​ตาม​เบราว์เซอร์ ถ้า Safari สูง​กว่า​เบราว์เซอร์​อื่น​มาก ข้อ​จำกัด​นี้​เป็น​หนึ่ง​ใน​สาเหตุ​ที่​ควร​พิจารณา

ITP 2.1 ออก​มา​กับ Safari รุ่น​ไหน และ​เปลี่ยน​อะไร​อีก

บทความ​เดียวกัน​ของ WebKit ระบุ​ว่า ITP 2.1 อยู่​ใน iOS 12.2 รุ่น​เบตา และ Safari 12.1 บน macOS High Sierra กับ Mojave อีก​เรื่อง​ที่​ประกาศ​พร้อม​กัน​คือ Safari เลิก​รองรับ​สัญญาณ Do Not Track (DNT) ซึ่ง​เป็น​ค่าที่​ผู้​ใช้​เปิด​ใน​เบราว์เซอร์​เพื่อ​ขอ​ให้​เว็บ​ไม่​ติดตาม WebKit ให้​เหตุผล​ว่า​เว็บ​ส่วน​ใหญ่​ไม่​ได้​เปลี่ยน​พฤติกรรม​ตาม​สัญญาณ​นี้ โครงการ DNT ปิด​ไป​โดย​ไม่​ได้​ออก​เป็น​มาตรฐาน และ​สัญญาณ​นี้​กลับ​เพิ่ม​ข้อมูล​ให้​ใช้​ระบุ​ตัว​เบราว์เซอร์ (fingerprinting) ได้​มาก​ขึ้น

เว็บ​ที่​เคย​อ่าน​ค่า DNT เพื่อ​ตัดสิน​ว่า​จะ​ติดตาม​ผู้​เข้า​ชม​หรือ​ไม่ จึง​ไม่​ได้​รับ​ค่า​นี้​จาก Safari ตั้งแต่​รุ่น​นั้น การ​เลือก​ของ​ลูกค้า​เรื่อง​การ​ติดตาม​บน​เว็บ​ของ​ธุรกิจ​ต้อง​มา​จาก​สิ่ง​ที่​ลูกค้า​กด​เลือก​บน​เว็บ​เอง เช่น​แบนเนอร์​ขอ​ความ​ยินยอม

ทำไม WebKit จำกัด​คุกกี้​ของ​เว็บ​เจ้าของ​เอง

บทความ​ของ WebKit ให้​เหตุผล​ไว้​สาม​ด้าน คือ​ความ​เป็น​ส่วน​ตัว ความ​ปลอดภัย และ​ประสิทธิภาพ

  1. ความ​เป็น​ส่วน​ตัว ผู้​ติดตาม​ข้าม​เว็บ​เริ่ม​ใช้​โถ​คุกกี้​ของ​เว็บ​เจ้าของ​เอง​เพื่อ​ติดตาม​ผู้​ใช้​แบบ​ถาวร และ​สคริปต์​ติดตาม​ทุก​ตัว​ที่​ทำงาน​ใน​บริบท​ของ​เว็บ​เจ้าของ​อ่าน​และ​เขียน​ข้อมูล​ของ​กัน​และ​กัน​ได้ บทความ​ยก​ตัวอย่าง​ว่า​ถ้า​เครือ​ข่าย​โซ​เชีย​ล​เขียน​รหัส​ติดตาม​ผู้​ใช้​เป็น​คุกกี้​ของ​เว็บ​ข่าว สคริปต์​วิเคราะห์ สคริปต์​โฆษณา และ​สคริปต์​วิดีโอ​บน​เว็บ​ข่าว​นั้น​ก็​ใช้​รหัส​เดียวกัน​ได้
  2. ความ​ปลอดภัย คุกกี้​ที่​อ่าน​ได้​ผ่าน document.cookie ถูก​ขโมย​ได้​ด้วย​การ​โจมตี​แบบ speculative execution และ cross-site scripting จึง​ไม่​ควร​เก็บ​ข้อมูล​อ่อน​ไหว เช่น​ข้อมูล​ยืนยัน​ตัว​ตน
  3. ประสิทธิภาพ คุกกี้​ถูก​ส่ง​ไป​กับ​ทุก​คำขอ​ที่​เกี่ยวข้อง คุกกี้​จำนวน​มาก​ทำให้​หน้า​โหลด​ช้า และ​บทความ​เล่า​ว่า​ทีม​เคย​ตรวจ​กรณี​ผู้​สมัคร​สมาชิก​เว็บ​ข่าว​ถูก​ออก​จาก​ระบบ​เอง เพราะ​คุกกี้​ของ​ผู้​ติดตาม​มี​มาก​จน​คุกกี้​ล็อกอิน​ของ​เว็บ​ถูก​ดัน​ออก

Verified Partitioned Cache ใน​รุ่น​เดียวกัน​คือ​อะไร

บทความ ITP 2.1 ยัง​ประกาศ​อีก​กลไก​หนึ่ง​ชื่อ verified partitioned cache WebKit อธิบาย​ว่า​เบราว์เซอร์​แยก​แคช​ของ​ทรัพยากร​บุคคล​ที่​สาม​ตาม​เว็บ​เจ้าของ​มา​นาน​แล้ว เพื่อ​ไม่​ให้​ผู้​ติดตาม​ข้าม​เว็บ​ใช้​แคช​ติดตาม​ผู้​ใช้ แต่​งาน​วิจัย​ของ​ทีม​พบ​ว่า​ผู้​ติดตาม​หัน​มา​ใช้​แคช​แบบ​แยก​นี้​ใน​ทาง​ที่​ผิด เมื่อ​แคช​ถูก​สร้าง​ให้​โดเมน​ที่ ITP จัด​ว่า​มี​ความ​สามารถ​ติดตาม​ข้าม​เว็บ แคช​นั้น​จะ​ถูก​ทำ​เครื่องหมาย​ให้​ตรวจ​สอบ และ​หลัง​เจ็ด​วัน​จะ​ถูก​ตรวจ​ก่อน​ใช้​งาน กลไก​นี้​บอก​ว่า​ข้อ​จำกัด​ของ WebKit ไม่​ได้​อยู่​ที่​คุกกี้​อย่าง​เดียว วิธี​เก็บ​ข้อมูล​อื่น​ใน​เบราว์เซอร์​ก็​อยู่​ใน​ขอบเขต​การ​ป้องกัน​ด้วย

ข้อ​นี้​บอก​อะไร​กับ​ธุรกิจ​ที่​ติด​สคริปต์​หลาย​ตัว​บน​เว็บ

สคริปต์​ทุก​ตัว​ที่​ธุรกิจ​ติด​ไว้​บน​เว็บ​ทำงาน​ใน​บริบท​ของ​เว็บ​ธุรกิจ​เอง และ​อ่าน​เขียน​คุกกี้​ของ​เว็บ​ได้ ธุรกิจ​ที่​ติด​สคริปต์​ของ​ผู้​ให้​บริการ​ภายนอก​หลาย​ราย จึง​ควร​รู้​ว่า​แต่ละ​ตัว​เขียน​อะไร​ลง​คุกกี้​ของ​เว็บ​บ้าง ทั้ง​เพื่อ​ความ​เป็น​ส่วน​ตัว​ของ​ลูกค้า และ​เพื่อ​ไม่​ให้​คุกกี้​ที่​เว็บ​ต้อง​ใช้​จริง​ถูก​ดัน​ออก

คุกกี้​แบบ​ไหน​ไม่​ถูก​จำกัด

บทความ​ตอบ​คำถาม​ว่าการ​เปลี่ยนแปลง​นี้​จะ​ทำให้​ผู้​ใช้​หลุด​จาก​ระบบ​หรือ​ไม่​ไว้​ว่า คุกกี้​ยืนยัน​ตัว​ตน​ควร​เป็น Secure และ HttpOnly เพื่อ​ป้องกัน​การ​โจมตี​หลาย​แบบ และ​คุกกี้​ที่​สร้าง​ผ่าน document.cookie ตั้ง​ค่า HttpOnly ไม่​ได้ คุกกี้​ยืนยัน​ตัว​ตน​ที่​ตั้ง​ถูก​วิธี​จึง​ไม่​ควร​ได้​รับ​ผล​จาก​การ​จำกัด​อายุ ถ้า​ได้​รับ​ผล ผู้​พัฒนา​ต้อง​ตั้ง​คุกกี้​ยืนยัน​ตัว​ตน​ผ่าน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์ และ​กำหนด​เป็น Secure และ HttpOnly

คุกกี้ ตั้ง​ผ่าน อยู่​ใต้​การ​จำกัด 7 วัน​ของ ITP 2.1 หรือ​ไม่
คุกกี้​ถาวร​ที่​สคริปต์​บน​หน้า​เว็บ​สร้าง document.cookie อยู่
คุกกี้​ถาวร​ที่​ตั้ง​อายุ​ไว้​น้อย​กว่า 7 วัน document.cookie อยู่​ตาม​อายุ​เดิม​ที่​สั้น​กว่า
คุกกี้​แบบ session document.cookie ไม่​ได้​รับ​ผล
คุกกี้​ที่​เซิร์ฟเวอร์​ตั้ง​ใน​การ​ตอบ​กลับ HTTP response บทความ​จำกัด​เฉพาะ document.cookie

แถว​สุดท้าย​เป็น​เหตุผล​ที่​บาง​ธุรกิจ​ย้าย​การ​ติดตาม​ไป​ทำ​ฝั่ง​เซิร์ฟเวอร์ ข้อดี ข้อ​จำกัด และ​เรื่อง​ความ​ยินยอม​ของ​การ​ติดตาม​ฝั่ง​เซิร์ฟเวอร์ อธิบาย​ไว้​ในServer-Side Tracking คือ​อะไร ย้าย​แท็ก​แล้ว​ยัง​ต้อง​ขอ​ความ​ยินยอม

ข้อมูล​ของ​ตัว​เอง​ที่​ไม่​ต้อง​พึ่ง​คุกกี้

ถ้า​คุกกี้​ที่​สคริปต์​สร้าง​มีอายุ​จำกัด ข้อมูล​ที่​ธุรกิจ​เก็บ​ได้​มั่นคง​กว่า​คือ​ข้อมูล​ที่​ลูกค้า​ให้​ไว้​ผ่าน​การ​เป็น​สมาชิก​หรือ​การ​ทำ​ธุรกรรม ซึ่ง​ผูก​กับ​บัญชี​ของ​ลูกค้า ไม่​ได้​ผูก​กับ​คุกกี้​ใน​เบราว์เซอร์​เครื่อง​ใด​เครื่อง​หนึ่ง

  1. ระบบ​สมาชิก​ที่​ลูกค้า​ล็อกอิน​เอง เมื่อ​ลูกค้า​ล็อกอิน ร้าน​รู้​ว่า​เป็น​ลูกค้า​คน​เดิม​โดย​ไม่​ต้อง​พึ่ง​คุกกี้​ที่​ตั้ง​ไว้​เมื่อ​หลาย​สัปดาห์​ก่อน ตัวอย่าง​ระบบ​สมาชิก​ของ​ร้าน​เล็ก​บน​แพลตฟอร์ม​แชต อยู่​ในสมาชิก​ร้าน​สัตว์​เลี้ยง​บน LINE OA บัตร​แสตมป์​กับ CRM 369 บาท
  2. ประวัติ​คำ​สั่ง​ซื้อ ข้อมูล​ใน​ระบบ​หลัง​ร้าน​ไม่​ขึ้น​กับ​อายุ​คุกกี้​ใน​เบราว์เซอร์
  3. ความ​ยินยอม​ที่​ลูกค้า​ให้​ไว้​ตาม​วัตถุประสงค์ ข้อมูล​ที่​เก็บ​ด้วย​ความ​ยินยอม​ที่​ชัดเจน ใช้​ต่อ​ได้​ตาม​วัตถุประสงค์​นั้น​โดย​ไม่​ต้อง​พึ่ง​การ​ติดตาม​เบื้อง​หลัง

ข้อมูล​กลุ่ม​นี้​ก็​ยัง​เป็น​ข้อมูล​ส่วน​บุคคล​ตาม PDPA ลูกค้า​จึง​มี​สิทธิ​ขอ​ดู ขอลบ หรือ​ขอ​ระงับ​การ​ใช้ ขั้น​ตอน​รับคำ​ขอ​เหล่า​นี้​อธิบาย​ไว้​ในPDPA กับ​การ​ตลาด ลูกค้า​ขอ​ดู ขอลบ ขอ​ระงับ​ข้อมูล​ต้อง​ทำ​อะไร ส่วน​ธุรกิจ​ที่​มี​ข้อมูล​จาก​หลาย​ระบบ​และ​กำลัง​พิจารณา​ระบบ​รวม​ข้อมูล อ่าน​นิยาม​และ​ข้อ​จำกัด​ได้​ในCDP ต่าง​จาก CRM ตาม​นิยาม​ปี 2026 ของ CDP Institute

ทำไม​ข้อมูล​สมาชิก​จึง​มั่นคง​กว่า​ข้อมูล​จาก​คุกกี้

ข้อมูล​สมาชิก​ผูก​กับ​ตัว​ตน​ที่​ลูกค้า​ยืนยัน​เอง​ตอน​ล็อกอิน ขณะ​ที่​ข้อมูล​จาก​คุกกี้​ผูก​กับ​เบราว์เซอร์​ใน​เครื่อง​หนึ่ง ลูกค้า​คน​เดียว​ที่​เปลี่ยน​เครื่อง ล้าง​คุกกี้ หรือ​ใช้​เบราว์เซอร์​ที่​จำกัด​อายุ​คุกกี้ จะ​หาย​จาก​ข้อมูล​คุกกี้​ได้ แต่​ยัง​เป็น​สมาชิก​คน​เดิม​เมื่อ​ล็อกอิน​กลับ​มา ธุรกิจ​จึง​ควร​ออกแบบ​ให้​ลูกค้า​มี​เหตุผล​ที่​อยาก​ล็อกอิน เช่น​แต้ม​สะสม​หรือ​ประวัติการ​สั่ง​ซื้อ​ที่​ดู​ย้อน​หลัง​ได้ และ​ทำให้​การ​ล็อกอิน​ง่าย​พอ​บน​มือ​ถือ เพราะ​ลูกค้า​ที่​ต้อง​จำ​รหัส​ผ่าน​หลาย​ชุด​อาจ​เลือก​ซื้อ​แบบ​ไม่​ล็อกอิน แล้ว​ข้อมูล​ของ​ลูกค้า​คน​นั้น​ก็​กลับ​ไป​พึ่ง​คุกกี้​ใน​เบราว์เซอร์​ตาม​เดิม​เหมือน​ตอน​ที่​ร้าน​ยัง​ไม่มี​ระบบ​สมาชิก

สาม​เรื่อง​ที่​ควร​ตรวจ​ใน​เว็บ​ของ​ตัว​เอง

  1. สัดส่วน​ผู้​เข้า​ชม​ที่​ใช้ Safari ถ้า​สูง ข้อ​จำกัด​ของ​คุกกี้​ฝั่ง​ไคล​เอน​ต์​กระทบ​ข้อมูล​ของ​ธุรกิจ​มาก
  2. รายการ​คุกกี้​และ​สคริปต์​บน​เว็บ แยก​ว่า​คุกกี้​ตัว​ไหน​สคริปต์​สร้าง ตัว​ไหน​เซิร์ฟเวอร์​ตั้ง และ​สคริปต์​ของ​ใคร​เขียน​ลง​คุกกี้​ของ​เว็บ​บ้าง
  3. เหตุผล​ที่​ลูกค้า​จะ​ล็อกอิน ระบบ​สมาชิก​ที่​ไม่มี​ประโยชน์​ให้​ลูกค้า ทำให้​ข้อมูล​ของ​ตัว​เอง​ต้อง​พึ่ง​คุกกี้​ต่อ​ไป

ธุรกิจ​ที่​ตอบ​สาม​เรื่อง​นี้​ได้ จะ​รู้​ว่า​ข้อมูล​ส่วน​ไหน​ของ​ตัว​เอง​มั่นคง และ​ส่วน​ไหน​หาย​ได้​เอง​เมื่อ​ลูกค้า​กลับ​มา​ห่าง​กัน​เกิน​หนึ่ง​สัปดาห์

สรุป

ITP 2.1 ของ WebKit จำกัด​อายุ​คุกกี้​ถาวร​ที่​สร้าง​ผ่าน document.cookie ไว้​ที่​เจ็ด​วัน ทั้ง​ใน​เว็บ​เจ้าของ​เอง​และ​ใน iframe ของ​บุคคล​ที่​สาม โดย​ให้​เหตุผล​ว่า​ผู้​ติดตาม​ข้าม​เว็บ​ใช้​โถ​คุกกี้​ของ​เว็บ​เจ้าของ​เพื่อ​ติดตาม​ผู้​ใช้ คุกกี้​แบบ session ไม่​ได้​รับ​ผล และ​คุกกี้​ยืนยัน​ตัว​ตน​ควร​ตั้ง​ผ่าน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์​แบบ Secure และ HttpOnly First-Party Data ที่​เก็บ​ด้วย​คุกกี้​จาก​สคริปต์​จึง​หาย​ได้​ใน​เบราว์เซอร์​บาง​ตัว ข้อมูล​ที่​มั่นคง​กว่า​คือ​ข้อมูล​ที่​ผูก​กับ​การ​ล็อกอิน​และ​ประวัติการ​ซื้อ​ของ​ลูกค้า

คำถามที่พบบ่อย (FAQ)

บทความ​ของ WebKit จำกัด​คุกกี้​ถาวร​ที่​สร้าง​ผ่าน document.cookie เครื่อง​มือ​ที่​จำ​ผู้​เข้า​ชม​ด้วย​คุกกี้​แบบ​นี้​จึง​ได้​รับ​ผล​ใน Safari ส่วน​เครื่อง​มือ​ที่​ตั้ง​คุกกี้​ผ่าน​เซิร์ฟเวอร์​ใช้​วิธี​ตั้ง​อีก​แบบ ธุรกิจ​ควร​ตรวจ​กับ​ผู้​ให้​บริการ​เครื่อง​มือ​ว่า​คุกกี้​ของ​เครื่อง​มือ​ตั้ง​ด้วย​วิธี​ใด

WebKit อธิบาย​ว่า​คุกกี้​ยืนยัน​ตัว​ตน​ที่​ตั้ง​ผ่าน​การ​ตอบ​กลับ​ของ​เซิร์ฟเวอร์​แบบ Secure และ HttpOnly ไม่​ควร​ได้​รับ​ผล ถ้า​ลูกค้า​หลุด​จาก​ระบบ​หลัง​เจ็ด​วัน​บน Safari เป็น​สัญญาณ​ว่า​คุกกี้​ล็อกอิน​อาจ​ถูก​ตั้ง​ผ่าน​สคริปต์ และ​ผู้​พัฒนา​ควร​ตรวจ

บทความ​ที่​อ้าง​เผย​แพร่​ปี 2019 และ WebKit ปรับปรุง​การ​ป้องกัน​การ​ติดตาม​ต่อ​มา​อีก​หลาย​รอบ บท​นี้​จึง​ใช้ ITP 2.1 เป็น​หลัก​ฐาน​ว่า​ข้อ​จำกัด​ของ​คุกกี้​ฝั่ง​ไคล​เอน​ต์​มี​อยู่ และ​ธุรกิจ​ควร​ตรวจ​บล็อก​ของ WebKit ฉบับ​ล่าสุด​ก่อน​ตัดสิน​ใจ​ทาง​เทคนิค

การ​ย้าย​วิธี​ตั้ง​คุกกี้​ไม่​ได้​ทำให้​หน้าที่​ตาม PDPA หาย​ไป ข้อมูล​ที่​ใช้​ติดตาม​พฤติกรรม​ของ​ลูกค้า​ยัง​เป็น​ข้อมูล​ส่วน​บุคคล และ​ต้อง​มี​ฐาน​ทาง​กฎหมาย​หรือ​ความ​ยินยอม​รองรับ​เหมือน​เดิม

เริ่ม​จาก​ดู​สัดส่วน Safari ใน​รายงาน​ผู้​เข้า​ชม แล้ว​ถาม​ผู้​ดูแล​เว็บ​ว่า​เว็บ​ใช้​คุกกี้​จาก​สคริปต์​ตัว​ไหน​บ้าง จาก​นั้น​จึง​ตัดสิน​ว่า​จะ​ลงทุน​กับ​ระบบ​สมาชิก การ​ตั้ง​คุกกี้​ฝั่ง​เซิร์ฟเวอร์ หรือ​ยัง​ไม่​จำเป็น

PHYGITAL INSIGHT

ฟิจิ⁠ทัล​ตรวจ​คุกกี้​ของ​เว็บ​ลูกค้า​ก่อน​วางแผน​เก็บ​ข้อมูล​ลูกค้า​ทุก​ครั้ง ว่า​คุกกี้​ตัว​ไหน​สร้าง​จาก​สคริปต์ ตัว​ไหน​ตั้ง​จาก​เซิร์ฟเวอร์ และ​สคริปต์​ของ​ใคร​เขียน​อะไร​ลง​ไป​บ้าง รายการ​นี้​บอก​ได้​ว่า​ข้อมูล​ส่วน​ไหน​จะ​หาย​ไป​เอง​ใน​เบราว์เซอร์​บาง​ตัว และ​ส่วน​ไหน​ต้อง​ย้าย​ไป​เก็บ​ใน​ระบบ​ที่​ลูกค้า​ล็อกอิน​เอง บริการ​ทำ​เว็บไซต์​พร้อม​ระบบ​สมาชิก​ของ​ฟิจิ⁠ทัล​ออกแบบ​การ​ล็อกอิน​กับ​คุกกี้​ฝั่ง​เซิร์ฟเวอร์​ให้​ร้าน​จำ​ลูกค้า​ได้​โดย​ไม่​ต้อง​พึ่ง​คุกกี้​ที่​หมด​อายุ​ใน​เจ็ด​วัน

ให้ PHYGITAL AGENCY ช่วยต่อยอดเรื่องนี้สู่ผลลัพธ์จริง

คุกกี้​ที่​สคริปต์​บน​เว็บ​ของ​คุณ​สร้าง​เอง อาจ​อยู่​ใน Safari ได้​เพียง 7 วัน

ทีม PHYGITAL AGENCY ตรวจ​คุกกี้​และ​สคริปต์​บน​เว็บ​ของ​คุณ แล้ว​วาง​ระบบ​สมาชิก​กับ​การ​ตั้ง​คุกกี้​ฝั่ง​เซิร์ฟเวอร์ ให้​ร้าน​จำ​ลูกค้า​ได้​โดย​ไม่​ต้อง​พึ่ง​คุกกี้​ที่​หมด​อายุ​เอง

PARANATH PANARATANA

WRITTEN BY

PARANATH PANARATANA

CHAIRMAN OF PHYGITAL AGENCY

ประธานกรรมการบริษัท ฟิจิทัล เอเจนซี จำกัด มีประสบการณ์ดูแลการตลาดที่ผสานโลกจริงและโลกออนไลน์เข้าด้วยกัน ตลอดจนเป็นที่ปรึกษาในการวินิจฉัยธุรกิจ อีกทั้งยังเคยทำงานในสายวิดีโอโปรดักชั่นและภาพยนตร์ไทยอีกด้วย