เช็กลิสต์ ปุ่ม Reject All สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

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

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

ทำไมเช็กลิสต์นี้ต้องอยู่ในขั้นตอนส่งมอบงานของเอเจนซี

เอเจนซีและฟรีแลนซ์ที่ดูแลเว็บไซต์หลายสิบโปรเจกต์พร้อมกัน มักใช้เทมเพลต Consent Banner ชุดเดียวกันข้ามลูกค้าเพื่อความเร็ว แต่ปัญหาคือแต่ละโปรเจกต์มีการติดตั้งสคริปต์วิเคราะห์และโฆษณาต่างกัน บางเว็บใช้ Google Tag Manager บางเว็บฝังสคริปต์ตรงในธีม WordPress บางเว็บใช้ Webflow ที่ฝัง embed code แยกจากตัวจัดการคุกกี้หลัก ปุ่ม Reject All ที่ทำงานถูกต้องบนเว็บลูกค้ารายหนึ่งจึงไม่ได้แปลว่าจะทำงานถูกต้องกับลูกค้ารายถัดไปโดยอัตโนมัติ

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

เตรียมความพร้อมก่อนเริ่มตรวจ

ก่อนไล่เช็กลิสต์ ให้รวบรวมข้อมูลสามอย่างจากโปรเจกต์ที่กำลังจะส่งมอบ ได้แก่ รายชื่อโดเมนและ subdomain ทั้งหมดที่อยู่ในสโคปงาน (เว็บหลัก เว็บ blog แยก subdomain หน้า landing page แคมเปญ) รายการเครื่องมือที่ใช้จัดการ Consent Banner (ปลั๊กอินสำเร็จรูป, Google Tag Manager, หรือโค้ดที่พัฒนาเอง) และรายการสคริปต์บุคคลที่สามทั้งหมดที่ลูกค้าขอให้ติดตั้ง เช่น Facebook Pixel, Google Ads, เครื่องมือ heatmap หรือ live chat

คำถามที่ทีมต้องตอบได้ก่อนเริ่มตรวจ

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

เช็กลิสต์เดียวกัน แต่ปรับตามแพลตฟอร์มที่ลูกค้าใช้จริง

งานเอเจนซีมักไม่ได้ใช้ stack เดียวกันทุกโปรเจกต์ ลูกค้าที่ใช้ WordPress อาจพึ่งปลั๊กอินจัดการคุกกี้ที่ผูกกับ Google Tag Manager อยู่แล้ว ขณะที่ลูกค้าที่ใช้ Webflow หรือ Shopify มักต้องฝัง embed code ของ CMP แยกจากตัวธีม และบางโปรเจกต์ที่ทีมพัฒนาเขียนเว็บเองทั้งหมดจะไม่มีปลั๊กอินให้พึ่งพาเลย ทำให้ทุกจุดต้องผูกด้วยมือ ก่อนไล่เช็กลิสต์ ให้ระบุในเอกสารเตรียมงานว่าโปรเจกต์นี้อยู่ในกลุ่มไหน เพราะจุดที่มักหลุดของแต่ละกลุ่มต่างกัน กลุ่ม WordPress มักหลุดตรงปลั๊กอินเสริมที่ทีมการตลาดติดตั้งเพิ่มภายหลังโดยไม่ผ่านนักพัฒนา กลุ่ม Webflow/Shopify มักหลุดตรง embed code ที่ไม่ได้อัปเดตตามเวอร์ชันของ CMP หลัก และกลุ่มที่เขียนเองมักหลุดตรงสคริปต์ที่ฝังตรงในโค้ดโดยไม่ผ่านตัวจัดการคุกกี้กลางเลย

เช็กลิสต์ปุ่ม Reject All ก่อนเปิดใช้งานจริง

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

1. สคริปต์นอกหมวดจำเป็นต้องไม่โหลดก่อนได้รับความยินยอม

เปิด network tab ของเบราว์เซอร์บนเว็บที่ยังไม่ได้กดอะไรเลย แล้วไล่ดูว่ามี request ไปยัง Facebook Pixel, Google Ads, หรือสคริปต์วิเคราะห์พฤติกรรมยิงออกไปหรือไม่ ถ้ามี แปลว่าการตั้งค่า default-off ยังไม่ทำงาน แม้หน้าตั้งค่าคุกกี้จะเขียนไว้ว่าปิดโดยค่าเริ่มต้านก็ตาม

2. กดปุ่ม Reject All แล้วสคริปต์ต้องหยุดทำงานจริง

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

3. ทดสอบทุกโดเมนและ subdomain ในสโคปงาน ไม่ใช่แค่หน้าแรก

เว็บบล็อกที่แยก subdomain ออกจากเว็บหลัก หรือ landing page แคมเปญที่ทีมกราฟิกทำแยกด้วยเครื่องมืออื่น มักไม่ได้รับการติดตั้ง Consent Banner ชุดเดียวกัน ให้ไล่ทดสอบทีละโดเมนตามรายชื่อที่รวบรวมไว้ตอนเตรียมงาน อย่าเชื่อว่าการตรวจหน้าแรกแล้วผ่านหมายความว่าทุกหน้าผ่านตามไปด้วย

4. ปุ่ม Reject All ต้องกดง่ายเท่ากับปุ่ม Accept All

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

5. ตรวจการตั้งค่าบนอุปกรณ์มือถือแยกจากเดสก์ท็อป

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

6. เก็บภาพหน้าจอและผลทดสอบเป็นหลักฐานก่อนปิดโปรเจกต์

ถ่ายภาพหน้าจอ Consent Banner บนทุกโดเมน พร้อมภาพ network tab ก่อนและหลังกด Reject All แนบไว้ในเอกสารส่งมอบงาน วันที่ทดสอบและชื่อผู้ทดสอบควรระบุชัดเจน เพราะถ้าลูกค้าถูกตรวจสอบภายหลัง หลักฐานชุดนี้คือสิ่งแรกที่จะถูกขอดูว่าเอเจนซีเคยตรวจสอบมาก่อนหรือไม่

7. ส่งมอบเอกสารและความรับผิดชอบต่อให้ชัดเจนก่อนปิดงาน

ระบุในเอกสารส่งมอบว่าใครจะเป็นเจ้าของการตรวจซ้ำในอนาคต เอเจนซียังรับดูแลต่อภายใต้สัญญาบำรุงรักษาหรือไม่ และถ้าลูกค้ารับไปดูแลเอง ต้องมีคู่มือสั้น ๆ อธิบายวิธีตรวจข้อ 1-5 ด้วยตัวเองเมื่อมีการเพิ่มสคริปต์ใหม่ในอนาคต

สถานการณ์ตัวอย่างจริง

กรณีที่หนึ่ง — เทมเพลตเดิมใช้ได้กับลูกค้าเก่าแต่พังกับลูกค้าใหม่: ฟรีแลนซ์รายหนึ่งใช้โค้ด Consent Banner ชุดเดียวกันมาหลายโปรเจกต์ จนถึงงานที่ลูกค้าขอให้ติดตั้ง TikTok Pixel เพิ่มนอกเหนือจาก Facebook Pixel ที่เคยรองรับ ปุ่ม Reject All เดิมไม่รู้จักสคริปต์ตัวใหม่นี้ จึงปล่อยให้ทำงานต่อแม้ผู้ใช้งานกดปฏิเสธแล้ว การตรวจตามข้อ 2 ก่อนส่งมอบช่วยจับปัญหานี้ได้ก่อนขึ้นเว็บจริง

กรณีที่สอง — landing page แคมเปญไม่มีปุ่มปฏิเสธเลย: ทีมกราฟิกของเอเจนซีสร้าง landing page โปรโมชันแยกด้วยเครื่องมือ page builder คนละตัวจากเว็บหลัก เพื่อความเร็วในการเปิดแคมเปญ แต่ลืมฝัง Consent Banner ชุดเดียวกัน การไล่ตรวจตามข้อ 3 ทีละโดเมนตามรายชื่อที่เตรียมไว้ก่อนส่งมอบ จับปัญหานี้ได้ทันเวลาก่อนแคมเปญเริ่มยิงโฆษณาจริง

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

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

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

• ใช้เทมเพลต Consent Banner ชุดเดียวข้ามโปรเจกต์โดยไม่ปรับให้ตรงกับสคริปต์จริงของลูกค้าแต่ละราย
• ตรวจแค่หน้าแรกของเว็บหลัก ไม่ไล่ตรวจ subdomain หรือ landing page แคมเปญที่แยก deploy
• ทดสอบเฉพาะบนเดสก์ท็อป ไม่ทดสอบซ้ำบนอุปกรณ์มือถือก่อนปิดงาน
• ไม่เก็บภาพหน้าจอหรือผลทดสอบไว้เป็นหลักฐาน ทำให้ตอบคำถามย้อนหลังไม่ได้
• ปิดโปรเจกต์โดยไม่ระบุในเอกสารว่าใครรับผิดชอบตรวจซ้ำเมื่อมีการเพิ่มสคริปต์ใหม่
• ปล่อยให้ปุ่มปฏิเสธมีขนาดเล็กหรือซ่อนอยู่ลึกกว่าปุ่มยอมรับ เพราะโฟกัสแค่เรื่องดีไซน์ให้สวย

สรุป

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

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

แนวปฏิบัติเกี่ยวกับการขอและบันทึกความยินยอมภายใต้ PDPA ควรอ้างอิงจาก สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง เช็กลิสต์นี้เป็นแนวทางเชิงปฏิบัติที่สรุปจากรูปแบบปัญหาที่พบบ่อยในงานส่งมอบเว็บไซต์ของเอเจนซี ไม่ใช่การตีความข้อกฎหมายแทนหน่วยงานกำกับดูแล

ดูภาพรวมหัวข้ออื่นในหมวดเดียวกันได้ที่ คลังความรู้ Cookies & Consent และดูภาพรวมของคลัสเตอร์ปุ่ม Reject All สำหรับกลุ่มเอเจนซีทั้งหมดได้ที่ คู่มือปุ่ม Reject All สำหรับเอเจนซีและฟรีแลนซ์ ซึ่งครอบคลุมภาพรวมของทั้งคลัสเตอร์ รวมถึง วิธี Audit ปุ่ม Reject All สำหรับเอเจนซี สำหรับทีมที่ต้องการตรวจสอบเป็นรอบหลังส่งมอบงานแล้ว