华为张华|关于客户画像
作者介绍
张华，华为LTC BI+AI 主任工程师
从2004年开始在数据服务领域工作，拥有13+年的“可怕”经验，专长在数据建模领域和数据架构领域。
在大数据技术栈领域，拥有5+年的“吓人”经验，专长在依据不同的业务场景，整合功能各异的开源软件，组合出高可用、高性能、高并发的数据架构。
这几年逐步转向AI领域，专长在机器学习与自然语言处理的应用领域。
第62篇架构好文：5314字 | 8分钟阅读
客户画像的定义、逻辑分层
_____
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的虚拟环境。而且这是一个免费工具。
这是进入探索的第一步。客户画像没有最佳的技术栈，但有最佳实践，任何一家公司都有自己独到的东西，取决于自身技术程度、技术准备度、技术能力、团队以及硬件的水平。
做2C的客户画像有两类目的：品牌维系和精准营销。客户画像可以分得更细：包括营销响应、对品牌的态度、购买力、忠诚度、客户价值等，还可以看到客户的生命周期。
上图所示内容与客户画像的逻辑分层紧密相关，主要是用Spark+Drools来做规则的匹配和标签的组合，比如把一类标签和另一类标签组合在一起形成一个客户价值，把三种标签和另一种标签组合在一起形成品牌态度等。
上层应用提取的信息是来自标签层？度量层？还是数据仓库？其实各有千秋，业界并没有明确的好的做法，视业务而定。
2.2有趣的数据现象
现象一：A客户的历史寄件值是<5，寄件标签是“极低”，
却被认定是高价值客户？
因为ta的另一个度量值“历史收件量”>100，对品牌有传播力和影响力，所以ta是高价值客户。
现象二：B客户的历史寄件度量和收件度量标签是“极低”，
但却被认定是高价值客户？
因为ta的Id与外部爬取数据关联后，标记出是一个社区发现的中心点，所以ta是高价值客户。
2.3有趣的技术尝试
PrestoDB的探索——开源的分布式查询引擎。
度量层的数据是海量的，我们需要快速检查一些标签，看是否能为支撑决策做一些事情。
因此我们除了支持Hive的查询之外，还探索了PrestoDB的查询能力。如果你在分布式查询上需要有这样的一个摸索，可以试着用PrestoDB，其响应、处理能力和可靠性还是不错的。
ElasticSearch的探索
数据湖的持久化存储，除了选择Hadoop之外，还探索了把数据存储在ES中，实现半结构化数据进行快速检索。
想要知道用户的查单次数，以前这些数据都存在日志里，需要进行离线处理再到度量层里去，开销很大，我们的尝试是把日志文件扔到ES中去查询，并构建了一些报表。
2.4在做客户画像时一定会遇到的问题：
标签层之上的架构探索
客户价值可以由不同的规则组合得到，比如寄件量标签是“高”或者收件量标签是“高”，
标签层非稀疏性的架构探索
每个用户在度量层存在稀疏性特征，但是当抽象到标签层时，是不存在这个问题的。如果用户在某个度量上没有表现，是继续保持null还是用统计方法赋予缺省值，要结合业务区别对待。有很多做法，比如用一个平均值当成他的缺省值。
2C客户画像探索已经如汤沃雪
_____
为什么2C的客户画像都做得很不错，主要是因为数据源，2C客户画像的数据源有三种，
第一手数据指的是自有数据
第二手数据指的是爬虫数据
第三手数据指的是购买数据
显而易见，爬虫数据和购买数据是相对容易获取的，也容易关联。2C的客户画像是非常容易做的，这也是为什么我们做得更多的是精准营销和品牌维系，这是2C类公司天然的优势。
2B客户画像探索还在白云出岫
_____
2B企业也会收集客户数据，但是做得最多的还是2C的营销，比如携程收集了很多旅行社的旅游产品、导游评分等方面的数据，但最后还是为2C的客户服务。
从2C客户画像得知，一个好的客户画像往往得关联外部数据，但2B的数据，更多还是主数据和基本的RFM模型，很少以独立实体出现在爬虫数据范围内；
更困难的是，从其它渠道想获取到购买数据，几乎是不可能的。2B的客户画像在数据源上有天然瓶颈，所以2B更多的是做员工画像和组织画像。
想要加入中生代架构群的小伙伴，请添加群助手小姜的微信
申请备注（姓名+公司+技术方向）才能通过哦！
“做技术要懂管理，做管理要学模式”
突破是中生代社区新上架的图书
签名版即将售罄
购书后加上方微信可以进书友群
申请备注（购书）