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。 此处列出了工作人员作者。

将 MarTech 添加到您的 Google 新闻提要中。