建立用户画像的一些思考

引用一段话：

用户画像将产品设计的焦点放在目标用户的动机和行为上，从而避免产品设计人员草率地代表用户。产品设计人员经常不自觉的把自己当作用户代表，根据自己的需求设计产品，导致无法抓住实际用户的需求。往往对产品做了很多功能的升级，用户却觉得体验变差了。


在大数据领域，用户画像的作用远不止于此。用户的行为数据无法直接用于数据分析和模型训练，我们也无法从用户的行为日志中直接获取有用的信息。而将用户的行为数据标签化以后，我们对用户就有了一个直观的认识。


同时计算机也能够理解用户，将用户的行为信息用于个性化推荐、个性化搜索、广告精准投放和智能营销等领域。

这也是建立用户画像的初衷，能更全面更准确的了解用户，从用户行为 到数据处理后建立一套用户画像体系，能有效的实现业务增长，精准投放，营销，减少企业产品的推广成本，提高用户体验。

那用户画像建立应该从哪些方面入手呢？或者是什么样的呢？

说通俗一点就是打标签，怎么能打出更准确的标签也是建立用户画像的一个思考点，那用户标签从哪来？当然是从行为来。那有哪些标签？有哪些标签应该是根据业务需求来。

假如有一个用户A ，我们把他抽象成一个用户模型，首先用户A肯定会有基本属性，例如姓名 年龄 体重 性别 联系方式 学历 职位类型 等等这些描述用户画像主体特征 这些我们可以建立一个“用户画像主体”，这里“用户模型”与“用户画像主体”是一对一的关系，很好理解 用户A只能有一个名字 一个性别 一个学历 一个职位。

有基本信息了，再扩展该用户A的喜好行为，建立用户“画像条目”，如研究方向、爱好等。“用户画像主体” 跟 “用户画像条目” 是一对多关系，用户A喜好很多，研究的方向也很多 每一种条目都能与该用户建立起联系。

好了，如果说业务要求是对用户建立信用维度来判断一个用户的信用如何，这是关于用户信用方面的，现在再加上一个，业务要求建立用户浏览我们xx商城喜好什么类型的物品,那我们就建立另外一个维度关于用户喜好物品的类型标签，这写维度抽象处理就是“用户画像因子”  描述用户画像因子，更多承担配置项的职责，这就实现了画像可扩展。

从多个业务角度看 多个具有相同业务属性的画像因子可以将其分为一类，组成一个画像类型，一般是按业务线划分的，比如用户A  浏览xx商城7天的搜索关键词  xx商城里加入购物车的物品类型 xx商城7天的登录情况 这里三个画像因子就可归于xx商城画像类型，如果该公司还有其他业务线，比如这个用户A又去逛xx论坛 那就能计算他7天浏览的板块有哪些 收藏点赞的帖子是哪些类型 最近登录的客户端是什么  这些就可以归于论坛画像类型。画像类型可看作是画像条目的更细分类。

扩展点：

• 随着业务迭代，如果要扩充用户画像主体特征，则对“用户画像主体”进行扩展，注意保持领域边界，不要过度膨胀。
• 更多的是对用户画像多维度特征的扩充，则对“用户画像类型”，“用户画像因子”新增配置，“用户画像条目”核心逻辑无需变动，接入层代码做适配即可。

用户画像通用的模型就建立起来了，但还是有很多问题值得思考的，比如存储上的选择，数据格式一致问题，多介质存储下数据一致性怎么保证，某一个维度【字段】怎么监控哪些程序在写哪些程序在读？

个人观点：

这里我觉得Hbase 就很适合作为存储介质，优势嘛就不说了 ，面向列 可以不断扩展用户维度，海量数据查询响应快「为啥不用hive?参考https://www.jianshu.com/p/290a13b9b85c」，对于画像来说，最多的就是读写操作频繁，不断的更新用户画像，不断的有程序用到画像信息，如果对实时性要求不高的业务，比如用户感兴趣的物品推荐，我们可以选择每天同步Hbase的画像数据到hive里 让部分程序去读hive 减少对Hbase的访问压力。

谈完存储再说说写入的问题，比如现在我想向Hbase中写入一条用户的某一维度值，比如通过日志行为分析出这7天用户A喜欢的物品类型有苹果手机和牛仔裤，那我们存的时候就要考虑后续如果有推荐程序要用的话 他怎么知道用户A的7天搜索这个维度读出来的是苹果手机和牛仔裤呢？这里就要统一每个字段的数据格式 让读和写保持数据一致，这里最好的办法是建立一套元数据体系，记录每一个维度的数据的信息，比如用户7天搜索喜好，存储介质Hbase和redis[就是Hbase和Redis都存一份]，数据格式在Hbase是string,以逗号分割，在redis是list，这样就有了约定，以后那个程序要写这个字段都要按照这个要求来，那问题又来了，我想知道这个字段这一周有没有被更新呢，有哪些程序在写，哪些程序在读这个字段呢？从Hbase中或许我们可以看到时间戳，但是还是很麻烦，何不在写的时候 在读的时候就记录下呢？是的  可以开发一套专门读写画像的一套工具包 SDK ，约定读写画像的程序都通过这个SDK去写和读，写的时候记录程序名 写入负责人 ，我写的字段有哪些，写的画像类型 等等信息，这样在SDK中就能获取读写相关信息 而且还可以统一的对数据进行msg序列化反序列化 节省存储成本[不知msg的参考https://www.cnblogs.com/Leo_wl/p/8143259.html#_label0] ，进行后续的字段跟踪，血缘关系查找。好了这一套下来基本就已经很齐全了，还有很多小的细节问题还是多去打磨，有时间再补充。