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

ทีมการตลาดติดตั้ง GA4 บนเว็บไซต์บริษัทเวอร์ชันเดียวแล้วใช้ Container เดียวกันกับหน้าสมัครงาน โดยไม่มีใครแยกพิจารณาว่าหน้า Career กับหน้าสินค้าเก็บข้อมูลคนละแบบ ผู้สมัครงานกรอกอีเมล เบอร์โทร และอัปโหลดเรซูเม่ ซึ่งเป็นข้อมูลส่วนบุคคลที่มีบริบทต่างจากผู้เข้าชมเว็บทั่วไป การตรวจ GA4 บนเว็บสมัครงานจึงต้องดูมากกว่าการติด Tracking Code ให้ทำงาน

เอกสารนี้เป็นเช็กลิสต์เชิงเทคนิคสำหรับฝ่าย HR ผู้ดูแลเว็บไซต์สมัครงาน และทีมที่ประสานกับ Recruitment เพื่อตรวจว่า GA4 ถูกตั้งค่าให้สอดคล้องกับ Consent ของผู้สมัคร ก่อนที่จะปล่อยให้ Event ยิงเข้า Google Analytics โดยอัตโนมัติ

ข้อมูลอะไรบ้างที่ GA4 อาจเก็บบนหน้าสมัครงาน

GA4 เปิด Enhanced Measurement เป็นค่าเริ่มต้น ซึ่งหมายความว่า Page View, Scroll, Outbound Click และ File Download จะถูกส่งเข้า GA4 ทันทีที่สคริปต์โหลด โดยไม่ต้องเขียนโค้ดเพิ่ม บนหน้าสมัครงาน เหตุการณ์เหล่านี้จับพฤติกรรมที่เชื่อมโยงกับผู้สมัครได้ เช่น scroll ถึงส่วนเงินเดือนแล้วออกจากหน้า หรือคลิกลิงก์ไปหน้า LinkedIn ของบริษัท

สิ่งที่ต้องตรวจเพิ่มคือ Session ที่มาจาก UTM ของแคมเปญรับสมัครงาน เพราะ GA4 จะผูก Traffic Source กับ Session ID และถ้ามีการส่ง User ID หรือ Client ID เข้าไปยัง ATS (Applicant Tracking System) ด้วย ก็มีความเสี่ยงที่ข้อมูลพฤติกรรมใน GA4 จะเชื่อมกับตัวตนของผู้สมัครจริงโดยที่ Privacy Policy ของเว็บสมัครงานไม่ได้ระบุไว้

ตั้งค่า Consent Mode ก่อน GA4 เริ่มยิง Event บนหน้าสมัครงาน

หลักการของ Google Consent Mode คือกำหนด Default Consent State เป็น denied ก่อนที่ Tag ใดจะทำงาน แล้วอัปเดตเป็น granted เฉพาะเมื่อผู้ใช้เลือกยอมรับหมวดที่เกี่ยวข้องจาก Banner จริง สำหรับหน้าสมัครงานที่มักมีอัตราการออกจากหน้ากลางฟอร์มสูง ทีมพัฒนาต้องตรวจว่า analytics_storage และ ad_storage ถูก denied ตั้งแต่โหลดหน้าแรก ไม่ใช่แค่ซ่อน Banner ไว้ด้านบน

สิ่งที่พลาดบ่อยคือ Container เดียวกันถูกใช้ทั้งเว็บหลักและ Sub-domain ของหน้าสมัครงาน (เช่น careers.บริษัท.com) แล้ว Consent State ที่ตั้งไว้บนโดเมนหลักไม่ถูกส่งต่อไปยัง Sub-domain ทำให้ GA4 บนหน้าสมัครงานเริ่มยิง Event ก่อนผู้สมัครเห็น Banner ด้วยซ้ำ ต้องทดสอบแยกเป็นรายโดเมนด้วย Tag Assistant หรือเครื่องมือ Debug ของ GTM ปัจจุบัน

IP Anonymization และการเก็บข้อมูลผู้สมัครใน GA4

GA4 ไม่มีสวิตช์ Anonymize IP แบบที่ Universal Analytics เคยมี เพราะ GA4 ออกแบบให้ไม่เก็บ IP Address แบบเต็มไว้ในรายงานตั้งแต่ต้น แต่ยังใช้ IP ชั่วขณะเพื่อประมาณตำแหน่งภูมิศาสตร์ก่อนตัดทิ้ง สิ่งที่ทีม HR ควรตรวจคือการตั้งค่า Google Signals และ Data Sharing Settings ในระดับ Property เพราะสองส่วนนี้เกี่ยวกับการรวมข้อมูลข้ามอุปกรณ์ ซึ่งไม่จำเป็นสำหรับ Career Site ที่ไม่ได้ทำ Remarketing

ระยะเก็บข้อมูล (Data Retention) กับผู้สมัครที่ถูกปฏิเสธ

ใน GA4 Admin เมนู Data Settings มีค่า Data Retention ให้เลือก 2 เดือนหรือ 14 เดือนสำหรับข้อมูลระดับ Event ที่ผูกกับ User-property และ Audience นี่คือค่าที่ควบคุมเฉพาะข้อมูลฝั่ง GA4 เท่านั้น แยกขาดจากระยะเก็บข้อมูลผู้สมัครที่ถูกปฏิเสธในระบบ ATS หรือฐานข้อมูล HR ซึ่งมักมีนโยบายเก็บยาวกว่าเพื่อเปิดตำแหน่งใหม่ในอนาคต

ช่องว่างที่พบบ่อยคือทีม HR ตั้งนโยบายลบข้อมูลผู้สมัครที่ถูกปฏิเสธหลังจากพ้นระยะหนึ่ง แต่ไม่มีใครตรวจว่า Log พฤติกรรมของผู้สมัครคนเดียวกันใน GA4 (ผ่าน Client ID หรือ Session ที่เชื่อมโยงได้) ยังถูกเก็บอยู่หรือถูกลบไปพร้อมกันหรือไม่ การตรวจ Retention ของทั้งสองระบบจึงควรทำพร้อมกัน ไม่ใช่แยกทีมตรวจคนละช่วงเวลา

ระบบสมัครงานที่ฝัง Widget จาก LinkedIn, JobsDB และ ATS ภายนอก

เว็บสมัครงานส่วนใหญ่ฝัง Widget แสดงตำแหน่งงานจาก JobsDB, LinkedIn Job Board หรือปลั๊กอิน ATS ที่โหลดเป็น iframe หรือสคริปต์แยก Widget เหล่านี้มักตั้งคุกกี้ของตัวเองทันทีที่โหลด โดยไม่รอ Consent จาก Banner ของเว็บหลัก เพราะเป็นสคริปต์บุคคลที่สามที่ไม่ได้ผ่าน Tag Manager เดียวกันกับ GA4

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

แบบฟอร์มอัปโหลดเรซูเม่กับ GA4 Event Parameter

ฟอร์มสมัครงานมักส่ง Custom Event เช่น resume_upload หรือ application_submit เข้า GA4 เพื่อวัด Conversion การตั้งค่านี้ต้องตรวจว่า Event Parameter ที่ส่งไปไม่มีชื่อ อีเมล เบอร์โทร หรือชื่อไฟล์เรซูเม่ติดไปด้วย เพราะ Google Analytics ไม่อนุญาตให้ส่งข้อมูลที่ระบุตัวบุคคลได้โดยตรงเข้า Event Parameter และถ้าพบข้อมูลลักษณะนี้ ต้องแก้ที่ Data Layer ก่อน ไม่ใช่แก้ที่ระดับรายงานภายหลัง

วิธีตรวจที่ทำได้จริงคือเปิด GA4 DebugView ระหว่างกรอกฟอร์มสมัครงานจริงในโหมดทดสอบ แล้วดูค่า Parameter ของ Event resume_upload ทีละตัวว่ามีข้อความที่อ่านออกเป็นชื่อไฟล์หรืออีเมลหลุดเข้ามาหรือไม่ ถ้า Data Layer ถูกเขียนโดยทีมพัฒนาที่ไม่ทราบข้อจำกัดนี้ มักพบว่า Parameter ชื่อ file_name หรือ applicant_email ถูกส่งเข้าไปตรง ๆ ซึ่งต้องแก้ที่ต้นทางก่อนเปิดใช้งานจริง

Cross-domain Tracking ระหว่างเว็บหลักกับหน้าสมัครงาน

หลายบริษัทแยกหน้าสมัครงานไปอยู่บน Sub-domain หรือใช้แพลตฟอร์ม ATS ของผู้ให้บริการภายนอกที่มีโดเมนของตัวเอง เมื่อผู้สมัครคลิกจากเว็บหลักไปหน้าสมัครงานจริง GA4 ต้องตั้งค่า Cross-domain Measurement ให้ถูกต้องไม่เช่นนั้น Session จะถูกตัดเป็นสอง Session แยกกัน และ Consent State ที่ผู้ใช้เลือกไว้บนโดเมนแรกอาจไม่ถูกส่งต่อไปยังโดเมนที่สอง ทีมที่ดูแล GA4 ควรตรวจรายการโดเมนใน Property Settings และทดสอบว่า Referral ระหว่างโดเมนไม่ถูกนับเป็น Traffic Source ใหม่ทุกครั้ง

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

Widget จากบุคคลที่สามต้องรอ Consent เหมือน GA4 หรือไม่ ต้องตรวจแยกเป็นรายตัว บาง Widget ตั้งคุกกี้ Tracking บางตัวไม่ตั้ง ควรขอข้อมูลจากผู้ให้บริการแล้วจัดหมวดให้ตรงกับ Banner จริง

GA4 บนหน้าสมัครงานต้องตั้งค่าต่างจากหน้าเว็บหลักหรือไม่ ควรตรวจ Consent State แยกรายโดเมนหรือ Sub-domain โดยเฉพาะ เพราะ Container เดียวกันอาจไม่ส่ง Consent ต่อกันอัตโนมัติ

ข้อมูลผู้สมัครที่ถูกปฏิเสธใน GA4 ต้องลบพร้อมข้อมูลใน ATS หรือไม่ ควรตรวจ Retention ทั้งสองระบบพร้อมกัน เพราะ Data Retention ของ GA4 ควบคุมเฉพาะข้อมูลฝั่ง GA4 แยกจากฐานข้อมูล HR

ฟอร์มอัปโหลดเรซูเม่ส่งข้อมูลผู้สมัครเข้า GA4 ได้หรือไม่ ไม่ควร Event Parameter ต้องไม่มีชื่อ อีเมล หรือชื่อไฟล์ที่ระบุตัวบุคคล ต้องแก้ที่ Data Layer

ใครควรเป็นเจ้าของการตรวจ GA4 บนเว็บสมัครงาน ควรกำหนดเจ้าของร่วมระหว่างทีมการตลาดที่ดูแล GA4 กับฝ่าย HR ที่เข้าใจข้อมูลผู้สมัคร ไม่ใช่ปล่อยให้ทีมใดทีมหนึ่งตรวจฝ่ายเดียว

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

• ตรวจว่า Default Consent State ของ analytics_storage เป็น denied ก่อนโหลดหน้าสมัครงาน
• ทดสอบ Consent Mode แยกรายโดเมนและ Sub-domain ของหน้า Career
• ตรวจการตั้งค่า Data Retention ใน GA4 Admin ให้สอดคล้องกับนโยบายเก็บข้อมูลผู้สมัครของ HR
• ตรวจ Event Parameter ของ resume_upload และ application_submit ว่าไม่มีข้อมูลระบุตัวบุคคล
• ขอรายการคุกกี้จาก Widget LinkedIn, JobsDB และ ATS ภายนอกแล้วจัดหมวดให้ตรง Banner
• ปิด Google Signals บน Property ของหน้าสมัครงานหากไม่ได้ใช้ Remarketing
• กำหนดเจ้าของร่วมระหว่างทีมการตลาดและฝ่าย HR สำหรับการตรวจซ้ำทุกไตรมาส

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

• ใช้ GTM Container เดียวกับเว็บหลักโดยไม่ตรวจ Consent State แยกโดเมนของหน้าสมัครงาน
• ปล่อยให้ Widget จากบุคคลที่สามตั้งคุกกี้ก่อนผู้สมัครเห็น Banner เพราะคิดว่าไม่ใช่ Tracking Script
• ตั้ง Data Retention ของ GA4 โดยไม่เทียบกับนโยบายลบข้อมูลผู้สมัครที่ถูกปฏิเสธของ HR
• ส่งชื่อไฟล์เรซูเม่หรืออีเมลผู้สมัครเข้า Event Parameter โดยไม่รู้ตัว
• ไม่มีใครเป็นเจ้าของการตรวจซ้ำ ปล่อยให้การตั้งค่าเดิมค้างอยู่ทั้งปี

สรุป

เว็บไซต์สมัครงานมีข้อมูลผู้สมัครที่ต้องดูแลต่างจากเว็บทั่วไป การตั้งค่า GA4 บนหน้าเหล่านี้จึงต้องตรวจทั้ง Consent Mode, Data Retention, Event Parameter และคุกกี้จาก Widget ภายนอกไปพร้อมกัน เช็กลิสต์นี้ช่วยให้ทีม HR และทีมการตลาดตรวจจุดที่มักถูกมองข้ามได้ตรงจุดมากขึ้น แต่ยังต้องปรับตามระบบ ATS และ Widget ที่แต่ละบริษัทใช้จริง

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

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

ดูภาพรวมการตั้งค่า ความเป็นส่วนตัวในเครื่องมือ Tracking และ Martech หรือเทียบแนวทางสำหรับร้านค้าออนไลน์ใน GA4 และความเป็นส่วนตัวสำหรับ E-commerce เพื่อดูว่าการจัดการ Consent ต่างบริบทกันอย่างไร