摘要： 用户画像作为“大数据”的核心组成部分，在众多互联网公司中一直有其独特的地位。 作为国内旅游OTA的领头羊，携程也有着完善的用户画像平台体系。目前用户画像广泛用于个性化推荐，猜你喜欢等;针对旅游市场，携程更将其应用于“房型排序”“机票排序”“客服投诉”等诸多特色领域。
用户画像作为“大数据”的核心组成部分，在众多互联网公司中一直有其独特的地位。
作为国内旅游OTA的领头羊，携程也有着完善的用户画像平台体系。目前用户画像广泛用于个性化推荐，猜你喜欢等;针对旅游市场，携程更将其应用于“房型排序”“机票排序”“客服投诉”等诸多特色领域。本文将从目的，架构、组成等几方面，带你了解携程在该领域的实践。
首先要介绍一下用户画像
什么是用户画像
用户画像又称用户角色，作为一种勾画目标用户、联系用户诉求与设计方向的有效工具，用户画像在各领域得到了广泛的应用。我们在实际操作的过程中往往会以最为浅显和贴近生活的话语将用户的属性、行为与期待联结起来。作为实际用户的虚拟代表，用户画像所形成的用户角色并不是脱离产品和市场之外所构建出来的，形成的用户角色需要有代表性能代表产品的主要受众和目标群体。
用户画像，简单来说就是通过一系列简短、精炼、易识别的语言来描述一个人/物。
但是要强调一下：用户画像不是一个数学问题，也不是技术问题，实际上是一个业务问题。关键在于我们希望从哪些角度去了解我们的用户，这个是跟我们的目的相关的。
比如，我们想追求范冰冰，那关注点应该是婚姻情况/恋爱情况，喜欢吃什么，有什么爱好;那如果我们是希望给她推荐化妆品，那关注点可能就是，皮肤是不是敏感、油性还是干性这些了。关键还是业务问题，但是用户画像的实现更多是技术问题，主要是给用户打标签。
用户画像的八要素
做产品怎么做用户画像，用户画像是真实用户的虚拟代表，首先它是基于真实的，它不是一个具体的人，另外一个是根据目标的行为观点的差异区分为不同类型，迅速组织在一起，然后把新得出的类型提炼出来，形成一个类型的用户画像。一个产品大概需要4-8种类型的用户画像。
用户画像的PERSONAL八要素
P代表基本性(Primary)：指该用户角色是否基于对真实用户的情景访谈;
E代表同理性(Empathy)：指用户角色中包含姓名、照片和产品相关的描述，该用户角色是否引同理心;
R代表真实性(Realistic)：指对那些每天与顾客打交道的人来说，用户角色是否看起来像真实人物;
S代表独特性(Singular)：每个用户是否是独特的，彼此很少有相似性;
O代表目标性(Objectives)：该用户角色是否包含与产品相关的高层次目标，是否包含关键词来描述该目标;
N代表数量性(Number)：用户角色的数量是否足够少，以便设计团队能记住每个用户角色的姓名，以及其中的一个主要用户角色;
A代表应用性(Applicable)：设计团队是否能使用用户角色作为一种实用工具进行设计决策。
L代表长久性(Long)：用户标签的长久性。
这里的标签，就是刚才我们提到的观察的一个角度，比如，性别、年龄、爱好、家庭情况、购买能力等。
具体来讲，当为用户画像时，需要以下三个步骤：
第一步：数据采集，因为我们用户画像是为了了解用户，因此需要收集用户所有的数据，主要包括静态信息数据、动态信息数据两大类，静态数据就是用户相对稳定的信息，如性别、地域、职业、消费等级等，动态数据就是用户不停变化的行为信息，如网页浏览行为、购买行为等;
第二步：分析这些数据，给用户打上标签和指数，标签代表用户对该内容有兴趣、偏好、需求等，指数代表用户的兴趣程度、需求程度、购买概率等;
最后将这些标签综合起来，我们对用户就有大概的了解了。
在完成用户画像之后，我们就可以用来精准营销，当然用户画像还有其他的应用场景，比如用户洞察、个性化推荐之类的应用，或者直接进行数据变现。具体的应用场景需要根据公司、业务的具体情况进行应用场景设计。
下面重点分析著名企业写成的用户画像分析系统！！！！
1.携程为什么做用户画像
首先，先分享一下携程用户画像的初衷。一般来说，推荐算法基于两个原理“根据人的喜好推荐对应的产品”“推荐和目标客人特征相似客人喜好的产品”。而这两条都离不开用户画像。
根据用户信息、订单、行为等等推测出其喜好，再针对性的给出产品可以极大提升用户感受，能避免用户被无故打扰的不适感。同时针对不同画像的用户提供个性化的服务也是携程用户画像的出发点之一。
2.携程用户画像的架构
2.1.携程用户画像的产品架构
如上图所示，携程用户画像的产品架构大体可以总结为
- 注册
- 采集
- 计算
- 存储/查询
- 监控
所有的用户画像都会在”UserProfile平台”中进行注册，由专人审核，审核通过的画像才可以在“数据仓库”中流转;之后会通过用户信息、订单、行为等等进行信息采集，采集的目标是明确的、海量的、无序的。
信息收集的下一步是画像的计算，携程有专人制定计算公式、算法、模型，而计算分为批量(非实时)和流式(实时)两种，经过严密的计算，画像进入“画像仓库”中;而根据不同的使用场景，我们又会提供实时和批量两种查询API供各调用方使用，实时的服务侧重高可用，批量服务侧重高吞吐;最后所有的画像都在监控平台中得到有效的监控和评估，保证画像的准确性。
2.2.携程用户画像的技术架构
携程发展到今天规模，更强调松耦合、高内聚，实行BU化的管理模式。而用户画像是一种跨BU的模型，故从技术架构层面，携程用户画像体系如上图所示。
各BU都可以贡献有价值的画像，而基础部门也会根据BU的需要不断制作新的画像。画像经过开源且经我们二次开发的DataX和Storm进入携程跨BU的UserProfile数据仓库。在仓库之上，我们会有Redis缓存层以保证数据的高可用，同时有实时和借助elasticsearch两种方式的API，供调用方使用。
该架构有如下关键点：
1.有异步和实时两种通道满足不同场景、不同画像的需要，实时类画像一般采用实时计算方式，而复合类画像一般采用异步方式。
2.携程强调专人专用，每个人做自己最适合的事。故整个UserProfile是多个团队合作完成的，其中包括但不限于各BU的开发、BI，基础的开发、BI等。
3.所有API都是可降级、可熔断的，可以根据需要切数据流量。
4.由于用户画像极为敏感，出于数据安全的考虑，我们查询服务有严格的权限控制方案，所有信息必须经过授权才可以访问。
5.出于对用户画像准确性负责的目的，我们有专门的UserProfile数据可视化平台监控数据的一致性、可用性、正确性。
上述是用户画像的总体描述，下面我将详细分享各个细节。
如上图所示，用户画像的注册在一个典型的Mis系统中完成，UserProfile数据的提供方在这里申请，由专人审核。申请时，必须填写画像的含义、计算方式、可能的值等。
3.携程用户画像的组成
3.1.信息采集
基础信息的采集是数据流转的开始，我们会收集UserInfo(比如用户个人信息、用户出行人信息、用户积分信息)、UBT(用户在APP、网站、合作站点的行为信息)、用户订单信息、爬虫信息、手机APP信息等。而上述每个基础信息的采集又是一个专门领域。比如下图展示了用户订单信息采集流程。
3.2.画像计算
基础信息是海量的、无序的，不经加工没有太大的价值。故用户画像的计算是数据流转的关键所在。我们的BI团队会制定严密的公式和模型，根据场景的需要，制定规则和参数，对采集信息做异步计算。这样的计算由于耗时较长，一般我们会采用T+N的方式异步更新，根据画像的不同，数据新鲜度的要求亦不同。动态和组合标签大多采用异步方式计算更新。Hive、DataX等开源工具被使用在这个步骤中。
而有些画像是事实或对新鲜度要求比较高的，故我们会采用Kafka+Storm的流式方案去实时更新计算。比如下图，UBT(用户行为数据)使用消息通道Hermes对接Kafka+Storm为UserProfile的实时计算提供了有力的支持。
3.3.信息存储
用户画像的数据是海量的，被称作最典型的”大数据”，故Sharding分布式存储、分片技术、缓存技术被必然的引入进来。
携程的用户画像仓库一共有160个数据分片，分布在4个物理数据集群中，同时采用跨IDC热备、一主多备、SSD等主流软硬件技术，保证数据的高可用、高安全。
由于用户画像的的使用场景非常多、调用量也异常庞大，这就要求用户画像的查询服务一定要做到高可用。故我们采用自降级、可熔断、可切流量等方案，在仓库前端增加缓存。如下图所示，数据仓库和缓存的存储目的不同，故是异构的。
3.4.高可用查询
响应时间和TPS是衡量服务可用性的关键指标，携程要求所有API响应时间低于250ms(包括网络和框架埋点消耗)，而我们用户画像实时服务采用自降级、可熔断、自短路等技术，服务平均响应时间控制在8ms(包括网络和框架埋点消耗)，99%响应时间控制在11ms。
大部分场景都是通过单个用户获取用户画像，但部分营销场景则需要满足特定画像的用户群体，比如获取年龄大于30岁、消费能力强、有亲子偏好的女性。这种情况下会返回大量用户，此时就需要借助批量查询工具。经过多次技术选型，我们决定采用elasticsearch作为批查询的平台，封装成API后很好的支持上述场景。
3.5.监控和跟踪
在数据流转的最后，数据的准确性是衡量用户画像价值的关键指标。基于高质量信息优于大数量信息的基调，我们设置了多层监控平台。从多个维度衡量数据的准确性。比如就用户消费能力这个画像，我们从用户等级、用户酒店星级、用户机票两舱等多个维度进行验证和斧正。同时我们还要监控数据的环比和同比表现，出现较大标准差、方差波动的数据，我们会重新评估算法。
上述所有环节组成了携程跨BU用户画像平台。当然技术日新月异，我们也在不断更新和局部创新，或许明年又会有很多新的技术被引入到我们用户画像中