เบอร์เดียวกัน แต่แฮชได้คนละค่า จุดพลาดของการ Normalize ข้อมูลไทยก่อนแฮชส่งเข้า CAPI

มีทีมหนึ่งที่ผมช่วยตรวจโค้ดให้ เขาบ่นว่า match quality บน Meta ตกต่ำผิดปกติ ทั้งที่ hash เบอร์โทรกับอีเมลไปหมดทุก event แล้ว ผมขอดู log การแฮชจริง ๆ พบว่าปัญหาไม่ได้อยู่ที่ตัวฟังก์ชัน SHA-256 เลย แต่อยู่ที่ข้อมูลก่อนแฮช ลูกค้าคนเดียวกันบางออเดอร์เก็บเบอร์เป็น 0812345678 บางออเดอร์เก็บเป็น 081-234-5678 บางออเดอร์เก็บเป็น +66812345678 ทั้งสามค่านี้ผ่าน SHA-256 แล้วได้ hash คนละค่ากันหมด ทั้งที่เป็นเบอร์เดียวกันเป๊ะ

นี่คือความเข้าใจผิดที่พบบ่อยในทีมพัฒนา คือคิดว่าเรื่องแฮชจบแค่ ‘เรียกฟังก์ชัน SHA-256’ แล้วส่งไป แต่ความจริงแพลตฟอร์มโฆษณาทุกเจ้าคาดหวังว่า input ก่อนแฮชต้องผ่านการทำความสะอาดตามสเปกที่กำหนดไว้ก่อน ถ้าทำไม่ตรง hash จะไม่มีวันตรงกับที่แพลตฟอร์มมีอยู่ในระบบของเขา ต่อให้เป็นข้อมูลถูกต้อง 100% ก็ตาม

บทความนี้จะเจาะกฎ normalize ที่ต้องรู้เป็นพิเศษเมื่อทำงานกับข้อมูลไทย เพราะเบอร์โทรและชื่อของคนไทยมีลักษณะเฉพาะที่สเปกทั่วไปของแพลตฟอร์มไม่ได้พูดถึงตรง ๆ

กับดักเบอร์โทรไทย: 0 นำหน้า vs +66 vs ช่องว่างที่มองไม่เห็น

เบอร์โทรไทยมาตรฐานคือ 10 หลักขึ้นต้นด้วย 0 แต่รูปแบบสากลที่แพลตฟอร์มโฆษณาส่วนใหญ่คาดหวังคือรูปแบบ E.164 ซึ่งต้องตัด 0 นำหน้าออกแล้วใส่รหัสประเทศ +66 แทน นั่นแปลว่า 0812345678 ต้องกลายเป็น 66812345678 ก่อนแฮช (ไม่มีเครื่องหมายบวก ไม่มีช่องว่าง) ถ้าระบบของคุณเก็บเบอร์แบบ 0812345678 ตรง ๆ แล้วแฮชเลยโดยไม่แปลง จะไม่มีวันจับคู่กับข้อมูลที่แพลตฟอร์มมีอยู่ได้เลย

ปัญหาที่ซ่อนอยู่ลึกกว่านั้นคือ แหล่งข้อมูลลูกค้าที่มาจากหลายช่องทางมักเก็บเบอร์คนละรูปแบบ แบบฟอร์มเว็บอาจเก็บ 081-234-5678 แอดมินพิมพ์มือใน CRM อาจเผลอเว้นวรรค หรือมีเลข 0 ซ้ำสองตัวจากการ copy-paste ผิด ทุกความต่างเล็ก ๆ เหล่านี้ทำให้แฮชออกมาคนละค่า ต้องมีขั้นตอน strip อักขระที่ไม่ใช่ตัวเลขออกทั้งหมดก่อน แล้วค่อยเช็กว่าขึ้นต้นด้วย 0 หรือ 66 แล้วแปลงให้เป็นรูปแบบเดียวกันเสมอ

อีเมล: ตัวพิมพ์เล็ก-ใหญ่ และช่องว่างหัวท้ายที่คนมักลืม

กฎของอีเมลดูเหมือนง่ายกว่าเบอร์โทร แต่จุดพลาดที่เจอบ่อยคือลืมแปลงเป็นตัวพิมพ์เล็กทั้งหมดก่อนแฮช เพราะ Somchai@Gmail.com กับ somchai@gmail.com คือกล่องเมลเดียวกันในทางปฏิบัติ แต่ SHA-256 มองว่าเป็นสตริงคนละตัวและให้ hash คนละค่า ถ้าฟอร์มลูกค้าอนุญาตให้พิมพ์ตัวพิมพ์ใหญ่ได้อิสระ (ซึ่งเบราว์เซอร์ส่วนใหญ่ก็ไม่บังคับ) ต้องมีขั้นตอน lowercase บังคับในโค้ดฝั่งเซิร์ฟเวอร์เสมอ อย่าไว้ใจว่าฝั่ง frontend ทำให้แล้ว

อีกจุดที่มองข้ามคือช่องว่างที่แฝงมากับการ copy-paste จากแอปแชท เวลาแอดมินคัดลอกอีเมลจากข้อความ LINE มาวางใน CRM บางครั้งจะติดช่องว่างที่มองไม่เห็นมาด้วย (เช่น zero-width space หรือ trailing space) ต้อง trim ทั้งหัวและท้ายสตริงก่อนแฮชเสมอ ไม่ใช่แค่ trim ช่องว่างธรรมดาที่มองเห็นด้วยตา

ชื่อ-นามสกุลคนไทย: ทำไมจับคู่ได้ยากกว่าประเทศอื่น

บางแพลตฟอร์มรับ hash ของชื่อ-นามสกุลเป็นสัญญาณเสริมเพื่อยกระดับการจับคู่ แต่ชื่อคนไทยมีความหลากหลายของการสะกดมากกว่าภาษาอังกฤษมาก คำเดียวกันสะกดได้หลายแบบ (เช่น สมชาย vs สมไชย ในบางกรณีเป็นคนละครอบครัวสะกดต่างกันจริง) และคนไทยมักใช้ชื่อเล่นในการทักแชทแทนชื่อจริงในเอกสาร ทำให้ signal จากชื่อมีความน่าเชื่อถือต่ำกว่าเบอร์โทรและอีเมลมาก

คำแนะนำที่ใช้ได้จริงคือ อย่าพึ่งชื่อเป็น signal หลักเพียงอย่างเดียว ให้ใช้เป็น signal เสริมที่ส่งไปพร้อมกับเบอร์โทรหรืออีเมลเสมอ และถ้าจะ normalize ชื่อ อย่างน้อยต้อง trim ช่องว่างและลบคำนำหน้าอย่าง นาย นาง นางสาว ออกให้สม่ำเสมอ เพราะบางระบบเก็บคำนำหน้าปนมากับชื่อ บางระบบแยกเป็นคอลัมน์ต่างหาก ความไม่สม่ำเสมอตรงนี้ก็ทำให้แฮชไม่ตรงกันได้เหมือนกัน

แต่ละแพลตฟอร์มสเปกไม่เหมือนกันเป๊ะ ต้อง normalize แยกชุด

วาง pipeline normalize ให้เป็นขั้นตอนเดียวที่ใช้ร่วมกันทุกแพลตฟอร์ม

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

ทีมที่ทำเรื่องนี้ได้ดีมักมี test suite เล็ก ๆ ที่ป้อนเบอร์โทรและอีเมลรูปแบบแปลก ๆ ที่เจอจริงจากข้อมูลลูกค้า (ไม่ใช่แค่เคสสวย ๆ ในเอกสาร) แล้วเช็กว่าผลลัพธ์ normalize ตรงกับที่คาดหวังเสมอ เพราะการไล่ดีบัก match quality ที่ตกต่ำในภายหลังจะยากขึ้นมากถ้าไม่มีจุดตรวจสอบตั้งแต่ตอนเขียนโค้ด

สรุป

ปัญหา match quality ต่ำที่หลายทีมโทษว่าแพลตฟอร์มโฆษณา ‘ไม่แม่น’ ส่วนใหญ่จริง ๆ แล้วเกิดจากข้อมูลก่อนแฮชในระบบตัวเองไม่สม่ำเสมอ ซึ่งเป็นเรื่องที่แก้ได้ด้วยโค้ดไม่กี่บรรทัด แต่ต้องรู้ก่อนว่าจุดที่ต้องแก้อยู่ตรงไหน

ถ้าทีมคุณยังไม่เคยเขียน test suite ทดสอบการ normalize เบอร์โทรและอีเมลรูปแบบแปลก ๆ ที่เจอจริงในฐานข้อมูล นี่คืองานที่ควรทำก่อนไปปรับจูนเรื่องอื่น เพราะต้นทางสะอาด ปลายทางถึงจะแม่นตามไปด้วย

• เบอร์โทรไทยต้องแปลงเป็น E.164 (66xxxxxxxxx) ก่อนแฮชเสมอ ไม่ใช่ 0xxxxxxxxx
• อีเมลต้อง lowercase และ trim ช่องว่างที่มองไม่เห็นก่อนแฮชทุกครั้ง
• แต่ละแพลตฟอร์มมีสเปก normalize ต่างกันเล็กน้อย ต้องแยกชั้นแปลงข้อมูลตามปลายทาง

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