数据平台CDP避坑指南

数据平台CDP避坑指南

前言：..........................................................................3

1.“入坑”CDP症状.............................................................3

1.1数据打通类...........................................................3

LL1症状一：明明接了很多系统数据源，为什么感觉好像白接了？.3

1.1.2症状二：人群画像为什么标签都是空的？很多用户信息都没有？

..................................................................4

1.1.3症状三：放了那么多数据，为什么CDP不能回答出正确的用户数

量？....................................................................4

L2数据分析类............................................................5

1.2.1症状四：规划设计了100多标签，结果用的时候总是要的没做，

做的没用，越用越多...................................................5

1.2.2症状五：隔壁埋点项目，怎么和CDP越来越像，是CDP做的不好？

还是埋点“卷”了CDP?..........................................6

1.2.3症状六：看上去CDP有很多分析功能，AIPL/5A/FAST/RISE...为

什么都用不起来？....................................................7

1.3数据应用.............................................................7

1.3.1症状七：都说CDP可以做模型，为什么自己的CDP连一个潜客模

型好像都做不到？....................................................7

1.3.2症状八：在CDP里面找人，怎么比在excel表里找数据还要复杂？

..................................................................8

1.3.3症状九：除了麻烦的找人，和没什么数据的画像，总挑战CDP有

什么业务价值？........................................................9

2.正确认识CDP...........................................................11

2.1CDP是数据，不是业务.................................................11

2.2CDP是工具，不是中台................................................12

2.3CDP以“人”为中心，不代表和“人”相关所有.....................13

2.4CDP是验证数据的起点，不是唯一点..................................14

2.5一方CDP和三方/二方产品的关系....................................14

3.如何走上CDP正轨..............................................................15

3.1做CDP之前需要回答的几个问题.....................................15

3.2实际落地实施CDP环节需要谨记的要点..............................16

3.3CDP项目上线收尾关键................................................17

前言:

6年前，如果一个公司说，有一个产品，能够帮助品牌打通数据孤

岛，让用户数据在广告投放、客户体验、产品定价优化、促销活动，

甚至非营销职能部门都能发挥数据价值，大概率你会认为这个产品特

别有吸引力，特别神奇，于是公司一定想尽快了解，快马加鞭的购买

部署。

就是CDP这样一个产品（或者叫方案），在中国从2016年到2022

年这6年间，在众多品牌和公司心里的变化过程，“好神奇”一“哪

都有”一“试一试”一“不一样”一“又一样”一“自己做”

一“做不出”一“请专家”一“定制化"一"四不像"，以上10

个心理不知道你们公司处于哪个阶段呢？

L“入坑”CDP症状

L1数据打通类

1.1.1症状一：明明接了很多系统数据源，为什么感觉好像白接了？

CDP需要的是描述人的数据，如果这个系统描述人的数据非常有限，例如

物流系统、门店管理、售后配件等，能提出来描述消费者的数据可能每个系统

只有那么1-2个关键动作。比如物流核心是包裹的状态，但描述人的数据是用

户查看过多少次物流信息，物流状态的更新本身不随用户行为发生变化，所以

即使对接了物流系统，CDP能用到的数据，最多就是用户对物流信息的查询和

订单操作，描述人的数据对CDP来说才是有用的数据。

不过即使是接了一个用户互动的触点，结果还是发现CDP里用户的行为数

据少之又少，例如车企留资最简单的落地页，或者银行信用卡申请最简单的留

资页，除了最后的留资记录和用户浏览什么都没有了，不仅留资记录不多，浏

览量也只是干巴巴的数字。

这种情况CDP不能背这个锅，如果用户不能在这个触点产生丰富

的有效互动，品牌设计的信息展示和互动都是纯纯自high,并不能引

导用户产生有价值的行为数据，例如刚才的汽车留资页，除了滑动长

长的产品介绍图和留资，用户已经没有什么动作了，那CDP能够获取

到其他有价值的信息么？所以触点的有效互动设计往往决定了触点有

价值行为数据的丰富程度。

1.1.2症状二：人群画像为什么标签都是空的？很多用户信息都没有？

分两种情况分析：一种是想了解用户的事实标签，例如男女、年龄、

职业这种。如果一个用户在你任何系统都没有留下这些信息，即使把全

公司数据都找遍了，也没有办法直接得出结论，这可能需要通过别的数

据信息来综合判断，例如称呼是先生/女士、工作地址、app定位等。但

这些信息的判断标准和规则，往往不是一两条能总结完的，所以如果要

基于其他信息来预测判断用户的事实标签，通常需要对每一个标签做一

套判断设计。复杂的说，一个标签一个模型；另一种情况是想了解用户

在你触点范围外的信息，例如喜欢什么IP等，这些信息在过去要么通

过从第三方数据源那里直接购买用户标签，当然现在这条路随着数据安

全和个保法的落地，已经没了。现在对这些信息的补全，需要通过在公

司业务所覆盖的触点范围内引导客户有所表达互动，基于表达互动在逐

一建模总结，总之标签的补足依靠的不是外部的输入，更多依赖对业务

范围内触点的用户引导运营。

1.1.3症状三：放了那么多数据，为什么CDP不能回答出正确的用户数

量？

能否在CDP准确回答用户数量，取决于在CDP里构建了一个什么样的one-

id,到底是实名的用户id是one-id,还是匿名+实名是one-id；匿名到是实名

的关键步骤摸清过么？从微信的uni-id、open-id到手机号、什么场景才能串联

起来？设备号在哪些渠道能获得，获得的是加密还是原值，有多少设备号？多少

加密方式，加密方式有没有有效期？现有系统里有没有用户中心？有没有系统能

够完成一个用户全盘从未注册到注册的id创建？用户id创建的逻辑是否支持

两个手机号同一个设备的注册？如果用手机号作为各个系统的用户id,那售后

的手机号和下订单的手机号不一样，怎么判断是不是一个人?

以上问题都不是单独依靠CDP来完成，都需要在构建CDP之前，通过业务系

统的整体设计和用户id的梳理提前完成。更重要的是，通过设计和运营，引导

用户完成其中匿名到实名的转换，也是这个问题的关键，如果抛开这样的运营引

导，即使有了用户中心这样的统一用户注册设计，CDP也”巧妇难为无米之炊"，

可以说用户中心是CDP的“硬件依赖”，继承用户中心构建匿名到实名one-id

的运营设计是“软件保障”，两个共同配合才是做能够让CDPone-id发挥价值。

1.2数据分析类

1.2.1症状四：规划设计了100多标签，结果用的时候总是要的没做，

做的没用，越用越多

先不论各个公司对标签的定义是什么，在你的系统里，标签是不

是这样的：

・有“近3天购买”的用户标签，也有“近30天购买”的各

种时间用户标签；

・有“购买XX系列”的用户标签，也有“购买YY系列”的穷

举商品的用户标签；

・有“退货失败”和“退货成功”这样成对的用户标签；

・甚至还有“活跃-用户运营”、“活跃-app”、“活跃-线索

运营”，这样不同业务不同部门不同时间定义的不同“活跃”

的用户标签；

当有100多个标签时，还勉强能找到，但随着业务发展，标签描

述的时间窗口不适用了、商品信息有变更了、业务状态有变化了等等

原因，这些标签都会被“打入冷宫”，做出更新的标签，删了怕哪天业

务要用，不删又越做越多，100多变成300多，甚至变成500多，等反

应过来想清理可能都是个巨大的工作。

究其原因还是因为对“标签”的理解太普世直接。举个例子，“近3天成

都车展留资”在很多公司可能是个标签，但其实是个人群包，这个人群包里包

含了很多要素、有时间、有地点、有业务动作，每个要素随着业务变化都会有

新需求，哪怕之变一个，可能都需要新做一个“标签”，所以正确的理解什么

是“标签”，什么是人群包，以及如何设计合理的标签，比一上来就做“标签”

更重要。

1.2.2症状五：隔壁埋点项目，怎么和CDP越来越像，是CDP做的不好？

还是埋点“卷”了CDP?

有没有发现，现在越来越多公司的CDP产品里，都在强调用户行

为事件，而这些行为事件不仅看上去非常“丰富”，而且覆盖的系统

越来越多，好像万物皆可埋点，打开app可以埋，看不看社区可以埋，

有没有点赞可以埋，有没有留资试驾也可以埋，甚至有没有创建订单

也可以埋，难道宇宙的“尽头”是埋点么？

其实埋点只对用户在系统触点上，对非业务结果的过程行为数据

补充，业务结果本身已经记录在了各个业务系统里，例如留资记录在

线索中心，订单结果在订单中心，点赞评论在社区数据库，他们本身

其实不需要埋点，过度相信和使用埋点采集，不仅会重复采集，还会

产生很多“看似有用”的用户“未完成”记录。例如用户点了提交，

但因为网络或者中断操作而没提交的记录，这些“未完成”记录看似

有用，但其实用全量用户去掉那些成功完成的，剩下的自然就是未完

成的，过多的埋点采集让用户客户端的上报数据从原本上报结果，变

成了上报一切，不仅流量暴增，能耗也暴增，卡顿在所难免。

所以埋点要适当，补全那些必要，但没有业务结果记录的过程数

据即可，例如：曝光日志、启动日志或者结果前的选择中间记录即可。

毕竟说到底埋点只是一个UBA（用户行为分析），这个Behavior指的

是单一触点的页面互动行为，解决的还是一个页面操作优化和流量分

析的问题，而CDP作为数据打通后的分析工具，应该抽样去解决跨端、

跨业务节点的全链路分析问题，业务使用CDP更关心多少人从注册变

成了活跃，变成了留资或者订单用户，而不是多少人注册后，在这个

页面停留了多少秒。如果要单独分析app设计和路径，这是埋点UBA

的场景，但分析全链路转化、跨端活跃等全局视角，才是CDP重点。

埋点的数据源只是CDP的源头之一，CDP更聚焦是各个触点的业务结

果，而不是每个触点的详细中间未完成过程。

1.2.3症状六：看上去CDP有很多分析功能，AIPL/5A/FAST/RISE...为

什么都用不起来？

不得不承认在当下中国的环境里，各大互联网平台掌握了消费者

丰富且海量的数据。各个平台，尤其是电商平台，在如何利用数据做

消费者运营和业务分析上有丰富的“土壤”，并且更具平台的特色，

有很多看上去很经典的指标和模型。

老生常谈，各个公司也都知道这样的指标模型可能不是全行业通

用，于是自己的CDP往往选择定制一个属于自己的“字母模型”，或

沿用、或继承、或扩展。但随着自身发展都会出现好像都不适用的情

况，究其原因，无非是忽略了自身业务所包含的用户数据基础和平台

用户数据基础的巨大差异。相比平台，公司自身业务形态的用户数据

不管是量级还是丰富程度都远远少于平台，如果只是在这些“字母模

型”的定义上，修改调整，盲目适配，是不可能反应自身业务状况的。

所以研究平台模型，不如根据自身业务绘制属于自己的用户生命周期,

可以是全业务的，也可以是单独某一个业务。对于生命周期中每个阶

段的描述，就利用最简单朴实的业务定义为其描述，回到业务根本，

以每个业务环节的核心指标来衡量分析转化的好坏，这才是对CDP中

数据价值的正确引导。

L3数据应用

L3.1症状七：都说CDP可以做模型，为什么自己的CDP连一个潜客模

型好像都做不到？

CDP里面确实有很多用户数据和标签，并且作为“建模”，这些

标签都是必要的一方特征。某些场景上，这些一方特征是有很高的挖

掘价值的，但注意这是某些场景。比如在存量用户中挖掘可能的潜客、

或者在保有客户中挖掘可能的增换购等，这些场景都有一个特点，就

是要找的目标人群在一方的业务范围内是拥有很多特征值得细细

“挖掘”。

也就是说，这些存量里的“潜在”客户，是有历史行为作为分析

依据的，但如果场景换一下，想对新注册的会员做一个购买潜客的预

测、对新的访客做一个可能下单的预测，这样的新用户预测场景，可

以说一方CDP里的数据，就不能发挥什么价值了。毕竟一个新会员/

新访客，除了贡献一个手机号/设备号和注册/访问渠道及时间其他什

么都贡献不了。

可能你会问，那我刚下载抖音，抖音不也会给我做很多猜我喜欢推荐么？

其实“推荐”或者准确的说，“实时推荐”和“潜客预测/潜客挖掘”，还是

两种不同的业务模式，这里不做特别详细的展开，简单说，“实时推荐”是通

过海量内容的不断学习了解，不断积累偏好模型的过程，是一个持续“养”的

方式；而“潜客预测/潜客挖掘”是一个by需求型的单次/多次定位输出的模

式，类似先找“靶子”再“开枪”，具体以后再做介绍。回到CDP的模型，给

个确诊的原因，CDP是给业务人员分析和直接应用的，建模是个算法技术活儿,

最好交给数据科学家。CDP的一方用户特征很有用，但场景更适用于存量客户

的“挖掘”，而不是纯新客的预测，至于结合二方/三方数据的联合/联邦建模,

下次可以再展开，存量客户的“挖掘”模型要做的好，丰富一方用户数据一定

是基础，这就又回到了在一方业务范畴内，多做用户运营，多设计有效互动，

多引导用户交互的运营问题。所以要想CDP模型做得好，一方运营就得跟上,

创造更多用户数据，才有在存量去“挖掘”的可能。

1.3.2症状八：在CDP里面找人，怎么比在excel表里找数据还要复杂？

有一个比较时髦的名字MarketingTechnology营销科学技术，简

称Martech,来形容CDP。所以一个技术产品在工具属性上必然有一

定的使用门槛，更何况这是图形化之后的数据分析工具，符合满足所

有数据分析的流程，即了解数据现状-》确定分析目的-》定位数据

对象-》维度下钻展开-》进一步了解数据的循环过程。

因此除了在CDP里“看”，动手去“找”，本质上在数据库里写

SQL定位数据是没有区别的，而现在市面上的CDP无非是将这个SQL

过程，通过图形化方式，做了低代码的产品形态包装。SQL当然比excel

更灵活，但门槛也比excel要高，所以操作CDP,尤其是操作CDP的

“圈人”这个核心功能，适当的数理逻辑是必须的。这里无非也是一

个帮助操作者，即业务人员，去理清思路的过程，因为“圈人”本质

就是在描述你的业务目标对象。

举个例子：业务想把去年双11的存量客户里，已经大半年不活

跃的捞出来做一波召回返厂，为双11预热，这里的对象描述就可以

拆解成：

・条件1：满足，去年10月20T1月11日内，在所有渠道，

创建了订单，这个行为的用户

・条件2：满足，最近半年，在所有渠道，创建了订单，这个

行为的用户

・条件1差掉（减去）条件2,取一个差集，这就简单的

得到了刚才的业务目标对象

上面这个操作里，从本质上是一个用户行为“创建订单”的不同

描述，是一条比较简单的SQL关联查询。但通过在CDP里不同描述的

逻辑组合，虽然没有实际写出SQL,但已经完成了数据定位。和操作

一个excel比，业务需要知道CDP里有什么用户行为标签，这些标签

是怎么描述用户的，基础的梳理逻辑“交、并、差”是什么意思，就

足够了。这当然对业务人员提出了一定的要求，但这也是数字营销大

时代下必备的技能。

1.3.3症状九：除了麻烦的找人，和没什么数据的画像，总挑战CDP有

什么业务价值？

确实要量化CDP的价值好像不能简单直接从销量、活跃、注册这

样的大指标上得出结论，但也要清楚认识到这些大指标的提升，应该

是一整套工具+运营动作的综合结果，把结果单纯归一到一个系统、或

者一个运营人员身上都是不科学不公平的。如果买一个系统就直接提

升销售和活跃，那卖系统的不就是在卖“智商税”的药方子么？

回到上面双11的例子，通过CDP找到目标用户只是这件事情的第

一步；第二步是了解这些用户为什么不活跃，回答这个问题可能通过

用户画像尝试看看有没有其他类似加购、留资、社区活跃这些统计，

也可以通过某个用户标签看看他们的购买评价都是什么分布或者反

馈评论关键词都是什么，当然也可以通过埋点这样的UBA产品，看看

这群人，在某个触点近半年的流量活跃情况是什么样，找到问题的初

步原因后；第三步，通过上一步的发现设计一个简单的运营方案，包

括用什么样的利益点、设计什么样的活动和落地页，在什么样的时间

频次上，通过什么渠道做用户触达；第四步是利用MA这样的营销工

具或者配合广告投放等，把上面的运营方案做一个落地，最后再回到

CDP里对这群对象做一个定向的转化分析。

很多公司在没有CDP之前总希望CDP+MA这两个工具组合能够贯

穿用户旅程的各个节点，一下子就打通形成一套完整的消费者运营或

者用户运营的模式，做完就可以交差了。但模式归模式，没有落地的

场景和结果，模式终究只是故事，这个故事用来内部立项可能还行，

但要让做CDP这件事情能够真的站起来了，一定需要聚焦这几个问题：

・谁是CDP+MA的第一批用户？

・第一批用户现在最重要/最需要的业务需求是什么？评价的

指标是什么？

・有CDP和没有CDP,能否在解决上述需求是有不一样？

如果上面这三个问题的答案都清晰了，那就确定了CDP及配套系

统的的一个验证业务场景，这个时候才是去针对场景规划运营方案，

以运营方案来指导系统建设和数据需求的正确步骤。

上面这些症状当然不能涵盖所有，但应该可以代表大部分公司在

“建设/使用/了解”CDP和相关方案时的很多典型疑问了，说到底，

产生这些疑问和症状的原因，是因为公司对CDP和相关方案没有一个

清晰正确的理解和认识，那如何客观的看待CDP呢？

2.正确认识CDP

2.1CDP是数据，不是业务

首先，必须要界定的是，CDP一定是一个数据分析产品，是数据分

析产品，那它就是业务产品ready之后，才有使用价值的，不能脱离

业务产品。

那什么是业务产品呢？简单说就是没了这个产品/系统，这个业务

就不能进行下去了，或者业务就不成立了，这就是业务产品。举个例

子，用户中心/CRM/会员中心/订单中心这些，都是业务产品，如果没

有用户中心的统一注册网关，用户的注册和用户id怎么生成？如果

没有CRM,线索如何进行收集和分发？如果没有会员中心，怎么确定

用户的等级和积分以及积分能做什么？如果没有订单中心，那订单又

改在哪里创建、流转和操作？所以发现了吗，业务产品/系统是能够源

源不断生产业务数据的，而CDP这样的产品，无非只是在回收/记录

数据，不会产生新的业务结果，因此就不能对CDP抱有业务系统的幻

想。例如，没有用户中心，希望CDP来完成全公司用户ID的生成，

那CDP是不是应该做一个生成队列，所有id的创建和请求都给CDP

来处理呢？这明显是把业务系统的功能放在了数据产品上。

同样，因为不是业务产品，那么这里没有“业务流程”的改造，

因为CDP不参与业务的处理和判断，不是业务正确与否的裁判员，用

户信息的正确性不是CDP说了算，而是业务系统说了算，CDP不过是

真实的记录还原了这个用户信息的结果以及结果的变化过程而已。

所以如果公司还没有和用户管理相关的业务产品，该还的债，还

是要还的，至于用户中心或者用户管理都应该做什么，或者公司销售

相关的业务产品之间怎么设计，以后可以单独开一个话题。

2.2CDP是工具，不是中台

这个说法可能很多公司不理解，明明CDP的P英文是platform,

平台的意思、，为什么CDP不是中台呢？准确的说，中台或者平台的定

义，本身就是不一样的，平台是很多方都会来和这个产品对接，并且

从这里进行信息交换或者业务处理。CDP可以是平台，毕竟完成了用

户数据采集和标签的工作，但CDP不是中台，更不是一个数据中台，

也不是公司整体的数据中台。CDP的底层数据基础，顶多算一个用户

数据的数仓而已。

为什么这么说呢？一个企业的数据中台，第一个使用对象是数据

管理员、数据科学家、数据分析师和数据开发，而不是面对业务分析

师和业务运营，但CDP首先是帮助业务发现数据价值，还原业务真实

情况，帮助发现并尝试业务解决问题的，所以是一个业务数据分析和

数据运营的工具，而不是一个用来做数据开发和数据挖掘的地方。使

用的部门都是相对独立和垂直的业务领域，他们带着业务诉求，打开

长篇，经过简单的点选，找到自己要圈的人，看到自己要看的数据，

就结束了，并不像纯粹的数据团队那样是支持业务的中台团队。

从功能上来说，CDP对接来的数据源，要么是业务系统比较清晰

明确的业务数据，要么是数据中台已经清理处理过的数据，当然CDP

也需要完成一些必要的数据处理和加工。但更基础的数据清晰工作，

尽量还是交给企业数据中台，或者业务系统自身完成数据的规范，例

如手机号这个信息，有的是188XXXXXXXX,有的是+86188XXXXXXXXC有

国际号），有的是1B8XXXXXXXX（混进了字母），有的是188XXXXXXX

（缺位）等这些基础数据的清洗工作。如果CDP来完成了统一数据和

规范，但是在源头上，这些数据还是存在的。那随着CDP将这些处理

结果反哺到业务系统中，源头的不规范和不处理，将来的某一天，其

他系统信息读取和反哺冲突了，在其他系统里就又会留下错误的字段,

甚至两个系统发生冲突和矛盾，这就把CDP这种数据产品“卷入”到

了业务系统之间数据合法合理的争执中。

所以不要妄想通过一个CDP来代替企业的数据中台，也不要奢望

CDP来完成企业的数据治理和统一，数据中台才是完成对历史数据规

范，并制定集团各个业务系统数据统一的标准和开发规范，同时进行

数据治理开发的地方。各个业务系统应该follow中台的这套数据治

理开发标准，规范业务数据的存储和判断，而这个时候专注数据分析

的CDP就“清清爽爽”focus在怎么分析和还原业务上，为业务带来

更多可能，拓展业务数据，这才是一个比较好的良性循环。当然CDP

这个平台，也具有别的系统查询/应用标签和查询应用人群的平台功

能性，但这个时候的平台开放，就focus在人群和标签应用上。

2.3CDP以“人”为中心，不代表和“人”相关所有

就像在前面症状里说的，CDP的核心能力是尽可能灵活合理的用

数据来描述“人”（消费者），只要是描述“人”的数据，都会出现

在产品里，但是如果描述的对象变了，变成了订单、商品、车，其实

这个时候在CDP里的描述主体，就变了。插个话，这里有个描述例外，

在教育行业，CDP描述的是“角色”，例如描述学生、描述老师，但

其实这里学生、老师已经是两个不同的对象或者叫主体。说回来，围

绕“人”这个主体，可以有人的标签、可以用人的标签来圈人，可以

有“人群”的应用，和对“人群”的标签洞察及行为分析，这些都是

合理的。

但如果要用CDP回答，以“人”为中心的在用所有数据来描述人，

人是对象，而不是把人相关数据都放进来后，分别描述和人相关的不

同对象，有些典型的“看似”和人相关的问题，其实不应该也不会在

CDP里解决。例如：各个大区门店的售后返厂质量如何？物流订单环

节里哪个环节耗时最长？同系列商品在过去两年大促的定价水平是

不是过高或者过低？各个渠道的库存深浅管理是否合理？以上这些

问题都好像和人相关，但其实都不是在描述人，他们分别描述的是售

后作业、物流订单、商品价格和门店库存，所以对他们的描述和对人

的描述就不同了。

2.4CDP是验证数据的起点，不是唯一点

前面症状九里提到，如果要验证CDP的价值，就不能单单只看一

个CDP里有什么，和CDP能做什么。这个价值验证应该是从CDP开始

的，从这里找到或者发起一个验证的出发点，然后再利用MA或者销

售助手、企微或者广告等方式，将发现应用到实际的消费者沟通中，

最后通过消费者的反馈，得到验证的结论，从而说明数据的价值和CDP

的能力。

毕竟这个C,是消费者，而对消费者的一切结果，都应该在和消费

者的实际沟通中得到反馈验证。这样的验证最好是在构建CDP前，就

有比较确定的业务目标，或者确定的业务场景，在CDP做实施部署开

发的时候，也要同步去设计这些场景的验证方案，需要用到什么沟通

方式，怎么设计沟通内容，用什么策略，以及如何进行数据的回收和

最终的数据比较。所以在讨论CDP的时候，往往需要把配套的一系列

产品和系统都考虑到，上游有：数据中台、埋点UBA,下游有：MA、

广告、客服外呼、CRM等。CDP是链接在其中的一个桥梁，不是说没有

CDP,他们就没有任何作用，而是说有了CDP从这里分析找到的数据

insight,输出的策略/人群包，才是一切数据验证的起点，和他们组

合出来的不同的消费者运营的场景，才是业务需要关注的核心，而不

是一个简单的CDPo

2.5一方CDP和三方/二方产品的关系

CDP这个概念是从国外的Martech进入中国，但是在国内把CDP

做的易用性最好。“感觉”也最好用的，往往是平台方的各种类CDP

产品，例如早期各个平台的DMP工具，主要核心作用是用平台标签圈

人，但现在的各个平台都有了更“营销”化的类CDP产品。例如巨量

引擎的云图、腾讯的知数和阿里的数据银行等，但是这些平台的产品，

或者叫二方产品，往往在数据封闭性上存在很多安全考量下的壁垒，

所以一方的CDP和他们之间，寄希望能够得到二方/三方的反哺，而

二方/三方也希望能够利用一方数据，来优化平台的营销模型，毕竟一

方最终和平台的合作还是在营销和卖货上。

所以这个时候，一方的CDP如果能够和平台的这些产品，能够在

安全合规的情况下，进行一些产品化的打通，就显得非常重要，常见

方式有这么两种：

・品牌f平台：一方CDP能够将应用人群包，和二方产品在不

出库、不下载导出、不明文、且不直接撞库的方式下，进行人群

包从一方到二方的应用，不仅拓展了一方数据的沟通方式，也

能通过这样的合规，变相的验证平台能力；

・平台一品牌：将二方的消费者数据标签，通过人群画像方式，

在一方的CDP中直接调用，让品牌能够在自己的CDP看到自己

的用户在平台的用户画像群体报告，不仅安全合规，同时也在

对画像分析之后，能够将策略直接在一方的主导范围内应用。

两种方式下，都有很多安全技术保证过程的合规合法，同时也保

证数据安全没有泄露风险，就像火山引擎数智平台VeDI提供的VeCDP

产品，不仅和抖音集团的巨量引擎做了安全合规的产品化链接，保证

私有化部署的VeCDP里，能够直接将人群应用到巨量引擎，同时也可

以在私有化VeCDP中，调用公域客群画像能力，帮助品牌在安全合理

合法的方式下，享受到平台数据合作的好处。

3.如何走上CDP正轨

前面既然说到了入坑的症状和原因，也帮助你正确认识了CDP是什

么，那最后这里的干活，就是实打实的教你，如何让自己的CDP项目走

上正轨？

3.1做CDP之前需要回答的几个问题

CDP做好了，第一个用户是谁？痛点是什么？

这个问题，决定了CDP项目的成功方向，能否找到第一个核心

的业务部门，列出他们的业务痛点场景都有什么。

・解决这个痛点的最小用户旅程是什么？或者说最小业务闭

环是什么？

针对第一个用户列出来的业务痛点，能不能围绕这个业务绘制

出最小的用户旅程，从哪个触点开始，在这个触点用户做了什么业务

操作，每个业务节点都是什么？发生在什么系统，最终实现什么样的

业务目标？是注册、留资、加购/收藏、购买、到店还是完成评价？

然后，在这个场景下，是不是一个简单的UBA就能实现，例如业

务部门的目的是为了优化app的下载流程？或者优化/设计下单流程，

提升转化？亦或者是了解线索跟进过程中的转化率低？或者线索有

效率低？如果这些场景没有跨触点，没有跨系统，在单一触点内，或

者单一系统内就完成了闭环，可能通过一个UBA或者一个单纯的BI

报表分析，也能定位问题，所以这里确定痛点的最小业务闭环和核心

指标就是设定具体的建设目标。

・支持解决问题的数据源都是否ready?

在这个最小的用户旅程上，涉及到用来描述用户的数据是否都

ready?埋点数据都有么？业务数据都有么？存在数据只在二方/三

方平台不可能获取的状态么？获取到的这些数据的用户ID都是什么？

有没有用户中心在这个环节提供校验？验证业务的沟通渠道有哪些？

是否都支持个性化触达？有没有独立的产品来管理触达策略？这些

问题的确定都是在围绕CDP项目成功验证价值扫清障碍。

3.2实际落地实施CDP环节需要谨记的要点

・围绕验证的业务场景，抽象构建一个符合业务视角的标签体

系，而不是标签列表

标签是描述人的原子能力，而不是一个名称。前面说过，如果一

个名字来描述一群