10 ข้อผิดพลาดเรื่อง Cookie Consent Banner ที่เอเจนซีและฟรีแลนซ์ทำเว็บไซต์ควรหลีกเลี่ยง

โปรเจกต์ปิดจบไปแล้ว ลูกค้าเซ็นรับงาน แต่สามเดือนต่อมาทีมการตลาดของลูกค้าโทรมาถามว่าทำไมกด "ปฏิเสธทั้งหมด" บน Cookie Banner แล้ว Facebook Pixel ยังยิงอยู่เหมือนเดิม นี่คือสถานการณ์ที่เอเจนซีและฟรีแลนซ์ทำเว็บไซต์เจอบ่อยกว่าที่คิด เพราะ Consent Banner ไม่ใช่แค่ติดสคริปต์ให้ขึ้นป๊อปอัป แต่ต้องทำงานร่วมกับ Tag ทุกตัวบนเว็บไซต์จริง

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

ทำไม Agency ต้องระวังเรื่อง Cookie Consent Banner เป็นพิเศษ

เอเจนซีมักดูแลเว็บไซต์หลายสิบเว็บพร้อมกัน แต่ละเว็บมีทีม Marketing ของลูกค้าเพิ่ม Tag เองผ่าน Google Tag Manager โดยไม่แจ้งทีมพัฒนา ความเสี่ยงจึงไม่ได้อยู่ที่ตอนติดตั้ง Banner ครั้งแรก แต่อยู่ที่การดูแลต่อเนื่องหลังส่งมอบงาน ซึ่งเป็นช่วงที่เอเจนซีมักไม่มีสัญญาดูแลต่อแล้ว

10 ข้อผิดพลาดเรื่อง Cookie Consent Banner ที่ Agency พบบ่อย

ข้อผิดพลาดด้าน Consent UX

1. ทำปุ่ม "ยอมรับทั้งหมด" เด่นกว่าปุ่ม "ปฏิเสธทั้งหมด" อย่างชัดเจน เช่นใช้สีตัดกันเฉพาะปุ่มยอมรับ ทำให้ผู้ใช้เลือกยอมรับเพราะมองเห็นง่ายกว่า ไม่ใช่เพราะตัดสินใจจริง ซึ่งเข้าข่าย Dark Pattern ที่ควรหลีกเลี่ยง

2. จัดหมวด Cookie การตลาดหรือ Cookie วิเคราะห์เป็น "จำเป็น" (Necessary) เพื่อให้ Tag ยังยิงได้แม้ผู้ใช้กดปฏิเสธ ทั้งที่ Cookie จำเป็นควรจำกัดเฉพาะสิ่งที่บริการที่ผู้ใช้ร้องขอต้องพึ่งพาจริง เช่น Login หรือตะกร้าสินค้า

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

ข้อผิดพลาดด้านการบล็อก Script

4. ติด Banner แล้วแต่ไม่ได้ตั้งค่าให้ Tag บล็อกตามการเลือกของผู้ใช้จริง โดยเฉพาะ Script ที่ Hardcode ไว้ในธีมหรือ Header โดยตรงแทนที่จะยิงผ่าน GTM ทำให้ Banner ทำงานเป็นแค่ตัวแสดงผล ไม่ได้ควบคุม Tracking จริง

5. ทดสอบเฉพาะตอน Deploy ครั้งแรก แต่ไม่ทดสอบซ้ำหลัง Reload หน้าเว็บ เปิด Session ใหม่ หรือหลังผู้ใช้เปลี่ยน Preference ภายหลัง ทำให้พลาดกรณีที่ Consent เดิมไม่ถูกจดจำถูกต้อง

6. ไม่ตรวจ Embedded Content เช่น วิดีโอ YouTube หรือแผนที่ Google Maps ที่ฝังในหน้าเว็บ ซึ่งเรียก Third-party Request ได้เองโดยไม่ผ่านการควบคุมของ CMP ถ้าไม่ตั้งค่า Consent Overlay ให้ก่อน

ข้อผิดพลาดด้านการส่งมอบงานและ Ownership

7. ส่งมอบเว็บไซต์โดยไม่บอกลูกค้าว่าใครต้องอัปเดต Cookie Policy และ Banner เมื่อทีม Marketing เพิ่ม Tag ใหม่เอง ทำให้เอกสารกับพฤติกรรมจริงของเว็บไซต์ไม่ตรงกันภายในไม่กี่เดือน

8. ไม่มีเอกสารส่งมอบ (Handover Note) ที่ระบุว่า Cookie หมวดใดถูกจัดไว้อย่างไรและเพราะเหตุใด ทำให้เมื่อเปลี่ยนทีมดูแลเว็บไซต์ในอนาคต ไม่มีใครรู้ที่มาของการตั้งค่าเดิม

ข้อผิดพลาดด้าน Consent Log และหลักฐาน

9. ไม่เก็บ Consent Log หรือเก็บแต่ไม่มี Policy Version และ Banner Version ผูกไว้ด้วย ทำให้ภายหลังตรวจสอบไม่ได้ว่าผู้ใช้เห็นข้อความ Banner แบบไหนตอนที่กดเลือก

10. ใช้ปลั๊กอินฟรีที่ไม่มีการอัปเดตตามการเปลี่ยนแปลงของแพลตฟอร์ม Google Consent Mode แล้วปล่อยไว้โดยไม่ตรวจสอบซ้ำ ทำให้ Modeled Data หรือ Default State ของ Tag ไม่ตรงกับสิ่งที่ตั้งใจไว้ตอนแรก

ผลกระทบต่อ Agency เมื่อเกิดข้อผิดพลาดเหล่านี้

เมื่อ Tag ยังยิงหลังผู้ใช้กดปฏิเสธ ความเสี่ยงไม่ได้ตกอยู่ที่ตัวเอเจนซีโดยตรงในทางกฎหมาย เพราะลูกค้าคือเจ้าของเว็บไซต์และข้อมูล แต่ในทางปฏิบัติ ลูกค้ามักย้อนกลับมาที่เอเจนซีก่อนเสมอเมื่อพบปัญหา และความน่าเชื่อถือของงานที่ส่งมอบก็ถูกตั้งคำถาม โดยเฉพาะถ้าเอเจนซีเคยบอกว่าเว็บไซต์ "พร้อม PDPA" แบบเหมารวมโดยไม่มีขอบเขต

แนวทางป้องกันในกระบวนการทำงานของ Agency

กำหนดขั้นตอน Cookie Audit เป็นส่วนหนึ่งของ QA ก่อนส่งมอบทุกโปรเจกต์ ไม่ใช่แค่เช็กว่า Banner ขึ้นหรือไม่ ทดสอบการกดปฏิเสธจริงด้วย Developer Tools แล้วดูว่า Network Request ของ Tag การตลาดหยุดยิงจริงหรือไม่ และเขียนเอกสารส่งมอบที่ระบุ Owner ของ Banner หลังจบโปรเจกต์อย่างชัดเจน รวมถึงตกลงล่วงหน้ากับลูกค้าว่าใครต้องแจ้งเมื่อมีการเพิ่ม Tag ใหม่ในอนาคต

เครื่องมือสแกนอัตโนมัติช่วยได้แค่ไหน และตรวจไม่ถึงจุดไหนบ้าง

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

สิ่งที่เครื่องมืออัตโนมัติทำได้ดี

สแกนหลายหน้าพร้อมกันได้เร็ว ตรวจพบ Cookie ที่โหลดตั้งแต่ Landing Page แรกโดยไม่ต้องคลิกอะไรเพิ่ม และสรุปรายชื่อโดเมนปลายทางที่ Cookie แต่ละตัวส่งข้อมูลไป ซึ่งช่วยให้ทีมเห็นภาพรวมก่อนเริ่มจัดหมวดหมู่ได้เร็วขึ้นมาก โดยเฉพาะเว็บไซต์ที่ไม่เคยทำ Cookie Audit มาก่อนเลย

สิ่งที่เครื่องมืออัตโนมัติตรวจไม่ถึง

เครื่องมือส่วนใหญ่ไม่ได้จำลองพฤติกรรมผู้ใช้จริง เช่น การกดปฏิเสธแล้วเปลี่ยนหน้า การเข้าสู่ระบบสมาชิก หรือการกรอกฟอร์มระหว่างทาง จึงมองไม่เห็น Cookie ที่ยิงเฉพาะบางเส้นทางการใช้งาน และไม่สามารถบอกได้ว่า Banner ที่ขึ้นมานั้นบล็อก Tag ตามที่ผู้ใช้เลือกจริงหรือไม่ เอเจนซีที่พึ่งพาผลสแกนอัตโนมัติเพียงอย่างเดียวโดยไม่ทดสอบมือซ้ำ มักพลาดกรณี Script ที่ Hardcode ไว้ในธีมตามที่กล่าวไปข้างต้น ดังนั้นผลสแกนอัตโนมัติควรใช้เป็นจุดเริ่มต้นของการตรวจ ไม่ใช่ขั้นตอนสุดท้ายที่ใช้ปิดงาน

เมื่อโปรเจกต์มี Subcontractor หรือ Freelance ร่วมทีม ความเสี่ยงเพิ่มขึ้นตรงไหน

งานเว็บไซต์ขนาดใหญ่ที่เอเจนซีรับมาบางส่วนถูกส่งต่อให้ Freelance หรือทีมภายนอกทำในบางโมดูล เช่น ระบบ Booking หรือ Live Chat ทีมเหล่านี้มักติดตั้ง Script ของตัวเองโดยไม่รู้ว่าเว็บไซต์มี Consent Banner ควบคุมอยู่แล้ว ผลคือ Tag ใหม่จาก Subcontractor ยิงได้ทันทีโดยไม่ผ่านการตรวจสอบ Consent เพราะไม่ได้อยู่ในขอบเขตงาน ที่ทีมหลักรับผิดชอบตรวจสอบ เอเจนซีที่บริหารโปรเจกต์ลักษณะนี้ควรระบุในสัญญาว่างานส่วนใดต้องแจ้งทีมดูแล Consent ก่อนติดตั้ง Script ใด ๆ ไม่ว่าจะดูเล็กน้อยแค่ไหน และควรมีขั้นตอนตรวจรับงานจาก Subcontractor ที่รวมการทดสอบ Script Blocking เป็นหนึ่งในเงื่อนไขก่อนปิดงานทุกครั้ง ไม่ใช่ตรวจแค่ว่าฟีเจอร์ที่จ้างทำงานได้ตามสเปกเท่านั้น

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

• ทดสอบ Reject All ด้วย Developer Tools แล้วยืนยันว่า Network Request ของ Tag การตลาดหยุดยิงจริง
• ตรวจ Script ที่ Hardcode ในธีมหรือ Header แยกจาก Tag ที่ยิงผ่าน GTM
• ตรวจ Embedded Content เช่นวิดีโอและแผนที่ว่ามี Consent Overlay ก่อนโหลดหรือไม่
• เขียนเอกสารส่งมอบระบุ Owner ของ Banner และ Cookie Policy หลังจบโปรเจกต์
• ผูก Consent Log กับ Policy Version และ Banner Version ทุกครั้ง
• ตกลงกับลูกค้าล่วงหน้าว่าใครแจ้งเมื่อทีม Marketing เพิ่ม Tag ใหม่
• ทดสอบซ้ำหลัง Reload หน้าเว็บและหลังเปิด Session ใหม่ ไม่ใช่แค่ตอน Deploy ครั้งแรก

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

• ทำปุ่มยอมรับเด่นกว่าปุ่มปฏิเสธจนกลายเป็น Dark Pattern
• จัดหมวด Cookie การตลาดเป็น Necessary เพื่อให้ Tag ยังยิงได้เสมอ
• ติด Banner แต่ไม่ได้ตั้งค่าบล็อก Tag ตามการเลือกของผู้ใช้จริง
• ส่งมอบงานโดยไม่ระบุ Owner ของ Banner และ Cookie Policy ในอนาคต
• ไม่เก็บ Consent Log ผูกกับ Policy Version และ Banner Version

สรุป

Cookie Consent Banner ที่ดูเหมือนใช้งานได้ตอนส่งมอบ อาจไม่ได้ทำงานถูกต้องจริงเมื่อทดสอบเจาะลึกด้วย Developer Tools ทั้ง 10 ข้อผิดพลาดข้างต้นส่วนใหญ่เกิดจากการทดสอบไม่ครบและไม่มีเจ้าของดูแลต่อหลังส่งมอบ เอเจนซีที่วางขั้นตอน QA และเอกสารส่งมอบที่ชัดเจนจะลดความเสี่ยงเหล่านี้ได้มาก

ดูแนวทางที่แนะนำเพิ่มเติมได้ที่ Best Practices Cookie Consent Banner สำหรับ Agency และภาพรวมทั้งหมวดที่ หมวด Cookies & Consent

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• Google Tag Platform — Consent overview