10 ข้อผิดพลาดเรื่องปุ่ม Reject All ที่เอเจนซีและฟรีแลนซ์ควรหลีกเลี่ยง

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

ทำไม Agency มีความเสี่ยงเรื่องปุ่ม Reject All มากกว่าเจ้าของเว็บไซต์เดี่ยว

เจ้าของเว็บไซต์เดี่ยวมักรู้จักเว็บของตัวเองดีและสังเกตความผิดปกติได้เร็ว แต่เอเจนซีทำงานกับ Stack ที่หลากหลาย ลูกค้าแต่ละรายเลือก Plugin, App และ Theme ต่างกัน เมื่อใช้ Template Config เดียวเป็นจุดตั้งต้นให้ทุกโปรเจกต์ ความเสี่ยงคือสมมติฐานที่ใช้ได้กับลูกค้ารายแรกอาจไม่จริงกับลูกค้ารายที่สิบ และเมื่อไม่มีระบบติดตามว่าเว็บไหนติดตั้งไปแล้วเมื่อไหร่ การพังจึงถูกพบช้ากว่าที่ควร

ข้อผิดพลาดด้านเทคนิคที่ Agency ทำซ้ำในหลายเว็บไซต์ลูกค้า

Theme หรือ Plugin เปลี่ยนแล้ว Reject All ใช้ไม่ได้แต่ไม่มีใครรู้

ลูกค้าจำนวนมากอัปเดต Theme หรือติดตั้ง Plugin ใหม่เองหลังเอเจนซีส่งมอบงานไปแล้ว โดยไม่แจ้งเอเจนซี Plugin การตลาดตัวใหม่อาจฝัง Script ที่ไม่ผ่าน Consent Gate เดิม ทำให้ Reject All ที่เคยทำงานถูกต้องกลายเป็นใช้ไม่ได้ทันทีที่มีการเปลี่ยนแปลง และเนื่องจากเอเจนซีไม่ได้ Monitor เว็บของลูกค้าต่อเนื่อง ปัญหานี้จึงอาจอยู่นานหลายเดือนกว่าจะถูกพบ

Copy Config ข้ามลูกค้าโดยไม่ตรวจ Script ของแต่ละเว็บ

การใช้ Template เดียวกันเป็นจุดตั้งต้นเป็นเรื่องปกติของงานเอเจนซี แต่ข้อผิดพลาดเกิดเมื่อทีมไม่ตรวจ Script เฉพาะของแต่ละเว็บก่อนใช้ Template นั้น เช่น ลูกค้ารายหนึ่งมี Live Chat Widget ที่ฝัง Cookie ของตัวเอง หากไม่เพิ่มการควบคุมให้ครอบคลุม Widget นี้ Reject All จะบล็อกได้เฉพาะ Script ที่อยู่ใน Template มาตรฐาน ไม่ครอบคลุม Script เฉพาะของเว็บนั้น

ทดสอบบน Desktop อย่างเดียวโดยไม่ตรวจ Mobile

Banner ที่แสดงปุ่ม Reject All ชัดเจนบน Desktop อาจถูกบีบจนซ่อนอยู่ใต้การเลื่อนหน้าจอบน Mobile โดยเฉพาะ Theme ที่ไม่ได้ออกแบบมาสำหรับ Responsive Banner ตั้งแต่ต้น เอเจนซีที่ทดสอบเฉพาะหน้าจอใหญ่ตอนส่งมอบมักไม่พบปัญหานี้จนกว่าจะมีลูกค้าโทรมาแจ้ง

ข้อผิดพลาดด้านสัญญาและความรับผิดชอบ

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

ข้อผิดพลาดด้านการรายงานลูกค้า

อีกรูปแบบที่พบบ่อยคือทีมขายหรือ Project Manager แจ้งลูกค้าว่า "ติดตั้ง Reject All เรียบร้อยแล้ว" ทันทีที่ Consent Platform ปรากฏบนหน้าเว็บ โดยยังไม่ได้ทดสอบว่า Script ทุกตัวถูกบล็อกจริงหลังกด Reject All รายงานที่ส่งลูกค้าจึงกลายเป็นการยืนยันสิ่งที่ยังไม่ได้ตรวจสอบ ซึ่งต่างจากการรายงานว่าทดสอบ Script ใดแล้วบ้างและพบปัญหาอะไรบ้าง

ข้อผิดพลาดด้านการดูแลต่อเนื่อง

เมื่อโปรเจกต์จบและไม่มีสัญญาดูแลต่อเนื่อง เอเจนซีมักไม่มีช่องทางรู้ว่าลูกค้าเพิ่ม Tag ใหม่ผ่าน Google Tag Manager ภายหลังหรือไม่ Tag ใหม่ที่ลูกค้าเพิ่มเองโดยไม่ผ่าน Consent Gate จะทำให้ Reject All ที่เคยครอบคลุมครบกลายเป็นไม่ครบทันที และเอเจนซีจะไม่รู้จนกว่าจะถูกจ้างกลับมาตรวจใหม่

ข้อผิดพลาดด้านการส่งต่องานระหว่างทีมภายในเอเจนซีเอง

อีกจุดที่มักถูกมองข้ามคือการส่งต่องานระหว่างพนักงานภายในเอเจนซีเอง เมื่อคนที่ตั้งค่า Consent Platform ให้ลูกค้ารายหนึ่งลาออกหรือย้ายทีม แต่ไม่มีเอกสารบันทึกไว้ว่าตั้งค่าอะไรไปบ้าง คนที่เข้ามาดูแลต่อจะไม่รู้ว่าทำไม Config บางจุดถึงตั้งไว้แบบนั้น และอาจแก้ไขโดยไม่ตั้งใจจนปุ่ม Reject All หยุดทำงานถูกต้อง การทำเอกสารบันทึกการตั้งค่าไว้เป็นมาตรฐานภายในทีมจึงสำคัญไม่น้อยไปกว่าการทดสอบกับลูกค้า

ข้อผิดพลาดด้านการใช้ Testing Account ที่ไม่ตรงกับผู้ใช้จริง

ทีมเอเจนซีบางทีมทดสอบ Reject All ด้วยบัญชี Admin หรือเบราว์เซอร์ที่เคยตั้งค่า Consent ไว้ก่อนหน้าแล้ว ทำให้ผลทดสอบดูเหมือนใช้งานได้ปกติ ทั้งที่ผู้ใช้ใหม่ที่ไม่เคยตั้งค่ามาก่อนอาจเจอปัญหาต่างออกไป การทดสอบที่แม่นยำต้องใช้ Browser แบบ Incognito หรือ Session ใหม่ทุกครั้งเพื่อจำลองพฤติกรรมของผู้ใช้จริงที่เข้าเว็บครั้งแรก

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

ทำไม Reject All ที่เอเจนซีติดตั้งไว้ถึงใช้ไม่ได้หลังผ่านไปหลายเดือน สาเหตุที่พบบ่อยที่สุดคือลูกค้าเปลี่ยน Theme หรือติดตั้ง Plugin ใหม่เองโดยไม่แจ้งเอเจนซี ทำให้มี Script ใหม่ที่ไม่ผ่านการควบคุมของ Consent Platform เดิม การมีสัญญาดูแลต่อเนื่องช่วยลดความเสี่ยงนี้ได้

Copy Config จากลูกค้ารายอื่นมาใช้ได้เลยหรือไม่ ใช้เป็นจุดตั้งต้นได้แต่ต้องตรวจ Script เฉพาะของเว็บนั้นก่อนเสมอ เพราะ Widget หรือ App ที่ลูกค้าใช้อาจฝัง Cookie เฉพาะตัวที่ Template มาตรฐานไม่ครอบคลุม

เอเจนซีควรรายงานผลอย่างไรให้ไม่เกิดความเข้าใจผิดกับลูกค้า ควรระบุรายการ Script ที่ทดสอบแล้วว่าถูกบล็อกจริงหลังกด Reject All และ Script ใดยังพบปัญหา แทนการสรุปกว้าง ๆ ว่าติดตั้งเสร็จแล้วโดยไม่มีรายละเอียดการทดสอบ

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

• ทำรายการเว็บไซต์ลูกค้าทั้งหมดที่ติดตั้ง Consent Platform ไว้ พร้อมวันที่ทดสอบล่าสุด
• ตรวจ Script เฉพาะของแต่ละเว็บก่อนใช้ Template Config เดิมซ้ำ
• ทดสอบปุ่ม Reject All ทั้งบน Desktop และ Mobile ก่อนส่งมอบทุกครั้ง
• ทำสัญญาระบุขอบเขตความรับผิดชอบด้านเทคนิคแยกจากการตัดสินใจเชิงกฎหมาย
• เสนอแพ็กเกจดูแลต่อเนื่องเพื่อรับรู้เมื่อลูกค้าเพิ่ม Tag ใหม่ภายหลัง
• รายงานผลลูกค้าด้วยรายการ Script ที่ทดสอบจริง ไม่ใช้คำสรุปกว้าง ๆ

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

• ปล่อยให้ Theme หรือ Plugin ของลูกค้าเปลี่ยนแปลงโดยไม่มีการตรวจ Reject All ซ้ำ
• Copy Config ข้ามลูกค้าโดยไม่ตรวจ Script เฉพาะของแต่ละเว็บ
• ทดสอบ Reject All บน Desktop อย่างเดียวโดยไม่ตรวจ Mobile
• ไม่มีสัญญาระบุขอบเขตความรับผิดชอบ ทำให้ลูกค้าคาดหวังเกินสิ่งที่เอเจนซีตรวจได้จริง
• รายงานลูกค้าว่าติดตั้งเสร็จแล้วทั้งที่ยังไม่ได้ทดสอบว่า Script ถูกบล็อกจริง

สรุป

ข้อผิดพลาดเรื่องปุ่ม Reject All ของเอเจนซีส่วนใหญ่ไม่ได้เกิดจากขาดความรู้เทคนิค แต่เกิดจากสเกลของงานหลายเว็บพร้อมกันที่ไม่มีระบบติดตามและทดสอบซ้ำ การทำรายการลูกค้า ตรวจ Script เฉพาะเว็บ และเสนอแพ็กเกจดูแลต่อเนื่องช่วยลดความเสี่ยงเหล่านี้ได้ ดูเพิ่มเติมที่ แนวทางออกแบบปุ่ม Reject All และ โครงสร้าง Cookie Consent Banner

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• OWASP Cheat Sheet Series