客戶細分的技術方面——數據同步

已發表: 2022-04-18

“豐富的CRM數據庫分析和細分經驗”，“對受眾細分的把握”，“對數據細分和服務個性化內容的理解和經驗”。這些是 CRM/生命週期營銷工作機會中最常見的要求示例。儘管客戶細分的概念相當簡單且易於開始，但成為細分專業人士需要深入了解技術細節。通過本文，我們希望幫助您實現這一飛躍。

這就是為什麼有效的分段首先要確保從多個數據源到單個服務器的一致數據流。這個過程贏得了一個您最近可能經常聽到的名字——數據同步或簡單的數據同步。這是一個在系統之間建立一致性並隨後持續更新以保持一致性的過程。

很多聰明的詞意味著它主要是工程團隊的領域。但是讓自己熟悉關鍵概念會有很大幫助。這是一個概述：

數據同步——在本節中，我們將了解客戶數據的存儲方式、人們為什麼要移動它們以及數字團隊需要克服哪些障礙才能做到這一點。在更實用的方面，本章解釋了現代 CRM 系統如何通過 Internet 使用 API 交換數據的內部部分。
數據完整性和安全性——下一部分將幫助您了解在同步數據後如何使數據保持一致狀態。我們將學習如何使用模式來處理數據唯一性並防止數據重複。最後，我們將反思數據安全和隱私的技術方面，因為它們已成為後 GDPR 和 CCPA 時代的一等公民。
數據處理——最後，我們將通過向您展示一些關於數據過濾和一般數據驅動決策的技巧來幫助您變得流利。

存儲和格式複雜性

由於最近技術的發展，數據存儲的成本已經下降。這使企業能夠收集大量數據。

這些數據可以分為兩類：結構化和非結構化。為了使細分發揮作用，數字團隊需要弄清楚如何從非結構化過渡到結構化。

結構化數據存儲主要是指SQL 數據庫或Excel 文件。它們是出色的多功能工具，但也有其缺點。 SQL對於沒有技術背景的人來說很難學，Excel的頂級優勢，靈活性，成為長期維護數據完整性的噩夢。這就是為什麼這些通用軟件工具已經被更專注的工具所取代，如 CRM、CMS、ERP 或分析工具。

儘管這些以工作為導向的工具提高了他們所聘用的領域的生產力，但它們經常成為部門/公司層面的問題。為什麼？這些工具中的每一個通常都使用自己的數據格式，除非兩個軟件平台相互集成，否則數據交換會受到阻礙。而且，現代營銷人員使用了大量此類工具。

這就是大多數數據同步過程需要中間人的原因。它將創作軟件生成的數據格式（在 IT 世界中稱為“源”）適應目標格式（“目標”）。這種適應的過程稱為ETL。它是 Extract（來自源的數據）、Transform（以某種方式被目標識別和接受）、Load（向目標保持數據一致性）的縮寫。

在客戶細分行業你能遇到什麼樣的數據格式？

數據格式

如今，分割軟件在大多數情況下使用兩種開放格式進行數據同步。但是到底什麼是“數據格式”呢？這只不過是以計算機可以理解的方式構造的文本。讓我們從第一個更簡單的開始。

CSV – 逗號分隔值。想像一下你拿一張桌子。 MS Word 中的常規表格就可以了。現在讓我們刪除外部邊框並用逗號替換內部邊框。瞧，您剛剛創建了一個 CSV 文件。

最大的優勢？簡單和緊湊。開發人員可以輕鬆地以這種格式導出數據，因為 SQL 和 Excel 數據庫將數據存儲在表格中。

另一方面，CSV 有兩個主要缺陷。首先，在 CSV 文件中，您不能表示層次結構。例如，您不能顯示一個值與另一個值相關。第二個最重要的缺點是 CSV 是一種固定格式。它允許您根據您在開始時定義的列的確切數量和類型交換數據。如果您添加另一個目標系統所需的列或只是刪除一個列，則會在嘗試導入時導致錯誤。在這種情況下，開發人員將需要調整代碼以反映結構變化。

由於近年來營銷技術獲得的動態，這種限制被證明是一個主要障礙。

出於這個原因，現代系統開始使用XML和JSON數據交換數據。它們都基於相同的數據表示概念。我們將描述後者，因為它更受歡迎。

這是 JSON 文件的示例。當我們將我們的 JSON 文件與 CSV 對應文件進行比較時，我們會立即發現相似之處——我們可以看到這個文件存儲了完全相同的數據。

顯著的區別是 CSV 文件中的列名是重複的。雖然這對於人類來說似乎是多餘的並且阻礙了可讀性，但正是這種重複賦予了 JSON 靈活性——它使項目的順序變得無關緊要。如果您需要將新屬性（一列）添加到交換的文件中，這將很有幫助。期望新屬性的目標軟件將使用它，而在添加列之前處理文件的目標將忽略新屬性並且將不受干擾地工作。

此功能保證如果您在源應用程序發送的數據格式中添加更多字段，它不會破壞目標。這就是為什麼說 JSON 格式比 CSV 更具可擴展性和更靈活的原因。

您可以在此處閱讀有關 JSON 文件的更多信息。

同步頻率

今天的共同要求是電子商務系統是實時的。客戶希望查看他們的訂單狀態、實時包裹跟踪或他們賬戶上的當前餘額。此外，營銷人員希望快速做出反應，他們希望開展實時活動以創造及時的購物體驗。

為此，底層數據存儲采用了實時同步。

但是，需要注意實時同步的兩個挑戰。

首先，一般的經驗法則——你想要獲得的實時性越多，成本就越高。這種成本體現在開發人員的時間上，還體現在運行服務器的硬件（今天主要是雲解決方案）上，您需要保持數據同步系統正常運行。因此，在與工程師交談時提出“實時”要求之前，您的首要任務是考慮您真正需要什麼樣的數據同步頻率。也許，每小時或每天發送一次更新足以確保出色的客戶體驗，同時減少開發人員的工作並節省預算。

另一個挑戰是您使用的數據存儲的數據提取功能。有時，當其中一個系統不提供提取數據的簡單方法時，實時同步可能會受到阻礙。簡單意味著開發人員友好。讓我們通過開發人員如何在系統中移動數據來詳細分析這個問題。

數據同步介質

我們已經了解了數據的存儲方式、用於交換的格式以及同步頻率如何影響設置整個同步系統的工作。但是將數據從一個數據庫傳輸到另一個數據庫實際上需要什麼？嗯，你需要一個媒介。

它可以是物理存儲，如 DVD、USB 驅動器或其他基於硬件的同步，但由於海量數據和實時同步要求，如今很少有人這樣做。在大多數情況下，這一切都是通過電纜完成的，或者實際上是由全球計算機互連的許多電纜 - 稱為 Internet。

更具體地說，現代軟件平台使用作為萬維網基礎的超文本傳輸協議 (HTTP)。

如果您對服務器如何通過 Internet 相互通信感興趣（並且最好是！），我們強烈建議您閱讀本非技術人員的服務器指南。

簡而言之，您可以將 HTTP 協議視為指導開發人員如何通過 Internet 發送數據的指南。在 HTTP 之上，開發人員創建應用程序編程接口 (API) ，這些 API 是對可以在兩個系統之間交換的數據和順序的具體描述。

使 API 在 Internet 中可用並可供其他系統訪問（類似於您訪問常規網頁的方式）的軟件稱為應用程序服務器。它所做的只是監聽和響應來自其他應用程序服務器的請求，並根據請求添加或從底層數據庫獲取信息。有用信息：當人們提到 API 時，通常是應用服務器將 API 公開到 Internet 的快捷方式。

那麼讓我們來玩一下 API。

API 優先世界

API 已成為當今數字營銷的通用語。今天的大部分數據同步工作是學習一個能夠從中提取數據的 API。這就像從一門外語中學習另一組單詞一樣，假設您知道語法，在這種情況下，語法是由 HTTP 定義的。

儘管這是開發人員的工作，但深入研究此主題可能會幫助您瀏覽營銷技術世界。

我們創建了一篇專門的文章，其中包含一些關於理解 API 的實際示例，因此，如果您想掌握它（同樣，您應該），請在此處閱讀。

這是其中最重要的摘錄：

“如果你作為顧客去餐廳，你是不允許進入廚房的。你需要知道什麼是可用的。為此，您有菜單。查看菜單後，您向服務員點菜，服務員將其傳遞給廚房，然後由服務員提供您要的東西。服務員只能提供廚房能提供的東西。

這與 API 有什麼關係？服務員是 API。你是一個尋求服務的人。換句話說，您是 API 客戶或消費者。菜單是解釋您可以從 API 中請求什麼的文檔。例如，廚房是服務器；一個只包含特定類型數據的數據庫——無論買家為餐廳購買了什麼作為食材，廚師決定他們將提供什麼，以及廚師知道如何準備什麼。”

Kitchen – 數據庫，不允許客戶保護數據完整性。
Waiter – API，一個知道如何在不中斷數據庫功能的情況下提供數據庫數據的中間人。
客戶 – 想要獲取其數據的外部系統。
菜單 – 外部系統執行操作時必須使用的數據格式參考。
Order – 一個實際的單個 API 調用。

回到同步，現在剩下的問題是弄清楚兩個系統應該在什麼條件下交換數據。

數據同步觸發器

假設我們有兩個準備好交換信息的應用程序服務器。更具體地說，假設您的電子郵件服務提供商 ( ESP ) 想知道客戶訂單（電子商店）的數量，以便在第十個訂單之後向他們發送促銷優惠券。現在，我們可以實現什麼樣的數據流來實現這個場景呢？我們可以區分三個可以在 ESP 端啟動電子郵件優惠券機制的“觸發器”。

a)數據輪詢——在這種情況下，ESP 反复詢問 e-shop API：“讓我知道 Jane Doe 的總訂單量”。它每隔一分鐘、一小時或一天等執行一次。當 ESP 收到信息時，它將重新計算每個 API 請求的優惠券發送條件。如果您認為以這種方式調用和處理數據可能不是最理想的，那麼您的直覺是正確的。有什麼選擇？

b)數據推送——如果電子商店可以在 Jane 下第 10 個訂單的那一刻通知 ESP 應用程序會怎樣？這是正確的。現代電子商務平台已經意識到這些缺點，並將此類通知包含在其功能集中。它們通常稱為webhook或調用。這是一個簡單而強大的功能。它允許您定義在特定條件下應何時通知哪些應用程序。您還可以定義通知應包含哪些信息——有時發送完整信息是合理的，但通常只更改屬性就足夠了。

c)批處理——有時，請求的數量如此之多，以至於這兩種方法都不合理。處理負載所需的處理能力將損害一方（或什至雙方）。在這種情況下，開發人員將所有信息分組到一個“批次”中，並安排在晚上或更一般地，當服務器不忙於日常流量時進行數據交換。這有助於控制應用程序的流量並防止服務器的潛在壓力。

有用的術語：為了防止向服務器發送過多的請求，應用程序開發人員將速率限制器應用於他們的應用程序。它限制了給定時間段內的 API 調用次數，例如每分鐘 5000 次調用。通常，超出配額的調用會受到限制。這意味著它們最終會被送達（而不是完全放棄），但會有一些延遲。

到目前為止，我們已經了解瞭如何同步客戶數據。但是在進行實際的客戶細分之前，我們需要了解如何在您的數據庫中保持數據的一致性。在下一部分中，我們將描述如何確保數據完整性和安全性以實現效果良好的活動。