用户画像场景与技术实现方案

用户画像场景与技术实现方案

​作者介绍

@赵宏田

某科技公司大数据架构师；

《用户画像：方法论与工程化解决方案》作者。

---

大家好，我是赵宏田～

今天赵宏田分享的主题是用户画像场景与技术实现方案，主要分 3 部分：

一是常见应用场景；

二是画像产品一些常见的功能；

三是技术实现方案。

01 常见应用场景

1.1 画像常见的应用场景

不同行业业务属性不同能收集到的数据也不同，对画像的应用场景有不同的需求，下面梳理了互联网 TOC、电商和安防等行业的画像应用场景，提供画像可以应用的思路。

除了 360 全息画像、个性化内容推送等场景外，还可以提供实时预警管控、专项场景分析、个性化人工运营服务等方面支持。

其中，专项的场景分析就是一些常见的数据分析模型，比方事件分析、留存分析和漏斗分析，这些分析模型都是基于标签和行为数据之后，把数据模型产品化后做成一些特定场景的分析，这就是基于用户画像的一种应用场景。

上面讲的比较概念化，接下来通过几个具体的场景来认识一下。

1.1.1 互联网 TOC——微信场景（1）

这两年企业微信做的比较好，它是想通过企业微信的方式去接入 TOC 微信的一些个人运营和营销等。

下面先看几个在微信中常见的场景：

1）渠道活码

用企业微信沉淀顾客，可以在每个渠道都附上带活码的渠道专属二维码，比如可以在自己的公众号、朋友圈广告、企业官网以及其他物料上都附上二维码，将前来咨询的新老客户都引进到企业微信，这些客户会被随机分配给某个员工，这样既能保证员工公平，又能避免单个号当日加人达到上限的情况。

2）触发欢迎语

个性化推送一人一语。

用户扫描添加企业成员后，自动推送指定消息，支持同一个码不同员工推送回复不同的内容，帮助企业实现精细化运营，快速转化。

3）SOP 推送

SOP 是（Standard Operating Procedure）三个英文单词首字母的组合，翻译过来叫做标准化的运营流程。

基于给新加用户打的标签来实现定时推送个性化消息。

SOP 推送是微信私域运营的一个重要工具/手段。给不同类型的客户在不同时间段推送不同的内容，从而拉动用户的活跃。

1.1.2 互联网 TOC——微信场景（2）

基于群、基于个人的个性化 SOP 推送包括先给人或者给社群打标签。创建任务给不同标签的人或者社群推送不同的个性化内容。

比方说，基于一些标签去创建一些定时任务，去给某个学习标签的人或者某一批标签的群去做一些定时推送，去维护某个社群的活跃程度，以及促进用户在不同阶段的转化。

这里截图了某 SCRM 厂商的功能宣传页，我们都知道 CRM 是客户关系管理，SCRM 就是 Social CRM。

在国内的话，SCRM 基本上都是基于企业微信场景去做的功能，常见的场景：渠道活码、裂变获客以及抽奖引流等都是前期的引流工作；

后期的高效沟通，基于标签、基于来源渠道，去做定制化的高效沟通。因为后台的客服人员他们可能不是一对一，他们有可能是一对 N，这个 N 有可能是几百/上千，所以说它需要通过标签和场景或者渠道等等标志一个人之后，再去更高效地和运营沟通以及客服互动；

高效沟通完成之后，SCRM 去做一些智能化的定向营销，比如 SOP 的定向营销以及个性化的群聊配送，个性化的朋友圈，不同的人能看到不同的朋友圈状态，像短信、营销等等一些触达渠道；

最后，在不同行业都去运用这种基于微信场景的 SCRM 产品去做一些行业的东西。

这种 SCRM 也是基于用户画像、用户标签去做的一种应用，这种数据量级比较轻，大家可能听到的很多场景都是来自一些互联网大厂或者互联网一些 TOC 的 APP，它可能量级比较大，每天都有几十万、百万、千万或者上亿的日活用户，它的数据量级可能会像那种大数据集群。

像这种微信场景他们就会比较轻一些，我们基于单机的应用就可以做后台的数据处理过程，当然后面也会讲到不止是大数据，其实这种小数据也是跨站的一种重要的组成部分，也有广阔的应用场景，我们日常收到的一些快销产品的短信，其实很多也是基于这种轻量级的 SCRM 场景去做功能的实现。

1.1.3 电商场景

电商场景也有很多，大家日常工作中都会有很多感知。比方说短信推送的营销，包括我从京东上买到的一些书的书店或者在线下优衣库买过衣服，以及京东上买过的一些保健产品。

他们都会定期的做一些推送，像保健产品或者快销产品都是周期性产品，就是说隔几个月就会把这个东西消耗掉，可能会再次产生同样的需求，所以他跟你推送的时间点，一般都会算的比较准。

比方说养老保健品两三个月就会是一个周期，使用完之后基本上隔两三个月就会收到推送短信，告诉我都有什么保健品，号召我再去购买。

像京东、阿里这种厂商他们上面的商家会自动采购第三方的一些产品，一些千量级的产品把自己在京东、天猫上的商务、商铺的数据接到第三方的 SCRM 上，去做定时化的营销推送以及邮件推送。

当然邮件推送其实现在用的比较少，因为可能大家现在基本上邮件看的比较少，邮件营销其实也是一个很重要的场景，比方说我买了阿里云服务，经常会收到阿里云定时推送的东西。

Push 消息的话，是大家接触最多的消息，每天打开手机的话，可能满屏的 Push。Push 的话，有几个重要的应用场景。

比方说促活，它可能是根据你浏览的内容，去推送一些商品。因为可能是你感兴趣的，你就会去看，促进你在站内的活跃，这有可能会带来其他的一些转化。活跃度高了之后，就可以浏览广告、下单之类的行为。这是基于用户的浏览情况去推送。

刚刚讲的是促进活跃，还有就是促进转化，比方我之前在京东上买过洗衣液，然后隔段时间又给我推冰箱、洗衣机，想把我拉到站内再去购买。

这是一个促活、一个转化。这种促销渠道大家接触最频繁，因为 Push 的消息在渠道中是免费的。但是，像短信、邮件这种营销，都是有渠道成本的。

1.1.4 安防场景

安防场景能采集到的数据源非常多，包括物联网和信息网的数据。

其中，物联网主要是人脸识别数据；而信息网范围更广泛一些， 主要用途是安防保护、抓捕坏人，或者说预防潜在的坏人去做一些不好的事情。

比方说，我们近期看到的一些新闻 “抓捕轰动国内的知名犯罪分子”。他们其实是基于信息网的人脸识别，识别出来是谁，然后再去和后台的内容预警管控的名单去做一个实时数据的校验。然后当比对相似度大于某个具体值时，会触发预警。接下来线下人员就会介入这个安防的场景。

这个流程中就是说，先是我们这个视频的信息流去捕获这部分数据，然后传输视频流，解析数据，解析完成之后，再和数据库中的数据进行比对。

达到预警之后，再去和潜在管控名单进行比对，比对上之后再去触发实时预警。

当然这种案发场景的话，在我们生活中有很多，比如管控一些不当言论，管控一些潜在犯罪分子，以及识别一些犯罪驾驶的车辆。

当然识别人脸面部的是一块，基于车牌号的识别其实也是一块。其实，都是基于潜在风险的一些身份信息预警管控。

1.2 关于画像场景的一些思考

1）画像场景总结来看，其实包括：

（1）营销卖货：短信/邮件/电话/微信等各种渠道的营销来卖货；

（2）营销促活：同样是各种渠道的营销来把用户拉/引到平台上，促进用户的活跃，因为有人活跃的地方就有流量就有生意；

（3）个性化服务：这里不仅指个性化推荐，也包括个性化的人工客服、个性化的接口服务；

（4）用户分析：基于用户在平台上的行为特征来分析产品的优缺点、做产品迭代，以及分析用户特征，比如基于用户人群去做一些分析、基于用户场景去做一些漏斗分析、事件分析、专题分析等等；

（5）预警管控：基于不同行业不同应用场景来设计预警管控的模型，管控的东西不同行业也不一样，有的话可能会识别一些潜在的风险账号，直接将账号拉入黑名单；有的直接识别出来一些风险用户去直接做人工的干预管控。预警管控的数据基本上都是实时的数据，对潜在风险去做一个预防。

这是画像场景的总结。

2）对数据量的总结，一直在 TOC 类型的互联网公司从事大数据类的工作，接触到的用户量或行为日志数据量都是大几千万、几亿、几十亿、百亿规模的数据处理。用到的技术栈也是 HIVE、SPARK、Hbase、ES、CLICKHOUSE 这些处理大量数据的开源工具。但不是说只有大数据才能搞画像。

3）最近在研究基于微信生态的 SCRM 类产品时发现这类产品处理的数据量很小，不需要上那种很重的大数据生态组件，但同样可以实现基于特定场景/生态下的客户营销管理，同样有广阔的应用市场。同样地对接淘宝、京东等商家后台数据提供 CRM 功能的厂商也是，在画像这块处理的数据量有的情况都用不上大数据的组件。

4）画像产品、场景等方面的内容常见的形式也就是那些，针对自己要做的领域如果没有思路就看看别家是怎么做的。太阳底下无新鲜事，其实各家的东西最后都差不多的。原型、功能、流程上的设计都那几个套路。

02 画像产品功能

2.1 画像产品常见功能（1）

画像产品的常见功能，像标签的元数据管理，元数据管理功能一般包括用户属性和用户行为，但是产品设计形态上各有不同。

2.2  画像产品常见功能（2）

在标签的元数据管理-详情页，可以查看标签的元数据信息，标签每天的产出量，标签在所属大类下的覆盖率等。

2.3 画像产品常见功能（3）

2.4 画像产品常见功能（4）

单用户画像，我们基于标签会给每个人打上同样的标签之后，我们通过接口形式输入某个用户 ID，通过查询可以看到这个人全量的标签。

这部分常见的应用场景，一块是分析场景，分析师/业务人员可能需要具体的分析一个或某几个 ID 去做查询分析。还有一块是客户端的接口调用，通过线上服务的接口请求的方式，传入用户 ID 来查询这个人的全部相似的用户，或传入用户 ID 以及一些标签查询这些标签相对应的值。

当然，刚才讲了两块：一块是分析调用的，一块是客户端调用的。

这两块是两种不同的场景，一块就是说对于公司内部的分析用的，这块可能类似于一个公司内部的业务后台作为分析用；还有一块是 TOC 的客户端调用，涉及到高并发的东西。

这两块的数据服务能力是不一样的，一块不涉及并发，一块涉及高并发，所以说这部分需要单独部署两套。

2.5 画像产品常见功能（5）

人群圈选：基于标签或组合标签。基于标签的规则定义，去筛选出来指定人群。

2.6 画像产品常见功能（6）

2.7 画像产品常见功能（7）

1）行为分析模型是基于分析对数据的抽象。例如常见的留存分析、事件分析、分布分析、漏斗分析等等。

本质上是基于用户行为日志 + 用户属性数据，来对用户从多个分析维度进行分析。直白些说就是将分析师常写的分析 SQL 固化成产品和数据模型来进行实现，省去人工介入的时间。

2）现阶段还没有做行为日志的采集，一方面需要把日志这块缺漏补起来，另一方面 TOB 的行为分析模型和互联网 TOC 的这些分析模型也不尽相同，对于 TOB 经常需要做哪些分析还需要分析师整理提炼出来，再把常用到的分析固化成产品。

2.8 画像产品常见功能（8）

基于标签的 SOP 是标准化运营流程，例如 SOP 在 SCRM 产品的场景中，基于企业微信给微信用户打的标签，通过设置给这些标签用户制定的运营策略来实现自动推送消息。

03 技术实现方案

3.1 画像系统整体数据流程

画像系统中最重要的环节除了理清应用场景外，就是要理清整个系统的数据流向。

业务数据库接入的数据、爬虫外部抓取的数据都放在数仓的 ODS 层。基于 ODS 层数据围绕应用场景进行数据建模后，把数据模型结果写入到 DWS 层，然后推送到各服务层需要调用的数据库，以备线上 OLAS 分析、接口服务的调用。

3.2 画像系统的蓝图

画像系统最终上线后，是一套完整的数据模型和应用流程。后续新增加的标签或应用场景可以在现有的框架内增加流转起来。

标签规划：给标签做规划。产品经理包括业务人员基于公司的业务场景去把整体体系梳理出来。

数据开发：数仓人员或数据开发人员基于处理好的信息去开发对应的标签，去跑离线标签和实时标签。

这一块讲一些实时和离线标签，大部分标签都是离线标签，以及在离线标签里面也分为基于统计型的离线标签和基于算法型的离线标签。

大部分或者 90% 的标签都是离线型的统计标签，像机器学习这样的算法标签会很少，一方面它的开发周期会很长，另一方面它的效果也是有限。与统计类规则的标签相比不能说高多少，但是基于某一场景下，我们还是需要使用基于机器学习的标签的比重会很小。

有时我们会有一些实时数据支持，我们会通过实时数据的方式但不一定经过标签。会通过实时的数据流去给用户做一个刻画，刻画完成或者说做完特征的标记之后，我们会推送到线上的服务，线上服务再去查询、再去供下一个做调用。这是离线和实时数据应用情况。

用户维表：用户维表有可能是一张大宽表，大宽表基于筛选用户的属性或者说分析师去分析用户的时候用。

3.3 ETL调度模型示例

ETL 调度模型包括跑一个标签的计算、去做一个数据的校验，以及跑一个人群的计算，以及跑一些分析宽表。

刚才讲的数据模型，比如漏斗分析、事件分析这种模型的分析表。通过这些模型分析过之后，再推荐到线上服务层，线上服务层有很多，比如说 Redise、Clickhouse、ES 等等，分到服务层去做服务的调用，服务的调用又可能跟站内的服务以及 TOC 的客户端的调用，这样的话我们刚才也提到了场景不一样。

站内服务的话就是我们公司内部人员、分析人员或者说产品去做分析、去做营销用。还有一块客户端调用，就是说 C 端用户他们去浏览页面、点击的时候，去做的一个请求。

客户端调用的时候就涉及到一个高并发的场景。企业内部应用的时候，就是一个普通的请求。给客户使用的时候，就涉及到高并发，高并发场景需要单独一种服务。

3.4 技术栈划分

画像系统技术主要包括 大数据 + 应用服务。

3.5 技术栈难点

想了解更多数据知识也欢迎看，7 位大厂产品联合写的《大数据实践之路：数据中台+数据分析+产品应用》这本书。