https://zhuanlan.zhihu.com/p/27329292

贝聊是一款提供给幼儿园使用的APP，兼具“工具属性”、“社交属性”和“资源属性”，主要的用户构成是家长和老师。APP里面除了常见的工具属性功能外，还有类似于微信朋友圈的动态发布功能，也有类似于小米论坛的贝聊社区讨论模块，更有类似于慕课网的孩子学习课程资源平台，等等；所以贝聊的数据对象、数据主题、数据类型、数据维度和数据关系都十分丰富，面对数据应用业务场景也很多。这种背景下，如何串联起来各种应用场景、如何找到数据应用中心环节、如何构建弹性的数据产品体系、如何满足业务灵活多变的数据需求，等等问题立马就凸显出来，十分尖锐。以一系列的画像产品为核心，构建育儿大数据生态体系，串联各类数据应用场景，是贝聊大数据提出的解决方案之一！

同时，因为贝聊用户高活跃度的特点，所以用户行为数据的增长几乎呈指数化上升，目前每月的高价值用户行为数据规模增长量已是TB级。这些数据的积累为画像产品的构建打下了重要基础，也是画像产品可行性论证的重要指标（数据规模、数据颗粒度、数据频率、数据价值、数据有效性……）。

在这里，我们暂不分享具体的技术细节（留给后面几期文章），只跟大家聊一聊画像产品的构建思路、组成架构、应用方案和一些值得注意的事项，抛砖引玉!这些都是偏向于宏观的东西，但如果理不清这些东西，这个画像产品是无法构建好的，毕竟业内尚未有公开的成体系的成熟、权威方案，各家各路都在探索。

画像产品体系包括用户画像、内容画像、消息画像等等各个子画像，不同对象就有不同的画像，此文主要以用户画像为案例展开介绍，部分地方也会涉及到一些其他画像。

一、 追本溯源，应用为王

画像产品的构建好不好、全不全、弹性够不够，很多时候不是技术问题；关键就在于一开始应用的场景有没有想好、想全、想细，其次就是对自家数据的价值剖析对不对。不同的应用思路，就会有不同的画像产品形态；不同的数据价值，就决定了画像产品能实现到什么程度。提前想好这些，就会有前瞻性，画像产品体系后期的整合就更有利，开发过程的节奏就更合理。

就贝聊来说，画像产品的应用，主要聚焦在以下几方面：

1、 用户分析/研究需要：

画像产品需要提供单一用户全景视图，满足单一用户的行为细致分析、用户调研、发烧友使用习惯研究、活动筹备等方面需要；同时，需要提供用户行为分析、用户特征洞察、用户规模分析等系列报表，方便业务及时监控用户数量变化、用户行为变化、用户特征表现等等。

2、 用户运营和管理需要：

画像产品需要提供用户特征标签、用户群体细分、用户需求预测等方面结果，支撑用户分层管理、用户社群管理、用户精细运营，甚至用户个性化运营等各类用户管理和运营业务需要。

3、 精准广告投放需要：

画像产品需要结合用户全景视图、用户标签结果、推荐结果等各方面数据，提供一套能快速查询、精准筛选的DSP广告投放工具，支持商业部门灵活、精准广告投放需要。

4、 精准营销/服务需要：

画像产品的用户全景视图梳理是行为预警功能的基础，方便服务类型的业务能根据用户的行为变化，及时提供贴心周到的用户关怀、挽留、激励服务需要；同时用户的标签构建，需要覆盖用户的各类偏好、用户的所属地区等等，方能为公司的用户获取、营销策划提供支持。

5、 产品/内容运营需要：

画像产品需要提供诸如课程推荐、商品推荐、帖子推荐等个性化预测结果，以清单方式，提供给产品、内容运营团队直接应用。

从应用诉求出发，提炼画像产品的主要功能更加到位和实用，总的来说至少要有：用户全景视图、用户研究报表、用户特征标签、用户推荐引擎等等！

二、 产品功能，各自为政

画像产品的主要组成模块比较多（如下图），每一个模块都有很多的子功能，涉及的数据链路比较长，相互间依赖关系比较复杂。要保证画像产品的稳定性，必须提前规划好主要功能模块，做到各模块之间尽可能的各自为政，以免出现“一步错、步步错”或者“一着不慎、满盘重构”的不利局面。

1、 数据仓库：

画像产品的数据覆盖面非常广，数据计算任务非常多，几乎聚拢了业务系统的所有数据。做画像产品前，必须构建统一的数据仓库，对数据集市按对象、主题、类型进行切分，提高后续链条的数据查询、数据计算、数据存储等效率。

经验来说，画像产品构建初期，数据仓库也会进行几次的重构才能最终稳定下来，主要是因为业务的快速变化引发数据主题的变化造成的；所以其他模块要做到弹性兼容，以免数据底层重构，所有模块都要重构。

2、 用户全景视图：

数据仓库构建后的用户全景视图的构建，技术上来说几乎没有难度，需要注意的地方是用户全景视图的构建不单单是用户的个人信息、用户的行为明细数据，还会包括用户标签的识别结果、用户的推荐结果等等。同时，如果公司有明显类型区分的用户时候，用户全景视图是很难统一的，建议区别构建，会有意想不到的好处；例如贝聊就有家长、宝宝、老师、幼儿园等用户对象，不同对象的行为和标签等数据差异很大，全景视图展示也无法统一；切开做后，再关联，复杂度快速下降，实效很多。

另一个相对麻烦少许的地方就是用户规模上去后、用户行为数据沉淀量很大的情况下，允许的查询方式和查询条件又很多，数据查询速度会比较慢。技术可选方案很多，各有利弊，这里不做详述！

3、 标签引擎构建：

用户标签是用户画像产品的核心组成部分，应用最灵活、应用面最广、应用频率最高。构建标签引擎前，标签体系的构建必须要确定清楚，并且要尽可能的设计好，否则以后应用起来很麻烦，重构成本也非常大。

上图是贝聊的标签体系划分，不同的对象有不同的标签分类体系（里面还会分子目录），例如用户画像：基本属性主要囊括用户个人信息方面的出来的标签（如：地理、性别）；群体属性主要囊括用户在群体细分方面出来的标签（例如大V、话题制造者）；行为属性主要囊括用户在行为表现和偏好方面的标签（例如爱点赞、爱发图）；综合属性主要囊括用户在多方综合后得出的标签（例如生命周期、用户价值）。以贝聊的实践经验，群体细分时候，千万不要僵化思考，作茧自缚，不同的细分方向就会有不同的群体类型标签出来，所以会有很多群体类型标签！

关于用户标签的具体识别，目前很多公司经常喜欢利用数据挖掘模型进行识别（显得高大上？），其实不然，有时费时费力效果还不好。用户标签的妙处就在于轻量化应用，像便签一样，随手可用，生命周期不长、灵活度高、覆盖面广、容易理解、实用效率高才是重要的。仅仅依赖数据挖掘模型构（如，聚类算法）建出来的标签很难满足现实需要，目前贝聊构建的用户标签已有几百个，还在持续增加，下面谈谈贝聊的标签识别经验：

1） 基于规则型的人物特征标签识别技术

这类方法识别的标签应该是最多的！主要应用于较为直观或有清晰业务规则的人物标签，例如地域所属、家庭类型、年龄层等等。技术特点是直接有效灵活、计算复杂度低和可解释度高，单个标签涉及到的规则条件一般不超过3条，使用到的技术知识主要是数理统计类知识，例如基础统计、数值分层、概率分布、均值分析、方差分析等等。

2） 基于模型类的人物特征标签识别技术

主要应用于通过简单的规则条件之间组合无法有效识别的人物标签，但是识别出来的标签价值非常大，一般作为基础应用类型标签，标签的生命周期很长，例如行为偏好、性别预测、群体细分等等。

基于模型类的标签技术特点是综合程度高、复杂程度高；绝大部分标签需要先有针对性地构建相应的挖掘指标体系，依托经典数学算法或模型进行多指标间的综合计算方能得到特征标签，常常需要多种算法一起组合来建模。其中涉及到的经典算法技术主要有熵值法、层次分析法（处理模型权重问题），聚类分析等（处理分类和归集问题），回归分析、时间序列等（处理预测等问题），等等。

3） 基于算法型的人物特征标签识别技术

主要应用于特定类场景或特定类数据的人物标签识别。例如应用卷积神经网络和机器学习算法技术对孩子在幼儿园的活动参与图片进行识别，判断图片中幼儿周围的同伴数量，以此推断幼儿的社交活跃情况和性格（例如：活跃型、孤僻型等等）。

基于专类算法的标签技术特点是专业性强、针对性强、聚焦度高，部分场景下能批量输出一系列的人物标签。其中涉及到的专业技术主要有图像识别技术、音视频分析技术、文本分析技术等等，算法层主要有神经网络、机器学习、社群发现算法、语义分析算法等等。

4、 推荐引擎构建：

目前业内已经有很多的推荐算法在应用，效果参差不齐，作者认为最大的问题在于很多人过度依赖算法解决问题，试图用一套算法解决所有推荐问题，而不是把推荐当做一套引擎（或系统）来做。每一套算法背后都有一套推荐思想和逻辑在驱动，例如协同过滤算法背后的思想就是物以类聚或人以群分。但是每个算法都有自己的适用领域，只能解决自己领域内的推荐问题，例如很多推荐算法都存在冷启动问题（新用户没有数据怎么推荐？），这是没法调和的，所以强行适用就造成了一种尴尬，推荐的还没有猜的准。

要想推荐的准，我们必须放开思路，从多算法组合的思路出发，各自算法解决各自领域问题。以贝聊的实践经验来看，推荐的思想就是“算法组合+策略组合”，这套思想非常灵活，原理上算法和策略都可以无限加载和删除。

1） 推荐算法引擎

主要容载各个推荐算法，每个推荐算法输出自己的推荐结果以及得分；每个算法聚焦自己推荐问题领域的结果准确性，有些是解决新用户推荐问题的，有些是解决特殊场景推荐问题的，有些是解决业务依赖推荐问题的，不一一详述，以作者的经验，一般推荐组合中会有一套算法是重磅的、作为算法组合的母机！

推荐算法组合，关键要点是要解决好各算法推荐结果的得分量级一致性，意思是各算法的推荐结果得分要有可对比性，这个不难，不做详述。

2） 推荐策略引擎

主要容载各个推荐策略，需要区分不同的用户群体，每个群体适用不同的算法（通过权重分配），群体的划分，可以通过用户标签来指定（可以通过开发一个工具，打通策略引擎和标签引擎，进行快速配置推荐策略）。每条策略一定要有效期，否则无法进行策略的生命周期管理，有些策略生命周期很短的，例如节日期间的推荐策略，一般只适用这个节日前、中两个阶段，过了就要过期了。

3） 算法权重自分配机制

对具体用户来说，每条策略的各算法组合的权重是不同的，可以在配置策略的时候根据经验主观敲定，这种方法不利的地方，是无法及时有效的跟随用户的行为和需求变化（人是善变的！），作者偏好采用权重自分配调节机制。

作者的实践经验是，可以根据推荐的效果进行权重的自调节，例如新闻推荐：如果用户对算法组合中的一个算法的推荐结果不感冒（点击率低），则这个算法分配的权重自动降低一点（分配到效果好的算法上面去），经过一段时间后，该用户的推荐策略的算法权重分配就会稳定下来，并且可以自动化动态调整（跟随用户行为变化而变化），不用人为干预！

以上这些是贝聊构建画像产品主要模块实践过程中积累的一点小小的经验，权当抛砖引玉，跟大家一起交流和讨论！