CDP 應該放在你的營銷技術堆棧的什麼位置？

已發表: 2022-12-05

任何客戶數據平台 (CDP) 都必須很好地融入您的營銷技術堆棧，包括您的客戶數據生態系統。與許多架構選擇一樣，您在這裡幾乎沒有絕對的對錯，但您有值得考慮的選擇。

在 Real Story Group，我們看到了三種廣泛的方法，包括每種方法的變體：

當然，這些並不相互排斥。在某些情況下，企業會希望採用混合方法。然而，它們提供了有用的對比，所以讓我們深入挖掘。

方法 1：來自錨定套件的 CDP

許多套件供應商（SAP、Adobe、Oracle、Salesforce 和 Microsoft）銷售廣泛的營銷套件（在不同程度上）由他們熱切希望您獲得許可的可選 CDP 支持。

在買方方面，我理解這種誘惑。為什麼不嘗試簡化選擇呢？一些顧問和分析師也推動這種方法。

我們的研究表明並非如此，我們已經看到許多基於隨意 CDP 選擇的不合適的解決方案。以下是一些可能的原因。

考慮套件供應商的 CDP 附加組件沒有壞處。但是請確保您選擇它是根據它的優點，而不是因為它來自現有供應商。

深入挖掘：客戶數據平台 (CDP) 購買者指南

市場上有幾十個專門的 CDP。 CDP 可以提供範圍廣泛的功能，因此，市場是廣泛的、分散的，並且具有許多不同的功能集和架構方法。

因此，您很有可能找到合適的打包解決方案，這總是一件好事。不過請記住，即使使用同類最佳的 CDP，也可能需要有人執行大量的開發和集成工作。

獲取營銷技術！日常的。自由的。在您的收件箱中。

見條款。

您不使用打包的 CDP，而是使用其他組件“組合”您的 CDP。大多數企業已經擁有某種數據倉庫 (DWH) 和/或數據湖。因此，與其將數據從 DWH 複製到 CDP，不如將 DWH 用作 CDP？

當然，DWH 不是 CDP，因此這種方法需要其他組件構建類似 CDP 的層。至少，您需要一個反向 ETL 工具來從 DWH 中提取數據，然後將其推送到激活通道。

但這還不夠。您還需要 CDP 提供的其他功能的組件：

現在，您可能不需要所有這些，因此您可以挑選並選擇構建您所需要的。請記住，在某種程度上，您是在這裡構建軟件。開發人員感興趣的內容可能對業務利益相關者來說不是最佳選擇。

這種 CDP-by-assembly 的一些支持者已經到了聲稱 CDP 已死的程度，而這種方法就是您所需要的。我不同意。所有三種方法都有時間和地點。

從本質上講，現代營銷技術堆棧是“可組合的”。我相信上面的三種方法確實代表了可組合性的範圍。當您從“套件附加”轉變為“打包的同類最佳”再到“組件化”（甚至可能超越以完成 DIY）時，可組合性的粒度會增加。

最初，隨著粒度的增加，您會獲得更多的功能和能力。但是，可組合性的進一步提高只會帶來開箱即用功能方面的回報遞減，儘管有一個更有針對性的解決方案。

在這個市場上沒有“放之四海而皆準”，總是需要權衡取捨。

組件化使您能夠構建更有針對性的解決方案，它可以更好地滿足您當前的需求，同時可能更快地開始使用。

也就是說，隨著您的需求的發展或新需求的增加，您可能需要額外的組件並投入更多的時間和資源來構建可能在同類最佳工具中開箱即用的東西。因此，隨著您的需求和組件的擴展，堆棧的複雜性也會增加。

下圖提供了一個框架，用於決定哪種方法更適合您。它描述了各種權衡，以及這些方法中的每一種如何影響您的堆棧複雜性、適合目的、功能範圍、總擁有成本和實施難易程度。

您可以看到每種方法都有其優點和缺點。同類最佳的 CDP 可為廣泛的用例提供支持，並允許您逐步擴展以添加對其他用例的支持。

“組件化”方法允許您構建特定於當前需求的東西。開始可能很容易（“我們可以從 Snowflake 獲取您的數據並在 5 分鐘內將其發送到您的電子郵件平台”）。但是隨著您的要求變得越來越複雜，您需要更多的零件，從而使您的堆棧更加複雜。

同樣，這裡沒有拍拍答案。

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