MarTech 的真實故事：您應該建立還是購買客戶數據平台？

在技​​術市場的背景下，“構建與購買”是一個長期存在的爭論。 在 Real Story Group，我們看到這場辯論正在重新審視營銷技術堆棧，特別是針對客戶數據平台 (CDP)。

有一個正確的方法嗎？ 我不這麼認為，但這裡的細節很重要。 所以讓我們深入研究。

構建與購買

傳統上，獲得企業功能的兩種主要方法是：

1. 購買現成的包裝，然後根據特定需求對其進行定制。
2. 在內部構建平台，專門針對您的要求，有時通過打包的零件。

這兩種方法都有合理的理由，在過去的二十年裡，作為一名行業分析師，我已經看到幾乎所有技術市場都出現了這種選擇。 但是，在 CDP 中構建和購買之間的界限可能會變得更加模糊。

部分挑戰在於打包的 CDP 在範圍上可能會有很大差異。 有些具有很大的垂直深度，可以回到企業執行上游數據處理或向前延伸到參與層以提供實時交互。 一些打包的 CDP 圍繞編排、活動管理甚至出站消息提供橫向服務。

因此，在決定正確的方法之前，重要的是要回答 CDP 將專門為您的企業做什麼。

CDP（為您）做什麼？

該模型顯示了數據生命週期的不同階段，而與特定的技術平台無關。 您的客戶數據可能會經歷所有這些階段：

1. 您需要從各種在線和離線數據源中獲取數據，然後才能對其進行任何操作。 因此，您需要一些機制來攝取數據、清理數據、執行一些轉換和聚合，並確保質量。
2. 從不同來源收集或攝取數據後，您需要將其與用戶配置文件相關聯。 這包括身份解析和個人資料統一等活動。 您還可以使用其他數據豐富您的個人資料，同時確保數據治理和合規性。

在更大的組織中，這兩個初始階段通常發生在更廣泛的企業數據“結構”或“網格”的一部分中。 典型的企業已經擁有數據管理工具來處理這些服務——如數據湖、倉庫、ETL 工具、質量和治理等——並將它們應用於客戶數據。 但是，正如我們將在下面看到的，許多打包的 CDP 工具也提供其中一些服務。 無論如何，企業 IT 和數據團隊成為前兩個階段的重要利益相關者。

• 下一階段是您將所有這些清理、匯總、統一的配置文件數據用於您的業務目標。 例如，現在您擁有用戶或客戶的個人資料或 360 度視圖，您可以根據不同的屬性對其進行細分。 您可以對個人資料進行切片、創建群組、對相似數據進行分組、創建受眾等等——然後，至關重要的是，通過各種渠道激活這些數據。
• 此階段是您通過電子商務、電子郵件、網絡、移動、聊天或其他渠道，使用個性化內容和產品推薦與客戶互動的最後一英里。

您會看到營銷和客戶體驗團隊在後兩個階段的參與度相當高。

理論上，所有這些服務都可能由 CDP 解決。 您經常會發現 CDP 供應商吹噓他們可以同樣出色地執行所有這些階段。

然而，在實踐中，我們看到了這個模型的幾個變體。 例如，請參見圖中 A、B 和 C 公司的不同範圍。 大型、複雜的企業很少為所有這些階段部署一個平台。 至少有兩個原因：

1. 如您所見，整體潛在功能相當廣泛，大型企業已經在 CDP 之外針對上述幾個階段（或這些階段內的功能）制定了現有計劃。 這些功能通常包括數據管道管理、機器學習操作和身份解析，僅舉幾例。
2. 儘管供應商聲稱，事實是他們在所有這些階段從來都不是同樣出色的。 他們通常只能做好這些階段中的一兩個。

因此，CDP 適合您的 martech 堆棧的位置可能不同於它適合另一家公司的位置。 這會影響任何構建與購買的決定，因為問題最初變成： 建造或購買究竟是什麼？ 即使您為上述模型中的某些功能許可現成的 CDP，您也可能會為缺少的功能構建擴展。

所以第一課：無論整體策略如何，您都可能會做一些構建和一些購買。 那麼問題就變成了：比例是多少？

從零件組裝

一種可能對您開放的方法是組裝組件以構建 CDP 功能，而不是從頭開始開發或購買更廣泛、通用的現成 CDP。

這種方法具有一定的吸引力，因為您可能已經擁有一些強大的數據管理功能，作為更廣泛的客戶數據結構的一部分。

您還可以為這些不同的功能許可特定產品。 一些供應商為此類功能提供組件。 例如：

• 數據攝取：有專門的數據攝取供應商和 CDP 供應商自己的模塊。 Stitch（被 Talend 收購）、Snowplow、Fivetran、Matillion 等供應商提供用於數據攝取、數據管道管理、轉換和其他相關功能的模塊。
• ETL 和 ELT：許多供應商將提取-轉換-加載 (ETL)、提取-加載-轉換 (ELT) 和反向 ETL/ELT 用於您可以對原始數據進行的不同類型的轉換。 此類供應商的示例包括 Hevo Data、Hightouch、DBT 和 Census。
• 數據倉庫和數據湖：包括 Snowflake、Google 等在內的多個數據倉庫和數據湖包括數據管理和處理功能。 許多打包的 CDP 架構已經假設源數據將來自此環境。
• “虛擬” CDP ：一些供應商，例如 Aqfer、Rudderstack 和其他一些參與者，提供了一些服務，用於將 CDP 與解耦的數據層組合在一起。
• 身份解析：一些供應商以身份解析為目標。 許多 CDP 現在已經放棄了自己的身份解析工作，而不是與 Neustar、Infutor、LiveRamp 等供應商合作。
• 參與度：以參與度為導向的產品市場仍然充滿活力。 您可以找到許多針對旅程編排、活動管理、個性化、推薦和其他參與用例的單點解決方案。 幾個打包的 CDP 在這方面也很強大。

這不是一個詳盡的服務列表，您可以找到許多其他專業供應商（例如，提供治理解決方案的供應商）。 關鍵是可以將這些服務組裝成一個可組合的數據生態系統，而不是使用單個 CDP 做所有事情。

閱讀下一篇：CDP 領域的深刻變化

你可能會錯過的

到目前為止，您可能已經發現上面的列表中缺少幾個關鍵的 CDP 服務：業務友好的細分和激活。 這些是購買現成的更具挑戰性的功能，在 RSG，當我們看到本土 CDP 時，企業通常會從頭開始構建這些業務用戶界面。 當我們聽到企業開發人員爭辯說“讓我們將數據倉庫用作數據層而不是 CDP”時，這通常是他們的目標。

不過，我會提醒您注意這種方法，因為自定義細分和激活工具可能很脆弱，而高級用戶體驗設計是您在 CDP 中支付的重要部分（但可以肯定的是：並非所有 CDP 都同樣擅長這一點）。

你應該做什麼

認識到您的 CDP 工作無疑將包括一些構建和購買的措施。 這只是比例和位置的問題。 即使您許可打包的 CDP - 並且有充分的理由這樣做 - 您也需要大量的開發工作將其拼接到您的客戶數據結構的其餘部分中，更不用說您的一線參與系統了。

陪審團仍然沒有為此選擇單一的最佳方法，但設計模式正在出現。 有關詳細信息，請參閱此簡報。

同時，當您希望在明年建立您的客戶數據管理能力時，請與您的數據科學家保持密切聯繫，但與您的開發人員保持密切聯繫。

本文中表達的觀點是客座作者的觀點，不一定是 MarTech。 工作人員作者在這裡列出。