CDP 在 Qunar 精细化运营中的建设实践

文章导读

客户数据平台 CDP（Customer Data Platform）已成为精细化运营的标配工具，去哪儿旅行经过多年的建设，广泛应用于各种业务场景中，产生累计亿级别的收益，并且CDP项目也获得了公司年度金项奖。本主题先后受邀在CSDI SUMMIT、InfoQ QCon+、DataFun 峰会，以及 Qunar 对外直播大数据系列课中进行了分享。本文结合对外分享内容进行整理，从 CDP 的业务背景、建设实践、总结应用、未来展望四个方面进行介绍精细化运营中 CDP 的业务价值，希望对这方面感兴趣的同学有所启发和收获。

一、CDP业务背景

首先我们结合去哪儿旅行的业务形态，从实际的精细化运营痛点问题出发，讲清楚 CDP 为业务带来价值的底层逻辑。

1. 去哪儿旅行的业务

去哪儿旅行成立于2005年，是中国领先的在线旅游平台之一，累计用户近6亿，包含机票、酒店、火车票等业务在内的十几个业务线，业务繁多。

2. 行业背景

互联网行业业务增长主要由两个方向来驱动：拉新和存量运营。随着目前大环境流量红利的消失，再叠加之前全球疫情的影响，业务增长策略重心逐渐由拉新转为存量运营。旅游行业也不例外，举两个日常存量运营的例子：针对流失用户，通过发送优惠券过期提醒信息等方式，唤醒沉睡用户；当用户在 APP 活跃浏览酒店时，识别为亲子类型的用户，通过置顶推荐亲子类酒店、房型，来促进转化。

3. 运营的痛点

通常一个完整的运营活动包括运营前期的数据分析、策略制定，运营过程中的需求研发，运营后期的效果分析、策略迭代，每个阶段都存在痛点问题。

运营前期阶段

• 业务数据孤立，分析难度大
• 标签准确度、质量不高，影响 ROI
• 标签复用性低，无高价值标签沉淀

需求研发阶段

• 涉及团队多、系统多，开发成本高
• 烟囱式开发，服务可用性保障难

运营后期阶段

• 周期长、迭代慢，运营效率低

4. 运营过程抽象

为解决运营痛点，我们对运营过程进行抽象，总结出了几个核心环节：

构建画像标签、圈选人群包、配置运营策略、分析运营效果，这些就组成了客户数据平台 CDP（Customer Data Platform）。我们对其定义是一站式精细化运营平台，通过对数据充分分析挖掘，将高价值数据反哺到业务，精准触达用户，实现业务增长赋能业务。

5. CDP 初印象

参考 Garnter 从 2016 到 2022 年发布的 Hyper Cycle for Digital Markting，CDP 连续 7 年入选，从发展趋势来看已经逐步走向成熟，成为业界精细化运营的标配工具。

CDP 相对 CRM、DMP 有所不同，CRM 起源于上世纪 90 年代，主要面向销售部门用于客户关系的管理；DMP 出现在 2010 年前后，主要应用匿名的公域数据，面向市场营销部门进行广告投放；CDP 则是起源于 2016 年前后，使用的角色比较广泛，包括运营、市场、产品、销售等，主要基于私域数据应用于精细化运营。

6. CDP 业务逻辑

CDP 之所以在业务增长中起到重要作用，其内在逻辑是这样的：当用户使用 APP 时，会通过数据采集获取到用户行为数据，经过数据逻辑加工，由 CDP 形成高价值数据反哺给业务，实现驱动业务增长的目的。

再进一步的核心方法论是：业务数据化、数据资产化、资产业务化，实现从业务到数据再回到业务的闭环。

从 4W1H 角度，CDP 做的事情可以总结为一句话：在合适的时间、合适的地点，以合适的方式，把一个合适的内容触达给合适的用户。

7. 去哪儿旅行中的应用

目前 CDP 在去哪儿旅行中的应用，如下图所示：

二、CDP建设实践

1. CDP建设思路

对于 CDP 的建设思路，首先作为公司的数据平台部门，面对的是所有业务线，如何满足各业务不同类型的运营诉求以及如何顶住全公司业务的请求压力，是我们要面对的问题，因此我们的建设思路主要有以下三点：

• 打造一站式解决方案，建设精细化运营全链路闭环系统，实现全流程全自助
• 基于全业务数据，支持对用户和商品进行打标签，打标对象甚至可自定义
• 提供稳定高可用服务，支撑高并发场景下的全业务实时调用

2. 数据平台整体架构

数据平台整体的架构如上图所示：

• 基础平台：包括 Hive、Trino、Flink、Hadoop、HBase、Kafka 等组件构建基础平台，基于此向上构建离线和实时数仓
• 数据开发：包括数据同步、调度系统、开发平台、埋点系统等
• 数据治理：包括数据标准、数据质量、数据资产、数据安全等
• 数据应用：基于数据底座的数据应用层，包括 BI、OneService API、CDP 等
• 业务应用：支撑的业务场景，包括酒店报价、酒店营销、会员权益、代理商数据平台、机票辅营、信息流推荐等等

其中 CDP 所处的位置是数据应用层，其依托于数据仓库、数据开发、数据治理，直接对接到业务，承载了高价值数据赋能业务的作用

3. CDP功能架构

CDP 的主要目标之一是实现运营全流程全自助，以下是 CDP 功能架构图

3.1 CDP 核心基础能力

标签作为 CDP 提供的核心基础能力，其加工过程包括：数据源、数据处理、标签生产。

其中数据来源支持 Qunar APP、小程序和集团数据、部分外部数据，将所有数据整合后，提供统一处理能力，并用算法模型计算基础画像，以及通过 IDMapping 将用户串起来。

标签生产主要包含了对标签的构建、质检和洞察。

1） 标签构建

标签构建是 CDP 发挥价值的根基，为支持更多样的业务诉求，需要满足各种类型的标签构建。

• 按统计方式来分，支持 SQL 统计类标签、规则配置类标签、算法模型类标签
• 按打标对象来分，支持用户标签、商品标签，以及任意对象的标签
• 按时效性来分，支持手动上传的静态数据标签、周期性更新标签、实时标签
• 为满足更复杂的业务逻辑，支持基于标签再加工的组合标签

2） 标签质检

质检是标签数据质量的重要保障，尤其是针对发布到线上被实时调用的标签，若质检不通过则阻断；对于日常构建的标签，展示各种维度的质检报告，以便辅助用户判断标签质量。

3） 标签洞察

标签洞察是对标签人群内部构成进行透视。

3.2 CDP 核心价值链路

以标签为基础，CDP 的核心价值体现在三个方面，下面分三条链路对功能架构拆解分析。

第一条链路：标签生产 - 数据分析

对沉淀的众多标签，进行组织分类形成标签地图，便于用户查找；再一个能够进行个体画像、群体画像分析以及作为数仓表进行用户分析和出业务报表。

第二条链路：标签生产 - 标签服务 - 业务应用

将标签数据以服务 API 的方式提供实时调用，直接对接业务系统应用到各业务场景，例如推荐、定价、促销、营销等。

第三条链路：标签生产 - 用户分群 - 营销策略 - 用户触达 - 效果分析

1 ）用户分群

人群圈选，支持拖拽式快速组合进行与或非条件圈选；人群预估，是指在不断调整圈选人群包条件时，能够及时给出人群包的圈选人数；人群洞察，是针对圈选出来的人群包，进一步分析其属性构成，以辅助判断是否是期望触达的用户群体，从而实现精细化人群圈选。

2 ）营销策略

即配置营销任务，在这里将上文的 4W1H 通过可视化配置的方式落地，并支持 AB 对照。

3 ）用户触达

目前去哪儿旅行已经实现全场景的用户触达，包括短信、站内信、优惠券、 PUSH、弹窗等，满足了业务对各种渠道的触达诉求。

4 ）效果分析

对每次圈选的人群包投放后进行效果分析，包括触达转化漏斗各阶段分析、AB 评估、业务报表分析等，这是迭代下次圈选策略的重要依据，形成完整闭环。

3.3 CDP 管理

对 CDP 整体的横向管理，包括调度、元数据、血缘、质量、权限，以及生命周期管理等等。

4. CDP 技术架构

关于 CDP 技术架构如上图所示，这里做一个整体上的概述，下个章节将详细介绍 CDP 的核心模块。

先看中间部分，基于各类数据源做数据处理，包括 IDMapping 、标准化数据和模型计算，然后用 Hive 和 FlinkSQL 分别构建离线和实时标签。标签服务部分对外提供了 Dubbo、HTTP 接口，数据存储在 HBase 和 Redis 中。人群圈选部分用 ClickHouse 进行人群预估和洞察，然后配置营销策略触达用户，最后回收数据进行效果分析。

再看两侧，监控方面做了全链路监控、客户视角监控、调用日志以及长尾分析等；质量方面做了构建事务、构建质检、返回值分布监控以及一致性监控等；服务方面提供了限流、权限、资源隔离、容器化、压测和故障演练等能力；管理方面涉及血缘、元数据、调度以及生命周期的管理等。

5. CDP 核心模块

标签体系： 构建业务需要的体系化标签，主要是内容建设

标签服务： 提供稳定可靠的在线服务，保障可用性

实时标签： 提升标签数据及时性，满足实时业务场景

人群圈选： 快速圈选人群，并预估和洞察分析

5.1 标签体系

标签体系构建原则是由实际业务需要进行梳理，标签对象包括用户、商品（酒店、航班、火车、门票等）。梳理标签分类遵循 MECE 原则，即相互独立，完全穷尽。

最终构建的标签体系，举例如下图所示：

5.2 标签服务

标签服务承载全业务各场景的实时调用请求，高并发场景下要求高性能，其 SLA 可用性目标如下图所示，在技术上有一定的挑战性。

为实现这些目标，我们主要从两方面做保障：

• 技术架构保障：调用方、服务方、数据存储、标签生产层面分别做了保障措施
• 部署环境保障：主要做了容器化部署、隔离部署

5.2.1 技术架构保障

标签服务技术架构如下图所示：

从技术架构角度对标签服务各层进行设计，保障整体服务的稳定性。

• 标签生产层

1）调度依赖：由调度任务触发标签执行构建，产出标签 Hive 表。保障不会因为上游表未正常产出就构建标签，导致标签数据不正常。

2）标签质检：对产出的标签数据进行质量检测，不通过则阻断，通过后对增删改的数据增量双写到 Redis 和 HBase 。质检是线上数据质量保障的重要环节。

3）构建事务：标签整个构建过程，从标签开始构建生成 Hive 表到质检，再到将增量的增删改数据写到线上，置于一个"事务"当中，保障标签构建的原子性、幂等性。

• 数据存储层

1）存储降级：标签数据写入 Redis 作为主，HBase 作为备。

2）版本切换：标签构建每天一个版本存入 Redis，一旦发现当前版本数据有问题后，可以秒级一键切换到上个版本数据，降低业务影响。

3）多级缓存：重复请求的结果数据作为第一层缓存，以快速返回结果，提升服务响应，同时也降低了第二层缓存压力。

• 服务层

1）熔断重试：推进调用方设置熔断机制，以及设置合理的重试机制，从最大程度上降低服务方故障或抖动的影响，保障调用方请求成功率。

2）服务限流：当调用方的请求量突增时，能够通过限流规则保护服务稳定性，避免雪崩。

3）缓存 HA：因业务特性调用方重复请求率高，设置第一层缓存必要性强，而且要保障其高可用，因此为解决 Redis 单点和抖动问题，设计了双写双读，择优返回，进一步提升了返回数据成功率。

4）故障降级：当请求是非重复时，根据 Key 进行 Hash 查询全量数据的第二层缓存 Redis，并且随机部分流量查询 HBase，进行抽样做一致性检查，保障主备存储的数据一致性。如果 Redis 发生故障，则可降级查 HBase，将影响控制到最小。

5）返回值监控：服务方返回给调用方的结果数据做实时监控，有异常波动可及时发现。

5.2.2 部署环境保障

在服务部署层面，分别从容器化和资源隔离方面做了稳定性保障。

• 容器化部署

为保障标签服务 HA，基于容器部署，容器化本身就是跨机房，再一个如果某个服务的容器挂掉，能够自动被驱逐，保障服务的容错性；另外 HPA 机制能够在流量突变情况下容器自动水平扩缩容，进一步保障服务集群的高可用。

• 资源隔离

为降低业务线之间的故障互相影响，按业务线和调用方重要程度两个维度进行拆分隔离，并且是服务和第一层缓存均独立隔离，尽可能得降低故障范围。

5.3 实时标签

关于实时标签在业务和开发两方面都有痛点。通常的离线标签在某些场景下是不符合业务诉求的，例如针对酒店新老客优惠策略无法及时触达；在实现上使用 Flink API 方式能满足需求，但开发成本高，周期长，无法像离线标签一样运营同学能自助完成。

解决实时标签场景问题，面临的挑战如下：

• 构建实时标签如何降低门槛，运营可自助
• 同一个标签的实时与离线数据如何融合

实时标签架构如下图所示：

实时数据源包括后端日志、前端埋点以及业务库 Binlog，数据进入 Kafka/QMQ 实时数据流通道，然后通过 FlinkSQL 进行实时标签构建，支持UDF以及从Redis中获取维度数据。构建之后分为两条链路，一条是实时规则的触发，匹配业务策略后触达 C 端用户，这条链路目前已更进一步降低门槛，通过可视化配置的方式配置触发规则；另一条是与离线标签的融合，离线和实时标签的数据都同步到 Redis，提供标签服务 API，由业务系统调用触达 C 端用户。

总结来看，通过 FlinkSQL 化/可视化配置降低了实时标签的构建门槛，通过 Lambda 架构实现了离线与实时数据的融合。

5.4 人群圈选

人群圈选是营销动作的重要一步，支持基于全业务用户行为和已有标签作为圈选条件，运营同学可进行拖拽式与或非圈选。

此场景下面对的技术挑战主要是：

• 数据量大：单个人群数据量上亿，并需支持多个人群交叉组合
• 计算复杂：需基于用户行为、已有标签、人群等再组合，几十个条件的与或非条件查询，进行预估和洞
• 查询速度要求高：运营需不断调整条件，获取预期数量的人群包，做精确去重，要求 5 秒内返回结果

我们采用 ClickHouse 作为数据存储和计算，其自带的 Bitmap 函数高度契合了与或非的逻辑查询，并且能够节省存储空间，实现了查询时长平均 2 秒。

以上图圈选的人群包为例，圈选条件为访问过机票或酒店频道的男性用户，其逻辑是（A 或 B）且 C，对应的人群为图中阴影部分，在 ClickHouse 中 SQL 伪代码实现为：

select bitmapCardinality (bitmapAnd(C, bitmapOr(A, B))) from tag_bitmap

人群圈选的技术架构如下图所示：

基础数据层： 基础数据以 Hive 表的形式存储，主要包括行为表和标签表两大类。行为表包括搜索、详情、下单等行为，标签表包括基本属性、偏好属性、关系属性等标签。两者通过 IDMapping 将用户拉齐归一。

数据计算层： 将 Hive 表数据导入 ClickHouse ，行为表存为分布式表，标签表存为分布式表后转为 Bitmap 表。

数据应用层： 即人群圈选模块，运营同学基于用户标签和行为，拖拽条件组合进行预估、洞察、生成人群包。预估和洞察对及时性要求高，通过 ClickHouseSQL 查询 ClickHouse 实现秒级响应；生成人群包对及时性要求不高，通过 HiveSQL 查询 Hive 进行周期或一次性构建。

三、CDP 总结应用

1. 运营闭环

经过多年的系统化建设，CDP 包含了标签生产、标签服务、用户分群、营销策略、用户触达、效果分析六个环节，实现精细化运营全链路闭环。

2. CDP 价值

CDP 带来的价值包括：

• 赋能业务：标签定义灵活，支持多变的业务诉求，覆盖业务线 15+，业务场景 30+；高价值标签沉淀，复用性高，ROI 相对提升 5 倍。
• 降本增效：一站式运营平台，全流程全自助，极大降低开发成本，运营效率相对提升 3 倍。
• 技术能力：标签服务可用性 99.99%，QPS20万（疫情恢复后峰值30万+）， 查询响应时长 P99 为 5ms，查询成功率 99.999%；人群包预估/洞察分析查询平均 2 秒。
• 价值成果：获得去哪儿旅行 2021 年度金项奖。

3. CDP 应用

基于"人货场"的精细化运营活动，去哪儿旅行实际的业务应用场景，已涵盖了方方面面，从用户和商品两个角度来看，应用举例如下

3.1 用户（人）运营

• 召回：圈选流失用户，发短信/PUSH
• 促活：将中秋促销活动信息触达给潜在用户，促进用户活跃
• 转化：针对亲子用户，推荐亲子酒店/房型，提升转化率
• 营收：增值服务
• 降损：黑产用户识别与过滤
• 用研：用户体验改版前，圈选用户做分析、调研

3.2 商品（货）运营

• 标签展示：APP 内各种标签展示，例如低价机票、特价酒店
• 特定类型酒店活动：五一劳动节推出豪华酒店优惠活动
• 特定区域酒店促销：考公打印准考证期间，考场附近酒店降价促销

四、CDP 未来展望

1. 丰富模型类标签

基于算法能力输出高价值数据，应用于各类场景，赋能业务。

2. 覆盖更多场景

与BI平台联动，进行丰富的分析和决策，或反向构建标签、圈选人群。

3. 平台智能化

智能选最优的触达策略，既能使 ROI 最高，又不骚扰用户。选定优质目标人群营销后，识别出关键特征扩充用户，进行智能迭代，既提升覆盖又提升转化率。

问答环节

Q：标签是人工标注的吗？

A：打标签主要分为三个部分：

规则类标签：规则类标签是支持拖拽自由排列组合的；

业务场景标签：通过 SQL 实现业务场景需要的标签；

模型类标签：由算法模型产出的标签，例如 RFM 模型、生命周期模型等

Q：针对用户触达的回收分析，系统是如何知道哪些在线用户已触达并进行了使用，该反馈机制是如何构建的？需要和业务系统进行打通吗？

A：对于触达是有不同类型的，例如 PUSH 会和第三方系统进行打通，弹窗、标签展示、站内信等方式是直接通过 APP 进行回收的。不同的方式会采用不同的实现策略。

Q：标签的质量是如何进行评估的？是如何透传给用户的？

A：通过质检模块，会将质检后的结果直接展示在标签上，包括各种维度的质检，可以理解为标签的元数据。比如数据量、波动率、活跃用户覆盖度、年龄比例分布等。这些详细信息会在标签详情页进行展示，用户可以直观的看到每个标签的质检结果，进而根据自己的实际需求对标签质量进行评估。

Q： 标签内容是如何产出的？是通过平台开发的吗？允许用户自定义且满足质检要求后生成吗？

A：我们建设 CDP 的主要目的之一就是释放开发资源，让运营和产品同学直接参与进来，基于平台本身实现全流程全自助的实现各类需求，所以标签内容很大一部分是自助产生的。此外，数据团队也会出"官方标签"，从全业务线的层面产出标准的基础的标签供全司使用。

以上就是本次分享的所有内容，最后为大家带来一个内推信息，欢迎优秀的你加入驼厂~

【内推链接】：app.mokahr.com/recommendat...