ข้อมูลส่งครบ แต่ผิดทุกแถว: วางชั้นตรวจสอบคุณภาพข้อมูลก่อนเข้าคลังข้อมูลจริง
สรุปสั้น ๆ
ระบบที่ 'ส่งข้อมูลได้สำเร็จ' กับระบบที่ 'ส่งข้อมูลถูกต้อง' เป็นคนละเรื่องกัน การมีชั้นตรวจสอบคุณภาพข้อมูลก่อนบันทึกลงคลังข้อมูลจริง ช่วยจับความผิดปกติตั้งแต่ต้นทาง แทนที่จะปล่อยให้ทีมวิเคราะห์ไปเจอความมั่วตอนทำรายงานปลายทาง
ทีมข้อมูลของธุรกิจขายเครื่องใช้ไฟฟ้าออนไลน์แห่งหนึ่งเจอเรื่องชวนปวดหัว คือทำรายงานยอดขายรายจังหวัดแล้วเจอว่ามีลูกค้าจากจังหวัด '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 นับซ้ำ และควรทำงานร่วมกับการกำจัดข้อมูลซ้ำในฐานลูกค้า เพื่อไม่ให้ปัญหาไหลต่อไปถึงชั้นรายงาน
ไม่ใช่ทุกข้อมูลผิดต้องถูกปฏิเสธเหมือนกัน
| ระดับความผิดปกติ | การจัดการ | ตัวอย่าง |
|---|---|---|
| ผิดร้ายแรง (ต้องปฏิเสธ) | ไม่บันทึกเข้าตารางจริง พักไว้ในตาราง reject พร้อมแจ้งเตือนทีมเทคนิค | ไม่มี LINE UID, เวลาที่เหตุการณ์เกิดเป็นค่าว่าง |
| ผิดปานกลาง (บันทึกพร้อมแจ้งเตือน) | บันทึกเข้าตารางจริงแต่ติดธงว่าผิดปกติ ให้ทีมวิเคราะห์รู้ว่าต้องระวัง | ยอดขายสูงผิดปกติเกิน 5 เท่าของค่าเฉลี่ย |
| ผิดเล็กน้อย (แก้ไขอัตโนมัติ) | แก้ไขให้อัตโนมัติตามกฎที่ตกลงไว้ล่วงหน้า | เบอร์โทรมีช่องว่างหรือขีดกลางแทรกอยู่ |
อย่าตั้งกฎแล้วลืม ต้องมีรอบทบทวน
กฎตรวจสอบที่ตั้งไว้วันนี้อาจใช้ไม่ได้อีกต่อไปเมื่อธุรกิจเปลี่ยนแปลง เช่นเริ่มขายในต่างประเทศแล้วเบอร์โทรไม่ใช่รูปแบบไทยอีกต่อไป ควรมีรอบทบทวนกฎเหล่านี้อย่างน้อยทุกไตรมาส และเมื่อไหร่ที่มีการเปลี่ยนฟิลด์ข้อมูลจากทีมโปรดักต์ ควรทบทวนทันที ไม่ต้องรอถึงรอบ เพื่อไม่ให้ซ้ำรอยปัญหาแบบที่เกิดกับการเปลี่ยนโครงสร้างข้อมูลกลางคัน การทำเช่นนี้ยังช่วยรักษามาตรฐานสุขอนามัยของข้อมูลลูกค้าในระยะยาวด้วย
สรุป
ข้อมูลที่ 'ส่งได้ครบ' กับข้อมูลที่ 'เชื่อถือได้' เป็นคนละเรื่อง ทีมที่วัดความสำเร็จของ pipeline แค่จากว่าข้อมูลไหลถึงปลายทางหรือไม่ มักพลาดจุดสำคัญที่สุดคือคุณภาพของสิ่งที่ไหลเข้ามา
การลงทุนวางชั้นตรวจสอบตั้งแต่ต้นทาง แม้จะดูเป็นงานที่ไม่มีใครเห็นผลทันที แต่มันคือสิ่งที่ทำให้ทุกรายงานและการตัดสินใจที่ต่อยอดจากข้อมูลนั้นน่าเชื่อถือจริง ๆ
- ควรตรวจสอบข้อมูลที่ชั้นกันก่อนเข้าตารางจริง ไม่ใช่ตรวจทีหลังตอนทำรายงาน
- แบ่งระดับความผิดปกติเป็นปฏิเสธ แจ้งเตือน หรือแก้ไขอัตโนมัติ ไม่ใช่ปฏิบัติเหมือนกันหมด
- กฎตรวจสอบต้องมีรอบทบทวน ไม่ใช่ตั้งครั้งเดียวแล้วปล่อยไว้ตลอดไป
คำถามที่พบบ่อย
ต้องเขียนโค้ดตรวจสอบเองทั้งหมดไหม
ไม่จำเป็นเสมอไป มีเครื่องมือสำเร็จรูปหลายตัวที่ช่วยตั้งกฎตรวจสอบข้อมูลได้โดยไม่ต้องเขียนโค้ดซับซ้อนมาก แต่ทีมยังต้องเป็นคนกำหนดเกณฑ์เองว่าอะไรถือว่าผิดปกติสำหรับธุรกิจตัวเอง
ข้อมูลที่ถูกปฏิเสธควรเก็บไว้นานแค่ไหน
ควรเก็บไว้อย่างน้อย 30-90 วันเพื่อให้ทีมเทคนิคย้อนดูสาเหตุได้ ไม่ควรลบทิ้งทันทีเพราะบางครั้งข้อมูลที่ดูผิดอาจเป็นเบาะแสของบั๊กที่ยังไม่ถูกแก้
การตรวจสอบข้อมูลจะทำให้ระบบช้าลงไหม
ถ้าออกแบบให้ตรวจที่ชั้นกันก่อนเข้าตารางจริง จะกระทบความเร็วเพียงเล็กน้อยเท่านั้น เพราะเป็นการตรวจข้อมูลทีละแถวที่ใช้เวลาสั้นมาก เทียบกับความเสียหายที่เกิดถ้าข้อมูลผิดหลุดเข้าไปแล้ว
ธุรกิจขนาดเล็กจำเป็นต้องมีชั้นตรวจสอบนี้ไหม
ถ้าปริมาณ Conversion ต่อวันยังน้อย อาจตรวจด้วยตาเปล่าเป็นระยะได้ แต่พอเริ่มมีหลายร้อยรายการต่อวัน ควรมีระบบอัตโนมัติแล้ว เพราะการตรวจด้วยมือจะพลาดและไม่ทันเวลา
ถ้าเจอข้อมูลผิดปกติจำนวนมากพร้อมกัน ควรทำยังไง
ควรหยุดกระบวนการนำเข้าชั่วคราวแล้วตรวจสาเหตุก่อน แทนที่จะปล่อยให้ไหลต่อไปเรื่อย ๆ เพราะจำนวนมากพร้อมกันมักแปลว่าเกิดจากการเปลี่ยนแปลงต้นทางที่ยังไม่ได้แจ้ง ไม่ใช่ความผิดปกติแยกรายเคส
บทความที่เกี่ยวข้อง
