Best Practices ปุ่ม Reject All สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์

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

ปุ่ม Reject All คืออะไร และทำไม Agency ต้องรับผิดชอบมากกว่าที่คิด

ปุ่ม Reject All คือทางเลือกที่ต้องกดง่ายเท่ากับปุ่ม Accept All ไม่ใช่ซ่อนอยู่หลังลิงก์เล็ก ๆ หรือกดหลายขั้นตอนกว่า สำหรับเอเจนซีที่ดูแลเว็บหลายราย ความเสี่ยงคือ Config เดียวที่เคยใช้ได้กับลูกค้า A อาจใช้ไม่ได้กับลูกค้า B เพราะ B มี Plugin การตลาดที่ยิง Tag แบบ Hardcode ไว้ในธีม ทำให้แม้ผู้ใช้กด Reject All แล้ว Script นั้นก็ยังทำงานอยู่ดี

ใครเป็นเจ้าของงานนี้ระหว่าง Agency กับลูกค้า

ก่อนเริ่มงาน ควรตกลงเป็นลายลักษณ์อักษรว่าเอเจนซีรับผิดชอบส่วนใดของ Reject All เช่น การติดตั้ง Consent Platform, การตั้งค่า Banner, และการทดสอบ Script Blocking เบื้องต้น ส่วนใดที่ต้องให้ลูกค้าตัดสินใจเอง เช่น การเลือกฐานทางกฎหมายสำหรับการเก็บข้อมูลแต่ละประเภท หรือการอนุมัติข้อความในนโยบายความเป็นส่วนตัว ความชัดเจนตรงนี้ป้องกันสถานการณ์ที่ลูกค้าคิดว่าเอเจนซี "ทำให้ครบแล้ว" ทั้งที่จริงมีบางส่วนที่ยังรอการตัดสินใจจากฝั่งลูกค้า สำหรับฟรีแลนซ์ที่รับงานคนเดียวโดยไม่มีทีมกฎหมายสนับสนุน การเขียนขอบเขตงานให้ชัดยิ่งจำเป็นกว่าเดิม เพราะเมื่อเกิดปัญหาภายหลัง เช่น ลูกค้าถูกร้องเรียนเรื่อง Cookie ฟรีแลนซ์คนเดียวมักไม่มีทีมช่วยตอบคำถามเชิงกฎหมาย การระบุไว้ล่วงหน้าว่าให้บริการเฉพาะด้านเทคนิคจึงเป็นเกราะป้องกันความเข้าใจผิดที่จำเป็น ไม่ใช่แค่รายละเอียดเล็กน้อยในสัญญา

ข้อจำกัดของแต่ละ CMS/Platform ที่ Agency เจอบ่อย

WordPress: Plugin และ Theme ที่ Hardcode Script ไว้

เว็บ WordPress จำนวนมากมี Plugin การตลาดที่ฝัง Pixel ไว้ในหน้า Header โดยตรง ไม่ผ่าน Tag Manager ทำให้ Consent Platform ที่ติดตั้งแยกต่างหากไม่สามารถควบคุม Script เหล่านั้นได้ เอเจนซีต้องตรวจ Source Code ของ Theme และ Plugin ที่ใช้งานอยู่ ไม่ใช่เชื่อว่าแค่ติด Consent Platform แล้วจะครอบคลุมทุก Script อัตโนมัติ

Shopify: ข้อจำกัดของ App และ Checkout

หน้า Checkout ของ Shopify มีข้อจำกัดด้าน Custom Script ที่ทำได้ตาม Plan ของร้าน และ App บางตัวยิง Customer Event โดยไม่ผ่าน Consent Layer ที่เอเจนซีติดตั้งไว้ จึงต้องตรวจแยกว่า App ตัวไหนเคารพการตั้งค่า Consent และตัวไหนไม่เคารพ ก่อนสรุปกับลูกค้าว่าระบบพร้อมใช้งาน

Webflow และ Website Builder อื่น: ข้อจำกัดด้าน Custom Code

บาง Plan ของ Website Builder จำกัดจำนวนจุดที่ใส่ Custom Code ได้ ทำให้การฝัง Consent Script ต้องวางแผนตำแหน่งให้ครอบคลุมทั้งเว็บตั้งแต่ต้น ไม่ใช่ค่อยแก้ทีละหน้าเมื่อพบว่า Script หลุด

ธีมและ Page Builder ที่เปลี่ยนบ่อยตามฤดูกาลโปรโมชัน

ลูกค้าหลายรายของเอเจนซีเปลี่ยนหน้า Landing Page ตามแคมเปญโปรโมชันบ่อย และมักใช้ Page Builder สร้างหน้าใหม่โดยไม่ผ่านทีมพัฒนา ทำให้ Script การตลาดที่แปะมากับ Block สำเร็จรูปของ Page Builder หลุดจากการควบคุมของ Consent Platform ได้ง่าย เอเจนซีที่ดูแลระยะยาวควรตกลงกับลูกค้าว่าเมื่อมีการสร้างหน้าใหม่ด้วย Page Builder ต้องมีขั้นตอนตรวจ Script ก่อน Publish เสมอ ไม่ใช่ปล่อยให้ทีมการตลาดของลูกค้าเผยแพร่เองโดยไม่มีการตรวจสอบ

เมื่อไรที่ Agency ควรปฏิเสธงานหรือส่งต่อให้ผู้เชี่ยวชาญ

บางเว็บไซต์ลูกค้ามีความซับซ้อนเกินขอบเขตที่เอเจนซีรับได้ เช่น มีการเชื่อมข้อมูลข้ามหลายระบบหลังบ้าน หรือมีข้อมูลอ่อนไหวอย่างข้อมูลสุขภาพที่ต้องมีทนายหรือ DPO ร่วมตัดสินใจเรื่องฐานทางกฎหมาย ในกรณีนี้เอเจนซีควรระบุในข้อเสนอโครงการตั้งแต่ต้นว่าให้บริการเฉพาะการติดตั้งและทดสอบ Reject All ทางเทคนิค ส่วนการตัดสินใจเชิงนโยบายที่ซับซ้อนต้องส่งต่อให้ผู้เชี่ยวชาญด้านกฎหมายของลูกค้าเอง

สิ่งที่ควรอยู่ใน Client Report กับสิ่งที่ต้องให้ลูกค้าตัดสินใจเอง

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

มาตรฐาน UX ที่ปุ่ม Reject All ต้องมีไม่ว่าจะติดตั้งให้ลูกค้ารายใด

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

การจัดการ Handover เมื่อเปลี่ยนทีมดูแลหรือส่งมอบงานให้ทีมลูกค้า

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

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

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

ใช้ Config เดียวกันกับลูกค้าหลายรายได้หรือไม่ ใช้เป็นจุดตั้งต้นได้ แต่ต้องตรวจ Script และ Plugin ของแต่ละเว็บแยกกันเสมอ เพราะ Theme หรือ App ที่ต่างกันอาจทำให้ Script บางตัวไม่ถูกควบคุมโดย Consent Platform แม้ตั้งค่าเหมือนกันทุกอย่าง

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

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

• ทำสัญญาหรือ Scope of Work ที่ระบุชัดว่า Agency รับผิดชอบส่วนใดของ Reject All และส่วนใดเป็นของลูกค้า
• ตรวจ Theme และ Plugin ของแต่ละเว็บลูกค้าแยกกัน ไม่เชื่อว่า Config เดิมจะครอบคลุมทุกกรณี
• ทดสอบ Script Blocking หลังกด Reject All บนแต่ละเว็บก่อนส่งมอบงาน
• บันทึกข้อจำกัดของ CMS/Platform ที่พบระหว่างติดตั้งไว้เป็นเอกสารอ้างอิงสำหรับลูกค้ารายถัดไปที่ใช้ Platform เดียวกัน
• ทำ Client Report แยกส่วน "ทดสอบแล้ว" กับ "ต้องให้ลูกค้าตัดสินใจ" ให้ชัดเจน
• ตรวจว่าปุ่ม Reject All มีน้ำหนักภาพเท่ากับปุ่ม Accept All ก่อนส่งมอบทุกครั้ง

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

• ใช้ Config เดียวกับลูกค้าทุกรายโดยไม่ตรวจ Plugin หรือ Theme ที่ต่างกัน
• ไม่มีเอกสารแบ่งความรับผิดชอบ ทำให้ลูกค้าคาดหวังว่าเอเจนซีรับผิดชอบด้านกฎหมายทั้งหมด
• ทดสอบ Reject All แค่ครั้งเดียวตอนส่งมอบ ไม่ได้ทดสอบซ้ำหลังลูกค้าเปลี่ยน Plugin ภายหลัง
• เขียนรายงานยืนยันว่าเว็บไซต์ปฏิบัติตามกฎหมายครบทุกด้านทั้งที่ตรวจได้แค่ Script ฝั่งหน้าเว็บ
• ปล่อยให้ปุ่ม Reject All ดูด้อยกว่าปุ่ม Accept All ในบาง Template ที่ลูกค้าเลือกเอง

สรุป

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

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

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