作者 | 火山引擎汽车营销云团队

　　出品 | CSDN（ID：CSDNnews）

　　6年前，如果一个公司说，有一个产品，能够帮助品牌打通数据孤岛，让用户数据在广告投放、客户体验、产品定价优化、促销活动，甚至非营销职能部门都能发挥数据价值，大概率你会认为这个产品特别有吸引力，特别神奇，于是公司一定想尽快了解，快马加鞭的购买部署。

　　就是CDP这样一个产品（或者叫方案），在中国从2016年到2022年这6年间，在众多品牌和公司心里的变化过程，“好神奇” →“哪都有” → “试一试” →“不一样” →“又一样” → “自己做” → “做不出” →“请专家” →“定制化”→“四不像” ，以上10个心理不知道你们公司处于哪个阶段呢？

　　“入坑”CDP症状

　　数据打通类：

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

　　CDP需要的是描述人的数据，如果这个系统描述人的数据非常有限，例如物流系统、门店管理、售后配件等，能提出来描述消费者的数据可能每个系统只有那么1-2个关键动作。比如物流核心是包裹的状态，但描述人的数据是用户查看过多少次物流信息，物流状态的更新本身不随用户行为发生变化，所以即使对接了物流系统，CDP能用到的数据，最多就是用户对物流信息的查询和订单操作，描述人的数据对CDP来说才是有用的数据。

　　不过即使是接了一个用户互动的触点，结果还是发现CDP里用户的行为数据少之又少，例如车企留资最简单的落地页，或者银行信用卡申请最简单的留资页，除了最后的留资记录和用户浏览什么都没有了，不仅留资记录不多，浏览量也只是干巴巴的数字。

　　这种情况CDP不能背这个锅，如果用户不能在这个触点产生丰富的有效互动，品牌设计的信息展示和互动都是纯纯自high，并不能引导用户产生有价值的行为数据，例如刚才的汽车留资页，除了滑动长长的产品介绍图和留资，用户已经没有什么动作了，那CDP能够获取到其他有价值的信息么？所以触点的有效互动设计往往决定了触点有价值行为数据的丰富程度。

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

　　分两种情况分析：一种是想了解用户的事实标签，例如男女、年龄、职业这种。如果一个用户在你任何系统都没有留下这些信息，即使把全公司数据都找遍了，也没有办法直接得出结论，这可能需要通过别的数据信息来综合判断，例如称呼是先生/女士、工作地址、app定位等。但这些信息的判断标准和规则，往往不是一两条能总结完的，所以如果要基于其他信息来预测判断用户的事实标签，通常需要对每一个标签做一套判断设计。复杂的说，一个标签一个模型；另一种情况是想了解用户在你触点范围外的信息，例如喜欢什么IP等，这些信息在过去要么通过从第三方数据源那里直接购买用户标签，当然现在这条路随着数据安全和个保法的落地，已经没了。现在对这些信息的补全，需要通过在公司业务所覆盖的触点范围内引导客户有所表达互动，基于表达互动在逐一建模总结，总之标签的补足依靠的不是外部的输入，更多依赖对业务范围内触点的用户引导运营。

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

　　能否在CDP准确回答用户数量，取决于在CDP里构建了一个什么样的one-id，到底是实名的用户id是one-id，还是匿名+实名是one-id；匿名到是实名的关键步骤摸清过么？从微信的uni-id、open-id到手机号、什么场景才能串联起来？设备号在哪些渠道能获得，获得的是加密还是原值，有多少设备号？多少加密方式，加密方式有没有有效期？现有系统里有没有用户中心？有没有系统能够完成一个用户全盘从未注册到注册的id创建？用户id创建的逻辑是否支持两个手机号同一个设备的注册？如果用手机号作为各个系统的用户id，那售后的手机号和下订单的手机号不一样，怎么判断是不是一个人？

　　以上问题都不是单独依靠CDP来完成，都需要在构建CDP之前，通过业务系统的整体设计和用户id的梳理提前完成。更重要的是，通过设计和运营，引导用户完成其中匿名到实名的转换，也是这个问题的关键，如果抛开这样的运营引导，即使有了用户中心这样的统一用户注册设计，CDP也”巧妇难为无米之炊“，可以说用户中心是CDP的“硬件依赖”，继承用户中心构建匿名到实名one-id的运营设计是“软件保障”，两个共同配合才是做能够让CDP one-id发挥价值。

　　数据分析类：

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

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

　　有“近3天购买”的用户标签，也有“近30天购买”的各种时间用户标签；

　　有“购买XX系列”的用户标签，也有“购买YY系列”的穷举商品的用户标签；

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

　　甚至还有“活跃-用户运营”、“活跃-app”、“活跃-线索运营”，这样不同业务不同部门不同时间定义的不同“活跃”的用户标签；

　　当有100多个标签时，还勉强能找到，但随着业务发展，标签描述的时间窗口不适用了、商品信息有变更了、业务状态有变化了等等原因，这些标签都会被“打入冷宫”，做出更新的标签，删了怕哪天业务要用，不删又越做越多，100多变成300多，甚至变成500多，等反应过来想清理可能都是个巨大的工作。

　　究其原因还是因为对“标签”的理解太普世直接。举个例子，“近3天成都车展留资”在很多公司可能是个标签，但其实是个人群包，这个人群包里包含了很多要素、有时间、有地点、有业务动作，每个要素随着业务变化都会有新需求，哪怕之变一个，可能都需要新做一个“标签”，所以正确的理解什么是“标签”，什么是人群包，以及如何设计合理的标签，比一上来就做“标签”更重要。

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

　　有没有发现，现在越来越多公司的CDP产品里，都在强调用户行为事件，而这些行为事件不仅看上去非常“丰富”，而且覆盖的系统越来越多，好像万物皆可埋点，打开app可以埋，看不看社区可以埋，有没有点赞可以埋，有没有留资试驾也可以埋，甚至有没有创建订单也可以埋，难道宇宙的“尽头”是埋点么？

　　其实埋点只对用户在系统触点上，对非业务结果的过程行为数据补充，业务结果本身已经记录在了各个业务系统里，例如留资记录在线索中心，订单结果在订单中心，点赞评论在社区数据库，他们本身其实不需要埋点，过度相信和使用埋点采集，不仅会重复采集，还会产生很多“看似有用”的用户“未完成”记录。例如用户点了提交，但因为网络或者中断操作而没提交的记录，这些“未完成”记录看似有用，但其实用全量用户去掉那些成功完成的，剩下的自然就是未完成的，过多的埋点采集让用户客户端的上报数据从原本上报结果，变成了上报一切，不仅流量暴增，能耗也暴增，卡顿在所难免。

　　所以埋点要适当，补全那些必要，但没有业务结果记录的过程数据即可，例如：曝光日志、启动日志或者结果前的选择中间记录即可。毕竟说到底埋点只是一个UBA（用户行为分析），这个Behavior指的是单一触点的页面互动行为，解决的还是一个页面操作优化和流量分析的问题，而CDP作为数据打通后的分析工具，应该抽样去解决跨端、跨业务节点的全链路分析问题，业务使用CDP更关心多少人从注册变成了活跃，变成了留资或者订单用户，而不是多少人注册后，在这个页面停留了多少秒。如果要单独分析app设计和路径，这是埋点UBA的场景，但分析全链路转化、跨端活跃等全局视角，才是CDP重点。埋点的数据源只是CDP的源头之一，CDP更聚焦是各个触点的业务结果，而不是每个触点的详细中间未完成过程。

　　症状六：看上去CDP有很多分析功能，AIPL/5A/FAST/RISE... 为什么都用不起来？

　　不得不承认在当下中国的环境里，各大互联网平台掌握了消费者丰富且海量的数据。各个平台，尤其是电商平台，在如何利用数据做消费者运营和业务分析上有丰富的“土壤”，并且更具平台的特色，有很多看上去很经典的指标和模型。

　　老生常谈，各个公司也都知道这样的指标模型可能不是全行业通用，于是自己的CDP往往选择定制一个属于自己的“字母模型”，或沿用、或继承、或扩展。但随着自身发展都会出现好像都不适用的情况，究其原因，无非是忽略了自身业务所包含的用户数据基础和平台用户数据基础的巨大差异。相比平台，公司自身业务形态的用户数据不管是量级还是丰富程度都远远少于平台，如果只是在这些“字母模型”的定义上，修改调整，盲目适配，是不可能反应自身业务状况的。所以研究平台模型，不如根据自身业务绘制属于自己的用户生命周期，可以是全业务的，也可以是单独某一个业务。对于生命周期中每个阶段的描述，就利用最简单朴实的业务定义为其描述，回到业务根本，以每个业务环节的核心指标来衡量分析转化的好坏，这才是对CDP中数据价值的正确引导。

　　数据应用：

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

　　CDP里面确实有很多用户数据和标签，并且作为“建模”，这些标签都是必要的一方特征。某些场景上，这些一方特征是有很高的挖掘价值的，但注意这是某些场景。比如在存量用户中挖掘可能的潜客、或者在保有客户中挖掘可能的增换购等，这些场景都有一个特点，就是要找的目标人群在一方的业务范围内是拥有很多特征值得细细“挖掘”。

　　也就是说，这些存量里的“潜在”客户，是有历史行为作为分析依据的，但如果场景换一下，想对新注册的会员做一个购买潜客的预测、对新的访客做一个可能下单的预测，这样的新用户预测场景，可以说一方CDP里的数据，就不能发挥什么价值了。毕竟一个新会员/新访客，除了贡献一个手机号/设备号和注册/访问渠道及时间其他什么都贡献不了。

　　可能你会问，那我刚下载抖音，抖音不也会给我做很多猜我喜欢推荐么？其实“推荐”或者准确的说，“实时推荐”和“潜客预测/潜客挖掘”，还是两种不同的业务模式，这里不做特别详细的展开，简单说，“实时推荐”是通过海量内容的不断学习了解，不断积累偏好模型的过程，是一个持续“养”的方式；而“潜客预测/潜客挖掘”是一个by 需求型的单次/多次定位输出的模式，类似先找“靶子”再“开枪”，具体以后再做介绍。回到CDP的模型，给个确诊的原因，CDP是给业务人员分析和直接应用的，建模是个算法技术活儿，最好交给数据科学家。CDP的一方用户特征很有用，但场景更适用于存量客户的“挖掘”，而不是纯新客的预测，至于结合二方/三方数据的联合/联邦建模，下次可以再展开，存量客户的“挖掘”模型要做的好，丰富一方用户数据一定是基础，这就又回到了在一方业务范畴内，多做用户运营，多设计有效互动，多引导用户交互的运营问题。所以要想CDP模型做得好，一方运营就得跟上，创造更多用户数据，才有在存量去“挖掘”的可能。

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

　　有一个比较时髦的名字Marketing Technology营销科学技术，简称Martech，来形容CDP。所以一个技术产品在工具属性上必然有一定的使用门槛，更何况这是图形化之后的数据分析工具，符合满足所有数据分析的流程，即了解数据现状 -》确定分析目的-》定位数据对象-》维度下钻展开 -》进一步了解数据的循环过程。

　　因此除了在CDP里“看”，动手去“找”，本质上在数据库里写SQL定位数据是没有区别的，而现在市面上的CDP无非是将这个SQL过程，通过图形化方式，做了低代码的产品形态包装。SQL当然比excel更灵活，但门槛也比excel要高，所以操作CDP，尤其是操作CDP的“圈人”这个核心功能，适当的数理逻辑是必须的。这里无非也是一个帮助操作者，即业务人员，去理清思路的过程，因为“圈人”本质就是在描述你的业务目标对象。

　　举个例子：业务想把去年双11 的存量客户里，已经大半年不活跃的捞出来做一波召回返厂，为双11预热，这里的对象描述就可以拆解成：

　　条件1：满足，去年10月20-11月11日内，在所有渠道，创建了订单，这个行为的用户

　　条件2：满足，最近半年，在所有渠道，创建了订单，这个行为的用户

　　条件1 差掉（减去） 条件2，取一个差集，这就简单的得到了刚才的业务目标对象

　　上面这个操作里，从本质上是一个用户行为“创建订单”的不同描述，是一条比较简单的SQL关联查询。但通过在CDP里不同描述的逻辑组合，虽然没有实际写出SQL，但已经完成了数据定位。和操作一个excel比，业务需要知道CDP里有什么用户行为标签，这些标签是怎么描述用户的，基础的梳理逻辑“交、并、差”是什么意思，就足够了。这当然对业务人员提出了一定的要求，但这也是数字营销大时代下必备的技能。

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

　　确实要量化CDP的价值好像不能简单直接从销量、活跃、注册这样的大指标上得出结论，但也要清楚认识到这些大指标的提升，应该是一整套工具+运营动作的综合结果，把结果单纯归一到一个系统、或者一个运营人员身上都是不科学不公平的。如果买一个系统就直接提升销售和活跃，那卖系统的不就是在卖“智商税”的药方子么？

　　回到上面双11的例子，通过CDP找到目标用户只是这件事情的第一步；第二步是了解这些用户为什么不活跃，回答这个问题可能通过用户画像尝试看看有没有其他类似加购、留资、社区活跃这些统计，也可以通过某个用户标签看看他们的购买评价都是什么分布或者反馈评论关键词都是什么，当然也可以通过埋点这样的UBA产品，看看这群人，在某个触点近半年的流量活跃情况是什么样，找到问题的初步原因后；第三步，通过上一步的发现设计一个简单的运营方案，包括用什么样的利益点、设计什么样的活动和落地页，在什么样的时间频次上，通过什么渠道做用户触达；第四步是利用MA这样的营销工具或者配合广告投放等，把上面的运营方案做一个落地，最后再回到CDP里对这群对象做一个定向的转化分析。

　　很多公司在没有CDP之前总希望CDP+MA这两个工具组合能够贯穿用户旅程的各个节点，一下子就打通形成一套完整的消费者运营或者用户运营的模式，做完就可以交差了。但模式归模式，没有落地的场景和结果，模式终究只是故事，这个故事用来内部立项可能还行，但要让做CDP这件事情能够真的站起来了，一定需要聚焦这几个问题：

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

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

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

　　如果上面这三个问题的答案都清晰了，那就确定了CDP及配套系统的的一个验证业务场景，这个时候才是去针对场景规划运营方案，以运营方案来指导系统建设和数据需求的正确步骤。

　　上面这些症状当然不能涵盖所有，但应该可以代表大部分公司在“建设/使用/了解”CDP和相关方案时的很多典型疑问了，说到底，产生这些疑问和症状的原因，是因为公司对CDP和相关方案没有一个清晰正确的理解和认识，那如何客观的看待CDP呢？

　　正确认识CDP

　　CDP是数据，不是业务

　　首先，必须要界定的是，CDP一定是一个数据分析产品，是数据分析产品，那它就是业务产品ready之后，才有使用价值的，不能脱离业务产品。

　　那什么是业务产品呢？简单说就是没了这个产品/系统，这个业务就不能进行下去了，或者业务就不成立了，这就是业务产品。举个例子，用户中心/CRM/会员中心/订单中心这些，都是业务产品，如果没有用户中心的统一注册网关，用户的注册和用户id怎么生成？如果没有CRM，线索如何进行收集和分发？如果没有会员中心，怎么确定用户的等级和积分以及积分能做什么？如果没有订单中心，那订单又改在哪里创建、流转和操作？所以发现了吗，业务产品/系统是能够源源不断生产业务数据的，而CDP这样的产品，无非只是在回收/记录数据，不会产生新的业务结果，因此就不能对CDP抱有业务系统的幻想。例如，没有用户中心，希望CDP来完成全公司用户ID的生成，那CDP是不是应该做一个生成队列，所有id的创建和请求都给CDP来处理呢？这明显是把业务系统的功能放在了数据产品上。

　　同样，因为不是业务产品，那么这里没有“业务流程”的改造，因为CDP不参与业务的处理和判断，不是业务正确与否的裁判员，用户信息的正确性不是CDP说了算，而是业务系统说了算，CDP不过是真实的记录还原了这个用户信息的结果以及结果的变化过程而已。

　　所以如果公司还没有和用户管理相关的业务产品，该还的债，还是要还的，至于用户中心或者用户管理都应该做什么，或者公司销售相关的业务产品之间怎么设计，以后可以单独开一个话题。

　　CDP是工具，不是中台

　　这个说法可能很多公司不理解，明明CDP的P英文是platform，平台的意思，为什么CDP不是中台呢？准确的说，中台或者平台的定义，本身就是不一样的，平台是很多方都会来和这个产品对接，并且从这里进行信息交换或者业务处理。CDP可以是平台，毕竟完成了用户数据采集和标签的工作，但CDP不是中台，更不是一个数据中台，也不是公司整体的数据中台。CDP的底层数据基础，顶多算一个用户数据的数仓而已。

　　为什么这么说呢？一个企业的数据中台，第一个使用对象是数据管理员、数据科学家、数据分析师和数据开发，而不是面对业务分析师和业务运营，但CDP首先是帮助业务发现数据价值，还原业务真实情况，帮助发现并尝试业务解决问题的，所以是一个业务数据分析和数据运营的工具，而不是一个用来做数据开发和数据挖掘的地方。使用的部门都是相对独立和垂直的业务领域，他们带着业务诉求，打开长篇，经过简单的点选，找到自己要圈的人，看到自己要看的数据，就结束了，并不像纯粹的数据团队那样是支持业务的中台团队。

　　从功能上来说，CDP对接来的数据源，要么是业务系统比较清晰明确的业务数据，要么是数据中台已经清理处理过的数据，当然CDP也需要完成一些必要的数据处理和加工。但更基础的数据清晰工作，尽量还是交给企业数据中台，或者业务系统自身完成数据的规范，例如手机号这个信息，有的是188XXXXXXXX，有的是+86 188XXXXXXXX（有国际号），有的是1B8XXXXXXXX（混进了字母），有的是188XXXXXXX（缺位）等这些基础数据的清洗工作。如果CDP来完成了统一数据和规范，但是在源头上，这些数据还是存在的。那随着CDP将这些处理结果反哺到业务系统中，源头的不规范和不处理，将来的某一天，其他系统信息读取和反哺冲突了，在其他系统里就又会留下错误的字段，甚至两个系统发生冲突和矛盾，这就把CDP这种数据产品“卷入”到了业务系统之间数据合法合理的争执中。

　　所以不要妄想通过一个CDP来代替企业的数据中台，也不要奢望CDP来完成企业的数据治理和统一，数据中台才是完成对历史数据规范，并制定集团各个业务系统数据统一的标准和开发规范，同时进行数据治理开发的地方。各个业务系统应该follow中台的这套数据治理开发标准，规范业务数据的存储和判断，而这个时候专注数据分析的CDP就“清清爽爽”focus在怎么分析和还原业务上，为业务带来更多可能，拓展业务数据，这才是一个比较好的良性循环。当然CDP这个平台，也具有别的系统查询/应用标签和查询应用人群的平台功能性，但这个时候的平台开放，就focus在人群和标签应用上。

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

　　就像在前面症状里说的，CDP的核心能力是尽可能灵活合理的用数据来描述“人”（消费者），只要是描述“人”的数据，都会出现在产品里，但是如果描述的对象变了，变成了订单、商品、车，其实这个时候在CDP里的描述主体，就变了。插个话，这里有个描述例外，在教育行业，CDP描述的是“角色”，例如描述学生、描述老师，但其实这里学生、老师已经是两个不同的对象或者叫主体。说回来，围绕“人”这个主体，可以有人的标签、可以用人的标签来圈人，可以有“人群”的应用，和对“人群”的标签洞察及行为分析，这些都是合理的。

　　但如果要用CDP回答，以“人”为中心的在用所有数据来描述人，人是对象，而不是把人相关数据都放进来后，分别描述和人相关的不同对象，有些典型的“看似”和人相关的问题，其实不应该也不会在CDP里解决。例如：各个大区门店的售后返厂质量如何？物流订单环节里哪个环节耗时最长？同系列商品在过去两年大促的定价水平是不是过高或者过低？各个渠道的库存深浅管理是否合理？以上这些问题都好像和人相关，但其实都不是在描述人，他们分别描述的是售后作业、物流订单、商品价格和门店库存，所以对他们的描述和对人的描述就不同了。

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

　　前面症状九里提到，如果要验证CDP的价值，就不能单单只看一个CDP里有什么，和CDP能做什么。这个价值验证应该是从CDP开始的，从这里找到或者发起一个验证的出发点，然后再利用MA或者销售助手、企微或者广告等方式，将发现应用到实际的消费者沟通中，最后通过消费者的反馈，得到验证的结论，从而说明数据的价值和CDP的能力。

　　毕竟这个C，是消费者，而对消费者的一切结果，都应该在和消费者的实际沟通中得到反馈验证。这样的验证最好是在构建CDP前，就有比较确定的业务目标，或者确定的业务场景，在CDP做实施部署开发的时候，也要同步去设计这些场景的验证方案，需要用到什么沟通方式，怎么设计沟通内容，用什么策略，以及如何进行数据的回收和最终的数据比较。所以在讨论CDP的时候，往往需要把配套的一系列产品和系统都考虑到，上游有：数据中台、埋点UBA，下游有：MA、广告、客服外呼、CRM等。CDP是链接在其中的一个桥梁，不是说没有CDP，他们就没有任何作用，而是说有了CDP从这里分析找到的数据insight，输出的策略/人群包，才是一切数据验证的起点，和他们组合出来的不同的消费者运营的场景，才是业务需要关注的核心，而不是一个简单的CDP。

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

　　CDP这个概念是从国外的Martech进入中国，但是在国内把CDP做的易用性最好。“感觉”也最好用的，往往是平台方的各种类CDP产品，例如早期各个平台的DMP工具，主要核心作用是用平台标签圈人，但现在的各个平台都有了更“营销”化的类CDP产品。例如巨量引擎的云图、腾讯的知数和阿里的数据银行等，但是这些平台的产品，或者叫二方产品，往往在数据封闭性上存在很多安全考量下的壁垒，所以一方的CDP和他们之间，寄希望能够得到二方/三方的反哺，而二方/三方也希望能够利用一方数据，来优化平台的营销模型，毕竟一方最终和平台的合作还是在营销和卖货上。

　　所以这个时候，一方的CDP如果能够和平台的这些产品，能够在安全合规的情况下，进行一些产品化的打通，就显得非常重要，常见方式有这么两种：

　　品牌→平台：一方CDP能够将应用人群包，和二方产品在不出库、不下载导出、不明文、且不直接撞库的方式下，进行人群包从一方到二方的应用，不仅拓展了一方数据的沟通方式，也能通过这样的合规，变相的验证平台能力；

　　平台→品牌：将二方的消费者数据标签，通过人群画像方式，在一方的CDP中直接调用，让品牌能够在自己的CDP看到自己的用户在平台的用户画像群体报告，不仅安全合规，同时也在对画像分析之后，能够将策略直接在一方的主导范围内应用。

　　两种方式下，都有很多安全技术保证过程的合规合法，同时也保证数据安全没有泄露风险，就像火山引擎数智平台VeDI提供的VeCDP产品，不仅和抖音集团的巨量引擎做了安全合规的产品化链接，保证私有化部署的VeCDP里，能够直接将人群应用到巨量引擎，同时也可以在私有化VeCDP中，调用公域客群画像能力，帮助品牌在安全合理合法的方式下，享受到平台数据合作的好处。

　　如何走上CDP正轨

　　前面既然说到了入坑的症状和原因，也帮助你正确认识了CDP是什么，那最后这里的干活，就是实打实的教你，如何让自己的CDP项目走上正轨？

　　首先，在做CDP之前，你需要回答如下问题：

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

　　这个问题，决定了CDP项目的成功方向，能否找到第一个核心的业务部门，列出他们的业务痛点场景都有什么。

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

　　针对第一个用户列出来的业务痛点，能不能围绕这个业务绘制出最小的用户旅程，从哪个触点开始，在这个触点用户做了什么业务操作，每个业务节点都是什么？发生在什么系统，最终实现什么样的业务目标？是注册、留资、加购/收藏、购买、到店还是完成评价？

　　然后，在这个场景下，是不是一个简单的UBA就能实现，例如业务部门的目的是为了优化app的下载流程？或者优化/设计下单流程，提升转化？亦或者是了解线索跟进过程中的转化率低？或者线索有效率低？如果这些场景没有跨触点，没有跨系统，在单一触点内，或者单一系统内就完成了闭环，可能通过一个UBA或者一个单纯的BI报表分析，也能定位问题，所以这里确定痛点的最小业务闭环和核心指标就是设定具体的建设目标。

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

　　在这个最小的用户旅程上，涉及到用来描述用户的数据是否都ready？埋点数据都有么？业务数据都有么？存在数据只在二方/三方平台不可能获取的状态么？获取到的这些数据的用户ID都是什么？有没有用户中心在这个环节提供校验？验证业务的沟通渠道有哪些？是否都支持个性化触达？有没有独立的产品来管理触达策略？这些问题的确定都是在围绕CDP项目成功验证价值扫清障碍。

　　然后，实际落地实施CDP环节，需要谨记的要点：

　　围绕验证的业务场景，抽象构建一个符合业务视角的标签体系，而不是标签列表

　　标签是描述人的原子能力，而不是一个名称。前面说过，如果一个名字来描述一群人，那这个只能叫“人群包”的名字，或是很多公司理解的“标签”列表，真正的标签，是一个体系。在确定验证业务场景后，就要从中抽样出需要用的描述用户的属性标签都有哪些，用户行为都有哪些。

　　以业务流程为基础，以指标为导向，设计符合业务分析思路的框架

　　CDP的分析不止一个简单的漏斗转化，在特定业务中，可以根据业务的分析习惯，抽样出每个环节的关键分析点。例如每个环节是在哪些触点发生，这个触点的描述有哪些维度，用户在这个触点环节里停留时长和关节动作都有什么。这样不仅是一个链路的转化比例，也能在每个环节中，看到用户行为反应出来的其他信息，而不是像做埋点的用户UBA一样，把所有大大小小的用户信息全部展示，什么点了什么按钮、在哪里停留多久，这些对业务分析在场景上，都太细化，聚焦业务关注的指标，和业务讨论才能更符合业务的分析需求。

　　让业务人员专注在分析业务上，而不要介入CDP的数据管理和定义中

　　业务分析对象是CDP的one-id，分析过程看的也是画像和分析看板，分析后的应用也是id组成的“消费者”人群包，全程业务关系的都应该是消费者是谁？在业务里发生了什么？业务情况怎么样？而不需要关心这个数据源是哪个系统、这个标签定义是怎么做的、要不要新加一个标签等这些数据管理和定义的问题，这些应该交给数据管理和CDP的数据运维来完成。所以在实施CDP的时候，不仅是角色权限，也应该在面向业务使用的产品能力上，都站在业务视角，做到“一看就懂”，“一点就会”，低代码终究不是代码，代码的工作，one-id逻辑都交给专业人士。

　　最后，CDP项目上线，收尾关键：

　　验证结果客观，以业务指标为核心，也还原中间过程

　　当然不会每个CDP做完后的业务场景验证都是指标提升了的，毕竟每个数据源质量不同，数据反应的也是历史和事实，最终的转化一定有很多不可控因素。但衡量CDP项目的好换不仅仅是看核心中标，还依赖与能否在指标并没有完全达到的时候，能够还原出中间的过程，有没有能力分析还原出是哪里的其他指标不理想，有没有能力对某个特定环节的用户行为定向的再圈人进行详细展开，这都是CDP能力的体现，因此关注结果同时，也关注数据带来的过程。

　　培养业务的数理逻辑思维，授人以鱼不如授人以渔

　　毕竟在CDP里的分析是一个不断发现，不断圈人，再不断发现的一个循环过程，而圈人这个重要的操作又是必不可少的环节。因此低代码的圈人方式，需要业务人员具备一定的数理逻辑，帮助业务快速掌握逻辑关系的应用，业务人员能做出更多有创造力的人群包。同时CDP的分析看板具备的灵活定义配置的能力，也是数理逻辑应用的体现，确定对象，套入分析框架，再确定新的对象，这样的逻辑关系理解，也需要一定的逻辑基础，所以初类培训产品使用，简单的数据分析框架也是必须的。

　　拓展新数据源之前，先确定新数据源要解决的场景目标

　　未来CDP随着业务发展一定有新的数据源接入，但是每接入一个数据源，都需要像开始CDP项目一样确定需要觉得业务场景和目标是什么，然后围绕这个目标的标签体系需要怎么补全，上面第一步的问题每次都确定一遍，才能保证CDP的使用和建设始终是围绕业务需求而进行，而不是为了吸收数据而吸收，为了做标签而做标签。

　　其实关于CDP，本文也只是浅显的谈论了其中常见的问题和注意事项，真正做好CDP，做好企业的数字化运营工作，尤其是消费者在全渠道全链路的数字化运营工作，一个CDP一定是不够的，高阶的数据模型如何构建，运营策略方案怎么设计，还有专精的触点优化，尤其是APP优化等等，都是非常有深度的课题。