คะแนน Event Match Quality ร่วงจาก 7.2 เหลือ 4.8 ในคืนเดียว: วาง Diagnostic Workflow ไล่หาสาเหตุแบบไม่เดาสุ่ม

ทีมหนึ่งที่ผมเคยช่วยดู เปิด Meta Events Manager มาเจอคะแนน EMQ ของ event Purchase ร่วงจาก 7.2 ลงมาเหลือ 4.8 ข้ามคืน โดยไม่มีการ deploy โค้ดใหม่เลยสักบรรทัดในช่วงนั้น ทีมงงว่าเกิดอะไรขึ้น แล้วเริ่มไล่แก้ด้วยสัญชาตญาณ ลองปิดฟิลด์ชื่อออกบ้าง ลองเปลี่ยนวิธีแฮชอีเมลบ้าง ทำแบบนั้นอยู่สี่วันคะแนนก็ยังไม่ขยับ

สุดท้ายเจอว่าสาเหตุจริงคือ ทีม infra เปลี่ยนผู้ให้บริการ SMS OTP ทำให้ฟิลด์เบอร์โทรบางส่วนที่เคย normalize ผ่าน middleware ตัวเก่า ไม่ได้ผ่าน middleware ตัวใหม่ที่เพิ่งสลับมา เบอร์โทรที่ส่งเข้า CAPI เลยเป็น raw format ปนอยู่ประมาณ 30% ของ event ทั้งหมด ปัญหานี้ไม่เกี่ยวกับโค้ด CAPI เลยสักนิด แต่เกี่ยวกับการเปลี่ยนแปลงในระบบข้างเคียงที่ไม่มีใครคิดว่าจะกระทบ

สิ่งที่ทำให้เคสนี้ใช้เวลานานเกินจำเป็น ไม่ใช่ความยากของปัญหา แต่คือการไม่มีลำดับการตรวจที่ชัดเจน ถ้ามี diagnostic workflow ที่บอกว่าต้องเช็กอะไรก่อนหลัง น่าจะเจอสาเหตุได้ภายในหนึ่งวัน ไม่ใช่สี่วัน บทความนี้จะวางลำดับการวินิจฉัยที่ใช้ซ้ำได้ทุกครั้งที่ EMQ ตกโดยไม่รู้สาเหตุ

ทำไม EMQ ถึงตกแบบไม่มีสัญญาณเตือนล่วงหน้า

Event Match Quality เป็นคะแนนที่คำนวณจากคุณภาพและปริมาณของ signal ที่ส่งเข้าไปให้แพลตฟอร์มจับคู่กับผู้ใช้จริง ปัญหาคือมันเป็นคะแนนเฉลี่ยที่คำนวณย้อนหลังจาก event จำนวนมาก ไม่ใช่ค่าที่แจ้งเตือนแบบเรียลไทม์เมื่อมีอะไรผิดปกติ ต่างจาก error 500 ที่เห็นชัดทันที การที่ฟิลด์หนึ่งเริ่มส่งผิดรูปแบบไปเรื่อย ๆ อาจใช้เวลาหลายชั่วโมงกว่าคะแนนเฉลี่ยจะขยับลงมากพอให้สังเกตเห็น

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

วางลำดับการตรวจแบบ diagnostic tree แทนการไล่สุ่ม

1. เริ่มจากถามก่อนว่า มีการ deploy โค้ดหรือเปลี่ยนแปลง infra อะไรในช่วงเวลาที่ EMQ เริ่มตก ถ้ามี ให้เริ่มตรวจตรงนั้นก่อนเสมอ เพราะเป็นสาเหตุที่พบบ่อยที่สุดและตรวจสอบง่ายที่สุด
2. ถ้าไม่มีการเปลี่ยนแปลงที่ทีมพัฒนารู้ตัว ให้เช็กว่ามีทีมอื่นที่แตะระบบข้างเคียงหรือเปล่า เช่น ทีม infra เปลี่ยนผู้ให้บริการ, ทีม CRM ปรับฟอร์มเก็บข้อมูลลูกค้า เพราะการเปลี่ยนแปลงเหล่านี้มักไม่ถูกแจ้งให้ทีมที่ดูแล CAPI รู้ล่วงหน้า
3. ไล่ดูสัดส่วนของแต่ละฟิลด์ (เบอร์โทร อีเมล ชื่อ ที่อยู่) ว่าอันไหนที่อัตราการส่งค่าเปล่าหรือค่าที่ผิดรูปแบบเพิ่มขึ้นผิดปกติเมื่อเทียบกับก่อนหน้า แทนที่จะดูแค่คะแนนรวมตัวเดียว เพราะฟิลด์ที่มีปัญหาจริงมักซ่อนอยู่หลังตัวเลขเฉลี่ยที่ดูเหมือนไม่เปลี่ยนมาก
4. เมื่อเจอฟิลด์ต้องสงสัยแล้ว ดึงตัวอย่าง event จริงในช่วงเวลานั้นมาดู raw payload ก่อนแฮชโดยตรง เพื่อยืนยันว่ารูปแบบข้อมูลผิดจริงหรือเปล่า ไม่ใช่แค่เดาจากตัวเลขสถิติเพียงอย่างเดียว
5. ถ้ายังหาไม่เจอ ให้ขยับกลับไปเช็กว่ากลุ่มลูกค้าที่ event มีปัญหาเป็นกลุ่มเดียวกันหรือกระจายทั่วไป เช่น เกิดเฉพาะลูกค้าใหม่ที่สมัครหลังวันที่หนึ่ง อาจชี้ไปที่ฟอร์มสมัครสมาชิกเวอร์ชันใหม่ที่เพิ่งเปลี่ยน

ตรวจทีละฟิลด์ตามน้ำหนักผลกระทบที่มีต่อคะแนน

สาเหตุที่พบบ่อยจริง ๆ เมื่อ EMQ ตกกะทันหัน

• เปลี่ยน library หรือ dependency ที่ทำ normalize — อัปเดตเวอร์ชันแล้วพฤติกรรมการ trim หรือ format เปลี่ยนไปโดยไม่มีใครสังเกต
• ฟอร์มหน้าเว็บเปลี่ยนโครงสร้างฟิลด์ — ทีมการตลาดปรับฟอร์มสั่งซื้อ แล้วชื่อฟิลด์ที่ backend อ่านไม่ตรงกับที่ frontend ส่งมาอีกต่อไป
• Consent banner บล็อกการอ่าน cookie ก่อนเวลา — โดยเฉพาะ fbc/fbp ที่ต้องอ่านก่อนผู้ใช้กด accept ถ้า banner บล็อกไว้ ค่าจะว่างเปล่าทั้งที่ก่อนหน้านี้เคยส่งได้ปกติ
• ผู้ให้บริการ third-party ที่ช่วย validate ข้อมูลล้ม — เช่น service ตรวจสอบเบอร์โทรถูกต้องหยุดทำงานเงียบ ๆ แล้วข้อมูลดิบหลุดผ่านไปโดยไม่ผ่านการตรวจ
• batch job ที่ backfill ข้อมูลเก่า — เผลอส่ง event เก่าที่มีคุณภาพข้อมูลต่ำกว่าเข้าไปปนกับ event ปัจจุบัน ทำให้คะแนนเฉลี่ยของช่วงนั้นตก

วางระบบติดตามแนวโน้ม EMQ ต่อเนื่อง แทนการเช็กเป็นครั้งคราว

การเปิด Events Manager มาดูคะแนนเป็นครั้งคราวมีข้อเสียคือ กว่าจะรู้ตัวว่าคะแนนตกก็อาจผ่านไปหลายวันแล้ว วิธีที่ทำให้จับปัญหาได้เร็วกว่าคือดึงคะแนน EMQ ผ่าน API มาเก็บเป็น time series ของตัวเองแล้วตั้ง alert เมื่อคะแนนตกเกินเกณฑ์ที่กำหนดในช่วงเวลาสั้น ๆ เช่น ตกมากกว่า 0.5 จุดภายใน 24 ชั่วโมง

อีกสิ่งที่ควรทำคู่กันคือเก็บ log อัตราการส่งค่าว่างหรือค่าผิดรูปแบบของแต่ละฟิลด์แยกจากคะแนน EMQ ของแพลตฟอร์ม เพราะมันเป็นสัญญาณเตือนล่วงหน้าที่ไวกว่า EMQ เอง ในเคสร้านที่เล่าตอนต้น ถ้ามี dashboard แยกแสดงอัตราเบอร์โทรที่ผิด format ทีมน่าจะเห็นความผิดปกติตั้งแต่ชั่วโมงแรกที่มีการสลับ SMS provider แทนที่จะรอให้คะแนนรวมตกจนสังเกตเห็น

สรุป

EMQ ที่ตกกะทันหันมักไม่ได้มีสาเหตุซับซ้อนอย่างที่คิด แต่การหาสาเหตุให้เจอเร็วต้องมีลำดับการตรวจที่ชัดเจน ไม่ใช่ไล่แก้ทีละจุดตามความรู้สึก ทีมที่มี diagnostic workflow พร้อมใช้ล่วงหน้า จะประหยัดเวลาไปได้มากเมื่อวันที่ปัญหาจริงเกิดขึ้น

สิ่งที่คุ้มค่าที่สุดในระยะยาวไม่ใช่การแก้ปัญหาให้เร็วอย่างเดียว แต่คือการวางระบบติดตามที่ทำให้รู้ตัวตั้งแต่ชั่วโมงแรกที่ค่าเริ่มผิดปกติ ก่อนที่มันจะกลายเป็นคะแนนเฉลี่ยที่ตกจนสังเกตเห็นชัดในหลายวันถัดมา

• EMQ ตกช้า ๆ เพราะเป็นคะแนนเฉลี่ยที่คำนวณย้อนหลัง ไม่ใช่ error ที่แจ้งเตือนทันที
• ไล่ตรวจตามลำดับ: การเปลี่ยนแปลงล่าสุด → ระบบข้างเคียง → สัดส่วนฟิลด์ → raw payload จริง
• วางระบบเก็บ time series ของ EMQ และอัตราค่าฟิลด์ผิดรูปแบบ เพื่อจับปัญหาได้เร็วกว่าการเช็กเป็นครั้งคราว

คำถามที่พบบ่อย