ใช้ Test Event Tool ให้เป็น ก่อนจะเสียเวลาไล่บั๊กผิดจุดไปหลายวัน
สรุปสั้น ๆ
Test event tool ของ Meta และ Google เป็นเครื่องมือฟรีที่ให้ดู event แบบเรียลไทม์พร้อมรายละเอียดว่าทำไมถึงถูกรับหรือถูกปฏิเสธ แต่หลายทีมไล่ดีบักด้วยการเดาแทน ทั้งที่ถ้าเปิดเครื่องมือนี้ตั้งแต่ต้น มักหาสาเหตุเจอภายในไม่กี่นาทีแทนที่จะเดาไปเรื่อย ๆ หลายวัน
ทีมพัฒนาของลูกค้ารายหนึ่งใช้เวลาสามวันเต็มไล่แก้บั๊ก conversion ที่ไม่เข้าระบบ (คล้ายกับอาการในเรื่อง pixel ไม่ยิงที่เคยเล่าไป) ลองแก้โค้ดไปหลายรอบ เปลี่ยน token ใหม่ เปลี่ยน endpoint ใหม่ ก่อนจะมาถามผมว่าเปิด test event tool ดูหรือยัง คำตอบคือยังไม่เคยเปิดเลยสักครั้งตลอดสามวันที่ผ่านมา
พอเปิดเข้าไปดู ปัญหาที่แท้จริงปรากฏชัดภายในไม่ถึงห้านาที คือฟิลด์หนึ่งในข้อมูลที่ส่งมีรูปแบบผิดจากที่ปลายทางต้องการ ทั้งที่เดาแก้กันมาสามวันไม่เคยตรงจุดเลยสักครั้ง เพราะไม่มีใครเห็นข้อความ error ที่แท้จริงจากปลายทาง
Test Event Tool ทำอะไรได้บ้าง
เครื่องมือนี้ทำหน้าที่แสดง event ที่ยิงเข้ามาแบบเรียลไทม์ พร้อมสถานะว่าถูกรับหรือถูกปฏิเสธ และถ้าถูกปฏิเสธจะบอกเหตุผลเฉพาะเจาะจง เช่นฟิลด์ไหนขาดหาย หรือรูปแบบข้อมูลผิดแบบไหน ต่างจากการดูแค่ response code ที่มักบอกได้แค่ ‘สำเร็จหรือไม่สำเร็จ’ แบบกว้าง ๆ
จุดสำคัญคือมันเป็นเครื่องมือของ ‘ปลายทาง’ ไม่ใช่ของเรา นั่นแปลว่ามันบอกความจริงที่สุดว่าปลายทางเห็นอะไรบ้างจากสิ่งที่เราส่งไป ต่างจากการเดาจาก log ฝั่งเราเองที่บอกได้แค่ว่า ‘เราส่งอะไรออกไป’ แต่ไม่รู้ว่าปลายทาง ‘ตีความมันว่ายังไง’
ใช้งานทีละขั้น ตั้งแต่เปิดจนได้คำตอบ
- เข้าไปที่หน้า event manager หรือเครื่องมือทดสอบของแพลตฟอร์มที่กำลังมีปัญหา (แต่ละแพลตฟอร์มมีชื่อเรียกและตำแหน่งต่างกัน)
- ยิง event ทดสอบหนึ่งตัวจากระบบจริง ไม่ใช่ event เก่าที่ค้างอยู่ เพื่อให้เห็นผลลัพธ์แบบสด ๆ ตรงกับสถานะปัจจุบันของระบบ
- ดูว่า event นั้นปรากฏในเครื่องมือหรือไม่ ถ้าไม่ปรากฏเลยแปลว่าปัญหาอยู่ที่การเชื่อมต่อ ไม่ใช่เรื่อง schema หรือข้อมูล
- ถ้าปรากฏแต่มีสถานะ error ให้อ่านรายละเอียด error message ที่แสดงให้ครบ อย่าข้ามไปเพราะมันมักบอกตรง ๆ ว่าฟิลด์ไหนมีปัญหา
- แก้ไขตามที่ error บอก แล้วยิง event ทดสอบซ้ำอีกครั้งเพื่อยืนยันว่าแก้ถูกจุดแล้วจริง ไม่ใช่แก้แล้วก็จบโดยไม่ตรวจสอบซ้ำ
ข้อความ Error ที่เจอบ่อย และความหมาย
| ข้อความ Error โดยประมาณ | ความหมาย | จุดที่ควรแก้ |
|---|---|---|
| Missing required parameter | ขาดฟิลด์ที่ปลายทางบังคับต้องมี | เพิ่มฟิลด์ที่ขาดในข้อมูลที่ส่ง |
| Invalid parameter format | รูปแบบข้อมูลผิด เช่นวันที่หรือตัวเลข | ปรับรูปแบบให้ตรงตามเอกสารของปลายทาง |
| Access token invalid or expired | token ใช้งานไม่ได้แล้ว | ตรวจสอบและต่ออายุ<a href="/blog/token-expired-conversion-api-line">token</a> |
| Duplicate event received | ปลายทางเห็นว่า event นี้ซ้ำกับที่เคยส่งมาแล้ว | ตรวจสอบ<a href="/blog/dedup-key-mismatch-line">การออกแบบ event ID</a> |
ทดสอบผ่านแล้ว ยังต้องทำอะไรต่อ
การที่ event ทดสอบผ่านไม่ได้แปลว่าทุกอย่างเรียบร้อยแล้ว 100% เพราะ event ทดสอบมักเป็นแค่หนึ่งตัวอย่าง ควรตรวจสอบต่อว่า event จริงจากผู้ใช้จริงในสัดส่วนที่หลากหลายก็ผ่านเช่นกัน ไม่ใช่แค่เคสที่ตั้งใจทดสอบเป็นพิเศษ
ผมมักแนะนำให้ทำเป็นนิสัยว่าทุกครั้งที่จะไล่ดีบักปัญหา tracking ให้เปิด test event tool เป็นขั้นตอนแรก ๆ เสมอ ก่อนจะเริ่มแก้โค้ดหรือเปลี่ยนค่าใด ๆ เพราะมันมักประหยัดเวลาได้มากกว่าการเดาสุ่มไปเรื่อย ๆ
สรุป
เครื่องมือ debug ที่ดีที่สุดคือปลายทางเอง ไม่ใช่การเดาจากฝั่งเราเพียงอย่างเดียว เพราะปลายทางเห็นสิ่งที่เราส่งไปในมุมที่เราเองมองไม่เห็นจากฝั่งต้นทาง
การเปิด test event tool เป็นขั้นตอนแรกก่อนไล่บั๊กไม่ใช่แค่ประหยัดเวลา แต่ยังลดโอกาสแก้ผิดจุดที่อาจทำให้ปัญหาซับซ้อนขึ้นไปอีก
- เปิด test event tool เป็นขั้นตอนแรกเสมอ ก่อนเริ่มแก้โค้ดหรือเดาสาเหตุ
- อ่าน error message ให้ครบ ไม่ใช่ดูแค่ว่าผ่านหรือไม่ผ่าน
- ทดสอบซ้ำทุกครั้งหลังแก้ไข เพื่อยืนยันว่าแก้ถูกจุดแล้วจริง
- ทำเป็นขั้นตอนมาตรฐานก่อน deploy โค้ดใหม่ทุกครั้งที่เกี่ยวกับ tracking
คำถามที่พบบ่อย
test event tool ของ Meta กับ Google ใช้งานเหมือนกันไหม
หลักการคล้ายกันคือแสดง event แบบเรียลไทม์พร้อมสถานะ แต่หน้าตาและตำแหน่งเมนูต่างกัน ควรอ่านเอกสารของแต่ละแพลตฟอร์มเฉพาะเจาะจง เพราะการตั้งชื่อฟีเจอร์และรายละเอียดปลีกย่อยไม่เหมือนกันทุกจุด
ถ้า event ทดสอบผ่านหมดแต่ event จริงยังมีปัญหา ควรทำยังไงต่อ
ให้เปรียบเทียบ payload ของ event ทดสอบกับ event จริงที่มีปัญหาอย่างละเอียด บางครั้งความต่างเล็กน้อย เช่นค่าว่างในบางฟิลด์ที่ event ทดสอบไม่เจอ แต่ event จริงบางเคสเจอ ก็ทำให้ผลลัพธ์ต่างกันได้
ต้องเปิด test event tool ทุกครั้งที่ deploy โค้ดใหม่ไหม
แนะนำให้ทำ อย่างน้อยเป็นการทดสอบเบื้องต้นก่อนปล่อยขึ้น production เต็มรูปแบบ เพราะช่วยจับปัญหาได้ตั้งแต่ก่อนกระทบผู้ใช้จริง ดีกว่ามารู้ทีหลังว่ามีปัญหาจากการที่ยอด conversion ตกลง
เครื่องมือนี้มีค่าใช้จ่ายไหม
โดยทั่วไป test event tool ของแพลตฟอร์มโฆษณาหลักเป็นฟีเจอร์ที่มาพร้อมกับบัญชีโฆษณาอยู่แล้วโดยไม่มีค่าใช้จ่ายเพิ่มเติม แต่ควรตรวจสอบเงื่อนไขล่าสุดของแต่ละแพลตฟอร์มโดยตรงเพราะนโยบายอาจเปลี่ยนแปลงได้
ทำไมทีมพัฒนาถึงมักลืมใช้เครื่องมือนี้ตั้งแต่แรก
ส่วนใหญ่เพราะความเคยชินที่จะไล่ดีบักจาก log และโค้ดฝั่งตัวเองก่อนเสมอ ทั้งที่ log ฝั่งเราบอกได้แค่ว่าส่งอะไรออกไป แต่ไม่บอกว่าปลายทางตีความมันอย่างไร การสร้างนิสัยเปิดเครื่องมือนี้เป็นขั้นตอนแรกช่วยประหยัดเวลาได้มากในระยะยาว
บทความที่เกี่ยวข้อง
