วิธีวางระบบ GA4 และความเป็นส่วนตัว สำหรับฝ่าย HR เว็บไซต์สมัครงาน และ Recruitment แบบเป็นขั้นตอน

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

ความต่างของสองบริษัทนี้อยู่ที่การวางระบบตั้งแต่แรกเป็นขั้นตอน ไม่ใช่ติดตั้งแล้วค่อยแก้ทีหลัง คู่มือนี้แนะนำ 5 ขั้นตอนที่ฝ่าย HR และทีม IT ใช้ร่วมกันเพื่อวางระบบ GA4 และความเป็นส่วนตัวบนเว็บไซต์สมัครงานให้ถูกต้องตั้งแต่ต้น ดูภาพรวมเพิ่มเติมได้ที่หมวด Tracking & MarTech

ขั้นตอนที่ 1: สำรวจ Touchpoint บนเว็บสมัครงาน

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

ขั้นตอนนี้ควรทำร่วมกันระหว่าง HR ที่รู้ว่า Journey การสมัครงานจริงมีกี่ขั้น และทีม IT ที่รู้ว่า Tag ไหนติดตั้งอยู่ตรงไหน เพราะ HR มักไม่รู้ว่ามี Tag ติดอยู่ และ IT มักไม่รู้ว่าฟอร์มไหนขอข้อมูลอะไรบ้าง

ขั้นตอนที่ 2: ตั้งค่า Consent Mode Default ก่อน GA4 ยิง Tag

ในกล่อง Google Tag Manager ให้ตั้งค่า Default Consent State เป็น denied สำหรับทุก Category ก่อนที่หน้าเว็บจะโหลด Tag ใด ๆ แล้วค่อยเขียน Tag ให้อัปเดตสถานะเป็น granted เฉพาะ Category ที่ผู้สมัครเลือกยินยอมจริงหลังโต้ตอบกับ Banner การตั้งค่าลำดับนี้สำคัญ เพราะถ้าสลับลำดับ Tag จะยิงเต็มรูปแบบไปก่อนแล้วค่อยพยายามหยุดทีหลัง ซึ่งข้อมูลที่เก็บไปแล้วดึงกลับไม่ได้

ทดสอบด้วยเครื่องมืออย่าง Tag Assistant ทันทีหลังตั้งค่า เพื่อยืนยันว่า Consent State ที่ Tag ได้รับตรงกับที่ตั้งไว้จริง ไม่ใช่ดูจากหน้าตา Banner เพียงอย่างเดียว

ขั้นตอนที่ 3: จับคู่ Category กับระบบ ATS ที่รับข้อมูลผู้สมัคร

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

ในขั้นตอนนี้ควรทำตารางเทียบง่าย ๆ ระหว่าง Category ของ Consent, Tag ที่เกี่ยวข้อง, และระบบปลายทางที่รับข้อมูล เพื่อให้เห็นภาพรวมทั้งสายไม่ใช่ดูทีละจุดแยกกัน

Category	Tag ที่เกี่ยวข้อง	ระบบปลายทาง
Necessary	Session ฟอร์มหลายหน้า	เว็บไซต์สมัครงาน
Analytics	GA4	Google Analytics
Marketing	Remarketing Tag แคมเปญรับสมัคร	แพลตฟอร์มโฆษณา
ข้อมูลใบสมัคร	ฟอร์มส่งข้อมูลตรง	ATS

กรณีใช้ Google Tag Manager แบบ Server-side

บางองค์กรย้าย GA4 ไปทำงานผ่าน Google Tag Manager แบบ Server-side เพื่อควบคุมข้อมูลที่ส่งออกได้ละเอียดขึ้นและลดผลกระทบจาก Ad Blocker แต่การย้ายมาใช้ Server-side ไม่ได้แปลว่าเรื่อง Consent หมดความสำคัญไป ทีม IT ยังต้องส่งค่าสถานะ Consent จากฝั่ง Client ไปยัง Server Container ให้ถูกต้อง เพราะถ้า Server Container ประมวลผลและส่งข้อมูลต่อไปยัง GA4 โดยไม่ตรวจสอบสถานะ Consent ก่อน ก็เท่ากับข้อมูลของผู้สมัครที่ Reject ไปแล้วยังถูกส่งออกอยู่ดี เพียงแต่ย้ายจุดที่รั่วไหลจาก Client มาที่ Server แทน

ทีมที่ใช้ Server-side ควรทดสอบเพิ่มอีกชั้นหนึ่ง คือตรวจ Log ฝั่ง Server Container ว่า Request ที่ส่งต่อไปยัง GA4 มีการแนบสถานะ Consent ไปด้วยจริง และ Server หยุดส่งข้อมูลเมื่อสถานะเป็น denied เช่นเดียวกับที่ทดสอบฝั่ง Client

เมื่อ ATS เป็นระบบของผู้ให้บริการต่างประเทศ

หลายองค์กรใช้ ATS ที่เป็นบริการของผู้ให้บริการต่างประเทศ ซึ่งข้อมูลผู้สมัครที่ส่งจากเว็บไซต์ไทยจะถูกส่งไปประมวลผลบนเซิร์ฟเวอร์ที่อาจอยู่นอกประเทศ ในขั้นตอนที่ 3 นอกจากจับคู่ Category กับระบบปลายทางแล้ว ทีม HR ควรตรวจเพิ่มว่าผู้ให้บริการ ATS รายนั้นมีเอกสารข้อตกลงการประมวลผลข้อมูล (Data Processing Agreement) กับองค์กรหรือไม่ และ Privacy Policy ของเว็บสมัครงานเปิดเผยเรื่องผู้ให้บริการต่างประเทศรายนี้ไว้ชัดเจนหรือไม่ ขั้นตอนนี้เป็นงานเอกสารที่ควรทำคู่ขนานไปกับการตั้งค่าทางเทคนิค ไม่ใช่รอให้ตั้งค่าเสร็จก่อนแล้วค่อยย้อนกลับมาทำทีหลัง

ขั้นตอนที่ 4: ทดสอบ Reject All บน Journey สมัครงานจริง

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

ทดสอบซ้ำอีกครั้งหลังกด Accept All และหลังเลือกบางหมวดแบบ Custom เพื่อยืนยันว่าพฤติกรรมของ Tag เปลี่ยนตามที่ผู้สมัครเลือกจริงในทุกกรณี ไม่ใช่แค่กรณีใดกรณีหนึ่ง ดูเช็กลิสต์และแนวคิดพื้นฐานเพิ่มเติมได้ใน GA4 และความเป็นส่วนตัว คืออะไร? คู่มือสำหรับฝ่าย HR

ลิงก์แนะนำพนักงาน (Employee Referral) ต้องตรวจแยกต่างหาก

โปรแกรมแนะนำพนักงานมักใช้ลิงก์พิเศษที่ฝังรหัสพนักงานผู้แนะนำไว้ใน URL เช่น ?ref=EMP1234 เพื่อคำนวณค่าตอบแทนแนะนำภายหลัง ลิงก์ลักษณะนี้เมื่อผู้สมัครกดเข้ามาที่หน้าเว็บสมัครงาน GA4 อาจบันทึก Full URL รวมถึงรหัสพนักงานไว้ในรายงานโดยอัตโนมัติ ซึ่งไม่ใช่ข้อมูลของผู้สมัครโดยตรงแต่เป็นข้อมูลของพนักงานที่แนะนำ ทีม IT ควรตรวจว่าพารามิเตอร์ประเภทนี้ถูกกรองออกจากรายงานสาธารณะภายในองค์กรหรือจำกัดการเข้าถึงเฉพาะทีมที่คำนวณค่าตอบแทน ไม่ปล่อยให้ปรากฏในรายงานทั่วไปที่พนักงานคนอื่นเข้าถึงได้

ขั้นตอนที่ 5: เก็บ Evidence และมอบหมาย Owner ฝั่ง HR และ IT

บันทึกภาพหน้าจอ Banner เวอร์ชันที่ใช้งานจริง ผล Network Tab ของทั้งสามสถานการณ์ในขั้นตอนที่ 4 และตารางจับคู่ Category กับระบบปลายทางจากขั้นตอนที่ 3 ไว้เป็นหลักฐานพร้อมวันที่ตรวจ เอกสารเหล่านี้ใช้อ้างอิงเมื่อมีการเปลี่ยนแคมเปญรับสมัครงานใหม่หรือเปลี่ยนระบบ ATS ในอนาคต

สุดท้ายมอบหมาย Owner ให้ชัดเจนว่าฝ่าย HR รับผิดชอบตรวจสอบว่าข้อมูลผู้สมัครที่ ATS รับไปสอดคล้องกับ Consent หรือไม่ ส่วนทีม IT รับผิดชอบดูแล Google Tag Manager Container และทดสอบ Consent Mode ทุกครั้งที่มีการเปลี่ยนแปลงระบบ การแบ่งบทบาทชัดเจนช่วยไม่ให้งานนี้ตกหล่นเมื่อมีการเปลี่ยนทีมงาน

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

• ทำรายการ Touchpoint ทั้งหมดของเว็บสมัครงานรวมระบบ ATS ที่รับข้อมูลต่อ
• ตั้งค่า Default Consent State เป็น denied ก่อน Tag ใด ๆ ยิงใน Google Tag Manager
• ทดสอบด้วย Tag Assistant ยืนยันว่า Consent State ที่ Tag ได้รับตรงกับที่ตั้งไว้จริง
• ทำตารางจับคู่ Category ของ Consent กับ Tag และระบบปลายทางที่รับข้อมูล
• ทดสอบ Reject All, Accept All และ Custom บน Journey สมัครงานจริงทุกกรณี
• ยืนยันว่าการกด Reject All ไม่กระทบความสามารถในการยื่นใบสมัคร
• เก็บ Evidence พร้อมวันที่ตรวจ และมอบหมาย Owner ฝั่ง HR และ IT ให้ชัดเจน

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

• เปิดใช้งาน GA4 บนเว็บสมัครงานตั้งแต่วันแรกโดยไม่ตั้งค่า Consent Mode เพราะต้องการเห็นตัวเลขผู้เข้าชมให้เร็วที่สุด
• ทดสอบเฉพาะกรณี Accept All เพราะเป็นกรณีที่ทีมการตลาดสนใจมากที่สุด แต่ไม่ทดสอบกรณี Reject All ให้ครบ
• ไม่ตรวจว่า ATS ที่รับข้อมูลต่อจากเว็บไซต์ใช้ข้อมูลผู้สมัครสอดคล้องกับ Consent ที่เลือกไว้หรือไม่
• มอบหมายให้ทีมเดียวรับผิดชอบทั้งหมด โดยไม่แบ่งบทบาทระหว่าง HR และ IT ให้ชัดเจน ทำให้งานตกหล่นเมื่อเปลี่ยนทีมงาน

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

ทีมงานมักถามว่าการกด Reject All จะทำให้ผู้สมัครส่งใบสมัครไม่ได้หรือไม่ คำตอบคือไม่ควรเป็นแบบนั้น การกด Reject All ควรกระทบเฉพาะ Tag ด้าน Analytics และ Marketing เท่านั้น ส่วน Cookie ที่จำเป็นต่อการกรอกและส่งฟอร์มควรทำงานได้ตามปกติ

อีกคำถามที่พบบ่อยคือหากองค์กรมีเว็บสมัครงานหลายภาษา เช่น หน้าภาษาไทยและภาษาอังกฤษแยกกัน ต้องตั้งค่า Consent Mode แยกกันหรือไม่ คำตอบคือใช้ Container และการตั้งค่าเดียวกันได้ถ้าทั้งสองภาษาอยู่บนโดเมนเดียวกัน แต่ต้องทดสอบ Journey ของทั้งสองภาษาแยกกันในขั้นตอนที่ 4 เพราะข้อความบน Banner และ Privacy Policy ที่แสดงผลอาจต่างกัน และทีมที่แปลเนื้อหาอาจตกหล่นบางส่วนที่ฉบับภาษาไทยมีแต่ฉบับแปลไม่มี

สรุป

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

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

• Google Ads Help — About Consent Mode
• Google Analytics Help — Consent settings in Google Analytics
• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC Thailand)