一个成熟的标签系统在公司进行到一定阶段，是一定需要有的，这样可以减少大量的重复劳动，然后同时保证公司可以更有效的利用资源，避免各部门重复造轮子，产生较多的人群包。在我理解中，这个系统应该包含几个功能：

 

标签管理：主要涉及标签树的建立，底层标签的管理

人群抽取&人群配置：主要涉及根据标签生成对应的配置，

查询引擎：主要涉及根据人反查标签，以及根据标签反查人，

人群分析：主要涉及各人群的聚集分析，行为漏斗，行为轨迹分析等等

标签管理，主要解决两个问题，工程上，解决标签按照标准格式录入，策略上，解决标签体系的建立。

 

工程上主要是涉及到如何通过标准化导入，将不同类型的数据以标准化的形式接入到系统，中间有个中间层做transfer，通过transfer之后，统一以标准化的方式转入数据引擎，同时在标签体系加上一个标签ID，这个标签ID就是我们日常维护标签体系，也是我们日常维护的基础集合。

 

策略上，如何从建立用户画像这个问题去思考这个事情，首先分为两类，一类是通用的用户画像，包括年龄地域性别等等，另外一类是定制化的用户画像，可以按分APP或者分组的方式来做这件事情。用户画像，这个也可以完整的分享一下。

 

 

人群抽取和人群配置，这个是一个页面配置平台，主要是交互的设计，主要操作时如何通过配置的方式将标签的操作生成一个json出来，这个会涉及几块，一块是人群抽取的交互逻辑，一块是任务管理，人群抽取主要解决根据目前已有的标签系统来生成对应抽取的配置代码（包括标签之前逻辑，抽取的频率，标签功能提供出来的方式），之后任务调度根据这个配置来产出人群结果文件，并提供服务；

 

查询引擎，主要指当我们产出文件之后，以什么样的形式提供给用户，他可以有以下方式，文件，hive表，服务，广告平台的url，主要由两部分组成，一部分是调度系统，通过人群包的配置，把相关的的人群包生成，这一块主要解决的是性能问题，尤其对一些更新频率较高的人群包，解决性能问题是这个事情的关键，第二部分是提供服务，文件，url，表这一块主要是一些调用接口，只是工作量的问题，另外一块是提供线上查询服务，这一块比较难一点，主要是在线性能的问题。主要解决两类问题：

A)    检查某个device是否在指定人群包里，

B)     检查某个device所在的人群包；

A比较好做，应用面也比较广，比如rta的各种查询等等，b可能会有性能的问题

 

人群分析是第四部分，这一块主要要解决的问题，是如何通过快速的计算，重新聚拢出相同的逻辑出来，这一块的核心关键是把原来的逻辑能够抽象出来，生成以device id维度的底表，在根据底表做一层一层的聚合，从感觉上来说，更加适合用流式计算来做；

 

以前我是自己写脚本出来做的，但是目前这个场景感觉更加适合流式计算，其实底表做流式是更加合适一点，当然这个是数据平台做的事情，人群包其实主要还是产出一些统计数据，+漏斗数据，用来分析人群的特点；