投稿入口|热门专题|网站地图|移动官网|微信编辑器|小程序商店
您的当前位置:网站首页 > 用户运营 > 正文

携程是如何做用户画像的

来源:未知 编辑:周源 时间:2018-09-28 23:59:47 阅读:

  用户画像作为“大数据”的核心组成部分,在众多互联网公司中一直有其独特的地位。作为国内旅游OTA 的领头羊,携程也有着完善的用户画像平台体系。目前用户画像广泛用于个性化推荐,猜你喜欢等;针对旅游市场,携程更将其应用于“房型排序”“机票排序”等诸多特色领域。

  本文将从目的,架构、组成等几方面,带你了解携程在该领域的实践。

  1.携程为什么做用户画像

        首先,先分享一下携程用户画像的初衷。一般来说,推荐算法基于两个原理“根据人的喜好推荐对应的产品”“推荐和目标客人特征相似客人喜好的产品”。而这两条都离不开用户画像。

  根据用户信息、订单、行为等等推测出其喜好,再针对性的给出产品可以极大提升用户感受,能避免用户被无故打扰的不适感。同时针对不同画像的用户提供个性化的服务也是携程用户画像的出发点之一。

  2.携程用户画像的架构

        携程用户画像的产品架构

      如下图所示,携程用户画像的产品架构大体可以总结为:

   携程是如何做用户画像的

    1.注册

    2.采集

    3.计算

    4.存储/查询

    5.监控

    所有的用户画像都会在”UserProfile 平台”中进行注册,由专人审核,审核通过的画像才可以在“数据仓库”中流转;之后会通过用户信息、订单、行为等等进行信息采集,采集的目标是明确的、海量的、无序的。

  信息收集的下一步是画像的计算,携程有专人制定计算公式、算法、模型,而计算分为批量(非实时)和流式(实时)两种,经过严密的计算,画像进入“画像仓库”中;而根据不同的使用场景,我们又会提供实时和批量两种查询API 供各调用方使用,实时的服务侧重高可用,批量服务侧重高吞吐;最后所有的画像都在监控平台中得到有效的监控和评估,保证画像的准确性。

  携程用户画像的技术架构

    携程发展到今天规模,更强调松耦合、高内聚,实行BU 化的管理模式。而用户画像是一种跨BU 的模型,故从技术架构层面,携程用户画像体系如下图所示。

  携程是如何做用户画像的

   各BU 都可以贡献有价值的画像,而基础部门也会根据BU 的需要不断制作新的画像。画像经过开源且经我们二次开发的DataX 和Storm 进入携程跨BU 的UserProfile 数据仓库。在仓库之上,我们会有Redis 缓存层以保证数据的高可用,同时有实时和借助elasticsearch 两种方式的API,供调用方使用。

  该架构有如下关键点:

        1.有异步和实时两种通道满足不同场景、不同画像的需要,事实类画像一般采用实时计算方式,而复合类画像一般采用异步方式。

  2.携程强调专人专用, 每个人做自己最适合的事。故整个是多个团队合作完成的,其中包括但不限于各BU的开发、BI,基础的开发、BI等。

  3.所有API都是可降级、可熔断的,可以根据需要切数据流量

  4.由于用户画像极为敏感,出于数据安全的考虑,我们查询服务有严格的权限控制方案,所有信息必须经过授权才可以访问。

  5.出于对用户画像准确性负责的目的,我们有专门的UserProfile数据可视化平台监控数据的一致性、可用性、正确性。

  上述是用户画像的总体描述,下面我将详细分享各个细节。

  携程用户画像的组成

        信息采集

        基础信息的采集是数据流转的开始,我们会收集UserInfo(比如用户个人信息、用户出行人信息、用户积分信息)、UBT(用户在APP、网站、合作站点的行为信息)、用户订单信息、爬虫信息、手机APP 信息等。而上述每个基础信息的采集又是一个专门领域。比如下图展示了用户订单信息采集流程。

  画像计算

   携程是如何做用户画像的

     基础信息是海量的、无序的,不经加工没有太大的价值。故用户画像的计算是数据流转的关键所在。我们的BI 团队会制定严密的公式和模型,根据场景的需要,制定规则和参数,对采集信息做异步计算。这样的计算由于耗时较长,一般我们会采用T+N 的方式异步更新,根据画像的不同,数据新鲜度的要求亦不同。动态和组合标签大多采用异步方式计算更新。Hive、DataX 等开源工具被使用在这个步骤中。

  而有些画像是事实或对新鲜度要求比较高的,故我们会采用的流式方案去实时更新计算。比如下图,UBT(用户行为数据)使用消息通道Hermes 对接Kafka+Storm 为UserProfile 的实时计算提供了有力的支持。

  信息存储

  携程是如何做用户画像的

    用户画像的数据是海量的, 被称作最典型的” 大数据”, 故分布式存储、分片技术、缓存技术被必然的引入进来。

  携程的用户画像仓库一共有160 个数据分片,分布在4 个物理数据集群中,同时采用跨IDC 热备、一主多备、SSD 等主流软硬件技术,保证数据的高可用、高安全。

  由于用户画像的的使用场景非常多、调用量也异常庞大,这就要求用户画像的查询服务一定要做到高可用。故我们采用自降级、可熔断、可切流量等方案,在仓库前端增加缓存。如下图所示,数据仓库和缓存的存储目的不同,故是异构的。

携程是如何做用户画像的

       高可用查询

          响应时间和TPS 是衡量服务可用性的关键指标,携程要求所有API 响应时间低于250ms( 包括网络和框架埋点消耗),而我们用户画像实时服务采用自降级、可熔断、自短路等技术,服务平均响应时间控制在8ms(包括网络和框架埋点消耗),99% 响应时间控制在11ms。

  大部分场景都是通过单个用户获取用户画像,但部分营销场景则需要满足特定画像的用户群体,比如获取年龄大于30 岁、消费能力强、有亲子偏好的女性。这种情况下会返回大量用户,此时就需要借助批量查询工具。经过多次技术选型,我们决定采用elasticsearch 作为批查询的平台,封装成API 后很好的支持上述场景。

  监控和跟踪

    携程是如何做用户画像的

    在数据流转的最后,数据的准确性是衡量用户画像价值的关键指标。

  基于高质量信息优于大数量信息的基调,我们设置了多层监控平台。从多个维度衡量数据的准确性。同时我们还要监控数据的环比和同比表现,出现较大标准差、方差波动的数据,我们会重新评估算法。

  上述所有环节组成了携程跨BU 用户画像平台。当然技术日新月异,我们也在不断更新和局部创新,或许明年又会有很多新的技术被引入到我们用户画像中,希望我的分享对你有所帮助。

  携程是如何做用户画像的

    作者简介周源,携程技术中心基础业务研发部高级研发经理,从事软件开发10 余年。2012 年加入携程,先后参与支付、营销、客服、用户中心的设计和研发。

图文精选:

Copyright©2012-2030小蚂蚁信息网版权所有 站长QQ:1614558876 粤ICP备14061018号-1


郑重声明:本网站资源、信息来源于网络,完全免费共享,仅供学习和研究使用,版权和著作权归原作者所有,如有不愿意被转载的情况,请通知我们QQ1614558876删除已转载的信息。

知道创宇云安全
Top