营销与数据工程最常误解的24个数据术语

想象你是一名营销人员，正在策划一场赢回活动，你向数据团队要一份“不活跃客户”名单。你预期的是90天内没有购买过任何东西的人。结果名单却是基于30天内没有打开过你应用的用户，因为数据中“不活跃”就是这么定义的。

或者你要求“实时”受众更新，以避免向刚刚下过单的人发送“我们想你了”。你设想的是每15分钟刷新一次的名单。数据团队听到的是“几秒内更新”，然后带着关于新基础设施、持续成本和更长交付周期的问题回来找你。

这些差异会影响要构建什么、成本多少，以及营销何时能用上它。尽早就“客户”指什么、什么使受众就绪、信号需要多新达成一致，可以防止误解变成活动返工。

本指南涵盖24个营销和数据工程常常理解不同的术语，围绕关于活动执行的五个实际问题组织。把成对的定义当作对话的开场白：把假设摆到台面上，厘清各方需要什么，并在工作开始前就适合你业务含义达成一致。

在此获取可打印PDF版全部24个术语。

1. 活动数据来自哪里？

营销工具中的信息可能依赖多个系统和处理步骤。理解这条路径有助于你说明你需要什么，并弄清变更应归在哪里。例如，拿一个叫“上次购买日期”的字段来说。在用它识别流失客户之前，先就要不要包含已取消订单、由哪个系统提供该日期达成一致。

需就以下达成一致： 值来自哪里、包含什么，以及由谁维护。

2. 一条客户记录代表谁？

客户身份决定了谁被纳入、被排除，或者更糟——被重复计算。首先要确定一条记录代表什么，以及团队如何判定两条记录属于同一个人。

营销对客户关系的了解有助于工程在身份方面做出更好的决策。在赢回示例中，个人和家庭都是组织客户数据的有用方式。活动需要在两者之间做出明确选择。按家庭视图可能适合每户限用一个的优惠。按个人视图可能适合个人忠诚度权益。

共享的数据基础让团队能够为这些用途维护命名清晰的视图，并复用合适的那一个。每个视图都需要有记录在案的含义、用于连接记录的标识符，以及匹配规则的负责人。

需就以下达成一致：活动是针对个人、账户、家庭还是设备，以及相关记录如何匹配。

3. 什么使受众可以激活？

一个受众会经过几个状态：定义它的规则、符合条件的记录，以及目标端可以使用的记录。每个状态回答关于活动就绪程度的不同问题。

假设有5万人匹配某个细分，但电子邮件平台只接受其中4.7万条记录。在这个例子中，差异可能反映目标端标识符缺失、记录被拒，或投放期间应用的排除。团队需要先解释这一差异，才能判定受众已就绪。

让定义、评估出的成员资格和投递结果都可识别，会让这件事更容易。营销可以检查规则是否表达了预期的受众。工程可以检查正确的记录是否到达了目标端。双方都能区分预期内的排除和需要修复的问题。

同样的精确性也有助于预测。如果营销活动需要一个倾向性评分，就为预测命名，并说明它旨在估计什么。这给团队提供了比“模型”更具体的构建和验证目标。

就以下事项达成一致：受众选择规则、所需的预测或特征，以及如何验证投放。

4. 数据何时足够新鲜？

新鲜度取决于你试图做出的客户决策。单个营销活动可能有多个时间要求，即使其数据来自同一个平台。

设想一个每晚计算的流失评分，每15分钟发送到互动工具。更频繁的投放并不会让预测变成15分钟前的。它仍然基于每晚的计算。

现在加入一位今早购买的客户。营销活动可能需要在下次发送前将该人从赢回受众中移除，而流失评分可以等待其下一次计划计算。这些是独立的要求，对客户有不同的影响。

要让新鲜度有意义，就要确定延迟的起点和终点：从购买发生，到其在数据平台中可用，从该可用性到成员资格变更，或从成员资格变更到目标端能够对其采取行动。

这些区分帮助团队在能够改变体验的地方投资于速度。它们也为营销提供了一种比说整个营销活动需要“实时”更好的方式来描述问题。

就以下事项达成一致：哪个客户事件启动计时、更新后的数据必须在哪里可用，以及可接受的延迟。

5. 当数据被使用时，谁负责？

获取客户数据的访问权限会带来关于其含义、允许的用途和持续所有权的问题。当受众离开数据平台时，这些责任仍然存在。

在实践中，治理还涵盖数据质量、所有权和适当使用。一个有用的起点是为每个决策确定指定的来源。建立客户身份的系统可能与记录渠道偏好或计算收入的系统不同。

然后跟踪数据到其目的地。导出时符合条件的受众可能需要在后续发送前更新排除名单。保存的副本可能比创建它的营销活动存续更久。团队需要知道变更如何到达目的地，以及当变更未到达时由谁负责这项工作。

Databricks CustomerLake，即 Agentic CDP，将客户数据平台能力原生引入 Databricks 及其治理基础。从这个共享基础出发，营销和数据团队有了一个共享可信客户上下文的地方。

就以下事项达成一致：每个决策的权威来源、允许的用途，以及目的地更新的负责人。

行动项：让一项协议在单个营销活动之外也有用

对于在 Databricks 上构建的团队，下一步是让这些关键协议可复用。团队可以在 Unity Catalog 中记录业务定义，然后在 Genie 中使其可被发现以用于分析，在 CustomerLake 中用于受众构建，或在 ML 模型开发中使用。每个新的营销活动都可以建立在营销和数据工程已经达成一致并付诸实践的定义之上。

选择一个在最近一次营销活动中引起混淆的术语。与你的数据团队一起处理一个客户示例，然后将决定记录在下一个使用数据的人能够找到的地方。

对于“客户”，这意味着命名一条记录代表什么以及其背后的标识符。对于“最后购买日期”，这意味着记录哪些交易计入。对于“受众就绪”，这意味着就发布前必须检查什么达成一致。

将商定的含义与实现它的数据集或工作流连接起来，并确定当它变更时谁应参与。文档和实现需要共同演进。

随着营销人员要求自然语言工具和 AI 代理处理客户数据，这一点变得尤为有用。“找出我们最有价值的流失客户”在价值、不活跃、身份和许可方面仍然留有模糊空间。没有明确的指令，AI 将自行做出决定——但每次都是不同的决定。给 AI 工具明确的业务定义和上下文将产生更好、更一致的结果。

一个有用的测试是，加入下一个营销活动的人是否能在不找到参加原始会议的人的情况下了解决定。如果他们能做到，团队就创造出了可以复用的东西。

关于本系列

帮助营销人员与数据工程沟通 是一个六部分系列，与 MartechTherapy 的 Matthew Niederberger 合作开发。本文中的 24 个定义转载自他独立制作的指南，由 Databricks 赞助。

阅读 Matthew 的原始文章，同一个词，不同的含义，了解他的观点以及可打印的参考资料，以便带入你的下一次会议。

本系列的下一篇：如何撰写一份别人可以据此采取行动的数据请求。