精通 Salesforce Audience Builder：数据工程师视角下的 Data Cloud 受众细分指南

背景与应用场景

作为一名 Salesforce 数据工程师，我们工作的核心是构建坚实、可靠且可扩展的数据基础，以驱动业务决策和个性化客户体验。在市场营销领域，Audience Builder 是一个历史悠久且广为人知的术语，它最初在 Marketing Cloud Engagement (前身为 ExactTarget) 中扮演着关键角色，允许市场营销人员通过图形化界面从 Data Extensions (数据扩展) 中筛选和创建目标受众列表。

然而，随着客户数据的爆炸式增长和来源的多样化（CRM、电商平台、移动应用、Web 日志、服务中心等），传统的 Audience Builder 面临着严峻的挑战。数据被困在各个“孤岛”中，难以形成统一的客户视图。市场人员需要依赖 IT 或数据团队编写复杂的 SQL 查询来关联数据，这不仅效率低下，而且无法实时响应市场变化。这正是 Salesforce Data Cloud (原名 Salesforce CDP) 应运而生的原因。Data Cloud 不仅仅是 Audience Builder 的升级，它是一个根本性的范式转变，为受众构建提供了前所未有的强大动力。

从数据工程师的视角来看，Data Cloud 是我们施展才华的核心平台。我们不再仅仅是数据的“搬运工”，而是整个客户数据战略的构建者。我们的任务是：

  • 数据集成与建模：设计并实施从各种数据源到 Data Cloud 的 Data Streams (数据流)，并将这些原始数据映射到标准化的 Cloud Information Model (CIM) (云信息模型)，构建成统一的 Data Model Objects (DMOs) (数据模型对象)。
  • 身份解析：配置和优化 Identity Resolution (身份解析) 规则，将来自不同渠道的匿名和已知用户数据整合，生成一个黄金标准的 Unified Individual (统一身份) 客户档案。
  • 数据洞察增强：通过创建 Calculated Insights (计算见解)，将复杂的业务逻辑（如客户生命周期价值 LTV、购买频率 RFM 模型等）预计算并附加到统一身份上，从而极大地简化和增强后续的受众细分能力。

在此基础上，市场营销团队便可以在 Data Cloud 强大的可视化Segmentation (细分) 画布上，轻松拖拽各种属性，创建出极其复杂和精准的受众。例如，我们可以轻松构建以下场景的受众：

  • “过去90天内消费超过500美元，并且浏览过‘高端吸尘器’品类页面，但从未购买，同时在过去30天内没有提交过服务个案的白金会员。”
  • “所有放弃购物车的用户，但排除掉在过去24小时内已经通过其他渠道完成购买的用户。”
  • “识别出流失风险高的客户群体：连续6个月没有购买行为，但最近7天内频繁访问帮助中心页面的用户。”

这些在过去需要数小时甚至数天编写和调试 SQL 的复杂场景，如今在 Data Cloud 中可以分钟级完成。而这一切的背后，都离不开数据工程师构建的坚实数据地基。

原理说明

要理解 Data Cloud 如何赋能新一代的 Audience Builder，我们必须深入其核心工作原理。这可以分为四个关键阶段，每个阶段都与数据工程师的职责息息相关。

1. 数据摄入与建模 (Ingestion & Modeling)

一切始于数据。Data Cloud 通过 Data Streams 从多个来源摄入数据。这些来源可以是 Salesforce 的标准云（如 Sales Cloud, Service Cloud）、通过 MuleSoft 连接的外部系统、云存储（如 Amazon S3）、Web 和移动 SDKs 等。数据首先被加载到 Data Lake Objects (DLOs) (数据湖对象) 中，保留其原始格式。接着，数据工程师的核心工作之一就是将 DLOs 映射到 Data Model Objects (DMOs)。DMOs 是基于 CIM 标准化模型构建的，这确保了数据的一致性和互操作性。例如，来自不同系统的订单数据最终都会被映射到一个统一的“SalesOrder” DMO 中。

2. 身份解析 (Identity Resolution)

这是 Data Cloud 的“魔法”所在，也是区别于传统数据库的关键。一旦数据被建模，Identity Resolution Rulesets (身份解析规则集) 就会开始工作。数据工程师需要配置 Match Rules (匹配规则)，例如“精确匹配 Email 地址”或“模糊匹配姓名和邮政编码”，来识别指向同一个真实个体的多条记录。匹配成功后，Reconciliation Rules (协调规则) 会决定在构建 Unified Individual 统一身份时，当多个源的数据发生冲突时应采用哪个值（例如，使用“最近更新的”或“来源最可信的”电话号码）。这个过程的产出是一个包含了客户所有相关信息的、360度的统一视图。

3. 洞察计算 (Insight Calculation)

虽然市场人员可以直接在细分工具中使用 DMO 属性，但更强大的能力来自于 Calculated Insights (CIs)。作为数据工程师，我们可以使用 SQL 在 Data Cloud 内部定义 CIs。这些 CIs 可以是聚合指标（如 `Total_Lifetime_Value__c`）、复杂的业务标签（如 `Churn_Risk_Score__c`）或是转换后的维度。CIs 会被物化（materialized）并附加到统一身份或相关的 DMO 上。这样做的好处是双重的：首先，它将复杂的计算逻辑与最终的细分操作解耦，让市场人员无需理解背后的 SQL；其次，由于结果是预计算的，细分查询的性能会得到极大的提升。

4. 细分与激活 (Segmentation & Activation)

这是价值实现的最后一步。用户在 Data Cloud 的可视化Segmentation Canvas (细分画布) 上，通过拖拽属性来定义受众规则。这些属性可以来自 Unified Individual DMO、任何关联的 DMO，以及我们数据工程师创建的 Calculated Insights。当用户点击“发布”时，Data Cloud 的引擎会高效地查询数以亿计的记录，并生成最终的受众列表。随后，这个受众可以通过 Activation Targets (激活目标) 推送到下游系统，例如 Marketing Cloud Engagement 的一个 Data Extension、广告平台（如 Google Ads, Meta）的自定义受众列表，或者更新回 Sales Cloud 的一个 Campaign Member 记录。

示例代码

作为数据工程师，我们常常需要通过 API 以编程方式管理 Data Cloud 的元数据，例如创建或更新一个 Calculated Insight。这在自动化部署 (CI/CD) 或批量处理复杂业务逻辑时非常有用。以下示例展示了如何使用 Connect API 来创建一个 Calculated Insight，该 Insight 用于计算每个客户的总消费金额 (Total Lifetime Value)。

注意：这是一个通过 REST API 创建元数据的示例。你需要一个有效的 access token 和正确的 Data Cloud 实例 URL。

POST /api/v1/calculated-insights

{
  "name": "TotalLifetimeValue",
  "label": "Total Lifetime Value",
  "description": "Calculates the total lifetime spend for each individual.",
  "status": "Active",
  "query": "SELECT Individual.Id AS IndividualId, SUM(ssot.SalesOrder.GrandTotalAmount) AS Total_LTV__c FROM Individual INNER JOIN ssot.SalesOrder ON Individual.Id = ssot.SalesOrder.IndividualId GROUP BY Individual.Id",
  "dimensions": [
    {
      "name": "IndividualId",
      "dataType": "Id",
      "label": "Individual ID"
    }
  ],
  "measures": [
    {
      "name": "Total_LTV__c",
      "dataType": "Number",
      "label": "Total LTV",
      "aggregation": "SUM",
      "precision": 18,
      "scale": 2
    }
  ],
  "objectCategory": "Profile",
  "joinKey": "IndividualId"
}

代码注释：

  • name / label: 这是 Calculated Insight 的 API 名称和显示标签。
  • status: 设置为 "Active" 以便在细分和其他地方可用。
  • query: 这是核心的 SQL 查询。它从 `Individual` DMO 和 `ssot.SalesOrder` DMO (ssot 是命名空间) 中查询数据，通过 `IndividualId` 进行关联，并按 `IndividualId` 分组计算每个人的总消费金额 (`GrandTotalAmount`)。
  • dimensions: 定义查询结果中的维度字段。在这里是 `IndividualId`，它将作为关联到统一身份的键。
  • measures: 定义查询结果中的度量字段。`Total_LTV__c` 是我们计算出的指标，我们定义了它的数据类型、精度和小数位数。
  • objectCategory: 指定这个 CI 是附加到 `Profile` (即 Unified Individual) 还是其他 DMO 类别。
  • joinKey: 指定使用哪个维度字段 (`IndividualId`) 将这个 CI 的结果关联回 `objectCategory` 中定义的对象。

通过 API 提交这个 JSON payload 后，Data Cloud 会验证并创建这个 Calculated Insight。一旦处理完成，市场营销人员在细分工具中就可以直接拖拽一个名为“Total LTV”的指标来筛选客户了，例如“Total LTV 大于 1000”。

注意事项

作为数据工程师，在实施和维护 Data Cloud 以支持受众构建时，必须关注以下关键点：

1. 权限与治理

确保遵循最小权限原则。Data Cloud Admin 权限集拥有最高权限。对于日常管理，应该创建自定义权限集，精细控制谁可以创建 Data Streams，谁可以修改 Data Model，谁可以定义 Identity Resolution 规则，以及谁可以创建和激活 Segments。

2. API 限制与配额

Data Cloud 的所有 API，包括 Ingestion API 和 Connect API，都有严格的速率限制和每日配额。在设计数据管道时，必须考虑这些限制，实施批量处理、错误重试和指数退避机制，以避免被限流。特别是在进行大规模历史数据回溯时，要提前规划好摄入策略。

3. 数据新鲜度与延迟

理解不同数据流的刷新频率至关重要。通过 Salesforce Connector 连接的数据可以实现近乎实时同步，而通过 S3 批量导入的数据则可能有数小时的延迟。这直接影响了受众的时效性。你需要向业务方明确说明数据延迟，并根据业务需求选择最合适的集成方式。

4. 细分性能

虽然 Data Cloud 性能强大，但不良的细分设计仍然可能导致性能问题。避免在细分规则中使用过多的“OR”条件和复杂的嵌套逻辑。优先使用预计算好的 Calculated Insights，而不是在细分时进行实时复杂计算。例如，与其在细分中计算“A+B>C”，不如创建一个CI来预计算这个结果，然后在细分中直接筛选“CI_Result = true”。

5. 身份解析的准确性

身份解析是所有工作的基础，也是最容易出错的地方。过度宽松的匹配规则会导致将不同的人合并成一个身份（过度合并），而过度严格的规则则无法将同一个人在不同系统中的记录关联起来（合并不足）。必须与业务团队紧密合作，定义清晰的规则，并定期审查和抽样验证统一身份的质量。

总结与最佳实践

对于 Salesforce 数据工程师而言，Audience Builder 的概念已经从 Marketing Cloud 的一个具体功能，演变为 Data Cloud 中以数据为核心、以统一身份为基础的战略性能力。我们不再是营销活动的被动支持者，而是个性化客户旅程的架构师。

要在这个新范式中取得成功，以下最佳实践至关重要：

  1. 拥抱 CIM 模型：不要试图重新发明轮子。尽可能将你的源数据映射到标准的 Cloud Information Model。这不仅能加速实施，还能确保你的数据模型能够无缝利用 Salesforce 未来的创新。
  2. 迭代式身份解析：不要追求一次性完美的身份解析规则。从最可靠的规则（如精确匹配电子邮件）开始，逐步增加更复杂的规则，并在每个阶段进行充分的测试和验证。
  3. 将业务逻辑沉淀到 Calculated Insights：将可复用的、复杂的业务逻辑封装在 Calculated Insights 中。这不仅能赋能业务用户，还能提高系统性能，并确保业务逻辑的一致性。
  4. 建立数据质量监控：为你的 Data Streams 建立监控和警报机制。数据源的任何问题（如格式变更、数据丢失）都应被及时发现，以免污染下游的身份和受众数据。
  5. 跨团队协作：与市场营销、销售、服务和分析团队保持紧密沟通。理解他们的业务目标，是构建真正有价值的数据产品（无论是统一身份还是精准受众）的唯一途径。

最终，Data Cloud 平台上的受众构建工作，其价值不仅仅是创建了一个列表，更是通过可靠、全面、实时的数据，在客户与品牌之间建立起一座座精准沟通的桥梁。而我们数据工程师，正是这些桥梁的奠基人。

评论

发表评论

此博客中的热门博文

Salesforce 登录取证：深入解析用户访问监控与安全

背景与应用场景 在当今的数字化环境中，企业信息安全至关重要。Salesforce 作为全球领先的 CRM 平台，存储着企业最核心的客户数据、销售记录和商业机密。因此，对 Salesforce 组织的访问控制和监控是安全体系中不可或缺的一环。 Login Forensics（登录取证） 是一种通过分析用户登录数据来识别、调查和响应潜在安全威胁的过程。 无论是满足合规性要求（如 SOX、GDPR、HIPAA），还是主动防御内部威胁和外部攻击，登录取证都提供了关键的数据支持。其主要应用场景包括： 安全审计与合规： 向审计人员提供详细的用户登录记录，证明企业已实施适当的访问控制措施。 威胁检测： 识别异常登录行为，例如： 短时间内来自不同地理位置的登录尝试。 在非工作时间或节假日的登录。 来自已知恶意 IP 地址的访问。 特定用户的大量失败登录尝试，可能预示着密码暴力破解攻击。 故障排查： 帮助用户解决“无法登录”等问题，通过查看登录状态和失败原因快速定位问题。 用户行为分析： 了解用户如何以及何时访问 Salesforce，为优化用户体验和系统性能提供数据依据。 Salesforce 平台提供了强大的原生工具来支持登录取证，主要依赖于两个核心功能：标准的 LoginHistory 对象和更为高级的 Event Monitoring（事件监控） 。 原理说明 Salesforce 通过记录每一次用户登录尝试的详细信息，为登录取证提供了数据基础。根据需求和复杂度的不同，我们可以通过两种主要方式来访问这些数据。 1. LoginHistory SObject LoginHistory 是一个标准的 Salesforce 对象，用于存储组织过去 6 个月内的用户登录历史记录。它就像一个标准的“登录日志”，记录了每次登录尝试的基本信息。系统管理员或拥有“查看设置和配置”权限的用户可以通过 SOQL (Salesforce Object Query Language) 查询、报表或 API 来访问这些数据。 该对象包含的关键字段有： UserId...
阅读全文

Salesforce Experience Cloud 技术深度解析：构建社区站点 (Community Sites)

背景与应用场景 在数字化转型的浪潮中，企业 increasingly seek to build engaging online spaces to connect with their customers, partners, and employees. Salesforce Experience Cloud, formerly known as Community Cloud, is a powerful platform designed precisely for this purpose. It enables the rapid creation of branded, secure, and intelligent digital experiences, all built on the trusted Salesforce platform. 作为一名 Salesforce 技术架构师，理解 Experience Cloud 的核心能力与架构是设计可扩展、安全且高性能解决方案的关键。这些数字体验站点（通常仍被称为 Community Sites）不仅仅是简单的网站，它们是深入集成到企业 CRM 数据和业务流程中的动态门户。 常见的应用场景包括： 客户自助服务门户 (Customer Self-Service Portal): 客户可以在这里查找知识库文章、提交和跟踪支持个案 (Cases)、参与社区讨论，从而降低服务成本并提升客户满意度。 合作伙伴关系管理门户 (Partner Relationship Management Portal): 合作伙伴可以通过门户进行交易注册 (Deal Registration)、管理销售线索 (Leads) 和业务机会 (Opportunities)、获取营销资料，与企业实现无缝的销售协同。 员工社区 (Employee Community): 为员工提供一个集中的平台，用于获取公司信息、进行内部协作、访问人力资源系统等，增强员工归属感和工作效率。 这些门户的核心价值在于，它们将正确的数据和流程在正确的时间，安全地呈现在正确的用户面前。而这一切的实现，都依赖于其背后精巧的技术架构。 原理说明 要精通 Experience Cloud，我们必须深入理解其...
阅读全文

精通 Salesforce Email Studio：咨询顾问指南之 AMPscript 与数据扩展实现动态个性化邮件

背景与应用场景 作为一名 Salesforce 咨询顾问，我经常与各种规模的企业合作，他们共同的目标是提升客户参与度并最终推动业务增长。在数字营销领域，电子邮件仍然是与客户建立和维持关系最有效、最具成本效益的渠道之一。然而，如今的客户期望收到的不再是千篇一律的通用邮件，而是与他们个人兴趣、行为和需求高度相关的内容。这正是 Salesforce Marketing Cloud 中的 Email Studio 发挥关键作用的地方。 Email Studio 不仅仅是一个群发邮件的工具，它是一个强大的平台，能够通过深度个性化来创造卓越的客户体验。实现这种深度个性化的核心技术在于 AMPscript 和 Data Extensions (数据扩展) 的结合使用。脱离了这两个工具，邮件营销很容易退化为简单的广播，导致参与度下降和客户流失。 在我的咨询实践中，以下是一些最常见的应用场景，它们都依赖于 AMPscript 和 Data Extensions 来实现： 1. 欢迎系列邮件 (Welcome Series) 当新用户注册时，根据其注册来源（如：官网、社交媒体活动、线下门店）或提供的兴趣偏好，动态展示不同的欢迎语、产品推荐或入门指南。 2. 废弃购物车挽回 (Abandoned Cart Recovery) 电商企业最关键的自动化流程之一。通过 AMPscript 查询与订阅者关联的废弃购物车 Data Extension，邮件可以动态地展示被遗弃的具体商品图片、名称、价格，并提供一个直接返回购物车的链接。 3. 个性化产品推荐 (Personalized Product Recommendations) 根据客户的购买历史、浏览行为或会员等级，从一个庞大的产品目录 Data Extension 中动态抓取并展示最相关的产品，实现“千人千面”的推荐效果。 4. 基于地理位置的动态内容 (Geo-Targeted Content) 根据订阅者档案中存储的城市或邮政编码，在邮件中动态展示距离最近的门店地址、当地的促销活动或符合当地气候的产品。 5. 忠诚度计划状态更新 (Loyalty Program Updates) 在每月账单或营销邮件中，动态显示客户的当前...
阅读全文