เปิด GTM container มาเจอ tag 47 ตัว ใช้งานจริงแค่ 12: วิธี audit container ให้เบาและปลอดภัย
สรุปสั้น ๆ
GTM container ที่ไม่เคยถูกทำความสะอาดมักสะสม tag ที่เลิกใช้แล้วแต่ยังทำงานอยู่ ซึ่งไม่ได้แค่ทำให้หน้าเว็บโหลดช้าลง แต่ยังเสี่ยงให้ trigger ที่ตั้งเงื่อนไขคล้ายกันชนกันจนยิง event ผิดพลาดโดยไม่มีใครสังเกต การ audit ต้องไล่ตรวจทั้งจำนวน tag ที่ยังใช้จริง และ trigger ที่อาจซ้อนทับกัน
ร้านขายเครื่องสำอางออนไลน์สมมติชื่อ 'เพียวลุค' เปลี่ยนเอเจนซี่ดูแลโฆษณามาแล้วสี่ครั้งในสามปี เมื่อเปิด GTM container ขึ้นมาไล่ดูจริง ๆ ถึงพบว่ามี tag ทั้งหมด 47 ตัว แต่พอเช็กทีละตัวว่ายังทำงานจริงหรือไม่ เหลือแค่ 12 ตัวที่ยังเชื่อมกับแพลตฟอร์มที่ใช้งานอยู่ในปัจจุบัน ที่เหลือคือ tag ของแพลตฟอร์มที่เลิกใช้ไปแล้ว หรือ tag ทดสอบที่ไม่มีใครลบออก
container ที่รกแบบนี้ไม่ได้แค่ทำให้หน้าเว็บโหลดช้าลงจากสคริปต์ที่ไม่จำเป็น แต่ยังเป็นความเสี่ยงเงียบ ๆ เพราะ trigger เก่าบางตัวอาจตั้งเงื่อนไขคล้ายกับ trigger ใหม่ ทำให้เกิดการยิง event ซ้ำหรือยิงผิดจังหวะโดยไม่มีใครตั้งใจ
บทความนี้จะพา audit container ทั้งในมุมความสะอาด (ตัดของที่ไม่ใช้ทิ้ง) และมุมความปลอดภัย (หา trigger ที่ชนกัน) ซึ่งเป็นงานที่ควรทำเป็นระยะ ไม่ใช่ปล่อยไว้จนกลายเป็นภูเขาแบบเพียวลุค
ขั้นแรก: ทำบัญชี tag ทั้งหมดว่าตัวไหนยังใช้จริง
- เปิดรายการ tag ทั้งหมดใน container แล้วจดชื่อแพลตฟอร์มปลายทางของแต่ละ tag ว่าเป็นของบริการอะไร
- ไปเช็กที่แพลตฟอร์มปลายทางแต่ละอันว่าบัญชีนั้นยังใช้งานอยู่จริงหรือปิดไปแล้ว เช่น เปิด Meta Ads Manager เพื่อดูว่า pixel ID ที่ tag อ้างถึงยังเชื่อมกับบัญชีที่ใช้งานอยู่หรือไม่
- สำหรับ tag ที่ไม่แน่ใจ ให้ดูวันที่ยิงล่าสุด (last fired) ถ้าไม่เคยยิงมานานเกินสามเดือน มีโอกาสสูงว่าเป็น tag ที่เลิกใช้ไปแล้ว
- ทำตารางแยกเป็นสามกลุ่ม คือ 'ใช้งานอยู่แน่นอน' 'ไม่แน่ใจต้องถามทีม' และ 'เลิกใช้แล้วพร้อมลบ' ก่อนตัดสินใจลบอะไรออก
จุดที่อันตรายกว่าจำนวน tag คือ trigger ที่ตั้งเงื่อนไขซ้อนทับกัน
ปัญหาที่ตรวจจับยากกว่าคือ trigger สองตัวที่ตั้งเงื่อนไขคล้ายกันมากจนบางสถานการณ์ทำงานพร้อมกันโดยไม่ตั้งใจ เช่น trigger ตัวหนึ่งตั้งให้ยิงเมื่อ URL มีคำว่า 'thank-you' อีกตัวตั้งให้ยิงเมื่อ URL มีคำว่า 'complete' ถ้าหน้าเว็บจริงมี URL ที่ตรงกับทั้งสองเงื่อนไขพร้อมกัน tag ทั้งสองจะยิงพร้อมกันในหน้าเดียว
การติดตั้ง tag ผ่าน GTMที่ทำต่อเนื่องกันมาหลายรอบโดยหลายคน มักเป็นจุดกำเนิดของ trigger ซ้อนแบบนี้ เพราะแต่ละคนไม่รู้ว่าเงื่อนไขที่ตัวเองตั้งไปทับกับของเดิมที่มีอยู่แล้วหรือเปล่า
วิธีหา trigger ที่ชนกันแบบไม่ต้องไล่อ่านทุกตัว
เปิดโหมด preview ของ GTM แล้วไล่เข้าหน้าเว็บสำคัญทุกหน้าในเส้นทางลูกค้า (หน้าแรก หน้าสินค้า หน้าตะกร้า หน้ายืนยัน) จากนั้นดูที่แผง 'Tags Fired' ว่าในแต่ละหน้ามี tag ใดยิงขึ้นมาบ้าง ถ้าเจอ tag มากกว่าที่ควรจะเป็นในหน้าเดียว ให้ไล่ดูว่า trigger ไหนที่ยิงโดยไม่ควร
อีกวิธีคือ export รายการ trigger ทั้งหมดออกมาเป็นตาราง แล้วเทียบเงื่อนไข URL หรือ event name ที่ใช้ ถ้าพบว่ามีสองตัวที่เงื่อนไขซ้อนทับกันได้ในบางกรณี ให้ทำเครื่องหมายไว้ตรวจสอบก่อน
ตารางแนวทางจัดการ container ตามระดับความเสี่ยง
| สถานการณ์ที่พบ | ความเสี่ยง | แนวทางจัดการ |
|---|---|---|
| Tag ไม่เคยยิงเกิน 3 เดือน | ต่ำ แต่ทำให้ container รก | หยุดใช้งาน (pause) ก่อนลบถาวร |
| Trigger เงื่อนไขซ้อนทับ | สูง เสี่ยงยิง event ผิด/ซ้ำ | แก้เงื่อนไขให้เจาะจงและไม่ทับกัน |
| Tag ผูกบัญชีที่ปิดไปแล้ว | ปานกลาง สิ้นเปลืองทรัพยากรเปล่า | ลบทิ้งได้ทันทีหลังยืนยันว่าปิดจริง |
ถ้าดูแล container ให้หลายลูกค้าพร้อมกัน ความเสี่ยงยิ่งสูงขึ้น
เอเจนซี่ที่ใช้container เดียวดูแลหลายลูกค้าต้องระวังเป็นพิเศษ เพราะ tag หรือ trigger ของลูกค้ารายหนึ่งอาจถูกตั้งค่ากว้างเกินไปจนไปยิงบนเว็บของลูกค้าอีกรายที่ใช้ container เดียวกัน ควรตั้งชื่อ tag และ trigger ให้ระบุชื่อลูกค้าชัดเจน และตรวจสอบขอบเขตของแต่ละเงื่อนไขอย่างเข้มงวดกว่าปกติ
สรุป
container ที่รกไม่ใช่แค่ปัญหาความเป็นระเบียบ แต่เป็นความเสี่ยงที่สะสมไปเรื่อย ๆ จนวันหนึ่งอาจทำให้ตัวเลข event ผิดเพี้ยนโดยไม่มีใครรู้ต้นตอ
การทำบัญชี tag และตรวจ trigger ที่ซ้อนทับเป็นงานที่น่าเบื่อ แต่ทำครั้งเดียวให้ละเอียดแล้วตั้งรอบตรวจต่อเนื่อง จะช่วยประหยัดเวลาสืบสวนปัญหาในอนาคตได้มาก
- ทำบัญชี tag ทั้งหมดและเช็กว่าตัวไหนยังเชื่อมกับบัญชีที่ใช้งานจริง
- ใช้โหมด preview ไล่เข้าทุกหน้าสำคัญเพื่อหา trigger ที่ยิงซ้อนทับกัน
- ตั้งชื่อ tag และ trigger ให้ชัดเจนเป็นพิเศษถ้าดูแล container ร่วมกันหลายลูกค้า
คำถามที่พบบ่อย
ควร audit container บ่อยแค่ไหน
แนะนำอย่างน้อยทุกไตรมาส หรือทันทีที่มีการเปลี่ยนทีมดูแลโฆษณา เพราะเป็นช่วงที่มักมีการเพิ่ม tag ใหม่โดยไม่รู้ประวัติของ tag เก่า
ลบ tag ที่ไม่แน่ใจว่ายังใช้อยู่ไหม เสี่ยงไหม
ควร pause (หยุดใช้งานชั่วคราว) ก่อนลบถาวรเสมอ แล้วรอสังเกตอย่างน้อยหนึ่งถึงสองสัปดาห์ว่ามีผลกระทบอะไรหรือไม่ ก่อนตัดสินใจลบออกจริง
trigger ที่ชนกันจะสังเกตผลกระทบได้จากตรงไหน
มักสังเกตได้จากจำนวน event ที่สูงผิดปกติในบางหน้า หรือ tag ของแพลตฟอร์มหนึ่งยิงขึ้นในหน้าที่ไม่ควรเกี่ยวข้องเลย เช่น tag การซื้อยิงขึ้นในหน้าแรกของเว็บ
มีเครื่องมือช่วยหา trigger ที่ซ้อนทับอัตโนมัติไหม
โหมด preview ของ GTM เองช่วยดูได้แบบเรียลไทม์เมื่อไล่เข้าหน้าเว็บจริง ส่วนการเทียบเงื่อนไขจำนวนมากยังต้องอาศัยการ export ข้อมูลมาไล่ดูด้วยตาเป็นหลัก
ทำไมการดูแล container หลายลูกค้าถึงเสี่ยงกว่าปกติ
เพราะเงื่อนไขที่ตั้งกว้างเกินไปสำหรับลูกค้ารายหนึ่งอาจไปกระทบเว็บของลูกค้าอีกรายที่ใช้ container ร่วมกัน ควรตั้งชื่อและขอบเขตเงื่อนไขให้ชัดเจนแยกตามลูกค้าเสมอ
ถ้าไม่มีเวลาทำ audit container เต็มรูปแบบ ควรเริ่มจากอะไรก่อน
เริ่มจากดูวันที่ยิงล่าสุดของทุก tag ก่อน เพราะเป็นข้อมูลที่หาได้เร็วและช่วยกรอง tag ที่ไม่ใช้แล้วออกไปได้จำนวนมากโดยไม่ต้องไล่อ่านเงื่อนไขทีละตัว
บทความที่เกี่ยวข้อง
