目录
前言
一、用户画像概述
1.1 用户画像
1.2 用户标签
1.3 用户群组
二、建设标签和标签体系
2.1 标签体系
2.1.1 统计类标签
2.1.2 规则类标签
2.1.3 机器学习挖掘类标签
2.2 标签建设流程
2.2.1 需求收集与分析
2.2.2 产出标签需求文档
2.2.3 标签的开发
Hive数据仓库ETL作业
Hive数据仓库用户画像主题建模
标签结果数据在应用端的存储( 标签落库)
2.2.4 标签发布与效果追踪
三、用户画像产品化
3.1 用户画像产品系统架构
3.1.1 数据采集
SDK
Importer
Link
3.1.2 数据接入
3.1.3 数据整合/标签计算
3.1.3.1 数据整合
3.1.3.2 标签计算
3.1.4 标签应用
3.2 用户画像产品功能模块
3.2.1 系统看板
3.2.2 标签管理
3.2.3 单用户画像
3.2.4 用户分群和用户群画像
用户分群
用户群画像
3.2.5 BI分析
3.2.6 OpenAPI
四、用户画像应用
4.1 经营分析
4.1.1 流量分析
4.1.2 用户分析
4.1.3 商品分析
4.1.4 订单分析
4.1.5 渠道分析
1、用户活跃
2、用户质量
3、渠道收入
4.1.6 产品分析
4.2 精准营销
4.2.1 短信/邮件/push营销
4 .3 个性化推荐与服务
五、用户画像实践案例
5.1 A/B人群效果测试
5.1.1 案例背景
5.1.2 用户画像切入点
1、对AB组用户做切分
2、测试文案标题对流量影响的方案
3、精准推送相比普通推送带来的流量提升的测试方案
5.1.3 效果分析
5.2 女神节定向营销
5.2.1 案例背景
5.2.2 实现逻辑
5.3 新安装未注册用户实时营销
5.3.1 案例背景
5.3.2 用户画像切入点
5.4 某电商再营销广告
5.4.1 案例背景
5.4.2 实现逻辑
前言
本文主要阐述0-1 构建用户画像涉及的一些核心概念,1)首先,描述了有关用户画像、用户标签、用户群组的认知性概念;2)然后,阐述了标签体系的分类,标签建设的流程和方法;3)为了说明如何让“躺在”数据仓库中的画像标签数据发挥更大的业务价值,就从系统架构、应用层功能两个角度,总结了用户画像系统的建设;4)最后,从经营分析、精准营销、个性化推荐这个三个角度总结了用户画像的应用,并在实践案例部分列举几个用户画像,实际应用的案例。
一、用户画像概述
1.1 用户画像
用户画像(Profile)更多被运营和数据分析师使用,精准营销,经营分析,个性化推荐都是基于用户画像的应用。用户画像是各类描述用户数据的变量集合,能够准确描述任何一个真实用户。如下是一个简化的用户画像:
构建用户画像,就是给用户打上各种维度的标签。从业务价值来说,标签和画像是类似中间层的系统模块,为数据驱动运营奠定了基础,可以帮助大数据“走出” 数据仓库,针对用户进行个性化推荐、精准营销等多样化服务。有关用户画像系统、落地应用的详细描述,见【三、用户画像产品化】、【四、用户画像应用】、【五、用户画像实践案例】章节。
1.2 用户标签
用户标签,即对用户某个维度属性的描述,具有相互独立、可枚举穷尽的特点。采集业务、日志、埋点等数据后,经过不同统计方式计算出用户属性、用户行为、用户消费、风险控制、社交等维度标签。例如:性别、年龄、近30日访问次数、购买水平、经常活跃时间段等。有关用户标签体系建设的详细描述。
这里通过一个场景来介绍基于用户标签圈选用户群组(多维标签组合,进行客群圈选)的应用。某女装大促活动期间,渠道运营人员需要筛选出平台上的优质用户,并通过短信,邮件、push 等渠道进行营销。
第一步:通过圈选“浏览”、“收藏”、“加购”、“购买”、“搜索”与该女装相关品类的标签来筛选出可能对该女装感兴趣的潜在用户;
第二步:组合其他标签(如“性别”、“消费金额”、“活跃度”等)筛选出对应的高质量用户群,推送到对应渠道。
因此,将用户属性,行为事件数据抽象成标签后,可通过组合标签方式找到目标潜在用户人群。从这个角度理解,用户群组是用户标签应用的一种方式。
1.3 用户群组
需要用户属性和动作行为进行组合,才能圈选出全面的目标群体。只有行为数据,只能看到这个人做过什么事,但这个人是男是女、年龄多大、注册多久 、购买能力如何等信息都不知道,这样圈选出的用户群是有缺陷的,一般不会直接应用于精准营销场景。
用户标签与用户群组的区别:
标签作为一个中间层系统模块,在精准营销场景,往往不会只使用一个标签进行推送,更多情况下需要组合多个标签来满足业务上对人群的定义。因此,将用户属性,行为事件数据抽象成标签后,可通过组合标签方式找到目标潜在用户人群。从这个角度理解,用户群组是用户标签应用的一种方式。
二、建设标签和标签体系
2.1 标签体系
标签本身会有很多分类方式,但从标签的实现规则来看,大致可以分为以下3种类型:(1)统计类标签,(2)规则类标签,(3)机器学习挖掘类标签
2.1.1 统计类标签
这类标签是最为基础也最为常见的标签类型,例如:对于某个用户来说,其性别、年龄、城市、星座、近7日活跃时长、近7日活跃天数等字段可以从用户注册数据、用户访问、消费数据中统计得出。该类标签构成了用户画像的基础。
2.1.2 规则类标签
该类标签基于用户行为,用户属性和确定的规则产生。例如,对平台上“消费活跃”用户这一口径的定义为“近30天交易次数≥2”。在实际开发画像的过程中,由运营人员和数据人员共同协商确定。
2.1.3 机器学习挖掘类标签
该类标签通过机器学习挖掘产生,用于对用户的某些属性或某些行为进行预测判断。例如,根据一个用户的行为习惯判断该用户是男性还是女性、根据一个用户的消费习惯判断其对某个商品的偏好程度。该类标签需要通过算法挖掘产生。
在项目工程实践中,一般统计类和规则类的标签即可以满足应用需求,在开发中占有较大比例。机器学习挖掘类标签多用于预测场景,如判断用户性别、用户购买商品偏好、用户流失意向等。一般地,机器学习标签开发周期较长,开发成本较高,因此其开发所占比例较小。
事实上,最终标签体系中是以用户视角定义的,需要结合具体的业务。比如某电商业务标签分类,用户属性维度标签、用户行为维度标签、用户消费维度标签、风险控制维度标签、社交属性维度标签。
2.2 标签建设流程
下图是一个标签建设流程,会侧重产品经理视角,主要描述需求的分析过程和产出文档,同时对标签的开发原理进行简单的总结。
2.2.1 需求收集与分析
在需求收集与分析环节,可以按【还原业务流程】——【明确商业目的】——【从策略推标签】——【组织标签】。
2.2.2 产出标签需求文档
2.2.3 标签的开发
在整个工程化方案中,系统依赖的基础设施包括Spark、Hive、HBase、Mysql。除去基础设施外,系统主体还包括ETL作业、用户画像主题建模、标签结果数据在应用端的存储3个重要组成部分。如图所示是用户画像数仓架构图,下面对其进行简单介绍。
Hive数据仓库ETL作业
下方虚线框中为常见的数据仓库ETL加工流程,也就是将每日的业务数据、日志数据、埋点数据等经过ETL过程,加工到数据仓库对应的ODS层、DW层、DM层中。
Hive数据仓库用户画像主题建模
中间的虚线框即为用户画像建模的主要环节,会对基于数据仓库ODS层、DW层、DM层中与用户相关数据进行二次建模加工。
标签结果数据在应用端的存储( 标签落库)
在用户画像主题建模过程中,会将用户标签计算结果写入Hive,由于不同数据库有不同的应用场景,下面分别进行描述:
(1)MySQL
作为关系型数据库,在用户画像中可用于元数据管理、监控预警数据、结果集存储等应用中。下面详细介绍这3个应用场景:
- 元数据管理:MySQL具有更快的读写速度,平台标签视图中(Web端产品)的标签元数据可以维护在MySQL关系型数据库中,便于标签的编辑、查询和管理。
- 监控预警数据:在对画像的数据监控中,调度流每跑完相应的模块,就将该模块的监控数据插入MySQL中,当校验任务判断达到触发告警阈值时,就触发告警。
- 结果集存储:存储多维透视分析用的标签、圈人服务用的用户标签、当日记录各标签数量等。
(2)HBase
与Hive不同的是,HBase能够在数据库上实时运行,而不是跑MapReduce任务,适合进行大数据的实时查询。下面通过一个案例来介绍HBase在画像系统中的应用场景和工程化实现方式:
某渠道运营人员为促进未注册的新安装用户注册、下单,计划通过App首页弹窗发放红包或优惠券的方式进行引导。每天画像系统的ETL调度完成后对应人群数据就被推送到广告系统(HBase数据库进行存储)。满足条件的新用户来访App时,由在线接口读取HBase数据库,在查询到该用户时为其推送该弹窗。
2.2.4 标签发布与效果追踪
通过开发测试,上线后需要持续追踪标签应用效果及业务方反馈,调整优化模型及相关权重配置。
三、用户画像产品化
开发完画像标签数据,如果只是“躺在”数据仓库中,并不能发挥更大的业务价值。只有将画像数据产品化后才能以标准方式提升数据处理链路上各个环节的效率,同时也更便于业务方使用。下面分别从产品化后涵盖的标签生产架构和功能模块两个角度进行总结:
3.1 用户画像产品系统架构
下图是一个用户画像产品系统的结构图,数据是从左到右的,主要包括数据采集、数据接入、数据整合/标签计算、标签应用4个层级。
3.1.1 数据采集
在数据采集模块,主要通过客户端/服务端SDK、导入、对接第三方应用3种埋点方式进行日志数据、业务数据、第三方数据的采集。
SDK
(1)客户端SDK:通过客户端SDK埋点,可以采集iOS、Android、小程序、网站等各种客户端的用户行为数据和用户属性信息。
(2)服务端SDK:若数据已经存在数据库、数据仓库,比如订单信息,可以使用对应开发语言的服务端SDK进行数据的采集。
Importer
可以根据运行环境、源数据格式、导入数据量的大小等影响因素,选择不同大导入方式,把历史文件数据导进用户画像产品系统。
Link
针对不同第三方产品OpenAPI的特点,采用接收事件消息推送、或主动轮询方式采集用户在不同第三方应用系统的个人属性和行为事件数据。
3.1.2 数据接入
埋点数据先大量进入Kafka,然后慢慢消费接入后续的数据整合存储系统。
3.1.3 数据整合/标签计算
在用户画像系统中,主要使用Hive作为数据仓库,进行ETL处理,开发相应的用户属性表和用户行为表,以及标签的计算。
3.1.3.1 数据整合
各种渠道接进来的数据,存在孤立、空值、格式不对应、超过极限范围等数据质量问题,因此需要进行脏数据清洗、格式转换、用户识别与合并等整合工作:
(1)清洗转换
(2)Id Mapping
各个渠道接进来的用户属性数据、行为事件数据等都是孤立的,为了能计算用户的全方位的综合标签,就需要做用户的识别合并,比如通过unionID,识别合并绑定在同一微信开放平台的公众号、小程序、网站的同一个用户的信息。
3.1.3.2 标签计算
在用户画像系统,会做一套批量离线的标签处理引擎,依赖的是底层比较稳定的数据结构。这个标签引擎一边读事件数据,一边读用户的属性数据,再配合上特定的标签规则,做一个批量计算,最后生成用户标签。
3.1.4 标签应用
标签的应用主要分为前端画像展示、通过API接入其他系统两大类应用方式。
3.2 用户画像产品功能模块
3.2.1 系统看板
通常用户画像系统的数据看板,以可视化形式展示企业的核心用户数据资产情况或者重点关注的人群数据。旨在建立和统一使用者对企业数据资产或者核心人群数据的基础认知,有以下几类:
- 用户量级及变化趋势:不同设备类型ID量级、不同类型用户量级(如注册与非注册用户、付费与非付费用户等);
- 标签资产:按主要类目统计标签个数等;
- 核心用户标签:展示固有或自定义人群的关键标签画像数据等;
3.2.2 标签管理
供业务人员进行标签的增、删、改、查等操作,包含:标签分类、新建标签、标签审核、标签上下架、标签覆盖人数监控等。
3.2.3 单用户画像
包含通过输入用户ID,来查看单用户画像的详情数据,如用户的属性信息、用户行为等数据。
3.2.4 用户分群和用户群画像
用户分群
用户分群功能主要是面向业务人员使用。产品经理、运营、客服等业务人员在应用标签时,可能不仅仅只查看某一个标签对应的人群情况,更多地可能需要组合多个标签来满足其在业务上对人群的定义。例如:组合“过去7天领取优惠券次数大于1次”、“活动活跃度等于高和极高”、“女性”用户这3个标签定义目标人群,查看该类人群覆盖的用户量。
用户群画像
和用户分群功能相似,用户群画像功能首先也需要组合标签圈定用户群体,不同之处在于:用户群画像功能支持从多个维度去分析圈定用户群体的特征,而用户分群功能侧重的是将筛选出来的用户群推送到各业务系统中,提供服务支持。
3.2.5 BI分析
BI平台和这些数据打通后,可以丰富数据的维度,支持通过多种分析模型进行更加丰富和深层的分析及对比。
3.2.6 OpenAPI
OpenAPI能够保障画像系统数据与各系统之间打通,例如push推送系统、营销系统、广告系统、推荐系统、BI 等平台,并且保证各系统数据的实时更新,避免同源不同数的问题。
四、用户画像应用
上述提到的用户画像主要有:经营分析、精准营销、个性化推荐与服务等3个方面的应用。具体又可以分为:
4.1 经营分析
用户画像系统的标签数据通过API进入分析系统后,可以丰富分析数据的维度,支持进行多种业务对象的经营分析。下面总结的是一些市场、运营、产品人员分析时会关注的指标:
4.1.1 流量分析
- 流量来源
- 流量数量:UV, PV
- 流量质量:浏览深度(UV、PV)、停留时长、来源转化、ROI(投资回报率,return on investment)
4.1.2 用户分析
- 用户数量:新用户数、老用户数、新/老用户数量比
- 用户质量:新增用户数(App启动)、活跃用户数(App启动)、用户留存、用户参与度
4.1.3 商品分析
- 商品动销:GMV、客单价、下单人数、取消购买人数、退货人数、各端复购率、购买频次分布、运营位购买转化
- 商品品类:支付订单情况(次数、人数、趋势、复购)、访购情况、申请退货情况、取消订单情况、关注情况
4.1.4 订单分析
- 订单指标:总订单量、退款订单量、订单应付金额、订单实付金额、下单人数
- 转化率指标:新增订单/访问UV、有效订单/访问UV
4.1.5 渠道分析
1、用户活跃
- 活跃用户:UV、PV
- 新增用户:注册量、注册同环比
2、用户质量
- 留存:次日/7日/30日留存率
3、渠道收入
- 订单:订单量、日均订单量、订单同环比
- 营收:付费金额、日均付费金额、金额同环比
- 用户:人均订单量、人均订单金额
4.1.6 产品分析
- 搜索功能:搜索人数/次数、搜索关键词
- 关键路径漏斗等产品功能设计分析
4.2 精准营销
4.2.1 短信/邮件/push营销
日常生活中,经常会从许多渠道接收到营销来的信息。一条关于红包到账的短信消息推送可能会促使用户打开已经很久没访问的App,具体有哪些类型的营销方式大致可以分为以下4类:
- 基于行为营销:产品浏览、加入购物车、门店扫码、订单取消、订单退货等;
- 基于位置营销:周边门店、周边活动、常去区域等;
- 基于节日营销:生日、春节、双十一、双十二、圣诞等;
-
基于会员营销:欢迎入会、卡券提醒、积分变更、等级变化、会员礼遇等
4 .3 个性化推荐与服务
应用的运营者,可以通过个推用户画像中的性别、年龄段、兴趣爱好、浏览购买行为等标签,给用户推荐不同的内容。如今日头条上的个性化文章内容推荐、抖音上基于用户画像做的个性化视频内容推荐、淘宝上基于用户浏览行为等画像数据做的个性化商品推荐等。
五、用户画像实践案例
基于画像系统去做多方面的数据分析、触达用户的运营方案,可以快速地将标签数据应用到服务层(T+1、实时应用),通过效果分析得到用户反馈后,帮助迭代营销策略或产品设计。下面通过一些实践案例来场景化复现用户画像的应用点和应用方式。
5.1 A/B人群效果测试
5.1.1 案例背景
某零食类快消商品为在大促活动期间获得较好的销量,计划通过消息推送的方式种草新上市产品等系列文章。为了精准定位目标人群流量,渠道运营人员现在计划做两个A/B人群效果测试:
- 不同内容标题对流量的影响;
- 精准推送相比普通推送带来的流量提升。
5.1.2 用户画像切入点
整个项目中需要梳理清楚如何切分AB组流量,如何设计好AB组的人群规则和效果监测。下面分步骤介绍画像系统如何切入AB人群测试中。
1、对AB组用户做切分
为了做A/B组测试,首先需要做好流量的切分,可以使用A/B分配随机分流的形式,将用户划分为A/B人群。
2、测试文案标题对流量影响的方案
某平台渠道运营人员为在大促活动期间召回更多用户来访App,计划在活动预热期选取少量用户做一版文案标题的AB效果测试。
在该测试方案中,控制组A选取了A路径、近x天来访过,且近x天内浏览/收藏/加购过该零食的用户群,给该批用户推送零售文案A;对照组B选取了B路径、近x天来访过,且近x天内浏览/收藏/加购过该零食的用户群,给该批用户推送零食文案B。控制组和对照组的用户量相同,但文案不同,后续监控两组人群的点击率大小,进而分析不同文案对用户点击的影响。
3、精准推送相比普通推送带来的流量提升的测试方案
在使用画像系统精细化推送人群前,某平台对用户采用无差别推送消息的形式进行推送。为了测试精细化运营人群相比无差别运营带来的流量提升,渠道运营人员决定在近期重点运营的零食营销会场做一个AB效果测试。
该测试方案中,控制组A选取了A路径、近x天来访过,近x天内浏览/收藏/加购过该零食的用户群;对照组B选取了B路径、近x天来访过,且没有类目偏好的用户群。对AB组用户群都消息推送相同的文案,后续监控两组人群的点击率大小,进而分析精准营销推送带来的增长点大小。
5.1.3 效果分析
在AB组人群消息推送上线后,后续需要搭建监控报表来监测控制组和测试组的流量和转化情况,主要关注下方列表中的指标:
5.2 女神节定向营销
5.2.1 案例背景
某女士商品的品牌商,计划在女神节对不同品类偏好的女神进行定向营销。营销信息会分两次推送,首次是在当天的10:00推送促销信息,第二次是在当天晚上的10:00再统一来一波促销提醒。最后通过追踪目标受众的当日支付订单完成率来评估营销效果。
5.2.2 实现逻辑
首先基于用户性别标签、年龄标签圈选出18~40岁,女性的用户。然后统一延时至2020-03-08 上午 10:00,根据用户品类偏好标签定向推送不同的营销内容,比如给品类偏好=彩妆护肤的人群推送春日美妆节类的营销信息。第二波推送会延时至2020-03-08 下午 10:00 进行推送,推送信息为统一的促销提醒。
5.3 新安装未注册用户实时营销
5.3.1 案例背景
某零食商城App的运营人员为了促使未注册的新安装用户注册及下单,制定了运营规则:新安装未注册用户打开App时,通过App弹窗方式为其推送优惠券进行营销。
5.3.2 用户画像切入点
渠道运营人员通过组合用户标签(如“未注册用户”和“安装距今天数”小于××天)筛选出对应的用户群,然后选择将对应人群推送到“广告系统”。这样每天的画像系统的ETL调度完成之后,对应人群数据就会被推送到HBase数据库进行存储。当满足条件的新用户来访App时,由在线接口读取HBase数据库,在查询到该用户时为其推送该弹窗。
5.4 某电商再营销广告
5.4.1 案例背景
某电商App的商品运营团队欲提升电子产品的老客复购率、新客下单率,于是选择了和头条合作投放再营销广告。比如,某用户在该电商App看了vivo手机,第二天刷今日头条的时候,就看到了对应手机的广告信息。
5.4.2 实现逻辑
首先需要保证该电商App和今日头条的API已经打通,然后基于用户在App内行为( 浏览、收藏、加购、搜索等)进行算法挖掘产生用户商品偏好的标签。今日头条捕获用户设备信息后,就会向该电商发送一个请求,询问是否需要对这个用户展示广告。此时电商平台会判断该用户,是否属于自己的用户,如果是,就会对今日头条返回一个推荐结果,那么用户就会在今日头条看到之前浏览过的商品信息了,点击后就可以跳转到电商App内的商品详情页了。
参考文章:
https://www.zhihu.com/question/340090811/answer/3403302873