从千万到数十亿的用户画像系统实践总结

爱运营 • 2018年9月12日下午1:35 • 数据分析

大数据时代，互联网公司或终端设备公司服务器上都存储了海量数据，这些数据会被加工处理成面向公司内部运营或服务最终用户的各种数据产品，比如用户画像系统。这篇文章将基于笔者的实践经历来总结一下自己对用户画像的工作心得。

用户画像——白话篇

首先，讲一下什么是用户画像？一句话描述它就是：用服务器中的数据信息对用户进行人物属性、行为和喜好的刻画。有了用户画像，我们就有了所有的用户属性或标签（属性描述颗粒度小于等于标签描述颗粒度），也就知道该通过什么条件来对这些用户进行划分。例如，下面两行用户数据就是用户画像的基本属性和行为信息。

数据示例

用户画像英文是Persona，它的概念最早由交互设计之父 Alan Cooper 提出，“Personas are a concrete representation of target users.” 指真实用户的虚拟代表，是建立在一系列属性数据之上的目标用户模型。

然后，我们说一下它有什么价值？通过用户画像的分析，运营和产品借助 IT 系统便可以进行更好的用户关系维护或产品体验优化。比如针对喜欢阅读的用户进行年卡促销，并且消息送达时间点在手机活跃时段；分析上线产品新版本功能是否受欢迎；还可以作为推荐系统的特征库，为提供千人千面的推荐模型提供更多特征。

用户画像系统——技术篇

上面白话篇提到的用户画像数据和业务功能看起来很简单，但面对大数据，用 IT 系统实现其目标的过程却是不简单的。对于我们数据平台而言，要处理几个方面的问题：

一、数据的接入，即 ETL

二、数据仓库的建模梳理

三、画像标签体系的建立和模型加工

四、调度监控管理

五、数据产品系统服务

其技术架构如下图所示，紫色背景部分对应画像的标签体系和模型设计，橙色背景部分是基于用户画像数据构建的系统服务或特征模型。我们的用户画像系统版本历经1.0到2.0，再到3.0演进而形成现在的架构。

下面我用表格列一下每个版本的技术栈，功能和优缺点。

版本演进过程最原始的驱动力就是大数据的接入，它代表了业务的发展和数据量的增大，对任务调度、计算平台、数据模型都带来了挑战。对于画像系统，演进的方向就是拉通全域数据，构建符合业务需求的标签体系，并且对于批量计算的数据更新到交互分析引擎要达到 T+1 的及时性要求。版本的技术架构演进是为了解决数据量大和实时的问题，但对于基于数据而生的数据产品，不变的关键点还在于构建能够真正服务于业务和最终用户的标签体系，所以好的标签体系衡量标准应该是准确和全面。

我们的标签分为两类：事实类标签和挖掘类标签。事实类标签基于业务的维度和指标需求构建，例如某业务是否购买VIP就是维度，累计消费金额就是指标。挖掘类标签对象一般是性别、年龄、职业、收入和喜好这些很少能从业务数据直接获得的，所以对于这些重要的人口属性信息，又需要懂数据挖掘的人来构建，而能挖出来哪些属性，又要看有什么数据。笔者认为，标签体系也是依赖业务的发展演化出来的，初始我们可以依照一个方法论去构建这个体系，真正落实成什么样子，还要看我们有什么数据原材料。

用户画像系统——反思篇

以上我已表明用户画像系统的最基础关键点是标签体系构建，落实到数据层面就是我们的画像模型数据建模问题。在拉通全域数据时，我们会发现不同的业务系统具备的用户标识是不一样的，有的是手机标识码，有的是手机号，有的是邮箱。而真实世界，一个自然人可能不止有一个终端设备，不止有一个手机号和邮箱，这就给用户画像带来一个识别自然人的问题。阿里针对这个问题的项目是One ID，我们目前的解决方案是上面技术架构中的统一ID，实际上要解决的是一个事情，不过处理方法各异。在营销场景，如何解决这个问题，还是取决于业务需求。但在数据探索和挖掘场景，我们应该需要构建一个针对自然人的 ID，而其他类型ID都归属于这个自然人ID，并且需要维护它们之间的绑定关系。