หน้าสินค้าส่ง price เป็น string หน้าตะกร้าส่งเป็น number: audit data layer ให้พูดภาษาเดียวกันทั้งเว็บ
สรุปสั้น ๆ
data layer ที่ต่างทีมเขียนคนละช่วงเวลามักมีโครงสร้างไม่ตรงกัน เช่น ชื่อ key ต่างกัน หรือชนิดข้อมูลต่างกันสำหรับความหมายเดียวกัน ทำให้ tag ที่อ่านค่าจาก data layer ทำงานถูกในบางหน้าแต่ผิดในบางหน้าโดยไม่มี error แจ้ง การ audit ต้องไล่เทียบโครงสร้างทีละหน้าในเส้นทางลูกค้า
ร้านขายรองเท้าออนไลน์สมมติชื่อ 'สเต็ปอัพ' พบว่ามูลค่าการซื้อขายรวมที่รายงานใน GA4 ต่ำกว่าความเป็นจริงอย่างสม่ำเสมอ ทีมพัฒนาไล่เช็กโค้ดหน้ายืนยันคำสั่งซื้อแล้วยืนยันว่าส่งค่า price ถูกต้อง แต่พอเจาะลึกไปที่หน้าเพิ่มสินค้าลงตะกร้ากลับพบว่า price ถูกส่งเป็น string ที่มีเครื่องหมายจุลภาคติดมาด้วย เช่น '1,290' แทนที่จะเป็นตัวเลข 1290 ทำให้ระบบไม่สามารถคำนวณรวมค่าได้ถูกต้องตั้งแต่ขั้นตอนนั้น
ปัญหานี้ต่างจาก event schema ที่พูดถึงชื่อ event เพราะที่นี่ปัญหาอยู่ใน 'โครงสร้างข้อมูล' ที่แนบไปกับ event คือ data layer ซึ่งเป็นชั้นที่ tag manager ใช้ดึงค่าไปประมวลผลต่อ ถ้าโครงสร้างไม่ตรงกันระหว่างหน้าต่าง ๆ tag เดียวกันจะทำงานถูกในหน้าหนึ่งและพังในอีกหน้าหนึ่งโดยไม่มี error ใด ๆ เตือน
บทความนี้จะพา audit ความสอดคล้องของ data layer ข้ามหน้า ซึ่งเป็นงานที่ต้องใช้ความละเอียดมากกว่าปกติ เพราะปัญหามักซ่อนอยู่ในรายละเอียดเล็ก ๆ ที่ตาเปล่ามองข้ามง่าย
ทำไม data layer แต่ละหน้าถึงพูดกันคนละภาษา
เว็บไซต์ขนาดกลางถึงใหญ่มักถูกพัฒนาเป็นส่วน ๆ โดยทีมต่างกันหรือเอเจนซี่ต่างช่วงเวลา หน้าแรกอาจทำโดยทีม A เมื่อสองปีก่อน หน้าตะกร้าทำโดยทีม B เมื่อปีที่แล้ว แต่ละทีมมักไม่รู้ว่าทีมก่อนหน้าตั้งโครงสร้าง data layer ไว้แบบไหน จึงเขียนตามความเข้าใจของตัวเอง ผลคือ key ชื่อเดียวกันอาจมีชนิดข้อมูลต่างกัน หรือความหมายเดียวกันถูกตั้งชื่อ key ต่างกันไปเลย
ปัญหานี้อันตรายกว่า event schema เพราะไม่แสดงอาการชัดเจนเท่า tag ยังคงยิงออกไปได้ปกติ แค่ค่าที่ส่งไปผิดพลาดหรือว่างเปล่าในบางกรณี ทำให้รายงานดูเหมือนทำงานปกติแต่ตัวเลขข้างในคลาดเคลื่อน
วิธี audit โครงสร้าง data layer ข้ามหน้าในเส้นทางลูกค้า
- เลือกเส้นทางลูกค้าหลักที่สำคัญที่สุด เช่น หน้าสินค้า หน้าตะกร้า หน้ากรอกข้อมูล หน้ายืนยันคำสั่งซื้อ
- เปิดเครื่องมือนักพัฒนาในเบราว์เซอร์ แล้วพิมพ์ dataLayer ในคอนโซลเพื่อดูโครงสร้างข้อมูลดิบของแต่ละหน้า
- จดชื่อ key และชนิดข้อมูล (string, number, object) ของฟิลด์สำคัญ เช่น price, item_id, currency ในแต่ละหน้า แล้วนำมาเทียบกันในตารางเดียว
- ไฮไลต์จุดที่ key ชื่อต่างกันสำหรับความหมายเดียวกัน หรือชนิดข้อมูลไม่ตรงกัน เพราะจุดเหล่านี้คือรอยรั่วที่ต้องแก้ก่อนที่จะไปแก้ tag ใด ๆ
จุดที่พบบ่อยที่สุด: โครงสร้าง ecommerce object ไม่ตรงตามมาตรฐาน
สำหรับเว็บที่ใช้ GA4 Ecommerce การส่งข้อมูลสินค้าต้องอยู่ในโครงสร้าง item scope ที่ถูกต้อง ปัญหาที่พบบ่อยคือหน้าสินค้าส่งข้อมูลเป็น object เดี่ยว แต่หน้าตะกร้าที่มีสินค้าหลายชิ้นส่งเป็น array ซึ่งถ้า tag ที่ตั้งไว้ไม่รองรับทั้งสองรูปแบบ จะอ่านค่าผิดพลาดในหน้าใดหน้าหนึ่งโดยไม่มีการแจ้งเตือน
การแก้ปัญหานี้ต้องตกลงร่วมกันทั้งทีมว่าจะใช้โครงสร้างเดียวตลอดทั้งเว็บ แม้บางหน้าจะมีสินค้าชิ้นเดียวก็ควรห่อด้วย array เพื่อให้ tag อ่านค่าด้วยลอจิกเดียวกันได้ทุกหน้า
ตารางเทียบตัวอย่างที่ควรทำ เพื่อไล่ audit ได้ง่ายขึ้น
| ฟิลด์ | หน้าสินค้า (ตัวอย่างที่พบ) | หน้าตะกร้า (ตัวอย่างที่พบ) |
|---|---|---|
| price | string '1,290' | number 1290 |
| item_id | product_id | sku |
| currency | ไม่มีฟิลด์นี้ | THB |
ถ้าพบปัญหาหลายจุด ควรแก้จุดไหนก่อน
- แก้ฟิลด์ที่เกี่ยวกับมูลค่าเงิน (price, value) ก่อนเสมอ เพราะกระทบตัวเลขรายได้ที่ใช้ตัดสินใจเรื่องงบโฆษณาโดยตรง
- แก้ฟิลด์ที่ใช้ระบุตัวสินค้า (item_id, sku) เป็นลำดับถัดมา เพราะกระทบการวิเคราะห์ว่าสินค้าไหนขายดี
- ฟิลด์เสริมอย่าง currency หรือ category ที่ไม่มีผลกระทบเร่งด่วน สามารถทยอยแก้ทีหลังได้โดยไม่ต้องรีบ
สรุป
data layer ที่ไม่สอดคล้องกันเป็นปัญหาที่มองไม่เห็นด้วยตาเปล่าจากหน้าเว็บปกติ ต้องเปิดเครื่องมือนักพัฒนาไปดูโครงสร้างข้อมูลดิบถึงจะเจอ แต่ผลกระทบที่มันสร้างกลับสะท้อนออกมาเป็นตัวเลขรายได้ที่ผิดเพี้ยนในรายงานทุกวัน
- เปิดคอนโซลเบราว์เซอร์เทียบโครงสร้าง data layer ของแต่ละหน้าในเส้นทางลูกค้า
- แก้ฟิลด์ที่เกี่ยวกับมูลค่าเงินก่อนเสมอ เพราะกระทบการตัดสินใจเรื่องงบโดยตรง
- ทำเอกสารมาตรฐาน data layer แชร์ให้ทุกทีมที่พัฒนาเว็บใช้อ้างอิงร่วมกัน
คำถามที่พบบ่อย
data layer กับ event schema ต่างกันยังไง
event schema คือชื่อของ event ที่ถูกยิง ส่วน data layer คือโครงสร้างข้อมูลที่แนบไปกับ event นั้น สองอย่างนี้ต้องสอดคล้องกันทั้งคู่ ถ้าอย่างใดอย่างหนึ่งเพี้ยนก็ทำให้รายงานคลาดเคลื่อนได้เหมือนกัน
จะรู้ได้ยังไงว่า price ที่ส่งเป็น string ทำให้รายงานผิดจริง
ให้ลองเปิด GA4 ecommerce report เทียบมูลค่ารวมที่ระบบคำนวณกับยอดขายจริงจากบัญชี ถ้าตัวเลขต่ำกว่าความจริงอย่างสม่ำเสมอโดยไม่มีเหตุผลอื่น ควรสงสัยชนิดข้อมูลของฟิลด์ price เป็นอันดับต้น
ต้องเช็กทุกหน้าของเว็บไซต์เลยไหม
ไม่จำเป็นต้องเช็กทุกหน้า ให้เน้นหน้าที่อยู่ในเส้นทางการซื้อหลักก่อน เช่น หน้าสินค้า ตะกร้า และยืนยันคำสั่งซื้อ เพราะเป็นหน้าที่กระทบตัวเลขสำคัญที่สุด
ถ้าเว็บใช้ระบบหลังบ้านคนละตัวสำหรับแต่ละส่วน จะยิ่งมีปัญหานี้มากขึ้นไหม
ใช่ เพราะแต่ละระบบมักมีทีมพัฒนาต่างกันและไม่ได้สื่อสารกันเรื่องโครงสร้างข้อมูล ยิ่งเว็บมีหลายระบบต่อกัน ยิ่งต้องเข้มงวดกับการตกลงมาตรฐาน data layer ร่วมกันมากขึ้น
ควรทำเอกสารมาตรฐาน data layer ไว้ไหม
ควรทำ เป็นเอกสารสั้น ๆ ระบุชื่อ key และชนิดข้อมูลของแต่ละฟิลด์สำคัญ แชร์ให้ทุกทีมที่พัฒนาเว็บใช้อ้างอิงร่วมกัน จะช่วยลดปัญหานี้ในระยะยาวได้มาก
แก้โครงสร้าง data layer แล้วต้องแก้ tag ทั้งหมดตามด้วยไหม
ส่วนใหญ่ต้องปรับ tag ที่อ้างอิงถึงฟิลด์ที่เปลี่ยนไปด้วย ควรทำคู่ขนานกันและทดสอบผ่านโหมด preview ก่อนปล่อยใช้งานจริง เพื่อไม่ให้ tag พังหลังแก้ data layer
บทความที่เกี่ยวข้อง
