ด้านเทคนิคของการแบ่งส่วนลูกค้า ส่วนที่ 2 – ความสมบูรณ์ของข้อมูล

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

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

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

เอกลักษณ์ของข้อมูล

ลองนึกภาพลูกค้าได้รับข้อความสองครั้งหรือที่แย่กว่านั้นคือได้รับข้อความสองครั้งในแต่ละครั้งโดยมีส่วนลดต่างกัน กรณีเดียวจะไม่ก่อให้เกิดอันตรายมากนัก แต่ถ้าตัวเลขนี้เพิ่มขึ้น แคมเปญอาจล้มเหลวทันทีและมีผลระยะยาว รวมถึงการลดลงในความภักดี

นี่คือเหตุผลที่ฐานข้อมูลลูกค้าของคุณต้องดูแลความเป็นเอกลักษณ์ของข้อมูล ในการดำเนินการดังกล่าว คุณต้องค้นหา ตัวระบุ ที่ช่วยให้คุณแยกความแตกต่างระหว่างลูกค้าสองราย อาจเป็นอีเมลหรือหมายเลขโทรศัพท์ แม้ว่าพวกเขาจะมีเอกลักษณ์เฉพาะตัวสำหรับ Tom, Dick หรือ Harry ทุกคน แต่ก็ไม่ใช่ตัวเลือกที่ดีสำหรับตัวระบุ ประการแรก ที่อยู่อีเมลและหมายเลขโทรศัพท์อาจเปลี่ยนแปลงสำหรับบุคคล ประการที่สอง คุณอาจมีปัญหาในการตรวจสอบความเป็นเอกลักษณ์ของอีเมล ซึ่งรวมถึง “.” และ “+” หรืออักขระที่ไม่ใช่ภาษาอังกฤษ

นั่นคือเหตุผลที่ CRM ใช้ตัวระบุภายในที่ไม่ซ้ำกัน ได้รับการประกาศเกียรติคุณให้เป็น Universally Unique Identifier (UUID) หรือ Globally Unique Identifier (GUID)

อัลกอริทึมเหล่านี้เป็นอัลกอริทึมที่ใช้แอตทริบิวต์เฉพาะของลูกค้า (เช่น อีเมลหรือหมายเลขโทรศัพท์) เข้ารหัส และสร้างสตริงอักขระสุ่ม ซึ่ง เป็นเอกลักษณ์สำหรับลูกค้าทุกราย เมื่อ John เป็นลูกค้าของคุณ CRM จะสร้างตัวระบุให้กับเขา เช่น 8f14a65f-3032-42c8-a196-1cf66d11b930

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

ชนิดข้อมูล

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

เมื่อคุณอ่านรายการตอบกลับ คุณจะเห็นบันทึกต่อไปนี้:

• iPhone X
• iphone X
• i Phone10
• IPhone X
• iphone 10
• โนเกีย 3310
• และอื่นๆ...

เมื่อสร้างเซ็กเมนต์สำหรับลูกค้า “iPhone X” ระบบจะแสดงลูกค้าเพียงรายเดียวแทนที่จะเป็นห้าราย วิธีแก้ปัญหานี้ตรงไปตรงมา — เพียงเปลี่ยนประเภทฟิลด์คำตอบเป็นรายการที่กำหนดไว้ล่วงหน้าแทนข้อความเปิด แต่ถ้าคุณลืมไปเสียก่อนที่จะเปิดตัว คุณจะพบกับงานที่ต้องทำเองจำนวนมากบนจานของคุณ

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

มาสำรวจกันว่าสคีมาข้อมูลมีลักษณะอย่างไร และคุณจะใช้ฟีเจอร์ของสคีมาได้อย่างไรเพื่อรับรองความสมบูรณ์ของข้อมูล ชนิดข้อมูลไปก่อน

ชนิดข้อมูล

ชนิดข้อมูลคือคุณลักษณะของข้อมูลที่บอก CRM ว่าเราจะใช้ข้อมูลได้อย่างไร หรือดำเนินการใดกับข้อมูลเหล่านั้นได้ นี่คือรายการประเภทที่คุณสามารถหาได้ในเครื่องมือ CRM ทุกชิ้น

Primitives – ประเภทพื้นฐาน

• บูลีน – แทนค่าจริงหรือเท็จ ตัวอย่างเช่น ลองนึกภาพแอตทริบิวต์: is_first_time_customer
• จำนวนเต็ม – แทนตัวเลข บวกหรือลบ ที่ไม่มีจุดทศนิยม ตัวอย่างเช่น ใน Salesforce CRM จำนวนเต็มมีค่าต่ำสุด -2,147,483,648 และค่าสูงสุด 2,147,483,647
• ทศนิยม (ลอย) – ตัวเลขที่มีจุดทศนิยม เช่น 3.14159
• อักขระ – ตัวอักษรตัวเดียวหรืออักขระใดๆ รวมทั้งตัวเลข (เรียกรวมกันว่าตัวอักษรและตัวเลข)
• สตริง – เก็บสตริงของอักขระที่เป็นตัวอักษรและตัวเลขคละกัน เช่น คำ วลี หรือประโยค
• วันที่ – ค่าที่ระบุวันใดวันหนึ่ง
• วันที่และเวลา – ค่าที่ระบุวันและเวลาเฉพาะ
• Blob – (จากไบนารีออบเจ็กต์ขนาดใหญ่) คอลเลกชันของข้อมูลไบนารีที่จัดเก็บเป็นออบเจ็กต์เดียว คุณสามารถมองว่ามันเป็นไฟล์เดียว (รูปภาพ การบันทึกเสียง ภาพยนตร์ PDF ฯลฯ) เพื่อความง่าย

ก่อนที่เราจะเปลี่ยนไปใช้ประเภทขั้นสูง ให้หยุดสักครู่เพื่อให้เข้าใจถึงวิธีเลือกประเภทที่ถูกต้องเสียก่อน คุณอาจสังเกตเห็นแล้วว่าข้อมูลแต่ละประเภทมีลักษณะสองประการ:

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

มีกฎทั่วไปสองข้อสำหรับทั้งคู่:

1) เมื่อพูดถึงการแสดงค่า - ยิ่งคุณมีความยืดหยุ่นมากเท่าไร การทำงานอัตโนมัติของข้อมูลก็จะน้อยลงเท่านั้น หรือดีกว่า การทำงานในซอฟต์แวร์ก็ยิ่งมีความจำเป็นมากขึ้นเท่านั้นในการประมวลผลข้อมูล ตัวอย่างง่ายๆ ก็คือรหัสไปรษณีย์ในสหรัฐอเมริกา หากเป็นตัวเลข เราสามารถใช้ช่วงเพื่อสรุปสถานะได้ (เช่น แอละแบมาคือ 35801 ถึง 35816) นั่นจะเป็นไปไม่ได้สำหรับสตริง

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

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

คอมโพสิต – เป็นผลมาจากการรวมสองสิ่งขึ้นไปเข้าด้วยกัน

• Array – กลุ่มของระดับพื้นฐานทุกขนาด โดยปกติจะแสดงเป็นอนุกรมหรือพื้นฐานในวงเล็บ เช่น [1, 3, 5, 13, 5]
• Set – กลุ่มของ primitives ทุกขนาดแต่มีค่าเฉพาะ [1, 3, 5, 13] เท่านั้น
• Enum – an enum (จากตัวแจงนับ) เป็นชนิดข้อมูลที่มีค่าที่แต่ละค่าใช้หนึ่งในชุดของตัวระบุที่คุณระบุ (เป็นข้อมูลที่เราควรใช้สำหรับการสำรวจของเราเพื่อหลีกเลี่ยงความยุ่งเหยิง!)
• วัตถุ – วัตถุคือค่าที่มีค่าอื่น ๆ โดยทั่วไปแล้วจะเป็นตัวเลขและลำดับคงที่และโดยทั่วไปจะจัดทำดัชนีตามชื่อ องค์ประกอบของเร็กคอร์ดมักจะเรียกว่าฟิลด์หรือสมาชิก จำตัวอย่าง JSON จากส่วนแรก พวกมันคืออ็อบเจกต์

ข้อจำกัดของข้อมูล

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

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

คุณเคยได้รับอีเมลชื่อ Dear {first.name} หรือไม่? ซึ่งอาจเป็นผลมาจากการลืมข้อจำกัดที่ไม่เป็นค่าว่างในแอตทริบิวต์ชื่อ

นี่คือวิธีการทำงานและข้อจำกัดทั่วไปอื่นๆ:

• ไม่เป็นค่าว่าง – แต่ละค่าต้องไม่เป็น “NULL” ซึ่งในภาษาอังกฤษล้วนหมายความว่าไม่สามารถเว้นว่างได้
• ไม่ซ้ำกัน – ค่าต้องไม่ซ้ำกันสำหรับแต่ละวัตถุในฐานข้อมูล ตัวอย่างเช่น หากคุณต้องการระบุลูกค้าด้วยอีเมลหรือหมายเลขโทรศัพท์ คุณควรทำให้ฟิลด์นี้ไม่ซ้ำกันเพื่อหลีกเลี่ยงข้อความที่ซ้ำกันและปัญหาที่รุนแรงมากขึ้น
• คีย์หลัก – ค่าต้องไม่ซ้ำกันสำหรับแต่ละอ็อบเจ็กต์และไม่ใช่ NULL CRM ส่วนใหญ่ใช้ข้อจำกัดเหล่านี้ตั้งแต่แกะกล่อง
• คีย์ต่างประเทศ – ค่าต้องอ้างอิงระเบียนที่มีอยู่ในวัตถุอื่น (ผ่านคีย์หลักหรือข้อจำกัดเฉพาะอื่นๆ) ลองนึกภาพว่าคุณพบบัตรของขวัญในระบบของคุณ แต่ไม่มีข้อมูลเจ้าของ คุณลังเลที่จะปิดการใช้งานเพราะบางทีลูกค้าของคุณอาจได้รับและจะผิดหวังหากไม่สำเร็จในขั้นตอนการชำระเงิน การเพิ่มคีย์นอกระหว่างบัตรของขวัญและออบเจ็กต์ของลูกค้าจะช่วยแก้ปัญหานี้ได้ เนื่องจากระบบจะไม่สร้างการ์ดโดยที่เจ้าของไม่ได้รับมอบหมายหรือนำเจ้าของออกจากบัตรที่มีอยู่โดยไม่ได้ตั้งใจ
• ตรวจสอบ – นิพจน์ที่ต้องเป็นจริงเพื่อให้เป็นไปตามข้อจำกัด นี่คือข้อจำกัดในร่มสำหรับเงื่อนไขที่คุณสามารถใช้กับแอตทริบิวต์ของประเภทข้อมูลเฉพาะได้ ตัวอย่างต่อไปนี้จะช่วยให้คุณเข้าใจแนวคิด:

• อีเมล (สตริง) ควรเป็นไปตามรูปแบบเฉพาะ (อ่านบทความ wiki เพื่อดูว่าซับซ้อนกว่าบังคับ @ ตรงกลาง)
• อายุ (จำนวนเต็ม) ควรมากกว่า 13
• วันเกิด (วันที่) ควรอยู่ในเดือนมีนาคม
• การสร้างลูกค้า (วันที่) ควรมาก่อนวันที่ 1 ตุลาคม 2020
• คำสั่งสุดท้าย (DateTime) ไม่ควรช้ากว่าเที่ยงวันของเมื่อวาน
• หมายเลขโทรศัพท์ (สตริง) ควรเริ่มต้นด้วยคำนำหน้าประเทศ
• ที่อยู่ (วัตถุ) ควรประกอบด้วยถนน หมายเลข เมือง ประเทศ รหัสไปรษณีย์ ซึ่งสามารถมีข้อจำกัดในการ "ตรวจสอบ" ได้ด้วยตนเอง ‍

การปรับข้อมูลให้เป็นมาตรฐาน

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

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

แทนที่จะเก็บชื่อของระดับ ซึ่งอาจยาวนานเท่ากับ Dunder Mifflin Golden Tier สำหรับทุกคน เราเพียงแค่เก็บตัวเลขที่อ้างอิงตารางของระดับของโปรแกรม

ดังนั้น แทนที่จะถือ 20000 Dunder Mifflin Golden Tier เรามีข้อมูลอ้างอิง 20000 รายการเช่น #3 เมื่อคุณต้องการเปลี่ยนชื่อระดับด้วยเหตุผลบางประการ คุณต้องอัปเดต ในที่เดียวเท่านั้น และความสมบูรณ์ของข้อมูลจะยังคงอยู่

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

ลูกค้า | ระดับ | วันที่ป้อนระดับ

ไมค์ สกอตต์ | DM โกลเด้นเทียร์ | 21/07/2020

ไมค์ สกอตต์ | DM ระดับเงิน | 04/06/2020

จิม ฮาลเพิร์ต | DM ระดับบรอนซ์ | 17/06/2020

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

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

ซื้อกลับบ้าน

เมื่อคุณพบว่าตัวเองทำงานกับ CRM ใหม่ ให้ไปที่เอกสารประกอบเพื่อสำรวจสคีมาข้อมูล ดูออบเจ็กต์เริ่มต้นเพื่อดูว่าคุณสามารถทำอะไรได้บ้าง เรียนรู้ประเภทข้อมูลและวิธีดำเนินการด้วยกลไกที่มีอยู่แล้วภายใน เช่น การคำนวณ Hubspot, Salesforce Calculated Fields พร้อมสูตร หรือวิธีนำเสนอด้วยภาษาเทมเพลต เช่น Liquid

คุณยังสามารถเยี่ยมชมบทความของ Fabric เกี่ยวกับการสร้างสคีมาข้อมูลอีคอมเมิร์ซ เพื่อสำรวจว่าทฤษฎีความสมบูรณ์ของข้อมูลจากโพสต์นี้นำไปใช้กับกรณีการใช้งานจริงได้อย่างไร