CDP是数据中台，以用户数据为核心的，具有很强的业务属性，面向用户运营的场景。下面这篇文章是笔者分享的关于CDP的相关内容，对此内容感兴趣的同学接着往下看叭！
从CRM到DMP，再到CDP的横空出世，数据产品领域推陈出新的速度也挺快。
而了解CDP的人可能会说，CDP和BI一样，糅杂了太多东西，都不知道如何概括。在我看来，CDP也是一个看似简单，但是需要借助数据平台的各种能力，将企业的数据资产深度挖掘出来的工具。
当中会涉及到数据的集成和加工，包含对埋点、数据仓库的数据重定义和应用。包含标签开发管理、人群创建、人群同步等。
会基于数据底层提供的查询服务，对埋点、数仓数据做深度的自定义探索查询，此处会跟数据可视化做深度的结合，包含对个体、群体的整体性（关键指标）的洞察和精细分析（各种维度、事件跟踪的分析)，将数据做多维度的可视化呈现。
也会涉及到数据同步和数据服务：加工好的标签和人群，也会基于数据同步服务对外提供数据，以便能对群体做策略；使用高低QPS搭配的数据服务对外提供及时的用户身份信息服务，以便做出相关策略；
而为了维持系统的运转和安全，还会设计到资产（标签、人群、数据集）的权限管控，以及底层对应用层的支持（血缘分析、开发任务智能化调度、预警监控）高阶的功能模块，还会跟算法、策略等开发系统打通，以便快速落地某些算法策略。
总而言之，CDP看似简单，实则是各种底层功能的集大成者，起到承上启下、打通底层系统和业务应用的关键作用。因为CDP的内容庞杂，所以本系列会分为多篇来讲解，敬请期待~
本文正文约7000字，预计阅读时间19分钟。
先来个问题，CDP是的英文，到底是哪个？Customer Data Platform，还是Client Data Platform？
初入行业，我对这个名称细节不以为意，没必要如此地咬文嚼字。到真正成为从业者，看的行业和竞品多了，我逐渐体会用词的细微差异，这体现出来的是服务对象特征的差异：toB vs toC。
一般来说，传统行业常用「客户」，而互联网尤其是消费互联网，则更多使用「用户」或者「消费者」这两个词。
所谓的传统和互联网企业，核心差异点在业务的开展是集中在线上还是线下，在收集、管理、分发、应用数据的方式和数据介入业务的程度都不同，侧重点上会有区别。
有了名字，那一般还会给名称做详细的注解，也就是「定义」。可能你在其他书里看过 CDP 定义，或许你深表赞同，或许你持保留意见。
单地从概念、名词角度进行区分，也始终都只是在抽象的世界里绕来绕去。以前刚做数据仓库时，时常背诵其特点：它是面向主题的，集成的、稳定的、时变的数据集合，面向数据分析，用以支持管理决策。
而经历了多个数据仓库实战项目后，这些定义反倒记不得了，需要专门翻资料才能列齐，但这些定义已经溶解在了更加具象化的案例中了。然后归纳总结，形成自己的理解。一千个观众有一千个哈姆雷特，百闻不如一见，最终还需要自己亲身去体会。
与其背诵定义，不如多看案例，带着定义上路去实践，在实践中归纳总结并形成自己的理解，你会感知到【定义是事实的切片，是特征的提炼】。
初学者有三种方式构建自己对新概念、新知识的理解。
作为 CDP 领域的从业者，给大家分享一些参考过的信息。
当从厂商的角度去调研CDP的发展历史、现状，发现多数数字化厂家都有有底层的数据开发治理运营平台，但是不一定都推出了CDP平台。
1) 先看国内的
再看看其他知名数据供应商的产品。
2) 再看看国外的产品介绍和文章
SAP：https://www.sap.com/products/crm/customer-data-platform.html
Enterprise-wide customer insights help you elevate customer engagement to increase conversion and strengthen retention.
From individual consumers to multiple business accounts, customers demand relevant, personalized engagements. With SAP Customer Data Platform, you can surface insights in real time across the enterprise to deliver winning engagements, boost revenue, and drive growth.
salesforce：https://www.salesforce.com/resources/guides/getting-started-with-a-customer-data-platform/
当然，你也可以看很多官方平台上发布的文章和介绍
微软：https://dynamics.microsoft.com/en-us/ai/customer-insights/what-is-a-cdp/
看了这么多厂商对CDP的定义，你有什么感觉呢？
最开始，我个人是从中台的角度去理解CDP的，我认为CDP是包含了数据集成、任务开发、模型构建、洞察分析、结果输出的自动化精准运营平台。这样说，好像跟很多数据中台的定义相似呢。
透过上文提及的竞品和文章，咱们会发现 CDP 的有关键词：营销、洞察。看完众多竞品，以及在企业实战后，我看CDP的视野，也逐渐从关注底层的数据集成、任务开发，慢慢转变到上层的业务分析、营销触达、效果分析。
作为一个数据平台，最终的价值还是融入到企业的价值链条里，所以，CDP的关键落脚点就是：营销系统。为了显得厉害一些可以再加一个定语，智能营销系统。
如果非要给CDP一个的定义，以终为始，我所给出的定义是：
在这里，我们就不讲谁首先提出来CDP了，估计也记不住。不管是谁提出来CDP的概念，CDP的出现，势必是要解决企业以及企业用户所面临的挑战。
当企业服务用户达到一定规模，面临的问题是类似的，而当下，我们又面临什么样的问题呢。
1）外部需求侧
消费者的娱乐、消费习惯都迁移到线上，需求的选项丰富多样式、需求更加容易满足，那么用户的变化也是非常快速的，一句话概括就是：海量用户需求个性化且快速变化的需求需要及时洞察和满足。
2）内部供给侧
企业需要自动化、智能系统有效地辅助记录、洞察、及时响应这些用户（客户）需求
3）整体环境
充分竞争的环境里，细分市场有新的机会后，大型、新型创业公司会快速跟进，有的会做资本方面的竞争。比如，烧钱抢占市场。随着市场格局基本尘埃落定后，企业需要更加精准化的运营，提高自己的差异化定位。
在初接触CDP系统时，虽然总把”为业务同事提供数据价值”挂在嘴边，但对于CDP产品的目标用户，我的第一反应还是：拥有技术背景的工程师、分析师。
或许是因为做技术出身，对技术充满敬畏，反正局限了我的视野和规划。正因为了解技术，所以总觉得数据的使用是有门槛的，必须能迈过门槛，才能发挥价值。而不知道，将技术语言翻译成业务语言才能让技术走进千家万户。
随着互联网公司的发展，一些企业要求数据驱动、快速迭代、信息快速流转，不少非技术岗位的员工也被要求具备数据素养，要有数据驱动意识，对数据有敏感度，能基于数据洞察做决策，同时，一些基础岗位的员工被要求掌握一些基础的技术，比如写SQL取数等。
所以，任何需要基于数据做决策的人，都应该是这个系统的用户。只不过，大家的技能点、关注点不同，对于数据的认知、操作的熟练度不同，最终在看数、用数的场景中需求有细微的不同。
在规划CDP系统时，要在技术、业务的用数场景中，找到受众覆盖面最大的点，然后设计产品流程和交互细节。
在推广和落地CDP系统，还要注意岗位职责划分、工作流&协作流程的优化，如果用数的业务角色习惯等待数据分析师产出数据分析结果，那么系统效果会大打折扣。具体价值如何量化，我们后面再讲。
对于定义、定位、发展有简单的了解之后，我们就可以尝试去基于需求构建我们的架构了。在画架构图之前，我们从场景和问题出发，并梳理问题之间的逻辑关系，这块，我先进行文字进行阐述。
企业的经营，离不开数据分析，哪怕是在刀耕火种的年代，人们也会手打算盘把账目梳理清楚。
所以，CDP必然包含分析模块。
但分析不是目的，是设定目标、达成目标的过程和手段。分析完数据后，经营者会提出假设，然后采取行动对假设做验证。比如，发现客流、流量减少了，那么可能要做一些广告活动吸引消费者，再比如，成本高了，要引入新的更有竞争力的供应商降低成本。
所以，CDP系统最终也要支持的营销和触达。
有的企业规划的CDP比较庞大，会包含营销触达的模块，比如短信、Push等。但一般来说，系统也不能太庞大，降低系统之间的耦合度，切分成不同的系统会更加灵活，所以有的企业会将这些模块独立出来，单独做个平行的系统，包含营销、流量策略等系统。
对于很多用户来说，使用底层表数据自己分析非常困难，所以我们会构建标签体系、人群画像等，为了高效建设和管理这些业务层关注的数据资产。
所以，CDP中还会包含综合服务管理后台。
在这个平台中，除了管理标签和人群，同时，也要做一些基础的权限开放和管控。
标签系统，就像堆乐高。完全靠不懂技术、不懂业务、不懂分析的用户自己发挥去洞察用户画像，很难。标签系统提供一些模板，快捷地参照教程，就能构建出人群和画像，并且售卖。
以上，核心业务环节的的架构基本有了，那还缺什么吗？
实际当中，还需要更加底层的数据平台支撑，也就是开发治理运维管理平台管理，后文会细讲。
1）整体逻辑
系统整体的模块，已经描述出来了：
2）整体逻辑拆解
我们再对当中的细节进行一定的拆解和补充。
分析当中，我们会对个体和群体进行分析，会基于实时、离线数据进行分析，会对行为过程和行为结果进行分析，分析的形式我们会用报表、图形等方式进行呈现，提高信息识别效率。
触达模块，会包含主动通知和规则匹配。
比如，主动圈选一批达到某些条件（如，新增用户、回流用户、近N天有消费用户等）的用户进行主动触达，方式包括发送短信、发送通知栏消息、发送横幅提醒、站内信等。同时也会包含规则匹配。系统基于各种策略（今天是否观看、当下是否有待支付订单）给用户进行更加及时的消息通知和内容推荐。
在综合服务管理后台，核心是给用户提供更加便捷的分析触达方式。虽然业务人员掌握了数据分析的技巧，但是处理大量的数据依然是一个精细化但是有点乏味的事情，如果花费过多的精力在技术细节上，那就成了技术人员了。
每个大的模块，又可以细分，具体这些模块，由什么系统来承担，每家企业都可以单独计划。
比如，分析模块是叫做BI商业智能，还是叫做行为分析、用户分析，或者两者都涵盖，其实无所谓。触达模块是叫流量策略、还是叫广告营销系统，也无所谓。
外层的开发治理运维管理平台，是叫数据中台还是叫治理套件也都无所谓。
3）模块和对应的人员角色
最后，我们再加入人员。相比于后面会讲到的产品架构图，我想通过这张图从一定抽象层侧上解释三个要点：谁（角色、岗位）、用什么（系统、模块）、做什么（功能点）
接下来，我们用大家常见的产品架构图来描述下系统的全局架构，系统的静态构成。一个重要前提：一张图不可能描述整个世界，总会有描述不出来、描述不当的地方。
前文的3个大模块，进一步细分成了5层：业务应用层、应用管理层、应用数据层、开发工具层、数据底座层。
1）分析和触达：业务应用层
该模块的核心是支持业务人员进行便捷的分析和洞察，分析洞察之后进行营销和触达，在应用层，就可以实现业务经营的PDCA的闭环。图中是对分析和营销触达进行了罗列，并不是非常严谨的分类，没有做到MECE（可能有些不太合理）
分析洞察，会包括三个层次：行业层、业务宏观层、业务细节层。
营销触达，会包含多种方式。图中列举的内容核心是想表达：企业经营过程中会通过各种方式、各种途径触达用户，进而促进企业关注的交易行为发生。
关于分析和触达，额外需了解3个概念：标签、人群（群体）、画像。
分析，我们会对个体和群体进行明细分析和统计分析，比如，分析高价值用户有哪些共性属性和共性行为，新用户转化为高价值用户会发生哪些关键高价值行为，这样可以制定策略对用户进行引导和干预。
这些行为特征、属性特征都是从数据加工而来，数据的信息量太大，标签的出现，就是将过量的信息进行简化，转译成业务场景的通用短术语，比如，高价值用户、高活用户、流失用户。
更多标签浅显化的介绍，可以看这篇：四千字全面解析数据产品经理必知概念：标签、维度、指标。
针对大客户，我们可以提供定制化服务，而针对大众，则需要批量的策略。所以，我们会圈选出来一些有共性的人群，做批量化的营销和触达策略。比如，批量给用户发活动通知短信、发送站内信、做内容推荐等。
2）综合服务管理后台：业务应用层、应用数据层
综合服务管理后台，分成了应用管理层和应用数据层。此模块的核心是为上层的业务应用做必要的后台建设和管理。
应用管理层中，涉及标签的创建、权限分配，人群权限的管控，画像中细节统计指标及所使用的标签权限管控。当对外提供服务时需要对接外部应用，所以也会有应用的注册、登记，也需要对服务应用的过程进行监控和管理。
应用数据层中，涉及标签、人群、画像、应用、服务等实体的元数据定义，核心是梳理这些抽象实体的属性、梳理实体之间的逻辑关系，为底层物理模型的构建奠定基础，梳理这些有利于早期规划时提高系统的扩展性和可维护性。
3）开发治理运维管理：开发工具层、数据底座层
该模块，可以简单地理解为数据中台。上层的分析、营销触达都需要基于底层数据，尤其是用户数据。
如果无法给CDP注入数据，那么CDP系统就是空架子。所以，底层的平台通常包括数据采集、数据加工处理，与其同时，要保证数据质量、保证数据能对外输出提供服务。
4）其他模块
一般来说，架构图整体是上下、左右排布，上层依赖下层，左右的部分，一般指的公共部分，以表示贯穿整个过程。
标签的建设、授权、应用，需要相关的流程规范来管理。而整个公司内部，也会维护相关的开发、治理规范，进而保证埋点、数仓、数据服务的规范性，后续再细讲，此处不展开。
这里，我们再基于火山引擎VeCDP的产品架构图来加深理解。
当一张架构图放在我们面前，我们要学会解读。初学者一下陷入细节的海洋，会没有头绪。
刚开始，我们可以粗看，看整体宏观结构。当只有细节时，我们可以主动对细节进行提炼和抽象，看懂一个，然后再看下一个，各个击破。
比如，火山CDP的产品结构图可以分为两个大的部分：数据准备、数据应用。
1）数据准备阶段
这部分跟数据中台、数据仓库的数据集成相同，要将企业的各种公域、私域数据（业务、订单、属性、行为数据）进行采集和统一存储。
如果拆得更细，会涉及到行为/埋点数据的上报和处理，如果上报量比较大，还涉及到一些边缘计算分担计算压力，另一面，也会涉及到业务结果数据（主从数据库、存储集群）的同步，以实时处理（流处理）、离线处理（批处理）的方式进行同步和计算。
各种业务数据经由采集后，原始数据要存储在数据层；再基于未来的分析需求，提前对当中的数据进行预处理处理，进入到汇聚层、整合层。当中还包含非常多的细节，比如，划分业务过程，基于分析需要去构建数仓的维度模型，构建不同粒度的事实表（经常也被称为宽表）。因为架构图的版图有限，也没法对这块进行非常详细的展开。
为什么这个图里还有统一档案层呢？
这里是用One Profile的概念进行解释的，也就是每个实体（不管是用户，还是移动设备、主播、直播间、商品等）都可以被打上唯一的标签。
底层已经构建了数据仓库，但是从数仓表还是有使用门槛，对于业务人员来说取数据很难，想象一下：把你一下子丢进物流公司的总仓库找双十一的订单，咱们是不是会晕头转向呢？
所以，我们要要进一步加工成标签，并且能以非常友好的方式让业务同事们使用。
2）数据应用阶段
然后基于这些标签进行应用，应用的场景包括利用标签进行群体圈选，然后对这些群体进行分析和洞察，最终进行营销和触达。
而所谓的场景层，是指基于这些标签、人群能在哪些场景里进行详细的应用，比如人货匹配、用户流失预警，架构图一般都只是对场景进行汇总和列举，并不代表全部的细分场景。
至于行业层，这是典型的SaaS型产品的自我营销和介绍模块了，也就是能在哪些行业落地和应用，吸引目标客户进行尝试。
以上，感谢阅读~
专栏作家
Lee，公众号：数据产品小lee，人人都是产品经理专栏作家。关注直播、短视频和文娱领域、擅长数据架构、CDP及数据治理相关工作。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。