客戶細分的技術方面第 2 部分 – 數據完整性

已發表: 2022-04-18

上一篇文章幫助我們了解了數據同步如何實現有效的分段。但要成為真正的細分嚮導，您還需要一件事——評估和維護數據質量的能力，統稱為數據完整性。雖然了解這一點的最佳方法是通過實踐，但圍繞關鍵概念展開思考會給你一個良好的開端。

數據完整性是一個廣泛的話題。說實話，這是整個 IT 部門的首要目標。他們都是為了避免根據不正確的數據得出見解。

當我們將其縮小到客戶細分時，CRM 專家應該意識到數據的唯一性、數據類型和數據約束。

數據唯一性

想像一個客戶收到兩次消息，或者更糟糕的是，每次收到兩次消息，但折扣不同。單個案例不會造成太大傷害，但如果這個數字擴大，該活動可能會立即失敗，並帶來長期後果，包括忠誠度下降。

這就是為什麼您的客戶數據庫必須處理數據唯一性的原因。為此，您需要找到一個標識符來區分兩個客戶。它可能是電子郵件或電話號碼。儘管它們對於每個 Tom、Dick 或 Harry 都是唯一的，但它們並不是很好的標識符候選者。首先，一個人的電子郵件地址和電話號碼可能會改變。其次，您可能無法確保電子郵件的唯一性，包括“.”。和“+”或非英文字符。

這就是 CRM 使用唯一內部標識符的原因。它被創造為通用唯一標識符 (UUID)或全局唯一標識符 (GUID) 。

這些算法採用客戶的獨特屬性（如電子郵件或電話號碼），對其進行加密，並生成一串隨機字符——每個客戶都是獨一無二的。當 John 成為您的客戶時，CRM 將為他生成一個標識符，例如 8f14a65f-3032-42c8-a196-1cf66d11b930。

通過創建如此長的標識符，您可以將生成重複 ID 的風險降低到幾乎為零。

數據類型

存儲數據的格式可能是另一個威脅或有助於數據完整性。想像一下，進行一項調查並詢問您的受眾最喜歡的智能手機——您想向在促銷期間選擇 iPhone X 的每位客戶發送報價。

當您閱讀回复列表時，您會看到以下記錄：

iPhone X
iphone X
我電話10
iPhone X
蘋果手機 10
諾基亞 3310
等等...

在為“iPhone X”客戶創建細分時，系統將只顯示一位客戶而不是五位客戶。這個問題的解決方案很簡單——只需將答案字段類型更改為預定義列表而不是打開的文本。但是，如果您在推出之前忘記了它，最終您的盤子上會有很多手動工作。

通過了解和仔細檢查每個客戶旅程步驟的數據模型，可以避免此類簡單但麻煩的錯誤。第一步是訪問有關您的 CRM 提供的用於存儲和處理每個實體的數據的選項的文檔 — 這稱為數據模式。

讓我們探索數據模式的外觀以及如何使用其功能來確保數據完整性。首先是數據類型。

數據類型

數據類型是數據的屬性，它告訴 CRM 我們如何使用數據或我們可以對它們進行哪些操作。這是您可以在幾乎所有 CRM 工具中找到的類型列表。

基元——基本類型

Boolean – 表示值真或假。例如，想像一個屬性：is_first_time_customer。
Integer – 表示一個數字，無論是正數還是負數，都沒有小數點。例如，在 Salesforce CRM 中，整數的最小值為 -2,147,483,648，最大值為 2,147,483,647。
Decimal (float) – 包含小數點的數字，例如 3.14159。
字符 – 單個字母或任何字符，包括數字（統稱為字母數字）。
字符串 – 存儲由任何字母數字字符組成的字符串，例如單詞、短語或句子。
日期 – 表示特定日期的值。
日期時間 – 指示特定日期和時間的值。
Blob –（來自二進制大對象）存儲為單個對象的二進制數據集合。為簡單起見，您可以將其視為單個文件（圖像、錄音、電影、PDF 等）。

在我們轉向高級類型之前，讓我們暫停片刻以了解如何選擇正確的類型。您可能已經註意到每種數據類型都有兩個特徵：

它可以代表什麼樣的價值觀，
它可以存儲的最小值和最大值是多少。

兩者都有兩條經驗法則：

1) 在價值表示方面——你擁有的靈活性越大，數據自動化的可能性就越小，或者更好的是，處理數據需要更多的軟件工作。一個簡單的例子是美國的郵政編碼。如果它是一個數字，我們可以使用範圍來推斷狀態（例如，阿拉巴馬州是 35801 到 35816）。這對字符串來說是不可能的。

另一個很好的例子是我們的調查。如果我們想計算帶有開放文本版本的 iPhone X 變體，我們需要調整查詢以包含所有值。另外，我們需要維護查詢——每次我們發現用戶輸入的新變體時，都必須更新查詢。

2）第二條規則是關於最小值和最大值。您為屬性設置的大小越大，它就越靈活。現在，您可能會問為什麼不總是使用最大的選項？因為更大的尺寸需要更多的計算機內存來處理數據，而這會花費更多。當您擁有數百條記錄時，它可能可以忽略不計，但當您增長到數百萬條時，您的 CRM 實例可能會響應較慢，或者您將達到限制並被迫升級到更高的定價計劃。

複合——結合兩個或多個基元的結果

數組——一組任意大小的基元。它通常表示為括號中的系列或原語，例如 [1, 3, 5, 13, 5]。
Set – 一組任意大小但只有唯一值的基元 [1, 3, 5, 13]。
枚舉 – 枚舉（來自枚舉器）是一種數據類型，每個值都恰好採用您指定的一組有限標識符中的一個（我們應該在調查中使用它以避免混亂！）。
對象 – 對像是包含其他值的值，通常採用固定數字和順序，通常按名稱索引。記錄的元素通常稱為字段或成員。記住第一部分的 JSON 示例，它們是對象。

數據約束

數據類型已經幫助我們維護數據的順序並防止繁瑣的數據清理任務，我們可以在機器的幫助下採取行動。但是我們可以在約束條件下做更多的事情。

數據約束定義了數據必須遵守的特定屬性。可靠的 CRM 系統可確保始終保持約束——即，當您創建新對像或修改現有對象時。

您是否收到過標題為 Dear {first.name} 的電子郵件？這可能是因為忘記了對名字屬性的 NOT NULL 約束。

以下是這個和其他典型約束的工作原理：

不為空——每個值都不能是“NULL”，用簡單的英語表示它不能為空。
唯一– 對於數據庫中的每個對象，值必須是唯一的。例如，如果您想通過電子郵件或電話號碼來識別客戶，您應該使此字段唯一，以避免重複消息和更嚴重的問題。
主鍵- 每個對象的值必須是唯一的，並且不能為 NULL。大多數 CRM 開箱即用地實現了這些約束。
外鍵——值必須引用另一個對像中的現有記錄（通過其主鍵或其他一些唯一約束）。想像一下，您在系統中找到了一張禮品卡，但它沒有所有者信息。您猶豫是否要停用它，因為也許您的一位客戶得到了它，如果它在結賬時失敗，您會感到失望。在禮品卡和客戶對象之間添加外鍵可以解決這個問題，因為系統不會在沒有分配所有者的情況下創建卡片，或者錯誤地從現有卡片中刪除所有者。
Check – 一個必須為真才能滿足約束的表達式。這是您可以應用於特定數據類型的屬性的條件的總括約束。以下示例應該可以幫助您掌握這個概念：

電子郵件（字符串）應符合特定模式（閱讀 wiki 文章以了解它比中間的強制 @ 更複雜）。
年齡（整數）應大於 13。
生日（日期）應該是三月。
客戶創建（日期）應在 2020 年 10 月 1 日之前。
最後一個訂單（DateTime）不應早於昨天中午。
電話號碼（字符串）應以國家/地區前綴開頭。
地址（對象）應該由街道、號碼、城市、國家、郵政編碼組成——它們可以有自己的“檢查”約束。 ‍

數據標準化

您應該了解另一個概念，以提高您對數據完整性的理解，更具體的數據複製部分。這稱為數據規範化。

例如，讓我們以忠誠度計劃為例。我們需要將客戶分層，以便稍後執行一些分析。想像一張表格，其中包含有關客戶何時加入特定層的信息。

我們不存儲層的名稱（每個人的長度可能與 Dunder Mifflin Golden Tier 一樣長），我們只需保存一個引用程序層表的數字。

因此，我們沒有持有 20000 個 Dunder Mifflin Golden Tier，而是擁有 20000 個參考，例如 #3。當您出於某種原因想要更改層名稱時，您只需在一處更新它，並且將保持數據完整性。

現在，讓我們更深入地研究一個更高級的規範化概念。假設您想要監控客戶如何跨不同層級移動。我們可以將其存儲在下表中：

客戶 | 層 | 層級輸入日期

邁克·斯科特 | DM 黃金級 | 2020 年 7 月 21 日

邁克·斯科特 | DM 銀級 | 2020 年 4 月 6 日

吉姆·哈爾珀特 | DM 青銅級 | 17/06/2020

但是最好創建三個單獨的對象來存儲它，一個包含層級列表的表，一個包含客戶列表的表，另一個將它們連接起來。這使我們在單獨更改客戶信息或層級信息時獲得了最大的自由度，當然，我們的重複數據更少。

默認的 CRM 對象通常遵循數據規範化概念。儘管如此，如果您想通過擴展開箱即用的模式來創建一些自定義對象，您應該始終將數據規範化放在腦海中。

外賣

當您發現自己正在使用新的 CRM 時，請訪問他們的文檔以探索數據模式。瀏覽默認對像以查看您可以立即執行的操作。了解數據類型以及如何使用內置機制（如 Hubspot 計算、帶有公式的 Salesforce 計算字段）或如何使用 Liquid 等模板語言呈現它們。

作為練習，您還可以訪問 Fabric 關於構建電子商務數據模式的文章，以探索這篇文章中的數據完整性理論如何應用於現實生活中的用例。