大家可能经常会听到用户画像这个词，但是具体在做的时候又会觉得无从下手，或者认为只是常规的标签统计，这往往是一个误区。本人在某互联网企业从事了将近一年半的用户画像开发。从一个刚刚接触用户画像的小菜鸟，到现在逐渐成长为画像开发的主力程序员，中间有许多的感受与经验想总结下来，分享给大家，大家也可以讨论讨论。
用户画像的应用
用户画像是目前数据挖掘当中比较容易入门的一个领域。它比较热门的应用便是推荐，最近常说的千人千面的核心基础便是构建人群的画像，通过人群的不同画像来做到个性化推荐。另外广告也是非常需要用户画像的支持，通过个性化的广告推送，也可以提高广告的点击率，带来更高的广告收入。其次用户画像很多时候都是可以做为销售的线索打包出售给特定的公司和合作伙伴来直接获取利润或者交换数据。
如果我们将一个用户各方面的画像整合起来使用，它的身份，性别，教育程度，学历信息，收入大致范围，购买力，常用位置等等标签一目了然，一个人的整体形象就跃然纸上。你有时候会觉得随着用户画像的技术的完善，用户的隐私会越来越少。我目前供职的还仅仅只是一家中型互联网公司，用户量也并非很多，对用户的各种画像挖掘就已经到了一个令我震惊的程度，阿里腾讯等大公司的用户画像只会做的更加完善。
用户画像初相识
刚开始接触用户画像并非是我的意愿，所以对用户画像完全不了解就开始上手了。当时对用户画像仅有的直观影响就是给用户打标签，比如一个人是男的还是女的，有车还是没车，喜欢看什么文章之类的。如果做过机器学习项目的话，会发现这个就是我们平时自己提取的特征。事实上刚开始做的话，整天便是写sql，从数据仓库以及各种数据来源提取数据，按照一定的处理逻辑来规整数据，最后处理的数据以HIVE 表的形式存到 HDFS，Hbase，Redis。不同的是，我们在某个项目提取的特征只会用于这个项目，一般不会用于其他的地方。但是用户画像的一个基本要求画像必须是可以通用的。就需要有一系列的规范来保证每个字段必须是可解释的，HIVE 表的命名是有意义，数据的输出是规范一致的。一切的一切都应该是有文档来记录以保证画像的通用性。
用户画像的基本前提
用户画像最重要的其实就是用户了，有人说这个就是废话。其实不是的，我们做用户画像需要获取这个用户在我们公司网站 pc端，app，m端(在手机端登录公司的网站)所有的数据。只有获取了这个用户在我们公司所有的数据，我们才能获取这个用户在我们公司最完整的画像，否则这个用户的画像就是有失偏颇的，不会那么准。这个问题完全可以通过非技术的手段来解决，比如用一个标志来标识用户在 pc端，app,和 m端的访问行为，这个标志一般就是我们所说的公司账号。有些公司是强账号体系，比如腾讯的qq号，阿里的淘宝账户，微博的微博账户，所以这些公司的用户画像天然就可以做的比较好。但是大部分公司都没有这种强账号体系，厉害如百度迄今也没有自己的强账号体系。所以百度掉队不是没有原因的。
那么那些没有自己强账号体系的公司是不是就没法开发出自己的用户画像体系呢？其实也是可以折衷的，那就是用户连线。通过各种连接信息，将同一个用户来自pc端的 cookie，app端的device_id，m端的cookie 数据连接在一起。判断一个公司的用户画像水平基本可以通过用户连线这一块了解个大概，这个也是每个用户画像部门最核心的算法之一。但是通过用户连线来做的画像准确率毕竟比不上有强账号体系的公司。主要是是因为连线的覆盖率和准确率一般是矛盾的，如果连线的覆盖率低了，虽然准确率高了，但是连的用户少了，比如就连线100个用户，对整体画像的准确率不会有明显的提升。如果连线的覆盖率上去了，准确率往往会下降，你连线连一堆错的，还不如不连线。这中间的折衷往往是取决于业务本身的需求。
用户画像的类别
用户画像一般是分为两类的。一类是实时用户画像，这类画像的处理逻辑一般都很简单，要求迅速响应，实时处理。数据从kafaka过来，通过storm 等实时开源框架处理之后存入redis 当中。
第二类便是离线用户画像，这类用户画像是把当天业务方需要的用户画像提前算好，然后供给业务方使用。由于对数据的时效性要求不是那么的高，可以使用较复杂的处理逻辑或者各种离线机器学习模型来保证画像的准确性。数据一般存在HDFS 和 Hbase 里面。
离线用户画像的一般处理逻辑
离线的用户画像的数据来源一般是来自采集或者数据仓库。如果是某些特殊数据的话，可能得先经过反作弊团队的预处理，比如淘宝的刷单行为，某些品类异常的浏览行为等等。我们利用sql 从这些数据源获取到我们需要的数据以后，首先经过用户连线将同一个用户的行为全部连线到一起，然后利用 mapreduce 按照一定的处理逻辑进行处理。处理完的结果可以和历史的数据进行合并 插入到当天的分区表当中去或者存入到 hbase 当中。整体而言处理的逻辑是比较的清晰的。
图一 ：用户画像处理的一般逻辑
可能有同学会好奇？那么仓库的数据是从哪里来的。其实都是来自我们日常在这个公司网站点击，浏览，购买，评论等行为。这些数据由公司的前端埋点以后，会不断的由采集收到仓库进行整理，整理成当天的流量日志。大部分的画像标签的数据源都是流量日志。
用户画像的体系建设
单个的用户画像很好做，但用户画像真正想发挥用途，必须得建立起自己的体系来。这样才能对一个用户进行全方面的描述。打包卖给别人的话，也更加值钱。初步来看用户画像的体系建设应该包括几个方面
标签系统的顶层设计，具体就是我们这个标签系统系统需要为哪些业务方服务，需要涵盖哪些类别，需要做哪些标签
标签系统的维度系统建设，我们的画像对外输出，如果只是输出中文的话，不大好用，有时候也不大好处理，就需要我们将标签的输出的值数值化，维度化。整个标签系统的值都可以通过一个统一的数值系统或者向量系统来进行描述。
标签开发规范，这个是保证标签代码的可维护性，易读性。
标签系统的可扩展性，由于很多业务方都需要根据自己的需求来定制化标签，就要求我们的标签系统应该是可扩展的，外部业务方自己定制的标签如果符合我们标签的维度系统以及开发规范，就应该是可以扩展进我们本身的标签系统的，供给全公司使用。
标签对外平台的开发，所有的标签最好只能有一个统一的输出口径对外输出，这样就可以切实保证只有符合我们标签开发规范的标签接入其中，同时也能做好标签系统的权限管理。
用户画像当前的困境
目前大部分用户画像都是基于统计的方法来做的，这种方法的优点是基础准确率比较高，但是整体的覆盖率不会很高。比如我要在一个购物网站做用户感兴趣的商品的画像。如果我使用基于统计的方法利用用户在购物网站 pc，m，app端的点击，浏览，下单，购买等一系列用户行为来对用户打标签，只能够得到用户关于她／他 已经点击，浏览，下单，购买的商品的画像。但是其他商品，我虽然没有点击，不代表我对这些商品没有兴趣，可是基于统计的方法无法推广到这些用户没用点击，浏览，下单，购买的商品。
基于统计的方法无法进行更深层次的推广，也就是缺乏我们常说的泛化能力，只会死读书，不会举一反三。我们更多的会通过使用机器学习或者其他算法来尝试解决这个问题。遗憾的是对于业界来说，这种标签占整个用户画像体系的比例也不会很高。因为这种标签做的费时费力，而且效果不一定好。有一个很关键的原因，我们举一个例子来尝试说明一下。比如某个汽车网站想预测用户有车无车，很多时候该汽车网站通过和4s店合作等等途径能够获取到只有哪些用户确切有车。我们在预测的时候，可以把这些有车的用户当作正样本来处理。问题在于我们找不到确切无车的用户，相当于找不到负样本。
一般的做法是我们把流量日志当中那些不是确切有车的的用户都当作无车用户来看，也就是当做负样本来看。但是这个只能说明这些用户只是在该公司的数据库里是没有买车的，他现实生活中可能是有车的，但是该公司并不清楚这一点。这样做的后果就是负样本里面参入了正样本，更可怕的是参入的比例有时候我们也不大好估计。这种情况就会导致模型在训练的时候准确率下降。
这样看来很多基于机器学习的算法其实都有样本标注的问题，对于这类标注的问题，一方面我们可以通过其他不同的数据来源，相互验证来保证标注的数据尽量准确。一方面可以考虑一下无监督的学习算法比如聚类算法来解决这个问题。但是目前来看，还不大清楚有没有其他比较实用的方式来解决这类问题。
总结
从数据挖掘的不同方向来看的话，用户画像应该是最好入门的一个方向之一。它对技术人员的要求是会sql和mapreduce 即可。其他机器学习的知识可以一边学习一边上手。作为一个程序员，其实我内心一开始是很不喜欢用户画像这个岗位的，毕竟每天重复性的工作很容易让人疲倦。但他确实也非常的重要，是整个数据挖掘方向最靠近业务的一个方向了。很多时候，深度学习也好机器学习也罢都离业务太远了，有时候是无法落地给公司带来直接的产出，非常容易就被边缘化了。并且在互联网行业数据挖掘从业者的平均薪资也还不错。那么就常常会有一个问题，数据挖掘部门的整体人力成本很高，但是产出却相当的低，对于整个公司来看其实也是一个很大的负担。
所以对于我个人来说的话，技术是很重要的，但是技术本身是没有产出的，所以我要尽量去想办法让我的技术有产出并且是可以度量的。这点落在选择公司的时候，我更多的也会考虑这个部门有没有很有前景的业务，再看这个部门的方向是否是感兴趣的。这样能够最大限度保证我的技术有落地，有产出，不至于被边缘化，同时也能一直保持我对技术的热情。
