แก้ปัญหา PDPA บนเว็บไซต์ SaaS: Telemetry ยิงก่อน Consent และปัญหาที่พบบ่อย

ทีม Engineering ของ SaaS รายหนึ่งได้รับอีเมลจากลูกค้าองค์กรที่ใช้ Browser DevTools ตรวจสอบเองแล้วพบว่า Analytics Script ของบริษัทยิง Request ออกไปตั้งแต่โหลดหน้า Onboarding ทั้งที่ยังไม่ได้กด Accept บน Consent Banner เลย ลูกค้าส่งภาพหน้าจอ Network Tab มาพร้อมคำถามตรง ๆ ว่าทำไมระบบยิง Tracking ก่อนได้รับความยินยอม เหตุการณ์แบบนี้ไม่ใช่เรื่องแปลกสำหรับ SaaS ที่มี Codebase ใหญ่และมีหลายทีมเพิ่ม Script คนละช่วงเวลากัน บทความนี้รวบรวมอาการปัญหาที่พบบ่อยพร้อมวิธีตรวจสอบและแก้ไขทีละจุด

ทุกหัวข้อในบทความนี้ใช้โครงสร้างเดียวกันคือ อาการที่พบ สาเหตุที่เป็นไปได้ วิธีตรวจสอบ และแนวทางแก้ไข เพื่อให้ทีม Engineering นำไปใช้เป็น Runbook ได้จริง

อาการ: Telemetry หรือ Analytics ยิงก่อนผู้ใช้งานกด Accept

อาการนี้มักถูกค้นพบโดยลูกค้าองค์กรที่มีทีม Security ตรวจสอบ Vendor ก่อนซื้อ หรือถูกพบจากการสุ่มตรวจภายในเอง สาเหตุที่พบบ่อยที่สุดคือ SDK ของ Analytics ถูก Initialize ทันทีที่หน้าโหลด (on page load) แทนที่จะรอ Event ยืนยัน Consent จาก Consent Management Platform ก่อน

วิธีตรวจสอบ

เปิด Network Tab ของเบราว์เซอร์ในโหมด Incognito แล้วโหลดหน้า Trial Signup หรือ Onboarding โดยยังไม่กดปุ่มใดบน Consent Banner จากนั้นสังเกตว่ามี Request ไปยังโดเมนของ Analytics หรือ Advertising Vendor เกิดขึ้นหรือไม่ก่อนที่จะมีการโต้ตอบใด ๆ

วิธีแก้ไข

ย้ายการ Initialize SDK ไปอยู่หลัง Event ที่ยืนยันว่าผู้ใช้งานเลือก Accept หมวดที่เกี่ยวข้องแล้ว หากใช้ Google Tag Manager ต้องตั้งค่า Consent Initialization และ Default Consent State ก่อน Tag อื่นทำงาน ตามแนวทางของ Google Tag Platform เวอร์ชันล่าสุด ไม่ใช่คาดเดาชื่อ Parameter จากความจำ

ปัญหา: Subprocessor List ไม่ตรงกับ Vendor ที่ใช้งานจริง

อาการที่พบคือหน้า Subprocessor List บนเว็บไซต์ยังมีชื่อผู้ให้บริการที่เลิกใช้ไปแล้ว หรือไม่มีชื่อผู้ให้บริการใหม่ที่เพิ่งเชื่อมต่อเข้าระบบ มักเกิดเมื่อทีม Engineering เปลี่ยน Vendor โดยไม่แจ้งทีมที่ดูแลหน้า Public

วิธีตรวจสอบ

ให้ทีม Engineering Export รายการ Third-party Service ที่ระบบเชื่อมต่ออยู่จริงจาก Infrastructure Config หรือ Billing Dashboard แล้วเทียบกับรายการบนหน้า Subprocessor List ทีละบรรทัด

วิธีแก้ไข

อัปเดตหน้า Subprocessor List ให้ตรงกับ Vendor ปัจจุบันทันที และกำหนด Process ว่าทุกครั้งที่มีการเพิ่มหรือเปลี่ยน Vendor ที่เข้าถึงข้อมูลลูกค้า ต้องมีขั้นตอนแจ้งทีมที่ดูแลหน้า Public ควบคู่กับการ Deploy โค้ด ไม่ใช่แยกกระบวนการออกจากกัน

ปัญหา: Data Residency ที่ระบุไว้ไม่ตรงกับสถาปัตยกรรม Multi-tenant จริง

อาการที่พบคือหน้า FAQ หรือ Security Page เขียนว่าข้อมูลจัดเก็บที่ Region เดียว แต่ระบบจริงมีการกระจาย Tenant ไปหลาย Region ตามการขยายตัวของธุรกิจ ทำให้คำตอบที่ให้ลูกค้าองค์กรไม่ตรงกับความเป็นจริง

วิธีตรวจสอบ

ให้ทีม Infrastructure ยืนยัน Region ที่ใช้งานจริงของแต่ละ Tenant หรือ Cluster แล้วเทียบกับสิ่งที่เขียนไว้บนเว็บไซต์และเอกสารขายที่ทีม Sales ใช้อยู่

วิธีแก้ไข

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

ปัญหา: API ให้สิทธิ์เข้าถึงข้อมูลโดยไม่มีการควบคุมตาม Consent หรือ Scope

อาการที่พบคือ API Key หรือ Integration Token ที่ออกไปนานแล้วยังสามารถดึงข้อมูลผู้ใช้งานได้ครบทุกฟิลด์ แม้ผู้ใช้งานจะเปลี่ยนการตั้งค่าความยินยอมในภายหลัง เพราะ API Layer ไม่ได้เช็ค Consent State ก่อนส่งข้อมูลกลับ

วิธีตรวจสอบ

สุ่มทดสอบเรียก API ด้วย Key เก่าหลังจากผู้ใช้งานเปลี่ยนสถานะความยินยอมในระบบ แล้วดูว่าข้อมูลที่ส่งกลับมาสะท้อนสถานะล่าสุดหรือไม่

วิธีแก้ไข

เพิ่มการตรวจสอบ Consent State หรือ Scope ที่ระดับ API Layer ไม่ใช่พึ่งพา Frontend เพียงอย่างเดียว และกำหนดรอบทบทวน API Key ที่ไม่มีการใช้งานต่อเนื่องเพื่อเพิกถอนสิทธิ์ที่ไม่จำเป็น

ปัญหา: Trial Signup เก็บข้อมูลแต่ไม่มีบันทึกว่าเก็บเพื่อวัตถุประสงค์ใด

อาการที่พบคือทีม Support ตอบคำถามลูกค้าไม่ได้ว่าทำไมระบบถึงมีอีเมลของผู้ใช้งานที่ไม่เคยสมัครสมาชิกจริง เพราะไม่มี Consent Log ผูกกับ Event การ Signup แต่ละครั้ง

วิธีตรวจสอบ

ตรวจว่าระบบ Signup มีการบันทึก Consent Event แยกจากตาราง User หลักหรือไม่ และเหตุการณ์นั้นผูกกับเวอร์ชันของ Notice ที่ผู้ใช้งานเห็น ณ ขณะนั้นหรือไม่

วิธีแก้ไข

เพิ่มการบันทึก Consent Event แบบ Append-only ทุกครั้งที่มีการ Signup พร้อมเวอร์ชันของ Notice ที่แสดง เพื่อให้ทีม Support และ Privacy ตรวจสอบย้อนหลังได้เมื่อมีคำถาม

ปัญหา: Preference Center แสดงว่าเปลี่ยนค่าได้ แต่ Script เดิมยังทำงานต่อ

อาการที่พบคือผู้ใช้งานเข้าไปปิด Analytics ในหน้า Preference Center ของบัญชี ระบบแสดงข้อความว่าบันทึกสำเร็จ แต่เมื่อโหลดหน้าใหม่ Script เดิมยังคงทำงานอยู่เหมือนเดิม เพราะ Preference ที่บันทึกในฐานข้อมูลไม่ได้เชื่อมกับตัวแปรที่ควบคุมการโหลด Script บน Frontend จริง

วิธีตรวจสอบ

เปลี่ยนค่า Preference ในบัญชีทดสอบ แล้วโหลดหน้าใหม่พร้อมเปิด Network Tab ดูว่า Request ไปยัง Vendor ที่เพิ่งปิดไปยังคงเกิดขึ้นหรือไม่ ทดสอบทั้งกรณี Reload หน้าเดิมและเปิด Session ใหม่ในเบราว์เซอร์อื่น

วิธีแก้ไข

ให้ค่า Preference ที่บันทึกในฐานข้อมูลเป็นแหล่งความจริงเดียว (Single Source of Truth) ที่ทั้ง Backend และ Frontend อ่านค่าเดียวกันก่อนตัดสินใจโหลด Script ไม่ใช่ให้ Frontend เก็บค่าคนละชุดกับที่บันทึกในบัญชีผู้ใช้งาน และทดสอบกรณี Cross-device ด้วย เพราะผู้ใช้งาน SaaS มักสลับใช้งานหลายอุปกรณ์

วิธีตั้ง Verification Workflow เพื่อไม่ให้ปัญหาเดิมกลับมา

หลังแก้ปัญหาแต่ละจุดแล้ว ทีมควรมี Checklist ทดสอบซ้ำก่อน Deploy ทุกครั้งที่มีการเพิ่ม Script, Vendor หรือ API Endpoint ใหม่ ขั้นตอนที่ทำได้จริงคือทดสอบ Network Request ในโหมด Reject All และ Accept All แยกกัน ทดสอบการเปลี่ยน Consent กลางเซสชัน และตรวจว่า Consent Log บันทึกเหตุการณ์ครบทุกกรณี

ทีมที่มี Codebase ขนาดใหญ่ควรกำหนดให้การตรวจสอบนี้เป็นส่วนหนึ่งของ Release Checklist ไม่ใช่ขั้นตอนแยกที่ทำเฉพาะเมื่อมีคนร้องเรียน เพราะปัญหาส่วนใหญ่ที่พบในหัวข้อก่อนหน้าเกิดจาก Script หรือ Endpoint ใหม่ที่เพิ่มเข้ามาระหว่างทาง ไม่ใช่จุดที่เคยตรวจสอบผ่านมาแล้วครั้งแรก การมี Owner ที่รับผิดชอบตรวจ Consent Behavior ก่อนทุก Release ช่วยลดโอกาสที่ปัญหาเดิมจะย้อนกลับมาซ้ำในเวอร์ชันถัดไป

ทีมที่ต้องการเห็นภาพรวมของ Script ที่ทำงานก่อนและหลัง Consent สามารถเริ่มจากการสแกนเบื้องต้นที่ PDPA Checker เพื่อดู Finding เบื้องต้นก่อนไล่ตรวจ Log ในระบบจริงต่อ และหากยังไม่มีชุด Template สำหรับ Notice และ Subprocessor List ที่ตรงกับระบบ ควรอ่านคู่กับ ตัวอย่างและ Template PDPA สำหรับเว็บไซต์ SaaS เพื่อปรับเอกสารให้ตรงกับสิ่งที่ตรวจพบ ส่วนภาพรวมของหมวดนี้ดูเพิ่มเติมได้ที่ Privacy Fundamentals

เมื่อพบปัญหาใหม่ที่ไม่อยู่ในรายการนี้ ทีมควรบันทึกอาการ สาเหตุ และวิธีแก้ไว้เป็นเอกสารภายในต่อเนื่อง เพื่อให้ Runbook นี้ครอบคลุมมากขึ้นตามที่ผลิตภัณฑ์เติบโต แทนที่จะพึ่งความจำของวิศวกรคนใดคนหนึ่งที่เคยแก้ปัญหานั้นมาก่อน

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

• ทดสอบ Network Request ในโหมด Reject All ก่อนทุกครั้งที่ Deploy Script ใหม่
• เทียบ Subprocessor List กับ Vendor ที่เชื่อมต่อจริงในระบบ Infrastructure
• ยืนยัน Data Residency กับทีม Infrastructure ก่อนเผยแพร่คำตอบให้ลูกค้า
• ตรวจสอบ Consent State ที่ระดับ API Layer ไม่ใช่ Frontend เพียงอย่างเดียว
• บันทึก Consent Event ทุกครั้งที่มีการ Signup แบบ Append-only
• ทบทวน API Key ที่ไม่มีการใช้งานต่อเนื่องเป็นระยะ

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

• Initialize Analytics SDK ก่อน Consent Banner แสดงผลหรือก่อนผู้ใช้งานเลือก
• ไม่อัปเดต Subprocessor List หลังเปลี่ยนผู้ให้บริการ Hosting หรือ Email
• เขียน Data Residency ตายตัวทั้งที่ระบบรองรับหลาย Region จริง
• ปล่อยให้ API Key เก่าที่ไม่ใช้งานแล้วยังมีสิทธิ์เข้าถึงข้อมูลเต็ม Scope
• ไม่มี Consent Log ผูกกับ Event การ Signup ทำให้ตอบคำถามลูกค้าย้อนหลังไม่ได้

สรุป

ปัญหา PDPA บนเว็บไซต์ SaaS ส่วนใหญ่เกิดจากช่องว่างระหว่างสิ่งที่ Notice เขียนไว้กับสิ่งที่ระบบทำงานจริงในแต่ละชั้น ตั้งแต่ Script บน Frontend, API Layer จนถึง Consent Log การตรวจสอบที่ได้ผลต้องทำเป็น Runbook ซ้ำได้ทุกครั้งที่มีการเปลี่ยน Script, Vendor หรือ Endpoint ไม่ใช่ตรวจครั้งเดียวตอนเปิดตัวผลิตภัณฑ์แล้วปล่อยผ่าน

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

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