เช็กลิสต์ Google Consent Mode สำหรับฝ่าย HR เว็บไซต์สมัครงาน และ Recruitment: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

เช็กลิสต์ Google Consent Mode ส่วนใหญ่เขียนเรียงตามหมวดเทคนิคราวกับมีคนคนเดียวตรวจทุกข้อ แต่ในเว็บไซต์สมัครงานจริงมีอย่างน้อยสามฝ่ายที่ต้องรับผิดชอบคนละส่วน ฝ่าย HR ดูแลเนื้อหาและกระบวนการสรรหา ทีมไอทีดูแลโค้ดและ Tag ส่วนผู้ให้บริการ ATS หรือ Recruitment Agency ภายนอกดูแลระบบของตัวเองที่บริษัทควบคุมโดยตรงไม่ได้ เช็กลิสต์ที่แยกตามหมวดเทคนิคอย่างเดียวจึงมักไม่มีใครรับผิดชอบข้อไหนชัดเจน

เช็กลิสต์นี้แบ่งตามผู้รับผิดชอบแทน เพื่อให้แต่ละฝ่ายรู้ว่าต้องตรวจอะไรก่อนเปิดใช้งาน Google Consent Mode จริงบนเว็บไซต์สมัครงาน และรู้ว่าเมื่อถึงจุดใดต้องส่งต่อให้อีกฝ่ายตรวจต่อ

สิ่งที่ฝ่าย HR ต้องตรวจก่อนเปิดใช้งาน

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

ฝ่าย HR ยังควรตรวจว่าประกาศตำแหน่งงานที่มีลักษณะเฉพาะ เช่น ตำแหน่งที่เกี่ยวข้องกับข้อมูลสุขภาพหรือใบอนุญาตพิเศษ มีฟอร์มถามคำถามเพิ่มเติมที่อาจดึงข้อมูลอ่อนไหวมาโดยไม่ตั้งใจหรือไม่ หากมี ต้องแจ้งทีมไอทีและทีมกฎหมายให้ตรวจแยกต่างหาก

สิ่งที่ทีมไอทีหรือนักพัฒนาเว็บไซต์ต้องตรวจ

ทีมไอทีรับผิดชอบตรวจว่า Default Consent State ถูกตั้งก่อน Container โหลด Tag อื่น โดยเปิดเว็บไซต์ในโหมด Incognito แล้วดู Network Request ว่าไม่มี Request ไปยัง Google Analytics หรือ Google Ads เกิดขึ้นก่อน Banner ปรากฏ และตรวจว่าค่า Default ของ ad_storage, analytics_storage, ad_user_data และ ad_personalization ตั้งเป็น denied ไว้ก่อนสำหรับผู้ใช้ที่ยังไม่ได้เลือก

ตรวจ Landing Page ของแคมเปญเฉพาะกิจแยกจากเว็บหลัก

ทีมไอทีต้องตรวจว่า Landing Page ของตำแหน่งงานเฉพาะกิจที่สร้างแยกไว้สำหรับแคมเปญโฆษณาใช้ Container เดียวกับเว็บหลักหรือแยกต่างหาก เพราะถ้าแยก Container ต้องตั้ง Default Consent State ซ้ำอีกชุดหนึ่งบน Container นั้นด้วย ไม่ใช่พึ่งพาการตั้งค่าที่ทำไว้บนเว็บหลักเพียงจุดเดียว

สิ่งที่ต้องยืนยันกับผู้ให้บริการ ATS ภายนอก

เมื่อบริษัทใช้ระบบ ATS ของผู้ให้บริการภายนอก ต้องมีคนสอบถามผู้ให้บริการโดยตรงว่าแพลตฟอร์มรองรับการรับค่า Consent จากเว็บหลักหรือมี Parameter ส่งต่อ Consent State หรือไม่ คำถามนี้ไม่ใช่หน้าที่ของทีมไอทีเพียงฝ่ายเดียว เพราะบางครั้งฝ่าย HR เป็นผู้ดูแลสัญญากับผู้ให้บริการ ATS โดยตรงและมีช่องทางติดต่อที่ทีมไอทีไม่มี

หากผู้ให้บริการ ATS ไม่รองรับการรับค่า Consent ต้องบันทึกไว้เป็นข้อจำกัดที่ทราบ และตกลงร่วมกันว่า Tag บนระบบ ATS นั้นจะถูกจัดการอย่างไร เช่น ปิด Tag ที่ไม่จำเป็นไว้ก่อนจนกว่าจะได้คำตอบชัดเจนจากผู้ให้บริการ

สิ่งที่ต้องยืนยันกับ Recruitment Agency หรือ Headhunter ภายนอก

หากบริษัทให้ Recruitment Agency ช่วยคัดกรองผู้สมัครหรือดูแลขั้นตอน Offer ต่อ ต้องตรวจว่า Agency มีเว็บไซต์หรือระบบของตัวเองที่ผู้สมัครต้องกรอกข้อมูลเพิ่มหรือไม่ และใครเป็นผู้รับผิดชอบ Consent Mode และ Cookie Inventory ของฝั่งนั้น หากบริษัทไม่มี Agency ภายนอกเข้ามาเกี่ยวข้อง หมวดนี้ไม่จำเป็นต้องตรวจ แต่ควรบันทึกไว้ว่าปัจจุบันไม่มี เพื่อให้ทบทวนใหม่หากมีการเปลี่ยนแปลงในอนาคต

การทดสอบร่วมกันก่อนวันเปิดรับสมัครจริง

ก่อนเปิดใช้งานจริง ทั้งสามฝ่ายควรทดสอบร่วมกันอย่างน้อยหนึ่งรอบ โดยจำลองเป็นผู้สมัครกด Accept All, Reject All และเลือกแบบ Custom แล้วไล่ตรวจ Consent Signal ตลอดเส้นทางตั้งแต่หน้าประกาศงานไปจนถึงระบบ ATS ฝ่าย HR ตรวจว่าข้อความและตัวเลือกบน Banner ตรงกับที่คาดหวัง ทีมไอทีตรวจ Consent Signal ทางเทคนิค และหากมี Agency ภายนอกร่วมด้วย ควรให้ Agency ยืนยันผลการทดสอบฝั่งของตัวเองกลับมาด้วย

เอกสาร Evidence และผู้ลงนามอนุมัติ

ก่อนกด Publish Container จริง ควรมีผู้อนุมัติอย่างน้อยหนึ่งคนที่ไม่ใช่ผู้แก้ไข Container เอง และบันทึกภาพหน้าจอผลการทดสอบทั้งสามสถานการณ์ วันที่ทดสอบ และรายชื่อผู้รับผิดชอบแต่ละฝ่ายไว้เป็น Evidence เพื่อให้เมื่อมีการเปลี่ยนแปลง Tag ในอนาคต มีจุดเทียบเคียงว่าเดิมทดสอบผ่านอย่างไร

เมื่อใดควรส่งต่อผู้เชี่ยวชาญด้านกฎหมาย

เช็กลิสต์นี้ครอบคลุมเฉพาะการตั้งค่าทางเทคนิคของ Consent Mode ไม่ใช่การยืนยันฐานทางกฎหมายสำหรับข้อมูลที่เก็บในกระบวนการสรรหา หากตำแหน่งงานเกี่ยวข้องกับข้อมูลสุขภาพ ศาสนา หรือมีการโอนข้อมูลผู้สมัครไปยัง Agency ต่างประเทศ ควรให้ทีมกฎหมายหรือ DPO ตรวจประเด็นฐานทางกฎหมายควบคู่ไปกับเช็กลิสต์ทางเทคนิคนี้

บทบาทของเครื่องมืออย่าง trusty

trusty ช่วยสแกน Cookie และ Tracking Script บนหน้าเว็บสาธารณะของเว็บไซต์สมัครงานเพื่อให้ทีมไอทีใช้ตรวจซ้ำก่อนกด Publish แต่ไม่ครอบคลุมระบบ ATS ที่ต้อง Login หรือระบบของ Recruitment Agency ภายนอก ฝ่ายที่เกี่ยวข้องจึงยังต้องยืนยันข้อมูลกับผู้ให้บริการโดยตรงตามหมวดที่สามและสี่ข้างต้น

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

เช็กลิสต์นี้ต่างจากเช็กลิสต์ Google Consent Mode ทั่วไปอย่างไร เช็กลิสต์ทั่วไปมักแบ่งตามหมวดเทคนิคอย่างเดียว ส่วนเช็กลิสต์นี้แบ่งตามผู้รับผิดชอบคือฝ่าย HR ทีมไอที ผู้ให้บริการ ATS และ Recruitment Agency ภายนอก เพื่อให้แต่ละฝ่ายรู้ว่าต้องตรวจข้อไหนด้วยตัวเอง

ถ้าไม่มี Recruitment Agency ภายนอก ยังต้องดูหมวดนั้นหรือไม่ ยังควรตรวจว่าปัจจุบันไม่มี Agency ภายนอกเข้ามาเกี่ยวข้องจริง และบันทึกไว้เพื่อทบทวนใหม่หากบริษัทเริ่มใช้ Agency ในอนาคต ไม่ใช่ข้ามหมวดนี้ไปเฉย ๆ

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

trusty ช่วยฝ่ายใดในเช็กลิสต์นี้ได้บ้าง trusty ช่วยทีมไอทีสแกน Cookie และ Tracking Script บนหน้าเว็บสาธารณะเพื่อตรวจซ้ำก่อน Publish แต่ไม่ครอบคลุมระบบ ATS ที่ต้อง Login หรือระบบของ Recruitment Agency ภายนอก

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

สำหรับขั้นตอนวางระบบตามเส้นทางผู้สมัครแบบเต็มรูปแบบ ดูเพิ่มเติมได้ที่ วิธีวางระบบ Google Consent Mode สำหรับฝ่าย HR และดูภาพรวม Consent Mode ได้ที่ Google Consent Mode คืออะไร สำหรับฝ่าย HR

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

• ฝ่าย HR ยืนยันข้อความ Banner ตรงกับวัตถุประสงค์จริงของฟอร์มสมัครงาน
• ทีมไอทีตรวจ Default Consent State ด้วย Network Request ก่อน Banner ปรากฏ
• ทีมไอทีตรวจ Landing Page ตำแหน่งงานเฉพาะกิจว่าใช้ Container เดียวกับเว็บหลักหรือไม่
• สอบถามผู้ให้บริการ ATS ว่ารองรับการรับค่า Consent จากเว็บหลักหรือไม่
• ตรวจว่ามี Recruitment Agency ภายนอกเข้ามาเกี่ยวข้องหรือไม่ และใครดูแล Consent ฝั่งนั้น
• ทดสอบร่วมกันสามฝ่ายด้วย Accept All, Reject All, Custom ก่อนวันเปิดรับสมัคร
• ให้ผู้อนุมัติที่ไม่ใช่ผู้แก้ไข Container ตรวจทานและบันทึก Evidence ก่อน Publish จริง

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

• ให้ทีมไอทีตรวจเช็กลิสต์ทั้งหมดคนเดียวโดยไม่ให้ฝ่าย HR ยืนยันเนื้อหา Banner
• ไม่มีใครสอบถามผู้ให้บริการ ATS จนกว่าจะเปิดใช้งานไปแล้วพบปัญหา
• ลืมตรวจ Landing Page ตำแหน่งงานเฉพาะกิจที่แยก Container จากเว็บหลัก
• ปล่อยให้ Recruitment Agency ดูแล Consent ฝั่งตัวเองโดยไม่มีใครยืนยันผลทดสอบกลับมา
• Publish Container จริงโดยไม่มีผู้อนุมัติตรวจทานผลการทดสอบก่อน

สรุป

เช็กลิสต์ Google Consent Mode สำหรับเว็บไซต์สมัครงานทำงานได้ดีที่สุดเมื่อแบ่งตามผู้รับผิดชอบ ไม่ใช่ให้ฝ่ายใดฝ่ายหนึ่งแบกรับทุกข้อคนเดียว ฝ่าย HR ดูแลเนื้อหาและกระบวนการสรรหา ทีมไอทีดูแลการตั้งค่าทางเทคนิค ส่วนผู้ให้บริการ ATS และ Recruitment Agency ภายนอกต้องถูกสอบถามโดยตรงว่ารองรับการรับค่า Consent หรือไม่ ประเด็นฐานทางกฎหมายสำหรับข้อมูลอ่อนไหวยังคงต้องส่งต่อผู้เชี่ยวชาญแยกจากเช็กลิสต์ทางเทคนิคนี้เสมอ

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

• Google Ads Help — About Consent Mode
• Google Tag Manager Help — Consent Mode overview