CDP 与 CRM 数据整合架构图，展示如何连接不同数据来源、形成统一档案并激活业务应用。

CDP + CRM 数据整合架构设计

客户关系管理（CRM）, Salesforce

2026年9月4日

很多企业的 CRM 已有客户及商机数据，但网站、App、电商、服务和营销互动仍分散在其他平台。同一个人可能出现多个身份，前线看到的记录亦不完整。CDP + CRM 数据整合架构的目的，是在保留系统责任的同时连结身份、统一分析及把可用洞察送回业务流程。LeadsTech 在设计这类架构时，会先厘清每项数据的来源主权、更新责任和使用情境，才安排身份连结与激活，避免统一 Profile 变成另一个难以维护的数据孤岛。

1. 本文重点精华（TL;DR）

CRM 主要支援销售与服务的营运记录；CDP 负责跨来源收集、标准化、身份连结、分群及激活，两者互补而非取代。
架构应明确划分来源、Ingestion、数据模型、Identity Resolution、Unified Profile 及 Activation 层。
Unified Profile 是连结来源记录的参考视图，不代表必须覆写每个来源系统的数据。
整合成效要同时监察数据新鲜度、身份配对、同意控制、激活成功率及实际业务使用。

2. CDP 与 CRM 在架构中分别负责甚么？

CRM 是销售、服务或客户成功团队处理工作的 System of Engagement，保存 Account、Contact、Lead、Opportunity、Case、活动及负责人等营运数据。CDP 则汇入已知与匿名数据，将不同格式映射到共同模型，连结身份、计算洞察、建立 Audience，再向营销、网站、广告、分析或 CRM 激活。

两者的边界需要以用例决定。例如客户的正式合约状态由 CRM 或 ERP 管理，网站浏览和 App 行为由数字平台产生；CDP 可以把这些讯号连结到统一 Profile，但不应无条件改写正式主档。企业要为每个重要字段定义来源系统、数据拥有人、更新方向、频率与冲突规则。

3. CDP + CRM 数据整合架构包含哪些层？

可把架构分为五层：Sources、Ingestion、Identity、Profiles 及 Activation。这种分层让团队先处理数据责任，再选择 Connector、API、Batch 或 Streaming 技术，避免从工具开始倒推需求。

Data Integration Layers 深色架构图，展示来源、数据汇入、身份连结、统一 Profile 及激活五层关系。

1. Sources 与 Ingestion

先建立数据目录，列出 CRM、ERP、网站、App、POS、Call Centre、Loyalty 及营销平台的物件、字段、识别码、数据量、更新频率与敏感级别。只有需要支援已定义用例的字段才进入首期，降低成本与治理复杂度。

2. Mapping 与标准数据模型

不同来源对姓名、电话、地址、产品、Consent 及交易的定义可能不同。数据要先正规化并映射到共同模型；错误的型别、时区、代码或必要字段映射，会直接影响身份配对和 Audience 准确度。

3. Identity、Insights 与 Activation

Identity Resolution 依 Match Rules 连结可能属于同一个人或公司的来源记录，再按 Reconciliation 或用途选择展示值。其后才能计算价值、最近互动、偏好或资格，并将 Segment、洞察或 Data Action 传至下游。

4. Identity Resolution 与数据主权如何设计？

身份规则应由高确定性识别码开始，例如登入 ID、会员编号或经验证电邮，再按需要加入标准化电话、姓名和地址。规则过松会把两个人错误合并，过严则无法连结同一客户。企业应用测试样本量度 false positive、false negative、合并率及无法配对原因。

Unified Profile 不等于把所有来源合成一笔永久「Golden Record」。更实际的做法，是保留每个 Source Record 的键，按不同用途选择可信数据。例如服务团队使用 CRM 中经确认的联系电话，营销则依最新有效 Consent 决定是否可联系。任何回写都要列明方向、字段、触发条件、审计及复原方法。

Data Governance Loop 暖色图解，整理数据拥有权、身份规则、同意、数据品质与监察的持续治理循环。

5. 如何把统一 Profile 激活至 CRM？

激活前先回答 CRM 用户需要甚么行动，而不是把所有 CDP 字段塞进页面。可把客户分群、价值级别、最近重要互动、下一步建议或高意向讯号送到 Contact、Lead、Account 或 Case 附近，并设定清楚的更新时间和解释文字。若洞察不能改变优先次序、回复或服务决定，便未必值得回写。

假设一家跨境零售企业的电商、门店会员与客服数据分开。CDP 先以会员编号、已验证电邮及电话连结身份，再计算最近购买与服务风险。CRM 只接收供客服使用的会员级别、最近订单摘要及需跟进标记，不覆写交易主档。团队追踪身份配对率、数据延迟、客服采用率、转派次数及解决时间，确认整合是否真正改善工作。

6. CDP + CRM 整合检查清单

是否已有清楚用例、用户、触发行动及成功指标？
每个来源、字段、识别码、数据拥有人与敏感级别是否有目录？
System of Record、更新方向、频率和冲突规则是否明确？
数据映射、型别、时区、代码及必要字段是否经样本验证？
Match Rules 是否量度错误合并及漏配风险？
Consent、Purpose、Retention 及数据存取是否能被执行与审计？
Activation 是否只送出业务真正会使用的字段与讯号？
整合错误、延迟、成本及数据品质是否有监察与负责人？

7. 如何衡量数据整合成效？

技术层可追踪数据流成功率、延迟、字段完整率、重复率、身份配对率、错误合并抽查与 Activation 成功率。营运层则看 CRM 用户是否查看及采用洞察、Lead 分派是否更准确、服务人员是否减少切换系统，以及 Campaign、商机或案件流程是否缩短。没有下游行动的 Profile 数量不应单独当作成功。

8. 常见问题（FAQ）

已有 CRM，为甚么还需要 CDP？

当客户行为分散于 CRM 以外、需要连结匿名与已知身份、跨渠道分群或近实时激活时，CDP 才能补足 CRM；若数据来源少且用例简单，未必需要。

CDP 可以取代 CRM 吗？

通常不可以。CDP 侧重数据统一、分析及激活，CRM 则管理销售与服务流程、负责人及互动记录。

整合一定要实时吗？

不一定。客户正在浏览时的个性化可能需要实时，日常报表或低频跟进可用批次；频率应由业务时效与成本共同决定。

Identity Resolution 如何避免错误合并？

从可靠识别码与严格规则开始，以真实样本测试，再逐步增加模糊配对；同时保留来源键、审计结果及拆分处理。

哪些数据适合送回 CRM？

适合回写能改变销售或服务行动、定义清楚且更新可控的洞察；高频事件明细通常留在 CDP 或分析层，以摘要方式提供。

9. 结语

CDP + CRM 数据整合架构设计的核心，是让数据在正确的系统保留责任，同时为客户建立可用的统一参考。企业应从少量高价值用例开始，先验证身份、同意、数据品质及下游行动，再扩大来源与激活范围。若你希望规划 Customer 360、身份规则或 CRM 激活流程，欢迎 Contact Us，亦可了解 LeadsTech 的 Salesforce Data Cloud 解决方案。