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

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

ขั้นตอนที่ 1 ทำบัญชีคุกกี้ทั้งหมดที่ใช้งานจริงในระบบของสถานศึกษา

เริ่มจากไล่เปิด Developer Tools บนทุกหน้าเว็บไซต์หลักที่มีผู้ใช้งาน ได้แก่หน้าแรก หน้า Login พอร์ทัลนักเรียน หน้า LMS หลังจาก Login และหน้ารับสมัคร บันทึกชื่อคุกกี้ โดเมนที่ตั้งคุกกี้ ผู้ให้บริการ และระยะเวลาหมดอายุของแต่ละตัวลงในตารางเดียวกัน อย่าลืมตรวจหน้าที่โหลด Script เพิ่มเฉพาะหลัง Login เช่นระบบส่งการบ้าน เพราะการตรวจแค่หน้าแรกจะพลาดคุกกี้กลุ่มนี้ไปทั้งหมด

ขั้นตอนที่ 2 จัดคุกกี้แต่ละตัวเข้าหมวดตามหน้าที่จริง ไม่ใช่ชื่อผู้ให้บริการ

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

ขั้นตอนที่ 3 ตรวจสอบคุกกี้ที่เกี่ยวข้องกับนักเรียนที่เป็นผู้เยาว์เป็นพิเศษ

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

ขั้นตอนที่ 4 เชื่อมหมวดคุกกี้เข้ากับ Consent Banner และทดสอบการบล็อก

เมื่อบัญชีคุกกี้และหมวดหมู่พร้อมแล้ว ให้ตั้งค่า Consent Banner ให้บล็อกคุกกี้แต่ละหมวดตามที่จัดไว้ แล้วทดสอบจริงบนเว็บไซต์ทดสอบก่อนขึ้นใช้งานจริง ทดสอบทั้งกด Accept All, Reject All และเลือกเฉพาะบางหมวด แล้วเปิด Network Tab ตรวจว่าคุกกี้ที่ควรถูกบล็อกไม่มี Request ยิงออกไปจริง ต้องทดสอบทั้งตอนโหลดหน้าแรกและตอน Login เข้าพอร์ทัลนักเรียน เพราะบางระบบโหลด Script เพิ่มเฉพาะหลัง Login เท่านั้น

ขั้นตอนที่ 5 มอบหมายเจ้าของงานต่อเนื่องเมื่อเพิ่มระบบใหม่

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

เครื่องมือที่ใช้ทำบัญชีคุกกี้โดยไม่ต้องมีทีมพัฒนาเฉพาะทาง

ทีมไอทีขนาดเล็กที่ไม่มีนักพัฒนาเฉพาะทางสามารถเริ่มทำบัญชีคุกกี้ได้ด้วยเครื่องมือพื้นฐานในเบราว์เซอร์เอง เปิด Developer Tools แล้วไปที่แท็บ Application หรือ Storage เพื่อดูรายการคุกกี้ทั้งหมดที่ถูกตั้งไว้บนหน้านั้น จดชื่อคุกกี้ โดเมน และวันหมดอายุลงในตารางง่าย ๆ เช่น Google Sheet ก่อน ไม่จำเป็นต้องใช้เครื่องมือสแกนอัตโนมัติราคาแพงตั้งแต่ต้น เพราะเว็บไซต์สถานศึกษาส่วนใหญ่มีจำนวนหน้าหลักไม่มาก การไล่ตรวจด้วยมือจึงทำได้จริงภายในเวลาไม่กี่วัน หากภายหลังต้องการความสะดวกมากขึ้น ค่อยพิจารณาเครื่องมือช่วยสแกนอัตโนมัติเพิ่มเติม

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

ตัวอย่างการนำ 5 ขั้นตอนไปใช้กับเว็บไซต์รับสมัครนักเรียนใหม่

สมมติสถานศึกษาแห่งหนึ่งกำลังจะเปิดฟอร์มรับสมัครออนไลน์รอบใหม่ ขั้นตอนที่ 1 เริ่มจากไล่ตรวจหน้าแรกของฟอร์ม หน้ากรอกข้อมูลผู้ปกครอง และหน้ายืนยันการสมัคร บันทึกคุกกี้ที่พบทั้งหมด ขั้นตอนที่ 2 จัดคุกกี้ของระบบยืนยันตัวตนเป็น Necessary จัดคุกกี้ของแชทสอบถามเป็น Functional หรือ Analytics ตามหน้าที่จริง และจัดคุกกี้ของ Pixel โฆษณาที่ใช้วัดผลแคมเปญประชาสัมพันธ์เป็น Marketing ขั้นตอนที่ 3 ตรวจว่าหน้ากรอกข้อมูลผู้ปกครองไม่มีคุกกี้ Marketing ทำงานก่อนได้รับความยินยอม ขั้นตอนที่ 4 ทดสอบว่า Consent Banner บล็อก Pixel โฆษณาได้จริงเมื่อผู้ปกครองกด Reject All ขั้นตอนที่ 5 มอบหมายให้เจ้าหน้าที่ฝ่ายรับสมัครแจ้งทีมไอทีทุกครั้งก่อนเพิ่มเครื่องมือใหม่ในฟอร์ม เช่นระบบอัปโหลดเอกสารหรือระบบนัดสัมภาษณ์ออนไลน์

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

• ไล่เปิด Developer Tools บนหน้าแรก พอร์ทัลนักเรียน LMS หลัง Login และหน้ารับสมัคร แล้วบันทึกคุกกี้ทั้งหมดลงตาราง
• จัดคุกกี้แต่ละตัวเข้า 4 หมวดตามหน้าที่จริง ไม่ใช่ตามชื่อผู้ให้บริการ
• ตรวจซ้ำเฉพาะหน้าที่นักเรียนผู้เยาว์เข้าถึงโดยตรงว่าไม่มีคุกกี้ Marketing ทำงาน
• อธิบายหมวดคุกกี้บนหน้ารับสมัครด้วยภาษาที่ผู้ปกครองเข้าใจง่าย
• ตั้งค่า Consent Banner ให้บล็อกคุกกี้แต่ละหมวดตามที่จัดไว้ แล้วทดสอบบนเว็บไซต์ทดสอบก่อนขึ้นจริง
• ทดสอบ Accept All, Reject All และเลือกเฉพาะบางหมวด พร้อมตรวจ Network Tab ทุกครั้ง
• กำหนดเจ้าของงานต่อเนื่องพร้อมปฏิทินแจ้งเตือนก่อนเปิดภาคการศึกษาใหม่

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

• ตรวจคุกกี้เฉพาะหน้าแรก แล้วพลาดคุกกี้ที่โหลดเพิ่มเฉพาะหลัง Login เข้า LMS
• จัดคุกกี้ Marketing เป็น Necessary เพราะเข้าใจผิดว่าจำเป็นต่อการประชาสัมพันธ์รับสมัคร
• ปล่อยให้คุกกี้ Marketing ทำงานบนหน้าตารางเรียนหรือหน้าส่งการบ้านที่นักเรียนผู้เยาว์ใช้งานโดยตรง
• เชื่อม Consent Banner กับหมวดคุกกี้แล้วไม่ทดสอบจริงบน Network Tab ก่อนขึ้นใช้งาน
• เพิ่มระบบใหม่ เช่นเปลี่ยน LMS แล้วไม่ปรับปรุงบัญชีคุกกี้และ Consent Banner ตาม

ความถี่ในการทบทวนบัญชีคุกกี้หลังวางระบบเสร็จแล้ว

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

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

สรุป

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

ความแตกต่างระหว่างการวางระบบครั้งแรกกับการทบทวนตามรอบ

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

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

ต้องเริ่มทำบัญชีคุกกี้จากระบบใดก่อนถ้าเวลามีจำกัด

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

ทำไมต้องตรวจคุกกี้ทั้งตอนโหลดหน้าแรกและตอน Login เข้า LMS

เพราะบางระบบโหลด Script หรือคุกกี้เพิ่มเฉพาะหลังผู้ใช้ Login เข้าใช้งานจริงเท่านั้น หากตรวจแค่หน้าแรก บัญชีคุกกี้จะไม่ครบถ้วนและ Consent Banner อาจไม่บล็อกคุกกี้กลุ่มนี้อย่างที่ตั้งใจ

เมื่อสถานศึกษาเปลี่ยนผู้ให้บริการ LMS ต้องทำขั้นตอนทั้งหมดใหม่ตั้งแต่ต้นหรือไม่

ไม่จำเป็นต้องทำใหม่ทั้งหมด แต่ต้องทำบัญชีคุกกี้ของ LMS ใหม่แยกต่างหากก่อนเปิดใช้งานจริง แล้วรวมเข้ากับบัญชีคุกกี้เดิมของเว็บไซต์หลัก พร้อมทดสอบ Consent Banner ซ้ำเฉพาะส่วนที่เปลี่ยนแปลง

ใครควรเป็นผู้รับผิดชอบปรับปรุงบัญชีคุกกี้เมื่อสถานศึกษาเพิ่มระบบใหม่

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

เมื่อหลายคณะในมหาวิทยาลัยดูแลเว็บไซต์ของตัวเองแยกกัน

มหาวิทยาลัยขนาดใหญ่มักมีเว็บไซต์คณะแยกจากเว็บไซต์กลาง แต่ละคณะอาจเลือกใช้ Website Builder หรือปลั๊กอินคนละชุด ทำให้บัญชีคุกกี้ของแต่ละคณะไม่สอดคล้องกัน แนวทางที่ทำได้จริงคือให้ฝ่ายไอทีกลางทำ Template บัญชีคุกกี้และ Consent Banner มาตรฐานให้ทุกคณะใช้เป็นฐาน แล้วให้แต่ละคณะเพิ่มเฉพาะคุกกี้เฉพาะทางของตนเข้าไปตามขั้นตอนที่ 1 ถึง 4 ที่อธิบายไว้ข้างต้น วิธีนี้ช่วยให้ทั้งมหาวิทยาลัยมีมาตรฐานการจัดหมวดคุกกี้ไปในทิศทางเดียวกัน โดยไม่ต้องบังคับให้ทุกคณะใช้ระบบเว็บไซต์เดียวกันทั้งหมด

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

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