วิธี Audit GA4 และความเป็นส่วนตัว สำหรับโรงเรียน มหาวิทยาลัย และธุรกิจการศึกษา

ทีมไอทีของโรงเรียนหรือมหาวิทยาลัยส่วนใหญ่ติดตั้ง Google Analytics 4 ไว้นานแล้วบนเว็บไซต์รับสมัครนักเรียน หน้า LMS หรือพอร์ทัลของโรงเรียน แต่ไม่มีใครกลับไปตรวจซ้ำว่า Consent Mode ทำงานถูกต้องหรือไม่ เพราะทีมไอทีของสถานศึกษามักมีคนเดียวหรือสองคนที่ดูแลทั้งระบบเครือข่าย เว็บไซต์ และ LMS พร้อมกัน จนไม่มีเวลาตรวจ Tracking Script ที่ฝังไว้ตั้งแต่วันแรก

บทความนี้เป็นคู่มือ Audit สำหรับตรวจว่า GA4 บนเว็บไซต์สถานศึกษาเก็บข้อมูลถูกต้องตามที่ Consent Mode ควรทำงาน และไม่ได้เก็บข้อมูลนักเรียนหรือผู้ปกครองเกินกว่าที่จำเป็น

ทำไมสถานศึกษาต้องตรวจ GA4 ต่างจากเว็บไซต์ทั่วไป

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

อีกจุดที่ต้องตรวจแยกคือ LMS (Learning Management System) และพอร์ทัลนักเรียนที่บางแห่งฝัง Google Analytics ของตัวเองแยกจากเว็บไซต์หลัก ทำให้ทีมไอทีต้องตรวจสองระบบ ไม่ใช่ระบบเดียว และบางครั้ง LMS เป็นซอฟต์แวร์สำเร็จรูปที่ทีมไอทีปรับ Consent Mode เองไม่ได้โดยตรง ต้องประสานกับผู้ให้บริการ

ตรวจสอบว่าเว็บไซต์ใช้ GA4 เวอร์ชันเดียวกันทุกหน้าหรือไม่

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

วิธีตรวจที่ทำได้เร็วคือค้นหาคำว่า gtag หรือ analytics ในโค้ดต้นฉบับของทุกเทมเพลตหน้าเว็บไซต์ แล้วเทียบว่า Tracking ID ที่พบตรงกับ GA4 Property ปัจจุบันหรือไม่ หากพบ ID เก่าที่ไม่ได้ใช้งานแล้วควรนำออกเพื่อลดความสับสนและลดจำนวนสคริปต์ที่ต้องดูแลด้าน Consent

ขั้นตอน Audit GA4 Consent Mode

ขั้นที่ 1 ตรวจ Default Consent State

เปิดโหมด Network ของเบราว์เซอร์แล้วโหลดหน้าเว็บไซต์สถานศึกษาก่อนกดปุ่มใด ๆ บน Cookie Banner ตรวจว่า Request ที่ส่งไปยัง Google Analytics มีพารามิเตอร์บ่งชี้ว่า Consent เป็น Denied อยู่หรือไม่ ถ้า Request ส่งข้อมูลแบบเต็มโดยไม่มีสถานะ Denied แสดงว่า Default Consent State ยังไม่ได้ตั้งไว้ก่อนโหลด Tag

ขั้นที่ 2 ตรวจการอัปเดตหลังผู้ใช้เลือก

กดปุ่มยอมรับหรือปฏิเสธบน Banner แล้วสังเกตว่า Request ถัดไปเปลี่ยนสถานะ Consent ตามที่ผู้ใช้เลือกจริงหรือไม่ ปัญหาที่พบบ่อยในเว็บไซต์สถานศึกษาคือปุ่ม Reject ใช้งานได้ แต่ Consent Mode ไม่ได้อัปเดตสถานะ ทำให้ GA4 ยังเก็บข้อมูลเหมือนเดิม

ขั้นที่ 3 ตรวจการตั้งค่า IP Anonymization และ Data Retention ใน GA4

เข้าไปที่ Admin ของ GA4 Property ตรวจการตั้งค่า Data Retention ว่ากำหนดไว้กี่เดือน และตรวจว่าฟีเจอร์ที่เกี่ยวข้องกับการลดความละเอียดของข้อมูล IP ถูกเปิดใช้ตามค่าที่ Google กำหนดในเวอร์ชันปัจจุบันหรือไม่ เนื่องจากการตั้งค่านี้เปลี่ยนแปลงได้ตามอัปเดตของ Google จึงควรตรวจจากหน้า Google Analytics Help ล่าสุดทุกครั้งที่ Audit ไม่ใช้ค่าจากความจำ

ขั้นที่ 4 ตรวจแบบฟอร์มรับสมัครแยกจากหน้าเนื้อหาทั่วไป

ตรวจว่าหน้าแบบฟอร์มรับสมัครนักเรียนมีการยิง Event ไปยัง GA4 ที่รวมค่าจากช่องกรอกข้อมูลส่วนตัวโดยไม่ตั้งใจหรือไม่ เช่น Event ที่แนบชื่อหรืออีเมลของผู้สมัครเป็นค่าพารามิเตอร์ ซึ่งเป็นรูปแบบผิดพลาดที่พบได้ในเว็บไซต์ที่ตั้งค่า GTM โดยทีมที่ไม่ได้เชี่ยวชาญด้าน Privacy

จุดที่มักถูกมองข้ามในการตั้งค่า GTM ของเว็บไซต์สถานศึกษา

สถานศึกษาหลายแห่งใช้ Google Tag Manager ตัวเดียวกันคุมทั้งเว็บไซต์หลักและหน้าแคมเปญประชาสัมพันธ์ที่ทำขึ้นชั่วคราว เช่น หน้า Event วันเปิดบ้าน หรือหน้าประกาศผลสอบ ปัญหาที่พบคือหน้าแคมเปญเหล่านี้มักถูกสร้างเร่งด่วนโดยทีมการตลาดหรือครูที่ดูแลประชาสัมพันธ์ และมีการแปะ Tag วัดผลเพิ่มเองโดยไม่ผ่านทีมไอที ทำให้ Tag ใหม่ไม่ได้ถูกผูกกับ Trigger ที่รอ Consent เหมือน Tag เดิม

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

ความแตกต่างระหว่างเว็บไซต์รัฐและเอกชนในการตั้งค่า GA4

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

หลักฐานที่ควรเก็บหลัง Audit แต่ละครั้ง

บันทึกภาพหน้าจอ Network Request ก่อนและหลังกด Consent พร้อมวันที่ตรวจ บันทึกค่าที่ตั้งใน Data Retention ของ GA4 Property ขณะนั้น และบันทึกรายชื่อหน้าเว็บไซต์ที่ตรวจแล้วว่าไม่มี Event ส่งข้อมูลส่วนตัวเกินจำเป็น หลักฐานชุดนี้ใช้ตอบคำถามจากฝ่ายบริหารหรือผู้ปกครองที่สอบถามเรื่องการเก็บข้อมูลได้โดยไม่ต้องเดา

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

ควรตรวจ Preference Center ของสถานศึกษา ควบคู่กันไปด้วย เพราะ Consent ที่ผู้ปกครองหรือนักเรียนเลือกไว้ผ่าน Preference Center ต้องส่งผลไปถึงสถานะ Consent Mode ของ GA4 จริง ไม่ใช่แค่เปลี่ยนหน้าจอ Banner เฉย ๆ ดูภาพรวมเพิ่มเติมได้ที่ หน้ารวมความรู้ Tracking และ Martech

เมื่อพบว่าฟอร์มยิง Event พร้อมข้อมูลส่วนตัว ควรแก้ที่จุดไหนก่อน

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

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

การประสานงานระหว่างทีมไอทีกับฝ่ายรับสมัครในช่วงเปิดรอบใหม่

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

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

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

ต้อง Audit GA4 บ่อยแค่ไหนสำหรับเว็บไซต์สถานศึกษา

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

LMS ที่เป็นซอฟต์แวร์สำเร็จรูปต้องตรวจ Consent Mode เองได้หรือไม่

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

แบบฟอร์มรับสมัครที่มีข้อมูลผู้เยาว์ต้องตั้งค่า GA4 ต่างจากหน้าอื่นหรือไม่

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

ถ้าพบว่า Consent Mode ไม่ทำงานตามที่ควร ต้องทำอะไรก่อน

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

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

• ตรวจ Request ของ GA4 ก่อนกด Consent ว่ามีสถานะ Denied ตั้งไว้เป็นค่าเริ่มต้นหรือไม่
• ทดสอบปุ่ม Accept และ Reject บน Banner แล้วยืนยันว่า Consent Mode อัปเดตสถานะตามจริง
• ตรวจการตั้งค่า Data Retention ใน GA4 Admin ว่าตรงกับที่ประกาศในนโยบายความเป็นส่วนตัว
• ตรวจหน้าแบบฟอร์มรับสมัครแยกต่างหากว่าไม่มี Event ส่งข้อมูลส่วนตัวของผู้สมัคร
• สอบถามผู้ให้บริการ LMS ว่า Consent Mode ของระบบ LMS ปรับได้เองหรือต้องแจ้งผู้ให้บริการ
• บันทึกภาพหน้าจอผลตรวจและวันที่ Audit ทุกครั้งเพื่อใช้เป็นหลักฐาน
• กำหนดรอบ Audit ประจำ เช่น ทุกภาคการศึกษาและก่อนเปิดรับสมัครรอบใหม่

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

• ตั้ง GA4 ไว้ตั้งแต่สร้างเว็บไซต์แล้วไม่เคยตรวจซ้ำ ปล่อยให้ Consent Mode ทำงานผิดหลายปีโดยไม่มีใครรู้
• ตรวจเฉพาะเว็บไซต์หลัก แต่ลืมตรวจ LMS หรือพอร์ทัลนักเรียนที่ฝัง Analytics แยกต่างหาก
• แบบฟอร์มรับสมัครยิง Event ไป GA4 พร้อมแนบชื่อหรืออีเมลผู้สมัครโดยทีมไม่รู้ตัว
• ปุ่ม Reject บน Banner ใช้งานได้ แต่ Consent Mode ไม่อัปเดตสถานะจริงเบื้องหลัง
• ไม่มีการบันทึกหลักฐานการ Audit ทำให้ตอบคำถามผู้ปกครองหรือฝ่ายบริหารไม่ได้เมื่อถูกถาม

สรุป

การ Audit GA4 และความเป็นส่วนตัวของสถานศึกษาต้องตรวจทั้ง Default Consent State การอัปเดตหลังผู้ใช้เลือก การตั้งค่า Data Retention และหน้าแบบฟอร์มรับสมัครที่มีข้อมูลผู้เยาว์โดยเฉพาะ ทีมไอทีที่มีทรัพยากรจำกัดควรกำหนดรอบตรวจที่ทำได้จริง เช่น ทุกภาคการศึกษา และเก็บหลักฐานทุกครั้งเพื่อใช้ตอบคำถามในอนาคต

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

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