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

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

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

การ Audit ในบทความนี้หมายถึงการตรวจสอบเชิงปฏิบัติเพื่อยกระดับความถูกต้องของการจัดหมวดคุกกี้และความพร้อมของหลักฐาน ไม่ใช่การตรวจรับรองตามกฎหมายโดยหน่วยงานภายนอก ข้อกำหนดที่เป็นทางการควรอ้างอิงประกาศของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง

ทำไมเอเจนซีต้อง Audit การจัดหมวดหมู่คุกกี้ แม้เว็บจะรันได้ปกติ

ปัญหาที่พบบ่อยที่สุดในงานเอเจนซีไม่ใช่การไม่มีระบบจัดหมวดคุกกี้ แต่คือการจัดหมวดที่ "ตั้งไว้ตอนแรกแล้วไม่เคยแก้" ในขณะที่เว็บไซต์ของไคลเอนต์เปลี่ยนไปทุกเดือน ทีม Growth ของไคลเอนต์เองอาจติดตั้ง pixel หรือสคริปต์ใหม่ผ่าน Tag Manager โดยไม่แจ้งเอเจนซี ปลั๊กอินอีคอมเมิร์ซที่อัปเดตเวอร์ชันอาจแอบเพิ่มคุกกี้ third-party ใหม่ หรือทีม content เพิ่มวิดีโอฝังจาก YouTube ที่มากับคุกกี้โฆษณาโดยไม่รู้ตัว การจัดหมวดที่ทำไว้ตอน launch จึงเสื่อมความถูกต้องไปเรื่อย ๆ โดยไม่มีใครสังเกต

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

เตรียมการก่อนเริ่ม Audit: ขอบเขต ทีม และเอกสารต่อไคลเอนต์

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

ทีมที่ควรมีส่วนร่วมในการ Audit ได้แก่ ผู้ดูแลโปรเจกต์ (account/project manager) ที่รู้ว่าไคลเอนต์เพิ่งขอฟีเจอร์อะไรใหม่ นักพัฒนาที่เข้าถึง Tag Manager และโค้ดหน้าเว็บได้จริง และถ้าเป็นไปได้ ตัวแทนฝ่ายไคลเอนต์ที่รู้ว่าทีมการตลาดของเขาเพิ่งเพิ่มเครื่องมือใดเข้าไปเอง เอกสารที่ควรรวบรวมก่อนตรวจ ได้แก่ รายการสคริปต์และคุกกี้ที่บันทึกไว้ตอน setup ครั้งแรก ประวัติการเปลี่ยนแปลง Tag Manager container และสัญญาหรือ SOW ที่ระบุขอบเขตงานด้าน consent ที่เอเจนซีรับผิดชอบ

คำถามที่ต้องตอบได้ก่อนเริ่มตรวจแต่ละโปรเจกต์

ก่อนลงมือ ให้ตอบคำถามเหล่านี้ต่อไคลเอนต์แต่ละราย: ใครเป็นคนแก้ไข Tag Manager container ล่าสุดและแก้อะไรไป, มีการเพิ่มปลั๊กอินหรือสคริปต์ฝังจากบุคคลที่สามในช่วง 6 เดือนที่ผ่านมาหรือไม่, และสัญญาที่ทำไว้ระบุหรือไม่ว่าเอเจนซีต้องตรวจ consent เป็นรอบ หรือเป็นความรับผิดชอบของไคลเอนต์เอง คำตอบเหล่านี้จะกำหนดว่ารอบ Audit นี้ต้องลึกแค่ไหน

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

ขั้นตอนต่อไปนี้ออกแบบให้ทำซ้ำได้กับไคลเอนต์แต่ละราย ใช้เวลาประมาณ 2-4 ชั่วโมงต่อเว็บไซต์หนึ่งแห่งสำหรับเว็บขนาดกลาง

ขั้นที่ 1: สแกนสคริปต์และคุกกี้จริงบนหน้าเว็บ

เปิดเว็บไซต์ในโหมดไม่ระบุตัวตน (incognito) แบบยังไม่กดยอมรับอะไร แล้วเปิด network tab ของเบราว์เซอร์ดูว่ามีสคริปต์ใดยิง request ออกไปบ้าง จากนั้นเทียบรายการที่เห็นจริงกับรายการที่ตั้งค่าไว้ในปลั๊กอินหรือ CMP ว่าจัดหมวดตรงกันหรือไม่ สคริปต์ที่พบบ่อยแต่ถูกจัดหมวดผิด ได้แก่ วิดีโอฝังที่ถูกจัดเป็น "จำเป็น" ทั้งที่มีคุกกี้โฆษณาติดมาด้วย และปลั๊กอินแชทสดที่จัดเป็น "ฟังก์ชัน" ทั้งที่ส่งข้อมูลผู้ใช้งานไปยัง third-party วิเคราะห์ด้วย

ขั้นที่ 2: ตรวจว่าคุกกี้นอกหมวดจำเป็นไม่โหลดก่อนได้รับความยินยอม

จากการสแกนในขั้นที่ 1 ให้แยกว่ามีสคริปต์หมวดวิเคราะห์หรือการตลาดตัวใดยิง request ออกไปก่อนที่จะกดยอมรับหรือไม่ ถ้ามี แปลว่าการตั้งค่า default-off ในปลั๊กอินไม่ได้ทำงานจริง แม้หน้าตั้งค่าจะแสดงว่าปิดอยู่ก็ตาม ปัญหานี้พบบ่อยเมื่อไคลเอนต์เพิ่มสคริปต์ผ่าน Tag Manager โดยตรงแทนที่จะผ่านการตั้งค่าของปลั๊กอินคุกกี้ ทำให้สคริปต์นั้นหลุดออกนอกการควบคุมของระบบ consent ทั้งที่ยังแสดงในรายชื่อคุกกี้ตามหมวดที่ถูกต้อง

ขั้นที่ 3: เทียบรายการคุกกี้กับคำอธิบายที่แสดงให้ผู้ใช้งานเห็น

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

ขั้นที่ 4: ตรวจการเปลี่ยนแปลงย้อนหลังผ่าน Tag Manager

เข้าไปดูประวัติเวอร์ชัน (version history) ของ Google Tag Manager container ว่ามีการเพิ่มแท็กใหม่ในช่วงที่ผ่านมาหรือไม่ และแท็กใหม่แต่ละตัวถูกเพิ่มเข้าไปในหมวดคุกกี้ที่ถูกต้องหรือยัง ขั้นตอนนี้สำคัญเพราะทีมการตลาดฝั่งไคลเอนต์มักมีสิทธิ์เข้าถึง Tag Manager เองและเพิ่มแท็กได้โดยไม่ผ่านเอเจนซี การไล่ดูประวัติเวอร์ชันคือวิธีเดียวที่จะจับความเปลี่ยนแปลงเหล่านี้ได้ทันโดยไม่ต้องรอให้ไคลเอนต์แจ้งเอง

ขั้นที่ 5: ทดสอบข้ามอุปกรณ์และหน้าย่อยของเว็บไซต์

เว็บไซต์ของไคลเอนต์จำนวนมากมีหน้า landing page แคมเปญ หรือหน้า checkout ที่ฝังสคริปต์เพิ่มเติมแยกจากหน้าแรก ให้สุ่มตรวจอย่างน้อย 3-5 หน้าที่มีลักษณะต่างกัน เช่น หน้าแรก หน้าสินค้า หน้าแคมเปญโฆษณา และหน้า checkout เพราะการจัดหมวดที่ถูกต้องบนหน้าแรกไม่ได้แปลว่าถูกต้องทั้งเว็บไซต์ โดยเฉพาะหน้าที่ทีม Growth สร้างแยกจากเทมเพลตหลัก

ขั้นที่ 6: ทบทวนสัญญาและรายงานส่งไคลเอนต์

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

Evidence ที่ควรเก็บจากการ Audit แต่ละรอบ

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

• รายงานผลตรวจต่อโปรเจกต์ ระบุวันที่ตรวจ ผู้ตรวจ และสิ่งที่พบแยกตามความรุนแรง
• ภาพหน้าจอ network request ก่อนและหลังกดยอมรับ แสดงว่าสคริปต์นอกหมวดจำเป็นไม่โหลดก่อนได้รับความยินยอม
• ภาพหน้าจอหน้าตั้งค่าคุกกี้ ที่ผู้ใช้งานเห็น พร้อมวันที่ตรวจ
• ประวัติเวอร์ชัน Tag Manager ที่แสดงการเปลี่ยนแปลงในช่วงที่ตรวจ
• รายการสคริปต์ที่พบว่าจัดหมวดผิดและวันที่แก้ไข ให้ตรงกับพฤติกรรมจริง

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

สถานการณ์ตัวอย่างจริง

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

กรณีที่สอง — วิดีโอฝังถูกจัดเป็นคุกกี้จำเป็น: ฟรีแลนซ์ที่รับงานทำเว็บให้ธุรกิจขนาดเล็กติดตั้งปลั๊กอินคุกกี้แบบตั้งค่าเริ่มต้นทั้งหมดโดยไม่ปรับแต่ง เมื่อทำการ Audit ตามขั้นที่ 1 พบว่าวิดีโอ YouTube ที่ฝังในหน้าแรกถูกจัดเป็นคุกกี้จำเป็นตามค่า default ของปลั๊กอิน ทั้งที่มีคุกกี้โฆษณาของ YouTube ติดมาด้วย ต้องย้ายไปจัดเป็นหมวดการตลาดและตั้งให้โหลดหลังได้รับความยินยอมเท่านั้น

กรณีที่สาม — หน้าแคมเปญแยกจากเทมเพลตหลัก: เอเจนซีที่ดูแลเว็บไซต์ธุรกิจบริการรายหนึ่งพบระหว่างการ Audit ตามขั้นที่ 5 ว่าหน้า landing page แคมเปญที่ทีม Growth สร้างแยกต่างหากไม่มีหน้าตั้งค่าคุกกี้เลย เพราะถูกสร้างนอกระบบ CMS หลัก ทำให้สคริปต์โฆษณาโหลดโดยไม่มีการขอความยินยอมใด ๆ ต้องเพิ่มสคริปต์ CMP เข้าไปในหน้านั้นแยกต่างหาก

ทำ Audit ให้เป็นส่วนหนึ่งของบริการ ไม่ใช่งานพิเศษ

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

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

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

• ทำรายการโปรเจกต์ไคลเอนต์ทั้งหมดที่ต้องตรวจในรอบนี้ พร้อมระบบ consent ที่แต่ละรายใช้
• สแกน network request จริงเทียบกับรายการหมวดคุกกี้ที่ตั้งค่าไว้
• ตรวจว่าสคริปต์นอกหมวดจำเป็นไม่โหลดก่อนได้รับความยินยอม
• เทียบคำอธิบายคุกกี้ที่ผู้ใช้งานเห็นกับพฤติกรรมจริงของสคริปต์
• ไล่ประวัติเวอร์ชัน Tag Manager เพื่อหาแท็กที่ไคลเอนต์เพิ่มเอง
• สุ่มตรวจหน้าย่อยและหน้าแคมเปญที่แยกจากเทมเพลตหลัก
• เก็บรายงานผลตรวจและภาพหลักฐานแยกโฟลเดอร์ต่อไคลเอนต์และต่อรอบ

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

• ใช้ค่าเริ่มต้นของปลั๊กอินคุกกี้โดยไม่ตรวจว่าตรงกับสคริปต์จริงบนเว็บไซต์นั้น
• ไม่ไล่ประวัติ Tag Manager จึงพลาดแท็กที่ทีมการตลาดของไคลเอนต์เพิ่มเอง
• ตรวจแค่หน้าแรก ไม่ตรวจหน้าแคมเปญหรือหน้า checkout ที่มีสคริปต์ต่างออกไป
• ไม่เก็บภาพหลักฐานการตรวจไว้ ทำให้ตอบไคลเอนต์ไม่ได้เมื่อถูกถามย้อนหลัง
• ทำ Audit เฉพาะตอนมีปัญหา ไม่ได้กำหนดเป็นรอบประจำในสัญญาดูแล

สรุป

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

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

แนวทางเชิงเทคนิคเกี่ยวกับการทำงานของคุกกี้ HTTP อ้างอิงจาก MDN Web Docs — Using HTTP Cookies ส่วนแนวปฏิบัติด้านความยินยอมภายใต้ PDPA ควรตรวจสอบเพิ่มเติมจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง บทความนี้อธิบายแนวปฏิบัติเชิงระบบ ไม่ใช่การตีความข้อกฎหมายแทนหน่วยงานกำกับดูแล