ข้อมูลส่งครบ แต่ผิดทุกแถว วางชั้นตรวจสอบคุณภาพข้อมูลก่อนเข้าคลังข้อมูลจริงยังไง

ทีมข้อมูลของธุรกิจขายเครื่องใช้ไฟฟ้าออนไลน์แห่งหนึ่งเจอเรื่องชวนปวดหัว คือทำรายงานยอดขายรายจังหวัดแล้วเจอว่ามีลูกค้าจากจังหวัด 'null' อยู่เกือบ 8% ของทั้งหมด พอไล่ดูต้นตอพบว่าฟิลด์ที่อยู่บางส่วนถูกกรอกมาแบบว่างเปล่าตั้งแต่ต้นทาง ระบบ tracking ก็รับเข้าไปเก็บโดยไม่ได้เช็กอะไรเลย เพราะ 'ส่งสำเร็จ' ไม่เท่ากับ 'ข้อมูลถูกต้อง'

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

บทความนี้จะพาดูว่าชั้นตรวจสอบคุณภาพข้อมูล (data validation layer) ที่ใช้งานได้จริงควรวางไว้ตรงไหน และตรวจอะไรบ้างถึงจะคุ้มกับเวลาที่ลงทุนไป

ตรวจตรงไหนถึงจะทัน ไม่ใช่ตรวจหลังเสียหายแล้ว

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

ตำแหน่งที่เหมาะสมคือ 'ชั้นกัน' (staging layer) ระหว่างจุดรับข้อมูลดิบจาก webhook กับตารางข้อมูลจริงที่ทีมวิเคราะห์ใช้งาน ข้อมูลทุกแถวต้องผ่านด่านนี้ก่อน ถ้าผ่านเกณฑ์ถึงจะย้ายเข้าตารางจริง ถ้าไม่ผ่านให้พักไว้ในตารางแยกพร้อมเหตุผลที่ถูกปฏิเสธ ไม่ใช่ทิ้งไปเฉย ๆ เพราะบางทีข้อมูลที่ 'ดูผิด' อาจเป็นสัญญาณของบั๊กจุดอื่นที่ต้องตามไปแก้

รายการตรวจที่คุ้มค่าที่สุด

• ตรวจฟอร์แมต (format check) เช่นเบอร์โทรต้องมี 10 หลักขึ้นต้นด้วย 0 อีเมลต้องมีเครื่องหมาย @ วันที่ต้องอยู่ในรูปแบบที่ระบบอ่านได้ถูก
• ตรวจค่าว่างในฟิลด์บังคับ (required field) เช่นทุก event ต้องมี LINE UID และเวลาที่เกิดเหตุการณ์ ถ้าขาดควรถูกปฏิเสธทันทีไม่ใช่ปล่อยผ่านเป็นค่า null เงียบ ๆ
• ตรวจความสมเหตุสมผลของค่า (range check) เช่นยอดขายติดลบ หรือเวลาที่เหตุการณ์เกิดในอนาคต ล้วนเป็นสัญญาณว่ามีบั๊กต้นทาง ไม่ใช่ข้อมูลจริง
• ตรวจการซ้ำ (duplicate check) โดยเทียบ event ID หรือ combination ของ LINE UID กับเวลา เพื่อกันไม่ให้ Conversion เดียวกันถูกนับซ้ำจากการยิง webhook สองครั้ง ปัญหานี้มักเกิดร่วมกับกรณีที่อธิบายไว้ใน Conversion นับซ้ำ และควรทำงานร่วมกับการกำจัดข้อมูลซ้ำในฐานลูกค้า เพื่อไม่ให้ปัญหาไหลต่อไปถึงชั้นรายงาน

ไม่ใช่ทุกข้อมูลผิดต้องถูกปฏิเสธเหมือนกัน

อย่าตั้งกฎแล้วลืม ต้องมีรอบทบทวน

กฎตรวจสอบที่ตั้งไว้วันนี้อาจใช้ไม่ได้อีกต่อไปเมื่อธุรกิจเปลี่ยนแปลง เช่นเริ่มขายในต่างประเทศแล้วเบอร์โทรไม่ใช่รูปแบบไทยอีกต่อไป ควรมีรอบทบทวนกฎเหล่านี้อย่างน้อยทุกไตรมาส และเมื่อไหร่ที่มีการเปลี่ยนฟิลด์ข้อมูลจากทีมโปรดักต์ ควรทบทวนทันที ไม่ต้องรอถึงรอบ เพื่อไม่ให้ซ้ำรอยปัญหาแบบที่เกิดกับการเปลี่ยนโครงสร้างข้อมูลกลางคัน การทำเช่นนี้ยังช่วยรักษามาตรฐานสุขอนามัยของข้อมูลลูกค้าในระยะยาวด้วย

สรุป

ข้อมูลที่ 'ส่งได้ครบ' กับข้อมูลที่ 'เชื่อถือได้' เป็นคนละเรื่อง ทีมที่วัดความสำเร็จของ pipeline แค่จากว่าข้อมูลไหลถึงปลายทางหรือไม่ มักพลาดจุดสำคัญที่สุดคือคุณภาพของสิ่งที่ไหลเข้ามา

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

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

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