GA4 มี event ชื่อคล้ายกันหกแบบสำหรับการกระทำเดียว: วิธี audit schema ก่อนรายงานจะโกหกคุณ
สรุปสั้น ๆ
ปัญหาที่พบบ่อยใน GA4 ไม่ใช่ 'ไม่มี event' แต่คือมี event เยอะเกินไปที่ชื่อต่างกันแต่หมายถึงการกระทำเดียวกัน ทำให้รายงานแตกกระจายและตัวเลขไม่สะท้อนความจริง การ audit schema คือการไล่รวมและตั้งมาตรฐานให้กลับมาเป็นภาพเดียวกัน
ลองสมมติร้านขายเครื่องใช้ไฟฟ้าออนไลน์ชื่อ 'บ้านสว่าง' เปิด GA4 ขึ้นมาไล่ดู event เพื่อทำรายงานประจำไตรมาส แล้วพบว่ามี event ชื่อ line_click, click_line, chat_start, line_contact และ contact_line ปรากฏอยู่พร้อมกันทั้งห้าชื่อ ทั้งที่ทุกตัวหมายถึงการกระทำเดียวกันคือ 'ลูกค้ากดปุ่มไปหา LINE OA'
ต้นตอมาจากการที่แต่ละแคมเปญหรือแต่ละหน้าเว็บถูกพัฒนาโดยคนละทีม คนละช่วงเวลา แล้วไม่มีใครกำหนดมาตรฐานการตั้งชื่อ event ไว้ตั้งแต่แรก พอเวลาผ่านไปนานพอ schema ก็กลายเป็นสวนสัตว์ที่ไม่มีใครกล้าแตะเพราะกลัวรายงานพัง
บทความนี้ไม่ได้บอกว่าต้องตั้งชื่อ event แบบไหนถึงจะถูก แต่จะพาไล่ audit ว่า schema ปัจจุบันของคุณมีปัญหานี้อยู่ไหม แล้วควรจัดการยังไงโดยไม่ทำรายงานเก่าพังไปด้วย
ทำไม event schema ถึง 'เพี้ยน' ไปเรื่อย ๆ โดยไม่มีใครตั้งใจ
GA4 ไม่มีการบังคับให้ event ต้องมีชื่อมาตรฐานตายตัว ต่างจากระบบเก่าอย่าง Universal Analytics ที่มีโครงสร้าง Category/Action/Label ชัดเจนกว่า ความยืดหยุ่นนี้เป็นทั้งข้อดีและข้อเสีย ข้อดีคือปรับแต่งได้อิสระ ข้อเสียคือถ้าไม่มีใครคุมมาตรฐาน แต่ละคนจะตั้งชื่อตามความเข้าใจของตัวเอง
ปัญหาจะยิ่งหนักขึ้นเมื่อมีการเปลี่ยนทีมพัฒนาเว็บหรือเปลี่ยนเอเจนซี่ เพราะคนใหม่มักไม่รู้ว่าเคยมี event ชื่อไหนตั้งไว้แล้วบ้าง จึงสร้างซ้ำด้วยชื่อใหม่ที่ตัวเองคุ้นเคยแทนที่จะต่อยอดของเดิม
ขั้นตอน audit schema แบบไล่จากกว้างไปแคบ
- เปิดรายงาน Events ใน GA4 แล้ว export รายชื่อ event ทั้งหมดที่เคยเกิดขึ้นในช่วง 90 วันล่าสุดออกมาเป็นลิสต์เดียว
- จัดกลุ่ม event ที่ 'น่าจะ' หมายถึงการกระทำเดียวกันไว้ด้วยกัน โดยดูจากคำในชื่อและ parameter ที่แนบไปด้วย
- เปิดDebugView แล้วทดสอบทำ action จริงบนหน้าเว็บแต่ละหน้า เพื่อดูว่า event ไหนถูกยิงขึ้นมาจริงสำหรับการกระทำแต่ละแบบ
- ทำตารางเทียบว่า event ชื่อไหนควรเป็นตัวหลัก (canonical name) แล้ววางแผนย้าย event เก่าที่ซ้ำซ้อนเข้าหาชื่อเดียวกันทีละหน้า
ปัญหาที่ซ่อนลึกกว่าชื่อ event คือ parameter ไม่ตรงกัน
แม้จะรวมชื่อ event ให้เหลือแบบเดียวได้แล้ว ปัญหาที่ยังเหลืออยู่บ่อยคือ parameter ที่แนบไปกับ event ชื่อเดียวกันมีโครงสร้างต่างกันในแต่ละหน้า เช่น หน้าหนึ่งส่ง page_location เป็น parameter หลัก อีกหน้าส่ง source_page ที่ทำหน้าที่เดียวกันแต่คนละชื่อ ทำให้ตอนสร้างรายงานแยกตามแหล่งที่มาไม่สามารถรวมข้อมูลได้ในตารางเดียว
การเช็กจุดนี้ต้องเปิด parameter ของแต่ละ event ใน DebugView เทียบกันทีละคู่ ไม่ใช่แค่ดูชื่อ event เฉย ๆ เพราะชื่อเหมือนกันไม่ได้แปลว่าโครงสร้างข้างในเหมือนกันเสมอไป
เช็กว่า key events ที่ตั้งไว้ยังตรงกับ event ที่มีอยู่จริง
อีกจุดที่มักหลุดคือการตั้งkey events (เดิมเรียก conversion events) ไว้ผูกกับชื่อ event เก่าที่เลิกใช้ไปแล้วหรือเปลี่ยนชื่อไปแล้ว ผลคือระบบยังคำนวณ key event ตามชื่อเก่าที่ไม่มีข้อมูลใหม่เข้ามาอีก ตัวเลข conversion จึงตกลงเรื่อย ๆ ทั้งที่ยอดขายจริงยังปกติ เพราะไปวัดผิด event
ควรเปิดรายการ key events ทุกตัวเทียบกับลิสต์ event ที่ยัง active อยู่จริงอย่างน้อยไตรมาสละครั้ง เพื่อจับจุดที่ผูกกับชื่อ event ที่ตายไปแล้ว
ตารางแผนย้าย event ที่ใช้ได้จริง ไม่ทำรายงานเก่าพัง
| ชื่อ event เดิม | ชื่อที่จะรวมเป็นมาตรฐาน | วิธีจัดการช่วงเปลี่ยนผ่าน |
|---|---|---|
| line_click, click_line | line_contact_click | คง event เก่าไว้คู่ขนาน 1-2 เดือนก่อนถอด |
| chat_start, contact_line | line_contact_click | อัปเดตโค้ดหน้าเว็บทีละหน้า ไม่ทำพร้อมกันทั้งหมด |
| form_submit_v1, form_submit_new | lead_form_submit | ย้าย key events มาผูกชื่อใหม่ก่อนถอดชื่อเก่า |
ป้องกันไม่ให้ schema เพี้ยนซ้ำในอนาคต
- ทำเอกสารมาตรฐานการตั้งชื่อ event หนึ่งหน้า แชร์ให้ทุกคนที่แตะโค้ดติดตาม ไม่ว่าจะเป็นทีมในหรือเอเจนซี่ภายนอก
- ก่อนสร้าง event ใหม่ทุกครั้ง ให้เช็กในลิสต์ก่อนว่ามี event ที่ทำหน้าที่คล้ายกันอยู่แล้วหรือไม่
- ตั้งรอบ audit schema ทุกไตรมาส ไม่ต้องรอให้ตัวเลขรายงานผิดปกติก่อนถึงจะเริ่มเช็ก
สรุป
schema ที่กระจัดกระจายไม่ได้ทำให้ GA4 พังในทันที แต่มันค่อย ๆ กัดกินความน่าเชื่อถือของรายงานจนกว่าจะถึงวันที่ต้องมาอธิบายว่าทำไมตัวเลขในสองรายงานไม่ตรงกันทั้งที่ควรเป็นเรื่องเดียวกัน
การ audit และรวม schema ให้เป็นมาตรฐานเดียวไม่ใช่งานที่ทำครั้งเดียวจบ แต่เป็นวินัยที่ต้องรักษาไว้ทุกครั้งที่มีคนใหม่เข้ามาแตะเว็บไซต์
- จัดกลุ่ม event ที่ทำหน้าที่เดียวกันแต่ชื่อต่างกันให้เห็นภาพก่อนเริ่มรวม
- เช็ก parameter ไม่ใช่แค่ชื่อ event เพราะโครงสร้างข้างในอาจต่างกัน
- ทำเอกสารมาตรฐานการตั้งชื่อ event แชร์ให้ทุกทีมที่แตะเว็บไซต์
คำถามที่พบบ่อย
ควรลบ event เก่าที่ซ้ำซ้อนทันทีเลยไหม
ไม่ควรลบทันที ควรคงไว้คู่ขนานกับ event ใหม่สักระยะ เพื่อให้มั่นใจว่าการย้ายมาตรฐานใหม่ทำงานถูกต้องก่อน แล้วค่อยถอด event เก่าออกเมื่อข้อมูลนิ่งแล้ว
ทำไม parameter ต้องตรวจแยกจากชื่อ event
เพราะ GA4 อนุญาตให้ event ชื่อเดียวกันมี parameter ต่างกันได้ในแต่ละหน้า ถ้าไม่เช็กแยก อาจพลาดว่าข้อมูลจริง ๆ ไม่ได้สอดคล้องกันแม้ชื่อจะเหมือนกัน
key events ที่ผูกผิด event จะรู้ตัวได้ยังไง
สังเกตจากจำนวน key events ที่ลดลงผิดปกติทั้งที่ยอดขายจริงไม่ได้ลด ควรเปิดรายการ key events เทียบกับ event ที่ยัง active จริงเป็นระยะ
ธุรกิจเล็กที่มี event ไม่เยอะยังต้อง audit เรื่องนี้ไหม
ยังควรทำ เพราะแม้จำนวน event จะน้อย แต่ถ้าปล่อยให้ตั้งชื่อไม่มีมาตรฐานตั้งแต่ต้น จะยิ่งแก้ยากขึ้นเมื่อธุรกิจโตและมีคนเพิ่มเข้ามาดูแลเว็บมากขึ้น
การเปลี่ยนเอเจนซี่ทำเว็บบ่อย ๆ มีผลกับ schema ไหม
มีผลมาก เพราะแต่ละเอเจนซี่มักมีธรรมเนียมตั้งชื่อ event ของตัวเอง ถ้าไม่มีเอกสารมาตรฐานส่งต่อให้ชัดเจน schema จะยิ่งกระจัดกระจายทุกครั้งที่เปลี่ยนทีม
มีเครื่องมือช่วยเทียบ event schema แบบอัตโนมัติไหม
DebugView ของ GA4 เองช่วยดูโครงสร้าง event แบบเรียลไทม์ได้ในระดับหนึ่ง ส่วนการเทียบชื่อ event ย้อนหลังจำนวนมากยังต้องอาศัยการ export ข้อมูลมาไล่ดูด้วยมือหรือสเปรดชีตเป็นหลัก
บทความที่เกี่ยวข้อง
