วิธีวางระบบ PDPA สำหรับ Agency อสังหาริมทรัพย์และธุรกิจที่เก็บ Lead แบบเป็นขั้นตอน

ทีมการตลาดของ Agency แห่งหนึ่งได้รับมอบหมายให้ดูแลเว็บไซต์โครงการอสังหาริมทรัพย์ใหม่สามโครงการพร้อมกันภายในเดือนเดียว งานเร่งด่วนคือทำให้แคมเปญโฆษณาเริ่มยิงได้เร็วที่สุด จนเรื่องการวางระบบ PDPA ถูกเลื่อนไปทำทีหลังเสมอ ผลคือเว็บไซต์ทั้งสามเปิดใช้งานโดยไม่มี Cookie Banner ที่ตรงกับ Script จริง และต้องกลับมาแก้ย้อนหลังหลังลูกค้าเริ่มถามหา Consent Log

ลำดับขั้นตอนด้านล่างช่วยให้ Agency วางระบบ PDPA ไปพร้อมกับการเปิดเว็บไซต์ตั้งแต่ต้น แทนที่จะต้องย้อนกลับมาแก้ทีหลังเมื่อแคมเปญเดินไปแล้ว

ขั้นตอนที่ 1: สำรวจข้อมูลที่เก็บจริงก่อนเริ่มวางระบบ

เริ่มจากไล่ดูทุกฟอร์มบนเว็บไซต์ ทุก Landing Page ของแคมเปญ และช่องทางแชทอย่าง LINE OA ว่าแต่ละจุดเก็บข้อมูลอะไรบ้าง ชื่อ เบอร์โทร อีเมล งบประมาณ หรือข้อมูลทางการเงินสำหรับขอสินเชื่อ จดบันทึกเป็นตารางว่าข้อมูลแต่ละประเภทถูกส่งไปเก็บที่ไหน เช่น CRM ของโครงการ หรือ Google Sheet ที่ทีมขายใช้ร่วมกัน ขั้นตอนนี้ควรทำก่อนเริ่มออกแบบ Cookie Banner เพราะ Banner ที่ดีต้องสะท้อนสิ่งที่เว็บไซต์เก็บจริง ไม่ใช่ Template ทั่วไป

อย่าลืมรวมช่องทางที่ไม่ใช่เว็บไซต์ไว้ในการสำรวจด้วย เช่น เบอร์โทรของ Call Center ที่ติดในโฆษณา ป้ายหน้าโครงการที่มี QR Code ให้กรอกฟอร์มกระดาษ หรือบูธในงานมหกรรมบ้านที่เก็บนามบัตรลูกค้า เพราะข้อมูลจากช่องทางออฟไลน์เหล่านี้มักถูกนำเข้า CRM เดียวกันกับข้อมูลจากเว็บไซต์ในภายหลัง และควรถูกนับรวมอยู่ใน Privacy Policy ฉบับเดียวกัน

ขั้นตอนที่ 2: จัดหมวด Cookie และ Tracking Script บนเว็บไซต์ที่ดูแล

ไล่ดู Google Tag Manager Container และโค้ดที่ฝังตรงในหน้าเว็บว่ามี Script ใดทำงานอยู่บ้าง แยกเป็นสี่หมวดคือ Necessary สำหรับสิ่งที่จำเป็นต่อการทำงานของเว็บไซต์ Functional สำหรับการตั้งค่าที่ผู้ใช้เลือกเอง Analytics สำหรับวัดผลการใช้งาน และ Marketing สำหรับโฆษณาและ Remarketing ห้ามจัดให้ Pixel โฆษณาอยู่ในหมวด Necessary เพียงเพราะทีมการตลาดต้องการข้อมูลนี้มาก เพราะ Necessary หมายถึงสิ่งที่จำเป็นต่อบริการที่ผู้ใช้ร้องขอเท่านั้น

สำหรับเว็บไซต์โครงการอสังหาริมทรัพย์ที่สร้างด้วย WordPress ควรตรวจ Plugin และ Theme เพิ่มเติมว่ามี Script ฝังมาเองโดยที่ Agency ไม่ได้ตั้งค่าผ่าน Tag Manager เช่น Plugin แสดงแผนที่ Plugin จองคิวเข้าชมโครงการ หรือ Plugin แชทสด ซึ่งบาง Plugin ตั้งค่า Cookie ทันทีที่หน้าโหลดโดยไม่รอ Consent ตัวอย่างการจัดหมวดที่ใช้ได้จริงมีดังนี้

ขั้นตอนที่ 3: ตั้งค่า Cookie Banner และ Consent Mode ให้ตรงกับหมวดจริง

ตั้งค่า Default Consent State ให้ Script ทุกหมวดยกเว้น Necessary เริ่มต้นที่สถานะปฏิเสธ แล้วอัปเดตสถานะเมื่อผู้ใช้กดยอมรับในภายหลัง Agency ที่ใช้ Google Consent Mode ควร Map หมวดของ Banner ที่ใช้กับ Consent Type ของ Google ให้ตรงกัน แล้วทดสอบด้วยเครื่องมืออย่าง Tag Assistant ว่าค่าที่ส่งออกไปตรงกับสิ่งที่ผู้ใช้เลือกจริง

ขั้นตอนที่ 4: ทดสอบ Script Blocking ก่อนและหลัง Consent

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

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

ขั้นตอนที่ 5: ร่าง Privacy Policy จากผลสำรวจข้อมูลจริง

ใช้ผลจากขั้นตอนที่ 1 และ 2 เป็นจุดตั้งต้นในการร่าง Privacy Policy แทนการคัดลอก Template จากเว็บไซต์อื่น ระบุประเภทข้อมูลที่เก็บ วัตถุประสงค์ ผู้รับข้อมูลถัดไปอย่างนายหน้าหรือธนาคารพันธมิตร และช่องทางติดต่อเมื่อผู้ใช้ต้องการใช้สิทธิของตน ให้เจ้าของโครงการตรวจทานเนื้อหาก่อนเผยแพร่ และส่งให้ผู้เชี่ยวชาญตรวจเพิ่มเมื่อธุรกิจมีความซับซ้อน เช่น ขายให้ลูกค้าต่างชาติ

ขั้นตอนที่ 6: วางระบบ Consent Log และหลักฐาน

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

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

ขั้นตอนที่ 7: กำหนดผู้รับผิดชอบและรอบทบทวนระบบ

ระบุว่าใครเป็นเจ้าของงานตรวจ Cookie ของแต่ละโครงการที่ Agency ดูแล และกำหนดรอบทบทวนที่ชัดเจน เช่น ทุกครั้งที่เพิ่ม Tag ใหม่หรือเปลี่ยน Theme เว็บไซต์ เพราะ Theme หรือ Plugin ที่อัปเดตอาจเพิ่ม Script ใหม่โดยที่ทีมการตลาดไม่รู้ตัว การมีผู้รับผิดชอบชัดเจนช่วยให้ระบบที่วางไว้ในขั้นตอนก่อนหน้าไม่ค่อย ๆ หลุดจากความจริงไปทีละน้อยเมื่อเวลาผ่านไป

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

ต้องทำครบทั้งเจ็ดขั้นตอนก่อนเปิดแคมเปญโฆษณาหรือไม่

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

ถ้าเว็บไซต์ใช้ Google Tag Manager Container เดียวกันหลายโครงการต้องแยกอย่างไร

ควรแยก Container ต่อโครงการแทนการใช้ตัวเดียวกันทั้งหมด เพราะแต่ละโครงการมี Vendor และการตั้งค่า Consent ที่ต่างกัน การใช้ Container รวมเพิ่มความเสี่ยงที่ Tag ของโครงการหนึ่งจะทำงานผิดเว็บไซต์

Agency ขนาดเล็กที่ไม่มีนักพัฒนาประจำจะทำขั้นตอนที่ 4 ได้อย่างไร

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

เว็บไซต์ที่ใช้ Shopify สำหรับขายของแต่งบ้านของโครงการต้องทำต่างจาก WordPress หรือไม่

หลักการเดียวกันยังใช้ได้ แต่จุดที่ต้องตรวจเพิ่มคือ App ที่ติดตั้งผ่าน Shopify App Store, Pixel ที่ผูกกับ Checkout และ Customer Events ที่ Shopify ส่งออกไปยังแพลตฟอร์มโฆษณาโดยอัตโนมัติ ซึ่งบาง App อาจทำงานนอกเหนือการควบคุมของ Tag Manager ที่ Agency ตั้งค่าไว้ ต้องตรวจแยกเป็นรายกรณีตาม App ที่ติดตั้งจริง

ถ้าพบว่า Reject All กดแล้ว Tag บางตัวยังยิงอยู่ควรทำอย่างไร

ควรบันทึกว่า Tag ใดยังทำงานอยู่ พร้อมภาพหน้าจอ Network Request เป็นหลักฐาน แล้วตรวจว่า Tag นั้นถูกฝังผ่าน Tag Manager หรือฝังตรงในโค้ดหน้าเว็บ เพราะ Script ที่ฝังตรงในโค้ดมักไม่ถูกควบคุมโดย Consent Mode และต้องแก้ที่ไฟล์ Theme โดยตรงแทนการปรับที่ Tag Manager เพียงอย่างเดียว

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

• ทำตารางสำรวจข้อมูลที่แต่ละฟอร์มและ Landing Page เก็บจริง
• จัดหมวด Cookie เป็น Necessary, Functional, Analytics และ Marketing ตาม Script จริง
• ตั้งค่า Default Consent State ให้ Script ที่ไม่จำเป็นเริ่มต้นที่สถานะปฏิเสธ
• ทดสอบ Script Blocking ทั้งสี่แบบ คือ Accept All, Reject All, Customize และโหลดซ้ำ
• ร่าง Privacy Policy จากผลสำรวจข้อมูลจริง ไม่ใช้ Template จากเว็บไซต์อื่น
• บันทึก Consent Log พร้อมเวลา เวอร์ชัน Policy และ Banner ที่ใช้ขณะนั้น
• กำหนดผู้รับผิดชอบและรอบทบทวนทุกครั้งที่เพิ่ม Tag หรือเปลี่ยน Theme

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

• ออกแบบ Cookie Banner ก่อนสำรวจว่าเว็บไซต์เก็บข้อมูลอะไรจริง
• จัด Pixel โฆษณาเป็นหมวด Necessary เพราะทีมการตลาดต้องการข้อมูลนี้มาก
• ทดสอบ Script Blocking เพียงครั้งเดียวตอนเปิดเว็บไซต์แล้วไม่ทดสอบซ้ำหลังอัปเดต Theme
• คัดลอก Privacy Policy จากเว็บไซต์อื่นทั้งฉบับโดยไม่แก้ให้ตรงกับสิ่งที่เก็บจริง

สรุป

การวางระบบ PDPA สำหรับ Agency อสังหาริมทรัพย์เป็นงานที่ทำเป็นลำดับขั้นได้จริง เริ่มจากสำรวจข้อมูล จัดหมวด Cookie ทดสอบการบล็อก Script ร่าง Policy จนถึงเก็บหลักฐานและกำหนดผู้รับผิดชอบ ทำให้ครบก่อนเปิดแคมเปญช่วยลดงานแก้ไขย้อนหลังได้มาก อ่านภาพรวมบทบาทของ Agency เพิ่มเติมได้ที่คู่มือ PDPA สำหรับ Agency อสังหาริมทรัพย์ หรือใช้เช็กลิสต์ก่อนเปิดใช้งานตรวจซ้ำก่อนเปิดตัวเว็บไซต์จริง

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

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