ตัวอย่างและ Template การจัดหมวดหมู่คุกกี้ สำหรับร้านค้าออนไลน์และ E-commerce

ทีมการตลาดของร้านค้าออนไลน์แห่งหนึ่งเปิดรายงานคุกกี้จาก Browser DevTools แล้วนับได้ 47 รายการ มาจาก Google Analytics, Facebook Pixel, TikTok Pixel, ปลั๊กอินรีวิวสินค้า, ระบบแชท และ Payment Gateway ปนกันหมด โดยไม่มีใครในทีมรู้แน่ชัดว่าตัวไหนจำเป็นต่อการทำงานของเว็บไซต์จริง ๆ และตัวไหนควรรอ Consent ก่อนทำงาน สถานการณ์แบบนี้เกิดซ้ำกับร้านค้าออนไลน์จำนวนมาก เพราะคุกกี้ในเว็บอีคอมเมิร์ซมาจากหลายระบบพร้อมกันและเปลี่ยนแปลงบ่อยตามแคมเปญการตลาด

บทความนี้รวบรวม Template และตัวอย่างการจัดหมวดหมู่คุกกี้ที่ปรับใช้กับร้านค้าออนไลน์ได้จริง ตั้งแต่โครงสร้างเอกสาร ตัวอย่างคุกกี้ตามจุดสัมผัสของลูกค้า ไปจนถึงวิธีปรับ Template ให้เข้ากับแพลตฟอร์มที่ใช้งานอยู่และแคมเปญที่เปลี่ยนไปตามฤดูกาล

โครงสร้าง Template จัดหมวดหมู่คุกกี้สำหรับร้านค้าออนไลน์

Template ที่ใช้งานได้จริงควรมีคอลัมน์ครบตามแนวทาง Cookie Inventory ไม่ใช่แค่รายชื่อคุกกี้กับหมวดหมู่สองคอลัมน์ ตารางต่อไปนี้เป็นโครงสร้างขั้นต่ำที่ทีมอีคอมเมิร์ซควรมีในเอกสารของตัวเอง

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

ตัวอย่างการจัดหมวดหมู่ตามจุดสัมผัสของลูกค้าในร้านค้าออนไลน์

การไล่ตามจุดสัมผัส (Touchpoint) ช่วยให้ไม่พลาดคุกกี้ที่แฝงอยู่ในหน้าเฉพาะทาง เช่น หน้า Checkout ที่มักมีสคริปต์จาก Payment Gateway เพิ่มเข้ามาโดยทีมพัฒนาไม่ได้แจ้งทีมการตลาด

หน้าแรกและหน้าสินค้า

มักพบคุกกี้ Analytics (เช่น _ga, _gid), Pixel โฆษณา (เช่น _fbp, ttp), และคุกกี้จากระบบรีวิวหรือแชทสด ส่วนใหญ่จัดเป็น Analytics หรือ Marketing เพราะไม่ได้จำเป็นต่อการแสดงผลหน้าเว็บ หน้าสินค้ายังมักมีสคริปต์เปรียบเทียบราคาหรือแนะนำสินค้าที่เกี่ยวข้องจากผู้ให้บริการภายนอก ซึ่งต้องตรวจแยกว่าทำงานก่อนผู้ใช้กด Accept หรือไม่

ตะกร้าสินค้าและ Checkout

คุกกี้ที่จดจำสินค้าในตะกร้า (เช่น cart_token) และคุกกี้ที่ป้องกันการโกงในระบบชำระเงินมักจัดเป็น Necessary เพราะเว็บไซต์ทำงานไม่ได้ถ้าขาดคุกกี้เหล่านี้ แต่คุกกี้ Retargeting ที่ยิงพร้อมกันในหน้าเดียวกันไม่ควรถูกจัดรวมเป็น Necessary ไปด้วย หน้านี้ยังเป็นจุดที่ทีมพัฒนามักติดตั้งสคริปต์ของ Payment Gateway หลายเจ้าพร้อมกันเพื่อทดสอบ A/B ทำให้ Template ต้องมีช่องบันทึกว่า Gateway ตัวไหนใช้งานจริงอยู่ในปัจจุบัน

บัญชีสมาชิกและหลังการซื้อ

คุกกี้ Session สำหรับ Login ถือเป็น Necessary ส่วนคุกกี้ที่ใช้แนะนำสินค้าเฉพาะบุคคลหลังการซื้อมักเป็น Marketing หรือ Analytics ขึ้นกับผู้ให้บริการและลักษณะการเก็บข้อมูล หน้าประวัติการสั่งซื้อและหน้าติดตามพัสดุก็ควรตรวจแยกต่างหาก เพราะบางร้านค้าฝังสคริปต์ของบริษัทขนส่งซึ่งอาจตั้งคุกกี้ของตัวเองเพิ่มเติม

ตัวอย่างคุกกี้ที่พบบ่อยในร้านค้าออนไลน์ไทย พร้อมแนวทางจัดหมวด

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

• คุกกี้ระบบตะกร้าและ Session Login มักจัดเป็น Necessary เมื่อจำเป็นต่อการทำธุรกรรม
• คุกกี้เลือกภาษา สกุลเงิน หรือธีมที่ผู้ใช้เลือกเองมักจัดเป็น Functional
• คุกกี้ Google Analytics และเครื่องมือวัดผลพฤติกรรมมักจัดเป็น Analytics
• คุกกี้ Pixel โฆษณาจากแพลตฟอร์มโซเชียลและเครื่องมือ Retargeting มักจัดเป็น Marketing
• คุกกี้จากแชทสดหรือระบบรีวิวขึ้นกับว่าทำงานทันทีหรือรอผู้ใช้เปิดใช้งานฟีเจอร์นั้นก่อน
• คุกกี้จากระบบเปรียบเทียบราคาหรือ Affiliate Tracking มักเป็น Marketing เพราะใช้ระบุแหล่งที่มาของยอดขาย

ปรับ Template ให้ตรงกับแพลตฟอร์มที่ใช้งานจริง

ร้านค้าที่ใช้ Shopify, WooCommerce, LINE OA หรือระบบสั่งทำเฉพาะทางมีจุดที่ต้องเพิ่มในการจัดหมวดหมู่ไม่เหมือนกัน

ร้านบน Shopify มักมีสคริปต์จาก Shopify App Store ติดตั้งเพิ่มโดยทีมการตลาด ซึ่งอาจไม่ผ่านการแจ้งทีมที่ดูแล Consent Banner ทำให้ Template ต้องมีช่องบันทึกชื่อแอปที่ติดตั้งควบคู่กับคุกกี้ที่แอปนั้นสร้างขึ้น ส่วนร้านบน WooCommerce มักผูกกับปลั๊กอินหลายตัวพร้อมกัน การจัดหมวดจึงควรอ้างอิงจากปลั๊กอินแต่ละตัวแยกกัน ไม่รวมเป็นก้อนเดียว เพื่อให้ตรวจสอบย้อนกลับได้เมื่อมีปัญหา ร้านที่ผูกระบบสั่งซื้อผ่าน LINE OA หรือ LINE Shopping ควรตรวจแยกว่าคุกกี้/Identifier ที่เกิดขึ้นในหน้าเว็บกับข้อมูลที่เก็บฝั่ง LINE Platform เป็นคนละชุดกัน และควรอธิบายความแตกต่างนี้ให้ทีมการตลาดเข้าใจตรงกันก่อนเขียน Privacy Policy

จัดการคุกกี้จากแคมเปญชั่วคราวโดยไม่ทำให้ Template ล้าสมัย

ช่วงแคมเปญใหญ่ เช่น 11.11 หรือ 12.12 ทีมการตลาดมักติดตั้ง Pixel หรือสคริปต์ใหม่ชั่วคราวเพื่อวัดผลแคมเปญเฉพาะช่วง แล้วลืมถอดออกหรือลืมอัปเดต Template หลังแคมเปญจบ ทำให้เอกสารไม่ตรงกับสิ่งที่เว็บไซต์ใช้งานจริงในระยะยาว แนวทางที่ช่วยได้คือกำหนดว่าทุกสคริปต์ที่เพิ่มเข้ามาต้องมีวันที่ติดตั้งและ Owner ผู้รับผิดชอบกำกับไว้ใน Template ตั้งแต่แรก และตั้งรอบทบทวนหลังแคมเปญจบทุกครั้งว่าสคริปต์ใดยังใช้งานต่อ สคริปต์ใดควรถอดออกพร้อมปรับหมวดหมู่ในเอกสารให้ตรงกับสถานะปัจจุบัน

เชื่อม Template เข้ากับ Consent Banner และ Google Consent Mode

เมื่อจัดหมวดหมู่เสร็จแล้ว ขั้นตอนถัดไปคือผูกแต่ละหมวดเข้ากับปุ่มใน Consent Banner และตั้งค่า Default Consent State ให้ตรงกับหมวดที่กำหนดไว้ก่อน Tag ยิงจริง จากนั้นจึงทดสอบว่าเมื่อผู้ใช้กด Reject สคริปต์ในหมวด Analytics และ Marketing หยุดทำงานจริงหรือไม่ ผู้ที่เพิ่งเริ่มวางระบบ Consent ควรอ่านรายละเอียดเพิ่มเติมที่ คู่มือการจัดหมวดหมู่คุกกี้สำหรับร้านค้าออนไลน์ ประกอบกับ Template นี้ และถ้าเคยเจอปัญหาว่าจัดหมวดแล้วแต่สคริปต์ยังทำงานผิดที่คาด ควรอ่านต่อที่บทความแก้ปัญหาการจัดหมวดหมู่คุกกี้สำหรับร้านค้าออนไลน์ประกอบกัน

เก็บ Template เป็น Evidence และแชร์ให้ทีมอื่นใช้ต่อ

Template ที่ทำเสร็จแล้วไม่ควรเก็บไว้เฉพาะในเครื่องของคนคนเดียว เพราะเมื่อมีการเปลี่ยนตัวรับผิดชอบหรือเปลี่ยนเอเจนซี ทีมใหม่จะไม่มีข้อมูลตั้งต้นให้ทำงานต่อ แนวทางที่ใช้ได้จริงคือเก็บ Template พร้อมวันที่ปรับปรุงล่าสุดไว้ในระบบกลางที่ทั้งทีมพัฒนา ทีมการตลาด และผู้ดูแล Privacy Policy เข้าถึงได้ พร้อมแนบภาพหน้าจอผลทดสอบ Reject All แต่ละครั้งไว้เป็นหลักฐานประกอบ เพื่อให้ตรวจสอบย้อนหลังได้ว่าเว็บไซต์เคยจัดหมวดหมู่และทดสอบอย่างไรในแต่ละช่วงเวลา เมื่อธุรกิจมีหลายเว็บไซต์หรือหลายแบรนด์ ควรตั้งชื่อไฟล์และเวอร์ชันให้แยกตามเว็บไซต์อย่างชัดเจน ไม่ใช้ Template ไฟล์เดียวปนกันทุกแบรนด์ เพราะแต่ละเว็บไซต์มักมีสคริปต์และแคมเปญที่ไม่เหมือนกัน

เช็กลิสต์ปฏิบัติ

• ดึงรายชื่อคุกกี้ทั้งหมดจากการสแกนจริง ไม่ใช้ Template ของเว็บอื่นโดยไม่ตรวจสอบ
• แยกคุกกี้ตามจุดสัมผัส เช่น หน้าแรก ตะกร้า Checkout และบัญชีสมาชิก
• ระบุ First-party และ Third-party ให้ชัดเจนในทุกแถวของตาราง
• บันทึกชื่อแอปหรือปลั๊กอินที่เป็นต้นทางของคุกกี้แต่ละตัว
• ทดสอบ Reject All จริงผ่าน Network Tab หลังผูก Template เข้ากับ Banner
• กำหนดผู้รับผิดชอบปรับปรุง Template เมื่อเพิ่มแอปหรือแคมเปญใหม่
• ตั้งรอบทบทวน Template หลังจบแคมเปญใหญ่ทุกครั้ง

ข้อผิดพลาดที่พบบ่อย

• คัดลอก Template จากเว็บไซต์อื่นทั้งหมดโดยไม่ปรับตามคุกกี้ที่ตรวจพบจริง
• จัดคุกกี้ Retargeting เป็น Necessary เพราะอยู่ในหน้าเดียวกับตะกร้าสินค้า
• ลืมอัปเดต Template เมื่อทีมการตลาดติดตั้งแอปใหม่จาก App Store
• ไม่แยกคุกกี้ First-party และ Third-party ทำให้ประเมินความเสี่ยงผิดจุด
• ปล่อยให้ Pixel แคมเปญชั่วคราวค้างอยู่ในเว็บไซต์โดยไม่อัปเดตเอกสารหลังแคมเปญจบ

สรุป

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

แหล่งข้อมูลอ้างอิง

• MDN Web Docs — Using HTTP Cookies
• Google Tag Manager — Consent Mode