วิธีวัดผลและแก้ปัญหาปุ่ม Reject All ของ SaaS เมื่อสคริปต์ยังยิงอยู่หลังผู้ใช้ปฏิเสธ

ทีม Engineering เปิด Network Tab หลังกด Reject All แล้วยังเห็น Request ไปยังโดเมนของ Google Analytics หรือ Meta Pixel นี่คืออาการที่พบบ่อยที่สุดเมื่อปุ่ม Reject All ของผลิตภัณฑ์ SaaS ไม่ทำงานจริงตามที่ตั้งใจ บทความนี้เรียงลำดับการวินิจฉัยปัญหาทีละชั้น เพื่อให้หาสาเหตุได้เร็วกว่าการเดาสุ่มแก้ทีละจุด

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

ชั้นที่หนึ่ง ตรวจ Consent State ในเบราว์เซอร์ก่อน

เปิด Developer Tools แท็บ Application หรือ Storage แล้วดู Cookie หรือ Local Storage ที่ CMP ใช้เก็บค่า Consent ว่าหลังกด Reject All ค่านั้นเปลี่ยนเป็นสถานะปฏิเสธจริงหรือไม่ ถ้าค่ายังคงเป็นค่าเริ่มต้นหรือไม่เปลี่ยนเลย แปลว่าปัญหาอยู่ที่ตัวปุ่มหรือ Event Listener ของแบนเนอร์เอง ไม่ใช่ปัญหาที่ Tag Manager

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

ชั้นที่สอง ตรวจ Mapping ใน Google Tag Manager Consent Mode

เข้าไปที่ Tag Manager แล้วเปิด Preview Mode ทดสอบพร้อมกับกด Reject All บนหน้าเว็บจริง ดูว่า Tag ที่ควรถูกบล็อกมี Trigger ผูกกับ Consent Type ที่ตรงกับหมวดที่ผู้ใช้ปฏิเสธหรือไม่ ปัญหาที่พบบ่อยคือ Tag ถูกสร้างขึ้นโดยไม่ได้ผูก Consent Trigger เลย ทำให้ Tag ทำงานตลอดเวลาไม่ว่าผู้ใช้จะเลือกอะไร

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

ชั้นที่สาม ไล่หาสคริปต์ Hardcode ที่ไม่ผ่าน Tag Manager

ถ้าตรวจสองชั้นแรกแล้วยังพบสคริปต์ยิงอยู่ ให้ค้นหาในโค้ด Source ของเว็บไซต์หรือแอปว่ามี Script Tag ที่ฝังตรงในไฟล์ Layout หรือ Component โดยไม่ผ่าน Tag Manager หรือไม่ สคริปต์ประเภทนี้พบบ่อยในผลิตภัณฑ์ SaaS ที่ทีม Growth เพิ่มเครื่องมือใหม่เร็ว ๆ ด้วยตัวเองโดยไม่ผ่านกระบวนการที่ทีม Engineering ควบคุม

วิธีแก้คือย้ายสคริปต์เหล่านี้เข้าไปอยู่ภายใต้เงื่อนไขตรวจ Consent State เดียวกับ Tag อื่น หรือย้ายเข้า Tag Manager ทั้งหมดเพื่อให้ควบคุมจากจุดเดียว ไม่กระจายอยู่หลายที่จนตรวจสอบยาก

อาการเฉพาะของ Single Page Application และ Multi-tenant

ถ้าปัญหาเกิดเฉพาะตอนเปลี่ยนหน้าภายในแอปโดยไม่ Reload ให้ตรวจว่า Router ของแอปเช็ก Consent State ซ้ำทุกครั้งที่เปลี่ยน Route หรือไม่ เพราะ Single Page Application ไม่โหลดหน้าใหม่ทั้งหมด สคริปต์ที่เคยถูกบล็อกตอนโหลดครั้งแรกอาจถูกยิงซ้ำตอนเปลี่ยนหน้าถ้า Consent Check ไม่ได้ผูกกับ Router ด้วย

ถ้าผลิตภัณฑ์เป็นแบบ Multi-tenant ที่มี Subdomain ของลูกค้าแต่ละราย ให้ทดสอบซ้ำทีละ Domain แยกกัน เพราะ Container ID หรือ Configuration ของ CMP อาจตั้งค่าถูกต้องเฉพาะ Domain หลัก แต่ไม่ครอบคลุม Subdomain ที่โหลดสคริปต์คนละชุด

วิธีวัดผลว่าการแก้ไขสำเร็จจริง

หลังแก้ไขแล้ว ควรวัดผลด้วยการทดสอบซ้ำใน Incognito Window อย่างน้อยสามรอบตามสถานการณ์ต่างกัน คือก่อนเลือก Consent หลังกด Reject All และหลัง Reload หน้า พร้อมบันทึกจำนวน Request ที่เห็นในแต่ละรอบเปรียบเทียบกับก่อนแก้ไข เพื่อยืนยันว่าจำนวน Request ไปยังโดเมน Analytics และ Marketing ลดลงจริงหลังกด Reject All ไม่ใช่แค่เชื่อว่าปุ่มทำงานเพราะหน้าตาเปลี่ยน

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

อาการที่พบบ่อยแยกตามสาเหตุ

อาการแบบที่หนึ่ง แบนเนอร์แสดงถูกต้อง กด Reject All แล้วแบนเนอร์ปิด แต่ Consent State ในเบราว์เซอร์ไม่เปลี่ยนเลย มักเกิดจาก Event Listener ของปุ่มผูกผิด Element หรือโค้ด JavaScript ของแบนเนอร์มี Error บางส่วนที่ไม่แสดงผลชัดเจนในหน้าจอปกติ ต้องเปิด Console ตรวจ Error Log ควบคู่ไปด้วย

อาการแบบที่สอง Consent State เปลี่ยนถูกต้อง แต่ Tag บางตัวยังยิงอยู่เฉพาะบางหน้า มักเกิดจาก Tag นั้นถูกตั้งค่าด้วย Trigger แบบ All Pages โดยไม่ได้ผูกเงื่อนไข Consent เพิ่มเข้าไป ทำให้ทำงานทุกหน้าไม่ว่าจะปฏิเสธหรือไม่

อาการแบบที่สาม ทุกอย่างถูกต้องบน Desktop แต่ยังพบปัญหาบน Mobile App ที่ฝัง WebView ไว้ กรณีนี้ต้องตรวจว่า WebView ใช้ Cookie Storage คนละชุดกับเบราว์เซอร์ปกติหรือไม่ เพราะบางแพลตฟอร์ม Mobile ไม่แชร์ Local Storage ระหว่าง WebView กับเบราว์เซอร์หลักของเครื่อง ทำให้ Consent ที่เคยเลือกไว้บนเว็บไม่ถูกใช้ซ้ำในแอป

ลำดับการรายงานปัญหาให้ทีมอื่นเข้าใจตรงกัน

เมื่อพบว่าปุ่ม Reject All ไม่ทำงานจริง ควรรายงานปัญหาพร้อมหลักฐานสามอย่างเสมอ คือภาพหน้าจอ Network Tab ที่เห็น Request หลุด ชื่อ Tag หรือ Trigger ที่ต้องสงสัยจาก Preview Mode และ URL ของหน้าที่ทดสอบ ไม่ใช่รายงานแค่ว่า 'ปุ่ม Reject All ยังไม่ทำงาน' เพราะทีมที่ต้องแก้ไขจะไม่รู้ว่าควรเริ่มไล่จากจุดไหน

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

เมื่อควรขอความช่วยเหลือจากผู้ให้บริการ CMP

ถ้าไล่ตรวจครบทั้งสามชั้นแล้วยังหาสาเหตุไม่เจอ ควรพิจารณาติดต่อผู้ให้บริการ Consent Management Platform ที่ใช้งานอยู่โดยตรง พร้อมแนบหลักฐานที่รวบรวมไว้ทั้งหมด เช่น ภาพ Network Tab, ชื่อ Tag ที่ต้องสงสัย และ URL หน้าที่ทดสอบ เพราะบางปัญหาอาจเกิดจากข้อจำกัดหรือบั๊กของตัว CMP เองที่ทีม Engineering ภายในแก้ไขจากฝั่งเว็บไซต์ไม่ได้

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

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

ทำไมปุ่ม Reject All ของ SaaS ถึงยังปล่อยให้สคริปต์ยิงอยู่หลังผู้ใช้กด ส่วนใหญ่เกิดจากสามจุด คือ Consent State ในเบราว์เซอร์ไม่เปลี่ยนจริง Tag ใน Tag Manager ไม่ได้ผูก Consent Trigger หรือมีสคริปต์ Hardcode ที่ไม่ผ่าน Tag Manager เลย ต้องไล่ตรวจทีละชั้นตามลำดับ

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

Single Page Application ต้องตรวจ Reject All ต่างจากเว็บไซต์ทั่วไปอย่างไร ต้องตรวจว่า Router ของแอปเช็ก Consent State ซ้ำทุกครั้งที่เปลี่ยน Route ภายในแอปโดยไม่ Reload หน้า เพราะสคริปต์ที่เคยถูกบล็อกอาจถูกยิงซ้ำได้ถ้าไม่ผูก Consent Check เข้ากับ Router

ควรวัดผลว่าการแก้ไข Reject All สำเร็จจริงได้อย่างไร ทดสอบซ้ำใน Incognito Window หลายรอบตามสถานการณ์ต่างกัน แล้วเปรียบเทียบจำนวน Request ไปยังโดเมน Analytics และ Marketing ก่อนกับหลังแก้ไข พร้อมกำหนดรอบตรวจซ้ำทุกครั้งที่มีการ Deploy Tag ใหม่

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

• ตรวจ Consent State ในแท็บ Application ของเบราว์เซอร์ว่าเปลี่ยนสถานะจริงหลังกด Reject All
• เปิด Preview Mode ของ Tag Manager ตรวจว่า Tag ทุกตัวผูก Consent Trigger ตรงหมวดที่ถูกต้อง
• ค้นหาสคริปต์ Hardcode ในโค้ด Source ที่ไม่ผ่าน Tag Manager แล้วย้ายเข้าเงื่อนไข Consent
• ตรวจลำดับ Tag Sequencing ให้ Consent Initialization Tag ทำงานเป็นอันดับแรกเสมอ
• ทดสอบซ้ำทีละ Domain สำหรับผลิตภัณฑ์แบบ Multi-tenant ที่มี Subdomain ของลูกค้าแต่ละราย
• บันทึกจำนวน Request ก่อนและหลังแก้ไขเพื่อยืนยันผลด้วยตัวเลขจริง ไม่ใช่แค่ดูหน้าตาแบนเนอร์

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

• เชื่อว่าปุ่มทำงานเพราะแบนเนอร์ปิดไปแล้ว โดยไม่เปิด Network Tab ตรวจ Request จริง
• ตรวจ Consent Mode เฉพาะ Domain หลักแต่ไม่ตรวจ Subdomain ของลูกค้าแต่ละราย
• ปล่อย Tag ที่ไม่ได้ผูก Consent Trigger ให้ทำงานตลอดเวลาโดยไม่มีใครสังเกต
• ไม่ผูก Consent Check เข้ากับ Router ของ Single Page Application ทำให้สคริปต์ยิงซ้ำตอนเปลี่ยนหน้า

สรุป

การแก้ปัญหาปุ่ม Reject All ของ SaaS ที่ไม่ทำงานจริง ต้องไล่ตรวจทีละชั้นตั้งแต่ Consent State ในเบราว์เซอร์ Mapping ใน Tag Manager จนถึงสคริปต์ Hardcode ที่หลุดออกนอกระบบควบคุม พร้อมวัดผลด้วยจำนวน Request จริงก่อนและหลังแก้ไข ไม่ใช่ตัดสินจากหน้าตาแบนเนอร์เพียงอย่างเดียว

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• ข้อผิดพลาดเรื่องปุ่ม Reject All ที่ SaaS ควรเลี่ยง
• วิธีแก้ปัญหา Google Tag Manager Consent