I. พื้นฐานข้อมูลและระบบ

🔐 คุณภาพและความถูกต้องของข้อมูล CRMCRM Data Quality & Governance

เมื่อทีมพูดว่า “ลูกค้าคนเดียวมี 3 โปรไฟล์ ส่ง SMS ไปเบอร์เก่า Dashboard ไม่ตรงกับบัญชี แล้วตอนนี้จะเอา AI มาตอบแชตลูกค้าอีก”

Data Quality & Governance คือการทำให้ข้อมูลลูกค้าใน CRM ถูกต้อง ครบ ไม่ซ้ำ ทันสมัย และมีคนรับผิดชอบชัดเจน ปี 2026 เรื่องนี้กลายเป็นเงื่อนไขของ AI เพราะ AI agent ที่ตอบลูกค้าหรือเลือกกลุ่มส่งแคมเปญ จะทำได้ดีไม่เกินคุณภาพข้อมูลที่มันอ่าน

ปรับปรุงล่าสุด ต.ค. 2026

เติมช่องว่างใน prompt อัตโนมัติกรอกข้อมูลธุรกิจครั้งเดียว ใช้ได้ทุก prompt

ประเภทธุรกิจชื่อธุรกิจหรือแบรนด์สินค้าหรือบริการหลักกลุ่มลูกค้าเป้าหมายช่องทางหรือแพลตฟอร์มหลักระบบ CRM หรือเครื่องมือที่ใช้

ข้อมูลเก็บไว้ในเบราว์เซอร์นี้เท่านั้น ไม่ได้ส่งไปที่ใด ช่องว่างที่ตรงกับข้อมูลนี้จะถูกเติมให้ทุก prompt ส่วนช่องอื่นกด "เติมช่องว่าง" ที่ prompt นั้น

Q1ข้อมูลใน CRM ไม่สะอาด เสียหายจริงแค่ไหน ทำไมต้องลงทุนแก้

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

HBR (2017) พบว่ามีแค่ 3% ขององค์กรที่ข้อมูลผ่านเกณฑ์คุณภาพพื้นฐาน ลองทำแบบเดียวกันได้ โดยหยิบเรคคอร์ด 100 รายการที่ทีมกรอกมาตรวจทีละช่อง

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

Prompt ต่อยอด

ช่วยประเมินผลเสียของข้อมูล CRM ที่ไม่สะอาดสำหรับ [ประเภทธุรกิจ] ที่มีลูกค้า [จำนวน] ราย สมมติว่าข้อมูลซ้ำ [x%] และเบอร์ผิด [y%] แยกเป็นตาราง: ค่าส่งข้อความที่เสีย ยอดขายที่พลาด ความเสี่ยงเมื่อใช้ AI และความเสี่ยง PDPA พร้อมสูตรที่ฉันแทนตัวเลขเองได้

Q2ควรวัดคุณภาพข้อมูลด้วยอะไร เริ่มจากมิติไหนก่อน

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

เลือกตามปัญหา:

ส่งข้อความไม่ถึง → วัดความถูกรูปแบบของเบอร์และอีเมล และความครบของช่องทางติดต่อ
รายงานไม่ตรง → วัดอัตราข้อมูลซ้ำ และความตรงกันระหว่าง CRM กับระบบขาย
Automation ยิงผิดเวลา → วัดความสดของตาราง

วัดเป็น % ของเรคคอร์ดที่ผ่านกฎ เช่น "% ลูกค้าที่มีเบอร์ถูกรูปแบบ" แล้วดูแนวโน้มทุกสัปดาห์ แยกตามสาขาหรือช่องทางที่ข้อมูลเข้ามา ตัวเลขก้อนเดียวไม่บอกว่าต้องแก้ตรงไหน

Prompt ต่อยอด

ช่วยออกแบบกฎตรวจคุณภาพข้อมูลสำหรับตารางลูกค้าของ [ประเภทธุรกิจ] ที่มีฟิลด์ [รายการฟิลด์] แบ่งตาม 6 มิติ ระบุกฎ วิธีคิดเป็น % และเกณฑ์เริ่มต้น ตอบเป็นตาราง และบอกว่ากฎไหนควรทำก่อนถ้าปัญหาหลักคือ [ปัญหา]

Q3ลูกค้าซ้ำกันเยอะ จะ merge อย่างไรไม่ให้รวมผิดคน

ใช้สองชั้นเสมอ และรวมผิดคนอันตรายกว่าปล่อยซ้ำ

ชั้นแรก คีย์ตรงกันแน่นอน: เบอร์มือถือที่จัดรูปแบบแล้ว (ตัดขีด เปลี่ยน +66 เป็น 0) อีเมล เลขสมาชิก ชั้นนี้แม่นแต่จับได้น้อย
ชั้นสอง ให้คะแนนความคล้าย: ชื่อ ที่อยู่ วันเกิด แล้วตั้งเกณฑ์ 3 ระดับ คะแนนสูงรวมอัตโนมัติ คะแนนกลางส่งคนตรวจ คะแนนต่ำปล่อยไว้

BlueConic แนะนำให้ใช้คีย์แน่นอนเป็นฐานของโปรไฟล์หลัก และใช้แบบให้คะแนนกับงานเสี่ยงต่ำ เช่น การหากลุ่มเป้าหมายแคมเปญกว้าง ๆ

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

Prompt ต่อยอด

ช่วยเขียนกฎหาลูกค้าซ้ำใน CRM ของ [ประเภทธุรกิจ] แยกเป็น (1) กฎคีย์แน่นอนที่รวมอัตโนมัติ (2) กฎให้คะแนนพร้อมเกณฑ์ รวมเอง/ส่งคนตรวจ/ไม่รวม (3) กรณีห้ามรวม เช่น [ครอบครัวใช้เบอร์เดียวกัน] ตอบเป็นตาราง

Q4Golden Record คืออะไร ถ้าข้อมูลหลายระบบขัดกัน ให้ค่าไหนชนะ

Golden Record คือโปรไฟล์ลูกค้าหนึ่งเดียวที่รวมจากหลายระบบ เช่น POS เว็บ LINE OA และคอลเซ็นเตอร์ โดยมีกฎตัดสินรายฟิลด์

Salesforce Data 360 (ชื่อเดิม Data Cloud) เรียกกฎนี้ว่า Reconciliation Rules มีให้เลือก เช่น

ค่าที่พบบ่อยที่สุด
ค่าล่าสุด (Most Recent)
ลำดับความน่าเชื่อถือของแหล่ง (Source Priority)

ตัวอย่าง: เบอร์มือถือใช้ค่าล่าสุดที่ลูกค้ายืนยันผ่าน OTP ชื่อจริงใช้จากระบบที่ตรวจบัตร ที่อยู่จัดส่งใช้จากคำสั่งซื้อล่าสุด

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

Prompt ต่อยอด

ช่วยกำหนดกฎ Golden Record ของลูกค้า [ประเภทธุรกิจ] ที่มีแหล่งข้อมูล [POS, LINE OA, เว็บ, คอลเซ็นเตอร์] ระบุรายฟิลด์ว่าใช้ค่าบ่อยสุด/ค่าล่าสุด/แหล่งที่เชื่อถือได้กว่า พร้อมเหตุผล และฟิลด์ไหนต้องให้คนตัดสิน ตอบเป็นตาราง

Q5ป้องกันข้อมูลผิดตั้งแต่ต้นทางทำอย่างไร แทนที่จะตามล้างทุกเดือน

แก้ที่จุดกรอกคุ้มที่สุด

บังคับรูปแบบทันที เช่น เบอร์มือถือ 10 หลักขึ้นต้น 0 ใช้ตัวเลือกแทนพิมพ์เอง
ตรวจซ้ำก่อนสร้าง HubSpot บล็อกการสร้าง contact ซ้ำด้วยอีเมล และบริษัทซ้ำด้วยโดเมน ตั้งฟิลด์ห้ามซ้ำเพิ่มได้ 10 ฟิลด์ต่อ object แต่กฎนี้ใช้กับฟอร์มไม่ได้ และบริษัทที่สร้างผ่าน API ไม่ถูกกันซ้ำ จึงต้องตรวจที่ระบบเชื่อมต่อเอง
ลดฟิลด์บังคับ ฟิลด์ที่คนไม่รู้จะกรอกอะไร จะกลายเป็น "-" หรือ "ไม่ทราบ"
ให้ลูกค้ายืนยันเอง ผ่าน OTP หรือ LINE Login ข้อมูลที่เจ้าของยืนยันแม่นกว่าพนักงานพิมพ์ให้

Prompt ต่อยอด

ช่วยออกแบบกฎตรวจฟอร์มสมัครสมาชิกผ่าน [LINE OA/หน้าร้าน/เว็บ] ของ [ประเภทธุรกิจ] ระบุรายฟิลด์: รูปแบบที่รับได้ regex ข้อความเตือนภาษาไทยที่สุภาพ ฟิลด์บังคับหรือไม่ และกฎกันซ้ำ ตอบเป็นตาราง และติดธงฟิลด์ที่อาจเก็บเกินจำเป็นตาม PDPA

Q6ข้อมูลจาก LINE OA, Shopee, TikTok Shop และไลฟ์ ทำให้ข้อมูลซ้ำและไม่ครบ ควรจัดการอย่างไร

เก็บรหัสของแต่ละแพลตฟอร์มแยกไว้ อย่ารีบรวม และอย่าสร้างโปรไฟล์ปลอม

LINE OA: LINE UID ของคนเดียวกันจะต่างกันถ้าอยู่คนละ Provider และถ้าลูกค้าไม่ยินยอมให้เข้าถึงโปรไฟล์ webhook จะไม่มี UID จึงต้องเก็บ UID คู่กับรหัส Provider เสมอ
Shopee: ปิดชื่อและเบอร์ผู้ซื้อ เหลือแค่ที่อยู่ส่งของ อย่าเดาจับคู่จากที่อยู่ ให้ลูกค้าเชื่อมเองผ่าน QR หรือลงทะเบียนรับประกัน
ไลฟ์และแชต: ชื่อบัญชีในคอมเมนต์ไม่ใช่ตัวตนจริง เก็บเป็นข้อมูลประกอบ ไม่ใช่คีย์จับคู่
ประวัติแชต: LINE OA แพ็กเกจพื้นฐานเก็บแชต 6 เดือน ถ้าต้องใช้ย้อนหลังต้อง export หรือใช้แพ็กเกจที่เก็บนานขึ้น

ตั้งกฎว่ารหัสไหนเป็นคีย์ รหัสไหนเป็นแค่ข้อมูลประกอบ

Prompt ต่อยอด

ฉันมีข้อมูลลูกค้าจาก [LINE OA (หลาย Provider?), Shopee, TikTok Shop, ไลฟ์, หน้าร้าน] ช่วยทำตาราง: รหัสแต่ละแพลตฟอร์ม ใช้เป็นคีย์จับคู่ได้หรือไม่ ข้อจำกัด วิธีให้ลูกค้าเชื่อมบัญชีเองอย่างถูก PDPA และกฎคุณภาพที่ต้องตรวจ ติดธงจุดที่อาจขัดเงื่อนไขแพลตฟอร์ม

Q7Data Steward ควรเป็นใคร ทีมเล็กจำเป็นต้องมีไหม

จำเป็น แต่ไม่ต้องเป็นตำแหน่งเต็มเวลา Steward คือคนฝั่งธุรกิจที่เป็นเจ้าของข้อมูลชุดหนึ่ง เช่น หัวหน้า CRM ดูแลข้อมูลลูกค้า หัวหน้าขายดูแลข้อมูล Lead

หน้าที่หลัก:

นิยามฟิลด์ให้ตรงกัน เช่น "ลูกค้า active" หมายถึงอะไร
ตัดสินกรณี merge ที่ระบบไม่มั่นใจ
อนุมัติการเปลี่ยนฟิลด์หรือตัวเลือก
ดู KPI คุณภาพข้อมูลทุกสัปดาห์
อนุมัติว่า AI agent ใช้ข้อมูลชุดไหนได้

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

Prompt ต่อยอด

ช่วยร่าง RACI ด้าน Data Governance ของ CRM ใน [ประเภทธุรกิจ] ทีม [จำนวนคน] ครอบคลุมบทบาท Data Owner, Data Steward, Data Engineer, CRM Admin, DPO สำหรับงาน: นิยามฟิลด์ อนุมัติ merge เปลี่ยนโครงสร้าง ตอบคำขอแก้ข้อมูล อนุมัติข้อมูลให้ AI agent ใช้ ตอบเป็นตาราง

Q8Data Contract คืออะไร ต่างจาก data dictionary อย่างไร

Data dictionary คือเอกสารให้คนอ่าน ส่วน Data Contract คือข้อตกลงที่เครื่องตรวจได้ ระหว่างระบบที่ส่งข้อมูล (เช่น POS หรือแอป) กับทีมที่ใช้ข้อมูล (ทีม CRM หรือทีมข้อมูล)

มาตรฐานเปิด ODCS (เวอร์ชันล่าสุดที่เอกสารอ้างคือ v3.1.0) มีหมวด เช่น

โครงสร้างข้อมูล (schema)
กฎคุณภาพ
SLA เช่น ความสดและระยะเวลาเก็บ
ทีม บทบาท และช่องทางติดต่อ

ประโยชน์กับ CRM: ถ้าต้นทางเปลี่ยนชื่อฟิลด์หรือเพิ่มสถานะใหม่ ระบบจะจับได้ก่อนข้อมูลไหลเข้า CRM ไม่ต้องมารู้ตอนแคมเปญส่งผิด เริ่มจาก 1–2 ตารางสำคัญ เช่น ข้อมูลลูกค้าและรายการขาย

Prompt ต่อยอด

ช่วยร่าง Data Contract ตามโครงสร้าง ODCS สำหรับตาราง [ชื่อตาราง] ที่ส่งมาจาก [ระบบต้นทาง] และใช้โดย [ทีม] ฟิลด์ [รายการ] ความสดที่ต้องการ [เช่น ทุก 15 นาที] กฎคุณภาพอย่างน้อย 5 ข้อ ระบุฟิลด์ที่เป็นข้อมูลส่วนบุคคล ตอบเป็น YAML พร้อมคำอธิบายภาษาไทย

Q9AI ช่วยเรื่องคุณภาพข้อมูลได้ตรงไหน และตรงไหนไม่ควรให้ AI ตัดสินเอง

ให้ AI เสนอ แต่ให้ระบบหรือคนยืนยัน

AI ช่วยได้ดี:

จัดรูปแบบ: แยกที่อยู่ภาษาไทยเป็น แขวง เขต รหัสไปรษณีย์ แยกคำนำหน้า ชื่อ นามสกุล
หาตัวซ้ำที่สะกดต่างกัน: เช่น "บจก.เอบีซี" กับ "ABC Co., Ltd."
หาข้อมูลอ่อนไหว: Data Classification ของ Databricks ใช้ AI ติดแท็กคอลัมน์ชื่อ เบอร์ อีเมล อัตโนมัติ แต่ยังไม่มีแท็กเลขบัตรประชาชนไทย ต้องเขียนกฎเอง
สรุปปัญหา: อ่านรายงาน monitoring แล้วจัดลำดับว่าควรแก้อะไรก่อน

ไม่ควรให้ AI:

รวมโปรไฟล์อัตโนมัติ โดยไม่มีเกณฑ์และคนตรวจกรณีก้ำกึ่ง
รับข้อมูลส่วนบุคคลดิบ ในเครื่องมือภายนอกที่องค์กรไม่ได้คุม

เก็บ log ทุกครั้งที่ AI เสนอและคนอนุมัติ

Prompt ต่อยอด

แนบรายชื่อลูกค้าหรือบริษัท [20–50 รายการ ที่ปิดเบอร์และอีเมลแล้ว] ช่วยจัดกลุ่มรายการที่น่าจะเป็นรายเดียวกัน ตอบเป็นตาราง: กลุ่ม, รายการที่รวม, ค่ามาตรฐานที่แนะนำ, ความมั่นใจ (สูง/กลาง/ต่ำ), เหตุผล และระบุกรณีที่ต้องให้คนตรวจก่อนรวม

Q10จะให้ AI agent ใช้ข้อมูล CRM ตอบลูกค้าหรือเลือกกลุ่มส่งแคมเปญ ต้องเตรียมข้อมูลแค่ไหน

ต้องเตรียมมากกว่าที่คิด Gartner คาดว่าจนถึงปี 2026 องค์กรจะล้มเลิกโครงการ AI ราว 60% ที่ข้อมูลไม่พร้อม ผู้ขาย CRM เองก็เร่งซื้อหรือสร้างชั้นข้อมูล เช่น Salesforce ซื้อ Informatica สำเร็จ พ.ย. 2025 และ HubSpot มี Data Hub ที่ใช้ AI ช่วยล้างข้อมูล

เช็กลิสต์ก่อนต่อ AI agent:

ข้อมูลที่ agent อ่าน ผ่านกฎคุณภาพและสดตาม SLA
มีสถานะ consent ล่าสุด และ agent ต้องเช็กก่อนส่งข้อความ
นิยามกลาง เช่น ระดับสมาชิก ยอดสะสม เขียนไว้ที่เดียว
สิทธิ์จำกัด agent เห็นเฉพาะฟิลด์ที่จำเป็น
ชุดทดสอบ คำถามจริงพร้อมคำตอบที่ถูก
log การกระทำ ว่า agent อ่านอะไรและทำอะไร

Prompt ต่อยอด

ช่วยทำเช็กลิสต์ความพร้อมของข้อมูลก่อนให้ AI agent [ตอบแชต LINE OA/เลือกกลุ่มส่งแคมเปญ] ของ [ธุรกิจ] ใช้ตาราง [รายการตาราง] ตอบเป็นตาราง: หัวข้อ, เกณฑ์ผ่าน, วิธีตรวจ, เจ้าของ และระบุความเสี่ยงถ้าไม่ผ่าน รวมถึงความเสี่ยง PDPA

Q11ทีมข้อมูลใช้ Databricks อยู่แล้ว จะเฝ้าคุณภาพข้อมูล CRM อย่างไร

ใช้ 3 กลไกที่มีอยู่แล้ว

Expectations ใน Lakeflow Spark Declarative Pipelines (ชื่อเดิม DLT) ตรวจทีละแถวตอนข้อมูลเข้า เช่น customer_id ห้ามว่าง เลือกได้ว่าจะเตือน ทิ้งแถว หรือหยุด pipeline
Data quality monitoring (ชื่อเดิม Lakehouse Monitoring) มี anomaly detection ที่เฝ้าทั้ง schema ว่าตารางมาช้าหรือแถวน้อยผิดปกติ และ data profiling ที่ดูค่าว่าง การกระจาย และ drift รันบน serverless คิดค่าใช้จ่ายแยก
Data Classification + ABAC ติดแท็กคอลัมน์ข้อมูลส่วนบุคคลอัตโนมัติ แล้วผูกนโยบาย mask ตามแท็ก

สิ่งที่ควรเพิ่มเอง: เมตริก duplicate rate และ % consent ถูกต้อง แล้วตั้ง alert ส่งถึง Steward

Prompt ต่อยอด

คุณเป็น Databricks engineer ช่วยออกแบบการเฝ้าคุณภาพข้อมูลสำหรับตาราง [catalog.schema.table] ที่ส่งเข้า CRM [ชื่อระบบ] ระบุ (1) expectations 8 ข้อ พร้อม action warn/drop/fail (2) การตั้ง anomaly detection และ data profiling (3) custom metric เช่น duplicate rate (4) alert และผู้รับ ตอบเป็นตารางพร้อมตัวอย่าง SQL สั้น ๆ

Q12PDPA เกี่ยวกับคุณภาพข้อมูลตรงไหน นอกจากเรื่องขอ consent

PDPA ให้ลูกค้าขอให้ข้อมูลของตน ถูกต้อง เป็นปัจจุบัน สมบูรณ์ และไม่ทำให้เข้าใจผิด องค์กรจึงต้องแก้ได้ครบทุกระบบ ไม่ใช่แก้แค่ใน CRM

ปี 2025 สคส. เริ่มปรับจริง และปรับทั้งเจ้าของข้อมูลและผู้รับจ้างประมวลผล เช่น บริษัทที่ทำระบบจองให้ ส่วนร่างแนวปฏิบัติด้านการตลาด (ก.ค. 2026 ยังเป็นร่าง) ขอให้

แยก consent การตลาดออกจากเงื่อนไขบริการ
ไม่ใช้ช่องติ๊กไว้ก่อน
ระวังข้อมูลที่ได้จากพาร์ตเนอร์หรือ data broker และตรวจสอบที่มา

สิ่งที่ทีม CRM ควรมี: consent แยกตามวัตถุประสงค์และช่องทางพร้อมเวลา, นโยบายลบหรือทำให้ระบุตัวไม่ได้เมื่อหมดความจำเป็น, log ว่าใครแก้อะไรเมื่อไร และสัญญากับ vendor ที่ประมวลผลแทน

Prompt ต่อยอด

ช่วยออกแบบขั้นตอนรับคำขอแก้ไขข้อมูลตาม PDPA สำหรับ [ประเภทธุรกิจ] ที่มีระบบ [CRM, คลังข้อมูล, ระบบส่ง SMS, LINE OA] ระบุ ช่องทางรับคำขอ การยืนยันตัวตน การแก้ให้ครบทุกระบบ SLA ภายใน log และข้อความตอบลูกค้าภาษาไทย ตอบเป็นขั้นตอนเลขข้อ

Q13ล้างข้อมูลครั้งใหญ่ไปแล้ว ผ่านไป 6 เดือนกลับมาสกปรกเหมือนเดิม แก้อย่างไร

เพราะแก้แค่อาการ ไม่ได้แก้ต้นเหตุ ต้องเปลี่ยนจากโปรเจกต์ครั้งเดียวเป็นงานประจำ

หาต้นเหตุทุกครั้ง ฟอร์มไหน ระบบไหน สาขาไหนสร้างข้อมูลเสีย แล้วแก้ที่นั่น
มี Dashboard คุณภาพข้อมูล แยกตามแหล่งที่ข้อมูลเข้า Steward ดูทุกสัปดาห์
ผูก KPI กับทีมที่กรอก เช่น % เบอร์ถูกต้องของแต่ละสาขา
ให้ลูกค้าอัปเดตเอง เช่น ให้แต้มเมื่อยืนยันเบอร์ใน LINE OA
ใช้ Data Contract กับทุกระบบที่เชื่อมเข้า CRM

ปัญหาจะไม่หายหมด แต่จะไม่สะสมจนต้องล้างใหญ่อีก

Prompt ต่อยอด

ช่วยหาต้นเหตุที่ข้อมูล CRM กลับมาเสียซ้ำ จากข้อมูลนี้: ข้อผิดพลาดที่พบบ่อย [รายการ] ช่องทางที่ข้อมูลเข้า [รายการ] ทีมที่กรอก [รายการ] จัดกลุ่มสาเหตุเป็น คน/ขั้นตอน/ระบบ เสนอวิธีป้องกันที่ต้นทาง และ KPI ที่พิสูจน์ผลใน 90 วัน ตอบเป็นตาราง

AI
ผู้ขาย CRM เร่งซื้อชั้นข้อมูล เพราะ AI agent ต้องใช้ข้อมูลสะอาด
Salesforce ซื้อ Informatica สำเร็จเมื่อ 18 พ.ย. 2025 เพื่อเสริม Data 360 และ Agentforce ส่วน HubSpot มี Data Hub ที่ใช้ AI ช่วยล้างและจัดรูปแบบข้อมูล ทีม CRM ควรวัดคุณภาพข้อมูลที่ agent จะอ่านก่อนเปิดใช้ ไม่ใช่หลังจาก agent ตอบผิด
ที่มา: salesforce.com,hubspot.com
ข้อมูล & ระบบ
ข้อมูลไม่พร้อม โครงการ AI มักถูกล้มเลิก
Gartner คาดว่าจนถึงปี 2026 องค์กรจะล้มเลิกโครงการ AI ราว 60% ที่ข้อมูลไม่พร้อม และ 63% ขององค์กรไม่มั่นใจในการจัดการข้อมูลสำหรับ AI (สำรวจ ก.ค. 2024) ทีมควรมีเช็กลิสต์ AI-ready data ก่อนต่อ AI agent
ที่มา: freevacy.com
ข้อมูล & ระบบ
Databricks ใช้ AI ติดแท็กข้อมูลส่วนบุคคลและเฝ้าคุณภาพทั้ง schema
เอกสาร ก.ย. 2026 ระบุว่า Data Classification ใช้ AI ติดแท็กคอลัมน์ชื่อ เบอร์ อีเมล แล้วผูกนโยบาย mask แบบ ABAC ได้ แต่ยังไม่มีแท็กเลขบัตรประชาชนไทย ส่วน Data quality monitoring (เดิม Lakehouse Monitoring) มี anomaly detection ที่เฝ้าทุกตารางใน schema ทีมควรเปิดใช้และเขียนกฎเพิ่มสำหรับข้อมูลไทย
ที่มา: learn.microsoft.com,learn.microsoft.com
กฎหมาย & ความเป็นส่วนตัว
สคส. ปรับจริง รวมถึงบริษัทที่รับทำระบบ
1 ส.ค. 2025 สคส. ประกาศปรับ 8 คำสั่งใน 5 คดี รวมราว 14.5 ล้านบาท บางคดีปรับผู้รับจ้างประมวลผลมากกว่าเจ้าของข้อมูล ร่างแนวปฏิบัติด้านการตลาด (7 ก.ค. 2026) ยังขอให้ตรวจที่มาของข้อมูลจากพาร์ตเนอร์และ data broker ทีมควรตรวจ vendor และบันทึกที่มาของทุกชุดข้อมูล
ที่มา: nagashima.com,legal500.com
แชท & ข้อความ
LINE OA เป็นแหล่งข้อมูลลูกค้าหลัก แต่ UID มีเงื่อนไข
LINE OA มีบทสนทนากว่า 12,000 ล้านครั้งในปี 2025 และกำลังเพิ่ม Customer Data Agent (ข้อมูลผู้ขาย) แต่ LINE UID ของคนเดียวกันต่างกันตาม Provider และแพ็กเกจพื้นฐานเก็บแชตแค่ 6 เดือน ทีมควรเก็บ UID คู่กับ Provider และวางแผนเก็บประวัติแชตที่ต้องใช้
ที่มา: developers.line.biz,marketingoops.com
Marketplace
ข้อมูลผู้ซื้อมาร์เก็ตเพลสถูกปิด อย่าเดาตัวตน
Shopee ปิดชื่อและเบอร์ผู้ซื้อในคำสั่งซื้อและ Open API เหลือแค่ที่อยู่ส่งของ การเดาจับคู่จากที่อยู่เสี่ยงรวมผิดคนและขัด PDPA ทีมควรเก็บเลขคำสั่งซื้อเป็นข้อมูลประกอบ และให้ลูกค้าเชื่อมบัญชีเองผ่าน QR หรือ LINE OA
ที่มา: shopee-channel.helpscoutdocs.com

เลือก 1–2 ตารางที่เจ็บที่สุด (มักเป็นข้อมูลลูกค้าและช่องทางติดต่อ) แล้ววัดค่าเริ่มต้นของข้อมูลซ้ำ ความครบ และความถูกรูปแบบก่อนแก้
ตั้ง Data Steward ฝั่งธุรกิจ 1 คนต่อตาราง และเขียนนิยามฟิลด์ไว้ที่เดียวให้ทุกทีมใช้
ปิดรูรั่วที่ต้นทาง: ตรวจรูปแบบและตรวจซ้ำที่ฟอร์ม ลดฟิลด์บังคับ และจัดรูปแบบเบอร์กับอีเมลก่อนบันทึก
ทำ Identity Resolution สองชั้น สร้าง Golden Record พร้อมกฎรายฟิลด์ และเก็บรหัสแพลตฟอร์ม (LINE UID + Provider, เลขคำสั่งซื้อมาร์เก็ตเพลส) แยกไว้
เขียน Data Contract ให้ทุกระบบที่ส่งข้อมูลเข้า CRM และให้ pipeline ตรวจทุกครั้งที่ deploy
เปิดการเฝ้าคุณภาพต่อเนื่อง ติดแท็กข้อมูลส่วนบุคคลและ mask อัตโนมัติ แล้วส่ง alert ถึง Steward
ก่อนต่อ AI agent ให้ผ่านเช็กลิสต์ AI-ready: ข้อมูลสด consent ล่าสุด นิยามกลาง สิทธิ์จำกัด ชุดทดสอบ และ log

ข้อผิดพลาดที่พบบ่อย

ล้างข้อมูลครั้งใหญ่ครั้งเดียวแล้วคิดว่าจบทำเป็นงานประจำ: ตรวจที่ต้นทาง เฝ้าต่อเนื่อง ทบทวนทุกสัปดาห์ และผูก KPI กับทีมที่กรอก
รวมโปรไฟล์อัตโนมัติด้วยการให้คะแนนความคล้าย โดยไม่มีเกณฑ์และคนตรวจใช้คีย์แน่นอนเป็นฐาน ตั้งเกณฑ์ 3 ระดับ เก็บ log และออกแบบให้แยกกลับได้
ใช้ LINE UID เป็นคีย์โดยไม่เก็บว่ามาจาก Provider ไหน พอมีหลายแบรนด์ ลูกค้าคนเดียวกลายเป็นหลายคนเก็บ LINE UID คู่กับรหัส Provider และใช้เบอร์ที่ยืนยันแล้วหรือเลขสมาชิกเป็นตัวเชื่อม
ตั้งฟิลด์บังคับเยอะ จนพนักงานกรอกค่าหลอกให้ผ่านฟอร์มบังคับเฉพาะฟิลด์ที่ใช้จริง ที่เหลือค่อยเก็บทีหลัง และนับค่าหลอกเป็นค่าว่างใน KPI
แก้ข้อมูลใน CRM แต่คลังข้อมูล ระบบส่ง SMS และ AI agent ยังใช้ค่าเก่ากำหนดระบบหลักต่อฟิลด์ และให้การแก้ไหลจากจุดเดียวไปทุกระบบผ่าน pipeline
ส่งไฟล์ลูกค้าดิบให้ AI ภายนอกช่วยล้างข้อมูลปิดชื่อและเบอร์ก่อน หรือใช้ AI ในแพลตฟอร์มที่องค์กรคุมสิทธิ์ได้ และมีสัญญาประมวลผลข้อมูลกับผู้ให้บริการ

Duplicate Rate
สูตร
จำนวนเรคคอร์ดที่ถูกระบุว่าซ้ำ ÷ เรคคอร์ดทั้งหมด × 100 (นับหลังจัดรูปแบบเบอร์และอีเมลแล้ว)
ค่าอ้างอิง
ขึ้นกับอุตสาหกรรมและวิธีนับ; ตั้งเป้าให้ลดลงต่อเนื่องจาก baseline ของตัวเอง
ทำไมต้องดู
บอกว่ารายงานนับลูกค้าเกินจริงแค่ไหน และแคมเปญส่งซ้ำไปกี่คน
Completeness Rate (รายฟิลด์)
สูตร
เรคคอร์ดที่ฟิลด์สำคัญมีค่าจริง (ไม่นับ "-" หรือ "ไม่ทราบ") ÷ เรคคอร์ดทั้งหมด × 100
ค่าอ้างอิง
ขึ้นกับฟิลด์; วัดเฉพาะฟิลด์ที่ใช้ตัดสินใจจริง เช่น ช่องทางติดต่อ consent
ทำไมต้องดู
ฟิลด์ว่างคือลูกค้าที่แบ่งกลุ่มและติดต่อไม่ได้
Contactability Rate
สูตร
เบอร์ อีเมล หรือ LINE UID ที่ส่งถึงจริง ÷ จำนวนที่พยายามส่ง × 100
ค่าอ้างอิง
ขึ้นกับช่องทาง; ใช้ผลแคมเปญล่าสุดเป็น baseline
ทำไมต้องดู
แปลงเป็นเงินได้ตรงที่สุด ข้อความที่ส่งไม่ถึงคือต้นทุนที่เสียเปล่า
Data Freshness
สูตร
เวลาปัจจุบัน − เวลาที่ตารางอัปเดตล่าสุด เทียบกับ SLA ที่ตกลง
ค่าอ้างอิง
ตาม SLA ภายใน เช่น ยอดขายไม่เกิน 15 นาที ข้อมูลลูกค้าไม่เกิน 1 วัน
ทำไมต้องดู
ข้อมูลช้าทำให้ Automation และ AI agent ทำงานผิดจังหวะ
Consent Sync Lag
สูตร
เวลาตั้งแต่ลูกค้าถอนความยินยอม จนถึงทุกระบบที่ส่งข้อความรับรู้ (เฉลี่ยและสูงสุด)
ค่าอ้างอิง
ตั้งเป้าภายใน; ยิ่งใกล้ศูนย์ยิ่งดี
ทำไมต้องดู
ถ้าช้า ระบบหรือ AI จะส่งข้อความหาคนที่ขอเลิกรับแล้ว ซึ่งเสี่ยง PDPA
Issue Resolution Time
สูตร
เวลาเฉลี่ยจากพบข้อมูลผิดหรือรับคำขอแก้ไข จนแก้เสร็จครบทุกระบบ
ค่าอ้างอิง
ขึ้นกับองค์กร; ตั้ง SLA ภายใน
ทำไมต้องดู
วัดว่า Steward และขั้นตอนแก้ไขทำงานจริง ไม่ใช่มีแค่ Dashboard

เติมช่องว่างใน prompt อัตโนมัติกรอกข้อมูลธุรกิจครั้งเดียว ใช้ได้ทุก prompt

แผนประเมินคุณภาพข้อมูล 30 วัน

ใช้เมื่อ ใช้เมื่อเริ่มโครงการคุณภาพข้อมูลจากศูนย์และต้องเสนอผู้บริหาร

คุณคือที่ปรึกษาด้าน Data Governance
บริบท: บริษัท [ประเภทธุรกิจ] ใช้ CRM [ชื่อระบบ] ลูกค้า [จำนวน] ราย ข้อมูลเข้าจาก [หน้าร้าน, LINE OA, เว็บ, Shopee, TikTok Shop, คอลเซ็นเตอร์] อาการที่พบ: [เช่น ลูกค้าซ้ำ เบอร์ผิด รายงานไม่ตรง]
งาน: วางแผน 30 วัน (1) ตารางและฟิลด์ที่ต้องประเมินก่อน (2) กฎตรวจตาม 6 มิติ อย่างน้อย 15 ข้อ (3) วิธีวัดค่าเริ่มต้นและหน้าตา Dashboard (4) ผู้รับผิดชอบ (5) ความเสี่ยงและวิธีลด
ข้อจำกัด: เฟสแรกห้ามซื้อเครื่องมือใหม่ ใช้ของที่มี [รายการเครื่องมือ]
รูปแบบผลลัพธ์: ตารางแผนรายสัปดาห์ ตารางกฎ และสรุป 5 บรรทัดสำหรับผู้บริหาร

คู่มือกฎ Identity Resolution ข้ามแพลตฟอร์ม

ใช้เมื่อ ใช้เมื่อต้องรวมโปรไฟล์จากหน้าร้าน LINE OA มาร์เก็ตเพลส และไลฟ์

คุณคือ MDM/CDP Architect ที่เคยวางระบบให้ค้าปลีกไทย
บริบท: แหล่งข้อมูล [ระบบและคีย์ เช่น POS=เบอร์, LINE OA=UID (Provider [จำนวน]), เว็บ=อีเมล, Shopee=เลขคำสั่งซื้อ] ปริมาณ [จำนวน] ราย ผลเสียถ้ารวมผิด: [เช่น แต้มไปผิดคน]
งาน: (1) วิธีจัดรูปแบบคีย์ (เบอร์ไทย อีเมล ชื่อไทย/อังกฤษ) (2) กฎคีย์แน่นอนที่รวมเอง (3) กฎให้คะแนนพร้อมเกณฑ์ 3 ระดับ (4) กฎ Golden Record รายฟิลด์ (5) รหัสที่เก็บเป็นข้อมูลประกอบเท่านั้น (6) log และวิธีแยกกลับ (7) กรณีห้ามรวม
ข้อจำกัด: ห้ามเดาตัวตนผู้ซื้อมาร์เก็ตเพลสจากที่อยู่ ทุกการเชื่อมบัญชีต้องมาจากลูกค้ายินยอม
รูปแบบผลลัพธ์: ตารางกฎ pseudo-code สั้น ๆ และคำถามที่ต้องให้ Steward ตัดสิน

สร้าง Data Contract

ใช้เมื่อ ใช้เมื่อต้องเขียน Data Contract ให้ระบบที่ส่งข้อมูลเข้า CRM หรือคลังข้อมูล

คุณคือ Data Platform Engineer ที่รู้มาตรฐาน ODCS
บริบท: ตาราง [ชื่อตาราง] ส่งมาจาก [ระบบ/ทีมต้นทาง] ใช้โดย [ทีม] เพื่อ [เช่น ส่งแคมเปญ ให้ AI agent ตอบแชต] ฟิลด์ [รายการพร้อมชนิดข้อมูล] อัปเดต [ความถี่] เก็บย้อนหลัง [ระยะเวลา]
งาน: เขียน Data Contract เป็น YAML ตามโครงสร้าง ODCS ครอบคลุม fundamentals, schema (ชนิดข้อมูล ฟิลด์บังคับ PII flag), quality อย่างน้อย 6 กฎ, SLA (ความสด ระยะเก็บ), team/roles และช่องทางติดต่อ
ข้อจำกัด: ระบุฟิลด์ข้อมูลส่วนบุคคลตาม PDPA ระดับสิทธิ์ และฟิลด์ที่ AI agent ห้ามเห็น
รูปแบบผลลัพธ์: YAML 1 ไฟล์ และคำอธิบายภาษาไทยว่ากฎแต่ละข้อกันปัญหาอะไร

ออกแบบการเฝ้าคุณภาพข้อมูลบน Databricks

ใช้เมื่อ ใช้เมื่อทีมข้อมูลต้องตั้ง expectations, monitoring และ masking ให้ตารางที่ส่งเข้า CRM

คุณคือ Databricks Solutions Architect
บริบท: Azure Databricks + Unity Catalog ตาราง [catalog.schema.table] ส่งเข้า CRM [ชื่อระบบ] ผ่าน [วิธี sync] ปัญหาเดิม [เช่น ข้อมูลไม่สด แถวหาย เบอร์ผิดรูปแบบ]
งาน: (1) expectations ใน Lakeflow Spark Declarative Pipelines อย่างน้อย 8 ข้อ พร้อม warn/drop/fail (2) ตั้ง anomaly detection ระดับ schema และ data profiling พร้อม custom metric เช่น duplicate rate, % consent ถูกต้อง (3) Data Classification และนโยบาย ABAC mask สำหรับชื่อ เบอร์ อีเมล และกฎเพิ่มเองสำหรับเลขบัตรประชาชนไทย 13 หลัก (4) ตาราง quarantine และขั้นตอนแก้ (5) alert และผู้รับ (6) วิธีดูค่าใช้จ่ายจาก system.billing.usage
ข้อจำกัด: ถ้าไม่แน่ใจว่าฟีเจอร์ใดยัง Beta ให้บอกว่าต้องตรวจเอกสารล่าสุด
รูปแบบผลลัพธ์: ตาราง และโค้ด SQL/Python สั้น ๆ ต่อข้อ

เช็กความพร้อมข้อมูลก่อนเปิด AI agent

ใช้เมื่อ ใช้ก่อนให้ AI agent ตอบแชตลูกค้า หรือเลือกกลุ่มส่งข้อความเอง

คุณคือ Data Governance Lead ที่ดูแลทั้งคุณภาพข้อมูลและ PDPA
บริบท: [ธุรกิจ] จะใช้ AI agent [เช่น ตอบแชต LINE OA, ส่งข้อเสนอให้ลูกค้า At risk] agent จะอ่าน [รายการตาราง/ฟิลด์] และทำ [การกระทำที่อนุญาต]
งาน: (1) ประเมินคุณภาพข้อมูลแต่ละฟิลด์ที่ agent ใช้ (ครบ สด ถูก) (2) ระบุฟิลด์ที่ agent ไม่ควรเห็น (3) กฎเช็ก consent ก่อนส่งข้อความ (4) ชุดทดสอบ 20 กรณี รวมกรณีข้อมูลขาดหรือขัดกัน (5) log ที่ต้องเก็บ และเกณฑ์ให้คนรับช่วงต่อ (6) เกณฑ์ผ่านก่อนเปิดใช้จริง
ข้อจำกัด: agent ต้องไม่ทำสิ่งที่ย้อนกลับไม่ได้โดยไม่มีคนอนุมัติ
รูปแบบผลลัพธ์: ตารางเช็กลิสต์ (หัวข้อ, เกณฑ์, วิธีตรวจ, เจ้าของ, สถานะ) และสรุปความเสี่ยง 5 ข้อ

รายงานคุณภาพข้อมูลรายเดือน

ใช้เมื่อ ใช้เมื่อ Steward ต้องสรุปผลให้ผู้บริหารและทีมปฏิบัติการ

คุณคือ Data Steward ที่ต้องรายงานผู้บริหาร
บริบท: ตัวเลขเดือนนี้เทียบเดือนก่อน: ข้อมูลซ้ำ [x% → y%], ความครบของเบอร์ [x% → y%], ส่งไม่ถึง [x% → y%], Consent Sync Lag [ชั่วโมง], คำขอแก้ไขจากลูกค้า [n] เวลาแก้เฉลี่ย [วัน] แหล่งที่แย่สุด [ช่องทาง/สาขา] สิ่งที่ทำไปแล้ว [รายการ]
งาน: เขียนรายงาน 1 หน้า (1) สรุป 3 บรรทัดว่าดีขึ้นหรือแย่ลงเพราะอะไร (2) ตาราง KPI พร้อมทิศทาง (3) ผลต่อธุรกิจ เช่น ข้อความที่ส่งถึงเพิ่มขึ้นกี่รายการ (4) 3 งานเดือนหน้าพร้อมเจ้าของ (5) เรื่องที่ต้องให้ผู้บริหารตัดสิน
รูปแบบผลลัพธ์: ภาษาไทยกระชับ ไม่ใช้ศัพท์เทคนิคเกินจำเป็น

หมายเลข 20.1–20.20 ตาม 500 CRM Prompts Book เติม [ช่องว่าง] ก่อนส่ง

เติมช่องว่างใน prompt อัตโนมัติกรอกข้อมูลธุรกิจครั้งเดียว ใช้ได้ทุก prompt

20.1
วางแผนการตรวจสอบความถูกต้องของข้อมูลลูกค้าใน [CRM System]
20.2
สร้าง Workflow การแก้ไขข้อมูลผิดพลาด เช่น [Data Correction Process]
20.3
ออกแบบแบบฟอร์มเก็บข้อมูลที่ถูกต้องตาม [มาตรฐาน เช่น PDPA]
20.4
แนะนำวิธีใช้ AI เพื่อ Clean ข้อมูล เช่น [Duplicate Detection, Error Checking]
20.5
สรุป KPI สำหรับวัดผล Data Quality เช่น [Data Accuracy %, Duplicate Rate]
20.6
วิเคราะห์ Pain Point ที่ทำให้ข้อมูลลูกค้าผิดพลาด เช่น [Human Error, Lack of Validation]
20.7
สร้าง Flow การแจ้งเตือนทีมงานเมื่อพบข้อมูลผิดพลาด
20.8
วางแผนการอบรมทีมงานเรื่อง Data Governance
20.9
ออกแบบกิจกรรมส่งเสริมการเก็บข้อมูลที่ถูกต้อง เช่น [Data Hygiene Week]
20.10
สรุปข้อดีข้อเสียของแต่ละวิธีตรวจสอบข้อมูล เช่น [Manual Audit vs Automated Audit]
20.11
แนะนำวิธีใช้ CRM เพื่อจัดการ Data Quality อย่างมีประสิทธิภาพ
20.12
สร้าง Script โทรศัพท์สอบถามข้อมูลที่ผิดพลาดจากลูกค้า
20.13
ออกแบบโปรโมชั่นสำหรับลูกค้าที่ช่วยอัปเดตข้อมูลให้ถูกต้อง
20.14
วิเคราะห์ผลกระทบของข้อมูลผิดพลาดต่อการทำการตลาด/การขาย
20.15
วางแผนการใช้ Data Analytics เพื่อปรับปรุง Data Quality
20.16
สรุป Pain Point ของทีม Data Steward และแนวทางการสนับสนุน
20.17
แนะนำวิธีติดตามผลลัพธ์การปรับปรุง Data Quality แบบรายเดือน
20.18
สร้าง Survey สำหรับทีมงานที่รับผิดชอบข้อมูล
20.19
วางแผนการใช้ Omnichannel กับการเก็บข้อมูลที่ถูกต้อง
20.20
วิเคราะห์ผลกระทบของ Data Quality ต่อ KPI หลักของธุรกิจ

ข้อมูลที่ผิดพลาดนำไปสู่การตัดสินใจที่ผิดพลาด หมวดหมู่นี้เน้นการสร้างกระบวนการตรวจสอบคุณภาพข้อมูล (Data Quality) และการกำกับดูแลข้อมูล (Data Governance) เพื่อให้ทุกการตัดสินใจขับเคลื่อนด้วยข้อมูลที่ถูกต้อง

ประโยชน์ที่ได้

เพิ่มความแม่นยำในการทำการตลาดและการขาย
ลดความเสี่ยงทางกฎหมายที่เกี่ยวข้องกับข้อมูล
วางรากฐานการทำงานของ CRM และ Automation ได้อย่างมีประสิทธิภาพ

ศัพท์ที่ต้องรู้

Data Quality Dimensions: มิติที่ใช้วัดคุณภาพข้อมูล ชุดที่ใช้บ่อยมี 6 ข้อ คือ ถูกต้อง (Accuracy), ครบ (Completeness), ตรงกันทุกระบบ (Consistency), ทันเวลา (Timeliness), ไม่ซ้ำ (Uniqueness) และถูกรูปแบบ (Validity)
Deduplication / Identity Resolution: การหาว่าเรคคอร์ดหลายอันเป็นลูกค้าคนเดียวกัน แล้วรวมเป็นโปรไฟล์เดียว ทำได้ทั้งแบบคีย์ตรงกันแน่นอน (Deterministic) และแบบให้คะแนนความคล้าย (Probabilistic/Fuzzy)
Golden Record: โปรไฟล์ลูกค้าฉบับที่เชื่อถือได้ที่สุด รวมค่าจากหลายระบบด้วยกฎตัดสินว่าค่าไหนชนะ และยังย้อนกลับไปดูต้นทางได้
Data Steward: คนฝั่งธุรกิจที่รับผิดชอบความหมายและคุณภาพของข้อมูลชุดหนึ่ง เช่น หัวหน้า CRM ดูแลข้อมูลลูกค้า ตัดสินกรณีก้ำกึ่ง และติดตาม KPI คุณภาพข้อมูล
Data Contract: ข้อตกลงที่เครื่องอ่านได้ (เช่น YAML ตามมาตรฐาน ODCS) ระหว่างระบบที่ส่งข้อมูลกับทีมที่ใช้ข้อมูล ระบุโครงสร้าง กฎคุณภาพ ความสด และเจ้าของ ใช้ตรวจอัตโนมัติก่อนข้อมูลเข้า CRM
Validation at Capture: การตรวจข้อมูลตอนกรอก เช่น บังคับเบอร์มือถือไทย 10 หลัก ใช้ตัวเลือกแทนพิมพ์เอง ตรวจซ้ำก่อนสร้างเรคคอร์ด เป็นวิธีที่ถูกที่สุดเมื่อเทียบกับการตามล้างทีหลัง
Data Observability / Monitoring: การเฝ้าดูสุขภาพของตารางข้อมูลต่อเนื่อง เช่น อัปเดตตรงเวลาไหม จำนวนแถวหายไหม ค่าว่างเพิ่มขึ้นไหม แล้วแจ้งเตือนอัตโนมัติ
AI-ready data: ข้อมูลที่พร้อมให้ AI ใช้ คือ สะอาด สดตามที่ตกลง มีนิยามชัด มีสถานะ consent และกำหนดสิทธิ์ว่า AI เห็นอะไรได้บ้าง ถ้าไม่พร้อม AI จะตอบผิดอย่างมั่นใจ

บริบทตลาดไทย

ในไทย คีย์ที่จับคู่ลูกค้าได้ดีที่สุดคือเบอร์มือถือ เพราะผูกกับ OTP, PromptPay และ LINE แต่ต้องจัดรูปแบบให้เหมือนกันก่อน (0xx กับ +66xx) ชื่อและที่อยู่ภาษาไทยสะกดได้หลายแบบและมักปนอังกฤษ จึงต้องจัดรูปแบบก่อนหาตัวซ้ำ LINE UID สำคัญแต่ต่างกันตาม Provider ส่วน Shopee ปิดชื่อและเบอร์ผู้ซื้อ ข้อมูลมาร์เก็ตเพลสจึงรวมตรง ๆ ไม่ได้ ด้านกฎหมาย PDPA ให้ลูกค้าขอแก้ข้อมูลให้ถูกต้องเป็นปัจจุบัน และกำหนดให้มีบันทึกกิจกรรมการประมวลผล (ROPA), DPO ตามเงื่อนไข และสัญญากับผู้ประมวลผล ปี 2025 สคส. เริ่มปรับจริงทั้งเจ้าของข้อมูลและบริษัทที่รับทำระบบ ธุรกิจหลายสาขาควรวัดคุณภาพข้อมูลแยกรายสาขา เพราะปัญหามักกระจุกที่จุดกรอกไม่กี่แห่ง

สิ่งที่ทีมข้อมูลต้องเตรียม

ทีมข้อมูล (Azure Databricks) ควรเตรียม: (1) customer_master แบบ SCD Type 2 ใน Unity Catalog มี golden_customer_id และ identity_link (source, source_id, id_type, line_provider_id สำหรับ LINE UID, match_method, score, merged_at, unmerged_at) เพื่อแยกกลับได้ (2) consent_log แยกวัตถุประสงค์และช่องทาง มีเวลาและแหล่งที่มา ใช้วัด Consent Sync Lag (3) expectations ใน Lakeflow Spark Declarative Pipelines (Python ใช้ dp.expect / expect_or_drop / expect_or_fail) และตาราง quarantine (4) เปิด Data quality monitoring: anomaly detection ระดับ schema และ data profiling บนตารางที่ส่งเข้า CRM พร้อม custom metric duplicate_rate (5) เปิด Data Classification แล้วผูก ABAC mask กับแท็ก class.name/class.phone_number/class.email_address ส่วนเลขบัตรประชาชนไทยไม่มีแท็กสำเร็จรูป ต้องเขียนกฎ regex + checksum เอง (6) Data Contract แบบ ODCS ตรวจใน CI (7) dq_metrics_daily ตารางเดียวให้ Superset และ Steward ใช้ร่วมกัน ติดตามค่าใช้จ่ายจาก system.billing.usage (DATA_QUALITY_MONITORING, DATA_CLASSIFICATION)

แหล่งอ้างอิง

HubSpot Knowledge Base — Deduplication of contacts, companies, deals, and tickets (อัปเดต ก.ย. 2026)กันซ้ำด้วยอีเมล/โดเมน ฟิลด์ห้ามซ้ำ 10 ฟิลด์ต่อ object ข้อจำกัดกับฟอร์มและ API
BlueConic — Probabilistic and Deterministic Matching Explainedใช้คีย์แน่นอนเป็นฐานโปรไฟล์ และแบบให้คะแนนกับงานเสี่ยงต่ำ
Salesforce Trailhead — Unify Your Data (Data 360)Match rules (exact/fuzzy/normalized) และ Reconciliation rules (Most Recent, Source Priority, ความถี่)
Open Data Contract Standard (ODCS)โครงสร้าง Data Contract (schema, data quality, SLA, team, roles, support) อ้าง v3.1.0
Microsoft Learn — Data quality monitoring (Azure Databricks, ก.ย. 2026)anomaly detection ระดับ schema, data profiling (เดิม Lakehouse Monitoring), ค่าใช้จ่าย serverless
Microsoft Learn — Data Classification (Azure Databricks, ก.ย. 2026)AI ติดแท็กข้อมูลอ่อนไหวอัตโนมัติ ผูก ABAC mask ไม่มีแท็กเลขบัตรประชาชนไทย
Microsoft Learn — Manage data quality with pipeline expectationsexpectations ใน Lakeflow pipelines: warn/drop/fail และ quarantine
LINE Developers — Get user IDsLINE UID ต่างกันตาม Provider และไม่มี UID ถ้าลูกค้าไม่ยินยอมให้เข้าถึงโปรไฟล์
HBR — Only 3% of Companies' Data Meets Basic Quality Standards (2017)สถิติ 3% และแบบฝึกตรวจเรคคอร์ด 100 รายการ
สภาดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งประเทศไทย — คู่มือ PDPA สำหรับผู้ประกอบการสิทธิขอแก้ข้อมูลให้ถูกต้องเป็นปัจจุบัน, ROPA, DPO, สัญญากับผู้ประมวลผล