编辑整理:申新兴 出品平台:DataFunTalk 导读:DMP是一个大家讨论已久的话题,尤其广告领域,是以DMP为基础来展开工作的。由于每个公司所面临的业务场景不同、问题不同,所以在具体落地时的做法也不尽相同。今天主要和大家分享贝壳如何进行DMP落地。 主要内容包括:
从几个案例出发介绍 1. APP消息推送 DMP的数据与贝壳APP的推送系统整合后,可以做到千人前面来推送消息,避免用户收到的推送消息千篇一律、一模一样。比如,有用户偏好北京回龙观总价400万的两居室,那我们可以在推送文案以及文案的落地页上加入跟用户感兴趣房子相关的一些数据,这样用户点击的意愿就会被提高很多。 2. DSP广告 贝壳的推广有一部分是DSP广告,也即我们在刷百度信息流的时候会刷到贝壳的广告。最早的投放方式是基于城市维度,每个人看到的都是和自己所在城市相关,比如北京的用户只看到了北京的一些广告文案。但是和DMP结合之后,就会跟兴趣挂钩。比如你昨天浏览了一个小区,那么第二天系统推送的时候,就会把这个小区的文案放在推送内容里面,这样用户的点击率意愿就会提高很多。进而整个广告的CTR也提升了,大概提升五到十倍左右,效果还是非常不错的。 3. 站内推荐 APP的首页有三部分:第一部分是专属二手房源,属于导购页的一个分发,是一个导购专题,里面都是关于房子的一些专题信息,这些专题信息也是和用户兴趣挂钩的;第二部分是列表页,业务方会根据用户不同的兴趣给出不同的排版策略,排新房、排租房与用户兴趣相关,这里的策略就是依据DMP的数据做的;第三部分是整个房源列表,这块的展示也是基于DMP做到千人千面,把用户最感兴趣的一些房子第一时间展示给用户,吸引用户发生浏览、进而提升留存和转换。 4. 搜索 搜索,跟推荐类似,都是把用户最感兴趣的一些房源展示给用户,促进用户留存。 5. 潜客召回 我们通过一些数据分析会发现,用户跟经纪人产生联系之后,它后续转委托以及转带看的概率就会高很多。所以我们会实时去计算用户的数据,当用户的搜索、浏览房源、以及查看经纪人的相关信息等行为量达到一定程度后,我们计算认为他的行为足够丰富,这个时候就会做潜客召回,也即给用户弹一个框,引导用户去留资,留资完后就把其信息分发给经纪人,这样经纪人通过电话就可以与用户产生联系。 6. 商机引导 这是IM场景下的一个例子,就是当用户跟经纪人产生联系后,我们会把用户的画像数据推送给经纪人,经纪人可以直观地了解用户的偏好,方便其更好的去与客户进行沟通,如果沟通效果不错,则客户会留下手机号,之后顺带的就会产生一次委托,成为委托客。客户成为委托客后,经纪人就可以在委托客分析B端查看到客户更详细的一些信息,比如说最近的活跃状态,最近的一些行为数据,浏览了哪些小区,所浏览小区房价的变化趋势,还有客户喜欢什么时间在线上浏览、喜欢什么时间出来带看,这些信息可以辅助经纪人做好后续的约带看安排。 从上面这些案例可以看出,无论是站外的老客召回,还是站内的精细化运营,DMP都在发挥着非常重要的一些作用。 那么到底什么是DMP呢? 其实DMP就是把用户各种各样的数据,包括结构化数据以及非结构化数据,进行整合计算然后标签化,通过标签来描述刻画用户I,理解用户。比如,通过标签,我们解读到一个北京的用户,想看郑州的房子,喜欢400万的两居室。通过用户的标签,我们可以非常直观的了解用户。然后基于这些结构化的标签数据,我们也可以很方便地跟各个下游系统做对接,实现站外或者站内的精细化运营。 1. DMP整体设计 贝壳DMP的整个架构设计,从下往上总共分成了五层: ① 最下面一层,也即第五层是数据收集层:收集层主要负责采集两类数据。第一类是用户在APP上的各种行为数据,比如搜索什么样的房子,浏览了什么样的房子,以及关注了什么样的房子等等。第二类是业务DB的各种线下数据,比如线下的带看、转委托等。这两类数据都会收集到hive里面。APP上用户的行为数据采集,通过系统罗盘来实现,这个系统是贝壳专门用来进行埋点管理和埋点数据收集的。 ② 第四层是数据加工层:数据采集到仓库里面后,会对数据进行各种的加工,然后产生相应的主题宽表。比如针对用户,我们会建一张用户主题宽表,将用户所有线上线下的数据打通,然后将数据整合到宽表里,基于这个宽表,我们可以做相关的数据分析以及模型计算。最终产出人房客的基础标签数据。 ③ 第三层是应用数据存储层:数据加工后产生的标签数据都是在hive里面的,大家知道hive其实是一个分析型的数据库,它的查询速度非常慢,是不能够支撑各种业务上高速查询的需求。所以我们需要一个应用存储层。目前对于存储,我们做了三种:第一种是Hbase,主要满足高并发场景下的KV高并发的查询;第二种是clickhouse,这是比较新的一种OLAP引擎,主要做SQL形式的人群圈包和人群的洞察;第三种是Mongo,在圈人群包之后,我们会将各种ID数据同步到Mongo,然后与业务系统对接满足业务上的查询需求。比如我们给用户推送消息时,push系统会把我们生产的人群包里面的设备数据拉走,然后按照设备给用户做推送,这里就会涉及到高稳定性高并发的分页查询。 ④ 第二层是应用层:基于存储层,我们搭建了应用层,主要提供的功能如下:
⑤ 最上面的一层就是API层:API层主要做的是一个统一的数据输出功能,且包含了鉴权、流控、容灾等各种控制。基于API层,我们可以对接各种业务系统,如推荐搜索、人群分析、push系统。另外,从数据层到API层,我们做了一个比较完整的监控报警功能,这样可以保证我们整个数据的可用性和API的高可用性。 2. 逐层介绍 接下来我们逐层看一下每层是怎么做的,以及遇到的问题和相应的解决方案。 ① 数据加工层: 在数据加工层,我们一共产出4种数据,2份偏基础的数据-基础数据、行为数据,2份偏核心的数据-偏好数据、预测数据。
在建设这些数据的过程中,我们遇到了很多问题。比较核心和突出的问题有三个。
② 存储层: 在存储层我们面对的问题主要有四个。
基于上述这些问题,我们首先看一下整体存储层的设计。
实时画像 另外,说一下实时画像。关于实时画像,大家都比较质疑,对于房产领域这种长周期的业务,到底有没有做实时画像的必要。在我们做数据分析的时候,发现用户生命周期是分几个阶段的,在早期的时候他的需求是不确定的,可能会随着时间的变化快速地发生变化,只有经过一段时间的沉淀之后,他的偏好才会稳定下来。如果没有实时画像的话,就无法捕获到用户前期兴趣的快速变化,在做差异化服务的时候效果就会打折扣,因此是有必要做实时画像的。具体的操作实践为:把线上的所有行为数据收集到kafka里面,线下所有的数据通过binlog的形式收集到kafka里面,然后通过行为聚合模块(也即Spark Streaming)消费kafka的数据,再加上房屋的各种数据,来统计汇总用户在各种各样行为上的次数。比如浏览了3次回龙观、浏览了5次400万以上的房等。基于这些次数,再结合kafka消费传递过来的用户信息,通过偏好计算模块和行为模块就可以得到用户的偏好数据。偏好数据的计算方式就是之前讲过的一个公式,用户行为次数乘以行为的权重再乘以时间衰减。表示偏好的得分数据最终存储到Redis里面,通过API对外提供服务。补充说明下,上述过程中的行为次数统计数据是存储在HBase中的,且汇总为小时级,每个小时会存一份数据,为了使偏好计算模块可以快速的查询数据,采用宽表的形式进行存储。实时画像主要应用在推荐和搜索,业务效果明显, CTR、CVR提升幅度在3%~10%+。 最后讲一下标签的快速上线,也就是如何把hive的数据快速的导入到CK里面。 这里我们通过配置化的管理,可以知道hive的表和字段在CK里面是映射到哪张表哪个字段,以及对应字段是枚举值还是个连续值。如果枚举值的话,就维护它的码表相关数据。通过Spark可以动态化的把数据导入到CK里面,导入CK后,就可以做标签配置了。通过这个标签配置管理,可以把CK的各种数据上线到标签层、以及标签的上下线、还有层级的维护。基于这些标签,就可以做可视化的圈包了,任意的拖拽标签之后,就可以看到这个标签组合下有多少人群,数量是多少,同时也可以做这种人群的各种细粒度多维度数据分析,比如这个人群的地域分布、性别分布、活跃情况等。 1. 全场景、海量用户覆盖 横贯打通了贝壳和链家两个APP,其中也整合了PCM站、APP、以及小程序,把所有数据整合到一起,总共涵盖4亿的用户;业务线涵盖了二手房、新房、租房、海外、装修,这些业务APP用户达到6000万。 2. 丰富的标签体系和强大的人群计算能力 总共有1300+标签, APP用户偏好覆盖率达到60%,每天产出200~500的人群包,分钟级的人群构建,秒级别人群预估。 3. 稳定、可靠的API服务 API目前已经有6亿的调用量了,高峰的时候有8亿的调用量,响应时间在五毫秒左右,SLA达到4个九。 贝壳是做人房客信息匹配的,标签在里面起到了非常好的连接作用,通过标签可以给客推荐房子,也可以给客推荐经纪人,同时也可以辅助经纪人更好地了解客户,同时也可以辅助经纪人给委托客推荐感兴趣的房子。通过分享中涉及到的案例,大家也能看到,DMP在业务上的应用还是非常广泛的。 后续我们的工作重心会放在完善数据的准确性和提高数据的覆盖率上,使其在业务上发挥更大的价值,同时我们也会做用户生命周期的管理。前面给大家讲的案例,都是在一个一个的点上发力,但是其实用户是需要有一个全生命周期的运营策略,比如怎么做站外触达、接下来怎么做站内精细化运营,站在一种统筹的高度做用户生命周期状态的管理,让用户尽可能的往成熟期去发展,然后最终产生商业价值。 今天的分享就到这里,谢谢大家。 |
|