华为张华：降临-用户画像

原创张华中生代技术

作者：张华

作者介绍：华为LTC BI+AI 主任工程师

从2004年开始在数据服务领域工作，拥有13+年的“可怕”经验，专长在数据建模领域和数据架构领域。

在大数据技术栈领域，拥有5+年的“吓人”经验，专长在依据不同的业务场景，整合功能各异的开源软件，组合出高可用、高性能、高并发的数据架构。

这2年逐步转向AI领域，专长在机器学习与自然语言处理的应用领域。

在携程旅行网时，担任数据产品研发经理，负责传统BI形式的客户画像、基于大数据平台的广告引擎等；

在顺丰科技时，担任大数据部负责人，数据产品包括大数据Hive形式的客户画像“丰向标”、基于实时大数据的信息安全一体化平台“长安”、基于实时大数据的路由运筹一体化平台“擎天柱”等；

目前在华为担任LTC BI+AI主任工程师，架构BI need AI形式的客户画像、知识智能推荐、智能日历等。

一、客户画像的定义、逻辑分层

1.1 客户画像的定义

关于客户画像的定义没有明确统一的说法，不同的人不同的公司有不同的做法，我个人认为：实施客户画像项目就像登山，有些人登上主峰，有些人登上其他的峰顶，不论如何，在他们看来结果都是登上了这座山。

客户画像就像一座山的不同侧面，实施者可以用不同的手段、方式、思维来构建客户画像，在这个过程中，没有一个绝对正确或错误的分界线，相同的一点是：大家都在朝同一个方向去做，不管是2B还是2C，把客户数据的价值发挥出来，就是一个好的客户画像，这也是最高阶的过程。

1.2 客户画像的逻辑分层

客户画像分为三层：度量层、标签层、分类层。

度量层的主要作用是计算，对原始数据进行SQL处理，将其抽象成两大块内容：第一块是在度量层里形成主数据，这些主数据可能是缓慢变化或不变化的静态的东西，这部分对应上面标签层里的静态属性标签；另一块则结合电商和2C类产品用RFM模型来做，对应上面标签层里的动态行为标签。

那么RFM模型怎么来做度量呢？这个模型在电商类公司经常用到，比如用户订单/投诉/退款，都可以用这个模型。R是时间的维度，可以设定为三周/三天/三月，看三周/三天/三月是否有订单/投诉/退款；F是频次维度，近三周/三天/三月有多少次订单/投诉/退款行为；M比较容易理解，量即客单价。RFM是从电商演化来的，基于时间序列投射在客户身上进行度量，形成模型，不同公司有不同的RFM强化模型。

度量层把UDID分成两大块，一块是静态属性，一块是动态行为，所以标签层是在此基础上做了一些细化。

先说静态属性标签，主数据里的内容都可以演化出很多不同的静态属性标签。举个例子：主数据记录了身份证号码，在标签层可以基于这个数据做很多静态属性的扩展，比如年龄、性别、星座、籍贯等；或者从度量层里知道客户的信用卡，可以知道发卡行、币种，还可以结合通过爬虫或第三方购买的数据，知道信用卡的限额，再进一步扩展用户的维度，我们还能知道用户的收入水平、工作年限、消费水平等。

再来看动态行为标签，动态行为标签大部分与业务强相关。举个例子，RFM模型里记录了某个客户的投诉行为，或者通过不同维度统计了该客户投诉的特征，这样在标签层就能形成一些标签，例如这个客户在某些方面有投诉行为和倾向。

再举个例子，以寄快递的行为来做动态行为标签。度量层记录了一个客户最近有寄件行为，标签层会生成标签：该客户在某类产品上有过寄件行为，这是以内容为维度的行为标签；或该客户在哪两个城市之间有过寄件行为，比如一线城市到一线城市的寄件、一线城市到二线城市的寄件，诸如此类以城市为维度的标签。

各种各样的标签都是和业务相关的行为设定，这些标签在应用时可以直接提取使用。特别是进行精准营销时，可以直接提取标签层的标签，比如通过客户的年龄标签、地域标签、行为标签，来判断他到底是不是我们的某种类型的客户。

从主数据到静态属性标签、从RFM模型到动态行为标签，上文讲了很多规则，那这两层之间怎么转化呢？我们用SQL处理+规则引擎搭配来实现从度量层到标签层的转化。具体怎么理解呢？

在度量层已经度量出来很多维度，然后要形成标签，不同的客户之间是用同样的规则还是不同的规则是根据业务来决定的，比如一线城市的人在某一特征上的值要设定为80，二线城市的人在这一特征上的值就要设定成60，这些需要通过规则引擎去配，然后在SQL处理的时候动态绑定，而不是把所有规则都写在SQL里。

最上层是分类层，同样的标签可以给不同的分类去用，标签层和分类层是多对多的关系。前文提到，在标签层有很多类的标签，比如客户是不是喜欢用我们的产品、喜欢用什么样的产品等，在分类层要做出的判断是客户是在哪类生命周期。把标签层和分类层分开的原因是：在标签层中同时存在ABCDE五类标签，也许ABC可以形成一种分类，BCD可以形成另一种分类。

比如我想分类出高价值的客户，在标签层有多种组合方式，第一种组合方式是：寄件行为特别多，显而易见贡献值比较大；第二种组合方式是虽然寄件行为很少，但他在客户群中处于中心汇聚节点，也就是说他可能对我们的品牌有大的影响力，这样他也能成为我们的高价值客户。

标签层到分类层之间数据转化和处理建模的方式基本用的都是规则引擎，SQL参与的过程很少。在标签层已经码完了标签，分类层要做的是标签的抽象和组合，这个过程基本是由规则引擎在处理。

整体来说，客户画像的逻辑分层就是：最底层的原始数据经过SQL处理到度量层，再经过SQL处理+规则引擎到标签层，再经过规则引擎到分类层，最后形成完整的客户画像，在这中间SQL处理和规引擎有不同的处理方式，结合业务找到最适合自己的方式最重要。

二、顺丰速运的客户画像技术探索

本章节中引用的例子来自我之前工作过的公司——顺丰速运用到的技术探索的框架，因为这里基本上是一些大数据的集合，大家更有感触。所以通过这个例子来讲其中的技术环节和技术架构。

2.1探索实践

数据层分了两类：自有数据和外部数据。2B的客户画像和2C的客户画像怎么实现？先以2C来讲，每个公司的业务都差不多（有单一、混合、纵深的业务），都会形成自己的自有数据，外部数据又分为两类：主动爬取的数据和通过合法渠道购买的第三方数据。合法的数据交易平台慢慢开始展现出生命力，可以关注一下数据交易市场会给你提供哪类第三方数据。

这是一个高阶的技术栈，中间的每一块都有很细节的设计。

首先从自有数据和外部数据来看，这部分数据可以先同步到中转站，然后通过这个往数据库进行汇聚，也可以通过存库的方式来汇聚这些数据。自有数据一般是结构化的，外部数据基本都是半结构化的，先要做一些数据清洗和整理的工作才能往数据湖中去汇聚，结构化非结构化半结构化甚至其他类型的数据都可以在数据湖中汇聚。数据湖里可以再细分为已经清洗的数据和中间过渡的数据，这是由Hadoop决定的。

从数据到数据湖这一层应用到了一些开源的框架，主要包含的是一些主流软件：结构化数据处理用的是Sqoop+Flume；Flume +Kafka用来处理半结构化的数据；Spark Streaming用来做一些数据清洗的工作或者轻度关联工作，中间还用到了其他的工具。这些软件能应付80%的数据结构。

从数据湖往上看，对应相对来说没有做标准化处理的数据生态，往上用到的主要是Hive & Kylin，在这一环节不同的电商不同的厂商有不同的做法。

在数据仓库里有不同维的仓库，图中每个粉红色的方块都对应度量层，每个方块里有一套UDID、主数据、RFM强化模型，我们需要做的是把UDID进行拉通的准备，这里我们用的是图数据库，把每个新出现的UDID都放到一个EFG里去。

在数据仓库里有一个很重要的工序是把不同的UDID进行统一存放和关联，这一层的关联在上面一层拉通时需要被直接使用到。

在数据仓库可以看到Hive & Kylin有不同的做法：Hive相对来说体积更大，所有数据都会在这里存放一份；Kylin里会结合具体业务做一些子集的拆分，更方便做外部的应用。

到了标签层用户ID是一个S，在不同的烟囱里用户可能需要不同的ID来进行注册，或者通过外部数据进行关联，所以在标签池里的第一大点是UDID的摆放、罗列，并做一些特殊标记。第二点是用户的主数据，这些主数据就是从数据仓库的不同维里提取的注册信息，比如快递维里需要实名认证，电商维里不需要实名认证。

往后是各种各样的标签的规则梳理，有多少业务、应用，就可以用多少标签群组来做梳理。

挖掘分析怎么做？Spark+Drools+Anaconda。Drools是我们用到的规则引擎，存储很多规则供spark调用；Anaconda是一个Python，之所以不选择python而选用Anaconda的原因是：Anaconda更便捷，它预装了很多数据科学家常用的包，可以为我们创建不同的Python的虚拟环境。而且这是一个免费工具。

这是进入探索的第一步。客户画像没有最佳的技术栈，但有最佳实践，任何一家公司都有自己独到的东西，取决于自身技术程度、技术准备度、技术能力、团队以及硬件的水平。