本文来自微信公众号 “ 浅梦学习笔记”，作者：赵宏田，纷传经授权发布。
导读：感谢DataFunTalk和一个数据人的自留地的邀请，今天和大家分享的主题是用户画像的场景与技术实现方案。主要分三大部分：
用户画像常见应用场景
画像产品功能
技术实现方案
01
常见应用场景
1. 画像常见的应用场景
不同行业业务属性不同，能采集到的数据源也不同，对画像的应用场景有不同的需求，下面梳理互联网 TOC、电商和安防等行业的画像应用场景，提供画像应用思路。
常见的360全息画像，就是给一个人打完全部标签之后，输入ID可以返回这个人的全部标签，看到这个人的全息画像，然后基于标签做个性化内容推送和消息推送，以及提供实时管控预警、专项场景分析。
比如我们常见的事件分析、漏斗分析等数据分析模型，其实都是基于标签和行为数据，把数据模型产品化之后做成的特定场景分析，提供个性化的运营服务支持。
不同行业有不同侧重点，主要源于不同行业采集到的数据源不同、不同行业的应用场景不一样。
互联网toC覆盖范围非常广，能采集到数据包括用户注册身份信息、用户强认证信息（比如身份证、银行卡等）、用户在APP站内的行为数据、填写表单的维度数据等。
互联网toC的场景化主要包括，给C端用户推荐站内的内容资讯，向用户推荐适合的个性化服务，SOP标准化营销流程。
电商也类似，主要基于用户的注册信息、站内行为数据和基础属性数据为用户提供服务，常见的发短信、发邮件、APP的消息弹窗等，以及给用户提供个性化的VIP服务。
安防场景的很多，比如用户的基础身份信息、出行数据、人脸识别数据等，基于这些数据给每个人建安全的全息档案画像。
安防有自己行业特性的分析场景，针对一些重点部位、人的行为轨迹等等。也会有实时的安防布控，去告诫可能潜在风险的人员，做提前的预警管控。
互联网金融服务，比如收集用户的注册信息、站内行为数据、用户的强行证明数据、用户手机装载的APP数据等。
这些数据可以对每个人做360度画像，以及管控潜在的风险账号。
比如多头借贷，多次违约等等，还可以基于建立的画像提供服务，包括评估个人还贷水平、违约等级等，根据评估来决定给用户提供对应的运营策略。
上面讲的比较概念化，下面详细讲解几个具体场景。
① 互联网TOC——微信场景（1）
渠道活码：用企业微信沉淀顾客，可以在每个渠道都附上带活码的渠道专属二维码。
比如在自己的公众号、朋友圈广告、企业官网以及其他物料上都附上二维码，将前来咨询新来客户都引进到企业微信，这些客户会被随机分配给某个员工。
这样既能保证员工工作的公平，又能避免单个号当日加人达到上限的情况。用户在扫码过程中会被自动打上标签，标识渠道来源。
触发欢迎语：给用户打上标签，标识渠道来源之后，可以触发欢迎语。
用户扫码添加企业成员后，自动推送指定消息，可以实现个性化推送一人一语，支持同一个码不同员工推送回复不同的内容，帮助企业实现精细化运营，快速转化。
SOP推送：SOP是Standard Operating Procedure（标准化的运营流程）。SOP推送是微信私域运营的一个重要工具/手段，可以给不同类型的客户在不同时间段推送不同的内容。
比如基于给新加用户打的标签来实现定时推送个性化消息，当用户扫描渠道码后，打上线上新人标签，后台先配置好运营推送策略，定时推送内容拉动活跃。
② 互联网TOC——微信场景（2）
基于群、基于个人的个性化 SOP 推送包括先给人或者给社群打标签。创建任务给不同标签的人或者社群推送不同的个性化内容。
比如基于一些标签创建某些定时任务，给某一批标签的人或某一批标签的群做定时推送，维护整个社群的活跃程度，以及促进用户在不同阶段的转化。
这里截图了某SCRM厂商的功能宣传页，我们都知道CRM是客户关系管理，SCRM就是Social CRM。
国内SCRM基本都是基于企业微信场景做的功能，常见场景：前期基于渠道活码、裂变获客、抽奖引流、自动标签、自动回复等的引流工作。
后期基于标签、基于来源渠道，做定制化的高效沟通。
高效沟通完成之后，SCRM去做智能化的定向营销，比如SOP定向营销、个性化的群聊推送、个性化朋友圈。
在电商，零售，教育培训等不同行业，都有基于微信场景的SCRM产品做一些行业的东西。
这种也是基于用户画像、用户标签做的一种应用，这种应用的数据量级比较轻，基于单机的应用就可以做后台的数据处理过程。
这种小数据也是跨站的一种重要的组成部分，也有很广阔的应用场景，我们日常接收到的一些快销产品的短信，很多也是基于轻量级的SCRM场景去实现功能。
③ 电商场景
电商场景包括如下几种：
短信推送营销：比如在京东买过书、保健产品、在优衣库买过衣服后，商家会做定期推送。通常隔两三个月会收到推送短信，告知优惠信息，通知续买。
还有像京东阿里平台的商家也会自建或采购第三方轻量级SCRM产品，把自身在京东淘宝的商铺数据接到第三方产品做定时的智能化营销推送以及邮件推送。
邮件推送营销：邮件推送现在用的比较少了，当然也是很重要的场景，比如买了阿里云服务，经常收到阿里云定时推送的营销邮件。
Push消息：有几个应用场景，一是促活，根据用户浏览内容进行推荐，用户感兴趣点击查看，可以促进用户在站内的活跃。
二是促进转化，当用户活跃度高之后，可能会多浏览广告或者带来下单转化。通常基于自己产品做Push消息配置是免费的，而像邮件短信则是有渠道成本的。
④ 安防场景
安防场景能采集到的数据源非常多，包括物联网和信息网的数据。主要用途是安防管控抓捕坏人，或者预防潜在的坏人做坏事。
比如我们近期看到的抓捕犯罪分子新闻，基本是基于人脸识别来识别，然后再和后台预警管控的名单做实时数据比对校验，当比对相似度大于某个阈值时会触发预警，后续视情况进行人为干预。
这种安防场景在我们生活中有很多，比如识别不当言论去管控潜在的风险犯罪分子，以及去识别犯罪分子驾驶的车辆。
人脸的面部识别、基于车牌号的识别其实都类似，都可以基于潜在风险的身份信息去做预警管控。
2. 关于画像场景的一些思考
① 画像场景总结起来，包括：
营销卖货：短信/邮件/电话/微信等各种渠道的营销来卖货。
营销促活：同样是各种渠道的营销来把用户拉/引到平台上，有人活跃的地方就有流量就有生意。
个性化服务：这里不仅指个性化推荐（比如淘宝上推荐商品，基于用户浏览或购买过兴趣类似或同类的商品，比如抖音快手上基于看过的视频内容推荐相似内容），也包括个性化的人工客服、个性化的接口服务。
用户分析：基于用户在平台上的行为特征来分析产品的优缺点、做产品迭代。
预警管控：基于不同行业不同应用场景来设计预警管控的模型，实现对潜在风险的预警与预防。
比如识别潜在的风险账号，把账号直接拉黑名单；比如直接识别出风险用户，直接做人工的干预管控，这也是预警管控，基本是基于实时数据对前方风险去做预防。
② 一直在toC类型的互联网公司从事大数据类的工作，接触到的用户量或行为日志数据都是大几千万、几亿、几十亿、百亿规模的数据处理。
用到的技术栈也是hive、spark、hbase、es、clickhouse这些梳理大量数据的开源工具。但不是只有大数据才能做画像。
③ 最近在研究基于微信生态的SCRM类产品时发现，这类产品处理的数据量很小，不需要很重的大数据生态组件，但同样可以实现基于特定场景/生态下的客户营销管理，同样有广阔的应用市场。
对接淘宝、京东等商家后台数据提供CRM功能的厂商也是，在画像这块处理的数据量有的用不上大数据组件。
02
画像产品功能
画像产品功能主要包括标签的元数据管理、单用户画像、人群筛选、人群分析等。
1.标签的元数据管理
元数据管理来说，产品设计形态上可能会有各有不同，基于用户属性、用户行为，来做123级目录分类的标签元数据管理。
在元数据详情页可以查看标签的源数据信息、标签每天的产出量、标签在所属大类下的覆盖率等。
在元数据编辑页面可以对目前平台上的标签信息进行增删等编辑。
2. 单用户画像
单用户画像，我们给每个人打上标签后，在运营时或通过接口形式输入用户ID，可查询到这个人的全量标签。
应用场景大致两种：一种是分析场景，即分析师/业务人员基于一个或某几个用户ID做具体的查询分析。
这种通常是公司内部业务后台作为分析自用；另一种是客户端接口调用，即通过线上服务接口请求方式传入用户ID查询标签，这涉及到高并发。
这两种应用场景，对数据服务能力要去是不一样的，前者不涉及并发，后者涉及高并发，需要单独部署两套。
3. 人群圈选
基于标签组合及标签的规则定义进行人群圈选，即基于维护的标签元数据信息、组合标签及条件筛选、即席查询符合特征覆盖到的人群数量、保存查询条件下用于下阶段的运营推送。
4. 人群分析
人群分析：可以从多个维度透视分析人群特征。分析维度可以通过预制设定来自动生成分析报表，也可以自主筛选。
选择分析人群、选择分析的维度、分析的结果，可以进一步查看对应的用户列表和标签详情。
5. 行为分析
行为分析模型是基于分析场景对数据的抽象。例如常见的留存分析、事件分析、分布分析、漏斗分析等等。
本质上是基于用户行为日志+用户属性数据，来对用户从多个分析维度进行分析。直白说就是将分析师常写的分析SQL固化成产品和数据模型来实现，省去人工介入的时间。
现阶段还没有做行为日志的采集，一方面需要把日志这块缺漏补起来，另一方面 TOB 的行为分析模型和互联网 TOC 的这些分析模型也不尽相同。
对于 TOB 经常需要做哪些分析还需要分析师整理提炼出来，再把常用到的分析固化成产品。
6. 基于标签的SOP
基于标签的SOP是标准化运营流程，例如SOP在SCRM产品的场景中，基于企业微信给微信用户打的标签，通过设置给这些标签用户制定的运营策略来实现自动推送消息。
03
技术实现方案
1.画像系统整体数据流程
画像系统中最重要的环节除了理清应用场景外，就是要理清整个系统的数据流向。
从项目全貌来说，我们首先是收集日志和属性数据，从线上业务库抽取业务数据、或从日志服务器抽取日志数据，把抽取的数据放到数据仓库里。
然后基于收仓的数据打标签、建模和行为主题的宽表建立。数据仓库层面一般分多层，比如ods做基础标签，dws层做直接推送到服务层的数据。
业务数据库接入的数据、爬虫外部抓取的数据都放在数仓的ods层。
基于ods层数据围绕应用场景进行数据建模后，把数据模型结果写入到dws层，然后推送到各服务层需要调用的数据库，以备线上OLAP分析、接口服务的调用。
2. 画像系统的蓝图
画像系统的技术蓝图包括标签规划、数据开发、应用场景等。画像系统最终上线后，是一套完整的数据模型和应用流程。
后续新增加的标签或应用场景可以在现有的框架内增加流转起来。
标签规划：由产品经理或业务人员基于公司的业务场景把整个标签体系梳理出来。
数据开发：由数据开发人员或数仓人员基于梳理好的标签体系开发对应的标签，跑离线标签以及跑实时任务。
就数据开发来说，实时数据和离线的大部分标签都是T+1的离线标签。
离线标签又分为基于统计类型的标签和基于算法性标签，大部分或者90%的标签都是统计类型标签，像机器学习的算法标签很少，一方面是开发周期很长，另一方面效果也有限。
但是基于某些场景，还是得需要使用机器学习，只是机器学习标签的比重会很小。
有时我们做实时数据支持，会通过实时数据流给用户做刻画或者做特征标记，可做线上服务接口调用查询。
用户维表是一张大宽表，大宽表基于筛选用户的属性或分析师分析用户的时候用。除了标签跑批、用户维表，还有人群计算、行为数据等的数据开发。
应用场景：开发完数据后，再推送到应用场景，包括人员360视图、人群圈选、人群分析、SOP运营、内容推荐等场景。
我们基于应用场景做迭代效果反馈之后，再反馈给标签规划以及数据开发，再优化数据标签以及数据开发的流程，这是整个应用的蓝图。
3. ETL调度模型示例
ETL调度模型包括标签的加工计算、数据标签的校验、人群计算、跑一些分析宽表。
跑完数据模型后，推荐到线上服务层，比如Redise、Clickhouse、ES ，分到服务层做服务的调用，包括站内的服务调用以及TOC的客户端服务调用。
站内的服务调用即公司内部的运营或产品人员用于分析、用于营销；TOC的客户端服务调用则是浏览页面点击时产生请求，客户端调用涉及到高并发的场景，需要单独处理接口服务。
4. 技术栈划分
画像系统技术主要包括大数据+应用服务。大数据从存储类型、开发语言、开发内容来了解；应用服务从技术选型与框架、开发内容来了解。
5. 技术栈难点
技术栈难点分两块来说明：
第一块是大数据，从查询速度来讲，画像相关的查询有很多场景，比如单用户画像查询、基于行为事件的分析、组合标签查询、实时查询等。
不同的场景需要考虑到用不同的工具去存储，比如es适合关键词检索、redis/hbase适合单用户查询、clickhouse适合多维度OLAP分析等。
从调度时间来考虑，用户基数规模较大的公司一般每天日志量很大，跑标签计算、跑数据服务的时间也会相对的较多。需要做一些优化来减少数据调度时间。
第二块是应用服务，从后台应用来说，后台应用就指单用户画像、行为时间分析、标签管理等方面的产品端，这块一般没有什么难点，就是后台应用的增删改查，面向的使用者也是企业内部人员。
从数据服务角度，指标签画像数据的接口调用，比如线上服务请求某用户的标签数据。
如果是热门应用的话，每天画像标签的接口请求就是一个高并发的问题，需要考虑用redis、hbase等工具去解决。
04
精彩问答
Q：咨询用户画像跟个人信息保护、数据安全方面的问题，在做技术底层架构的时候，数据安全有些什么措施？
A：就数据安全来说，在采集数据上，不是特别涉密、涉及敏感信息的数据会进行采集。但在标签应用查看权限上，技术上通过接口实现不同权限来控制。比如不同用户分组对应不同的权限，可以查看分组下对应的标签，通过这种方式控制内部的数据安全。
Q：公司已有推荐系统且有标签，公司还想建设标签画像中台。想咨询中台标签画像和标签系统的标签之间的关系应该是什么样的？
A：这个问题可能是局限于公司内部的问题，不是通用性的问题。可能是有的公司比较大，不同的部门牵头做一套自己东西，做的东西有冲突了。
Q：从最初的建立标签体系，比如第二级标签分组，除了梳理行业的竞品、客户的实际业务情况，还有没有其他维度或常见的体系方法论？
A：一般是基于自己公司的业务场景去梳理指标体系。梳理标签体系，一般由各个业务部门人员提需求，以及产品经理出需求。在开发过程中，根据使用情况不断地做迭代。现在市面上也有专门讲标签类目体系的书，专门讲如何面向业务去梳理标签体系。
Q：对于离线跟实时的标签，应该如何合理的处理？实时标签应该怎么做？
A：大部分场景基本90%多都是基于离线标签去做。实时标签是给用户推送一些实时的东西，但可能不一定基于标签的方式去做。就离线标签来说，我们给用户打上标签，然后再去做一些筛选及推送；实时场景则可能直接通过任务计算好了，并把计算出来的这批用户推送到对应的地方供调用。
