วิธี Audit การจัดหมวดหมู่คุกกี้ ของฝ่าย HR เว็บไซต์สมัครงาน และ Recruitment พร้อม Evidence ที่ควรเก็บ

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

ความจริงคือหน้าสมัครงานเป็นหนึ่งในหน้าที่มีความเสี่ยงสูงกว่าหน้าเว็บทั่วไป เพราะข้อมูลที่กรอกเข้ามาเป็นข้อมูลส่วนบุคคลของผู้สมัครโดยตรง การจัดคุกกี้ผิดหมวดหรือปล่อยให้สคริปต์วัดผลทำงานก่อนได้รับความยินยอมจึงกระทบผู้สมัครงานทุกคนที่เข้ามาที่หน้านี้ บทความนี้วางขั้นตอน Audit ที่ทีม HR และผู้ดูแลเว็บไซต์สมัครงานทำตามได้จริง พร้อมตัวอย่าง Evidence ที่ควรเก็บไว้ทุกรอบตรวจ

ทำไมหน้าสมัครงานต้องตรวจแยกจากหน้าเว็บหลัก

เว็บไซต์บริษัทส่วนใหญ่ทำ Cookie Consent Banner ไว้ที่หน้าแรกและใช้ค่าเดียวกันทั้งเว็บ แต่หน้าสมัครงานมักอยู่บนโดเมนย่อยหรือระบบ ATS (Applicant Tracking System) ของผู้ให้บริการภายนอก เช่นระบบสมัครงานที่แยกซับโดเมนออกจากเว็บหลัก ซึ่งบางครั้งไม่ได้เชื่อมกับตัวจัดการ Consent ตัวเดียวกัน ผลคือแบนเนอร์อาจไม่ปรากฏเลย หรือปรากฏแต่ไม่ได้บล็อกสคริปต์ของระบบ ATS จริง

อีกจุดที่ต่างจากหน้าเว็บทั่วไปคือฟอร์มสมัครงานมักฝังปุ่มแชร์ตำแหน่งงานไปยัง Facebook, LINE หรือ LinkedIn ซึ่งแต่ละปุ่มมีสคริปต์ของผู้ให้บริการภายนอกฝังมาด้วย และบางระบบ ATS ยังฝัง Pixel วัดผลแคมเปญสรรหาบุคลากรของตัวเองซ้อนอยู่อีกชั้น การ Audit จึงต้องแยกตรวจเป็นหน้าเฉพาะ ไม่ใช้ผลตรวจของหน้าแรกมาสรุปแทน

ขั้นตอน Audit การจัดหมวดหมู่คุกกี้ทีละขั้น

ขั้นที่ 1 — ทำ Cookie Inventory เฉพาะหน้าสมัครงาน

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

ขั้นที่ 2 — จับคู่คุกกี้แต่ละตัวกับหมวดหมู่จริง

นำรายการคุกกี้จากขั้นที่ 1 มาจัดเข้าหมวด Necessary, Functional, Analytics และ Marketing ตามลักษณะการใช้งานจริง ไม่ใช่ตามชื่อคุกกี้เพียงอย่างเดียว เช่น คุกกี้ที่เก็บสถานะฟอร์มระหว่างกรอกใบสมัครมักจัดเป็น Necessary ได้เพราะจำเป็นต่อบริการที่ผู้สมัครร้องขอ แต่คุกกี้ที่ระบบ ATS ใช้ติดตามว่าผู้สมัครมาจากแคมเปญโฆษณาใดต้องจัดเป็น Marketing แม้จะมาจากระบบเดียวกัน

ขั้นที่ 3 — ทดสอบ Timing ว่าสคริปต์ทำงานก่อนหรือหลังยินยอม

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

ขั้นที่ 4 — ตรวจปุ่มแชร์และสคริปต์ฝังจากบุคคลที่สาม

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

ขั้นที่ 5 — เทียบกับ Cookie Policy ที่เผยแพร่จริง

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

Evidence ที่ควรเก็บทุกครั้งที่ Audit

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

• ภาพหน้าจอรายการคุกกี้จากแท็บ Application/Storage พร้อมวันเวลาที่ตรวจ
• ไฟล์บันทึกคำขอเครือข่าย (Network Log) ก่อนและหลังกด Accept/Reject
• เวอร์ชันของ Cookie Policy และ Banner ที่ใช้อยู่ ณ วันตรวจ
• รายชื่อผู้ให้บริการ ATS และปลั๊กอินที่ฝังอยู่บนหน้าสมัครงาน
• รายการช่องว่างที่พบ พร้อมผู้รับผิดชอบและกำหนดแก้ไข

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

เมื่อพบคุกกี้ที่จัดหมวดผิด ควรแก้ตามลำดับอย่างไร

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

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

ตัวอย่างการมอบหมายงานแก้ไข

ใครควรเป็นเจ้าของงาน Audit นี้

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

อ่านแนวทางภาพรวมของการจัดหมวดหมู่คุกกี้สำหรับฝ่าย HR และ Recruitment ได้ที่ คู่มือการจัดหมวดหมู่คุกกี้สำหรับ HR และ Recruitment และดูสิ่งที่ควรทบทวนเป็นระยะที่ อัปเดตการจัดหมวดหมู่คุกกี้ปี 2026 สำหรับ HR ส่วนภาพรวมของหมวดคุกกี้และความยินยอมทั้งหมดอยู่ที่ ศูนย์ความรู้ Cookies & Consent

กรณีองค์กรมีหลายเว็บไซต์สมัครงานหรือหลายแบรนด์

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

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

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

หน้าสมัครงานต้องมี Cookie Consent Banner แยกจากหน้าเว็บหลักหรือไม่

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

คุกกี้ของระบบ ATS ควรจัดเป็น Necessary ทั้งหมดหรือไม่

ไม่ควร คุกกี้ที่จำเป็นต่อการทำงานของฟอร์มสมัครงาน เช่น เก็บสถานะการกรอก จัดเป็น Necessary ได้ แต่คุกกี้ที่ ATS ใช้วัดผลแคมเปญสรรหาบุคลากรต้องจัดเป็น Marketing และรอความยินยอมก่อนทำงาน

ควร Audit การจัดหมวดหมู่คุกกี้ของหน้าสมัครงานบ่อยแค่ไหน

ควร Audit ทุกครั้งที่เปลี่ยนผู้ให้บริการ ATS เพิ่มปลั๊กอินใหม่ หรือเปิดแคมเปญสรรหาบุคลากรใหม่ และควรมีรอบตรวจประจำอย่างน้อยปีละครั้งแม้ไม่มีการเปลี่ยนแปลงใด

ต้องเก็บ Evidence อะไรบ้างจากการ Audit

อย่างน้อยควรเก็บภาพหน้าจอรายการคุกกี้ Network Log ก่อนและหลังกดปุ่มยินยอม เวอร์ชันของ Cookie Policy และ Banner ที่ใช้ในวันตรวจ และรายการช่องว่างที่พบพร้อมผู้รับผิดชอบ

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

• ทำ Cookie Inventory แยกเฉพาะหน้าประกาศงาน หน้ากรอกใบสมัคร และหน้ายืนยันการส่ง
• จับคู่คุกกี้แต่ละตัวกับหมวด Necessary/Functional/Analytics/Marketing ตามการใช้งานจริง
• ทดสอบ Timing ด้วยการเคลียร์คุกกี้แล้วดู Network ก่อนกดปุ่มบนแบนเนอร์
• ทดสอบผล Accept All, Reject All และเลือกเฉพาะหมวดว่าบล็อกสคริปต์ได้จริง
• ตรวจปุ่มแชร์ตำแหน่งงานและวิดเจ็ตแผนที่ว่าถูกครอบด้วยตัวจัดการ Consent หรือไม่
• เทียบรายการคุกกี้ที่พบกับ Cookie Policy ที่เผยแพร่จริงทีละรายการ
• เก็บภาพหน้าจอและ Network Log พร้อมวันที่ตรวจไว้เป็นหลักฐาน
• กำหนด Owner และรอบตรวจซ้ำ เช่น ทุกครั้งที่เปลี่ยนผู้ให้บริการ ATS

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

• ใช้ผล Audit ของหน้าแรกเว็บบริษัทมาสรุปแทนหน้าสมัครงานทั้งที่อยู่คนละระบบ
• จัดคุกกี้ของระบบ ATS ทั้งหมดเป็น Necessary เพราะคิดว่าจำเป็นต่อการสมัครงาน ทั้งที่บางตัวใช้วัดผลแคมเปญ
• ไม่ทดสอบปุ่ม Reject All จริง เชื่อว่าการมีตัวเลือกให้กดก็เพียงพอแล้ว
• ลืมตรวจปุ่มแชร์โซเชียลและแผนที่ที่ทีมการตลาดเพิ่มเข้ามาทีหลังโดยไม่แจ้งทีม HR หรือไอที
• อัปเดต Cookie Policy ไม่ทันเมื่อเปลี่ยนผู้ให้บริการ ATS หรือเพิ่มปลั๊กอินใหม่

สรุป

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

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

• MDN Web Docs — Using HTTP Cookies
• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)