【转载】用户画像原理、技术选型及架构实现

一、 什么是用户画像

    用户画像是指根据用户的属性、偏好、生活习惯、行为等信息,抽象出来的标签化用户模型。通俗说就是给用户打标签,而标签是通过对用户信息分析而来的高度精炼的特征标识。通过打标签可以利用一些高度概括、容易理解的特征来描述用户,可以让人更容易理解用户,并且可以方便计算机处理。
image

用户画像是对现实世界中用户的建模,用户画像包含目标,方式,组织,标准,验证这5个方面。

目标:指的是描述人,认识人,了解人,理解人。

方式:分为非形式化手段,如使用文字、语言、图像、视频等方式描述人;形式化手段,即使用数据的方式来刻画人物的画像。

组织:指的是结构化、非结构化的组织形式。

标准:指的是使用常识、共识、知识体系的渐进过程来刻画人物,认识了解用户。

验证:依据侧重说明了用户画像应该来源事实、经得起推理和检验。

image
    在产品早期和发展期,会较多地借助用户画像,帮助产品人员理解用户的需求,想象用户使用的场景,产品设计从为所有人做产品变成为三四个人做产品,间接的降低复杂度。

二、 用户画像的作用

在互联网、电商领域用户画像常用来作为精准营销、推荐系统的基础性工作,其作用总体包括:

(1)精准营销:根据历史用户特征,分析产品的潜在用户和用户的潜在需求,针对特定群体,利用短信、邮件等方式进行营销。

(2)用户统计:根据用户的属性、行为特征对用户进行分类后,统计不同特征下的用户数量、分布;分析不同用户画像群体的分布特征。

(3)数据挖掘:以用户画像为基础构建推荐系统、搜索引擎、广告投放系统,提升服务精准度。

(4)服务产品:对产品进行用户画像,对产品进行受众分析,更透彻地理解用户使用产品的心理动机和行为习惯,完善产品运营,提升服务质量。

(5)行业报告&用户研究:通过用户画像分析可以了解行业动态,比如人群消费习惯、消费偏好分析、不同地域品类消费差异分析

    根据用户画像的作用可以看出,用户画像的使用场景较多,用户画像可以用来挖掘用户兴趣、偏好、人口统计学特征,主要目的是提升营销精准度、推荐匹配度,终极目的是提升产品服务,起到提升企业利润。用户画像适合于各个产品周期:从新用户的引流到潜在用户的挖掘、从老用户的培养到流失用户的回流等。
image
    总结来说,用户画像必须从实际业务场景出发,解决实际的业务问题,之所以进行用户画像,要么是获取新用户,要么是提升用户体验、或者挽回流失用户等具有明确的业务目标。
image
image
image
    另外关于用户画像数据维度的问题,并不是说数据维度越丰富越好,总之,画像维度的设计同样需要紧跟业务实际情况进行开展。

** 三、 用户画像的分类**

    从画像方法来说,可以分为定性画像、定性+定量画像、定量画像
image
    从应用角度来看,可以分为行为画像、健康画像、企业信用画像、个人信用画像、静态产品画像、旋转设备画像、社会画像和经济画像等。

四、 用户画像需要用到哪些数据

    一般来说,根据具体的业务内容,会有不同的数据,不同的业务目标,也会使用不同的数据。在互联网领域,用户画像数据可以包括以下内容:

(1)人口属性:包括性别、年龄等人的基本信息

(2)兴趣特征:浏览内容、收藏内容、阅读咨询、购买物品偏好等

(3)消费特征:与消费相关的特征

(4)位置特征:用户所处城市、所处居住区域、用户移动轨迹等

(5)设备属性:使用的终端特征等

(6)行为数据:访问时间、浏览路径等用户在网站的行为日志数据

(7)社交数据:用户社交相关数据

image
    用户画像数据来源广泛,这些数据是全方位了解用户的基础,这里以Qunar的画像为例,其画像数据主要维度如下所示,包括用户RFM信息、航线信息等。
image
    Qunar的画像数据仓库构建都是基于Qunar基础数据仓库构建,然后按照维度进行划分。
image

五、 用户画像主要应用场景

a)用户属性

b)用户标签画像

c)用户偏好画像

d)用户流失

e)用户行为

f)产品设计

g) 个性化推荐、广告系统、活动营销、内容推荐、兴趣偏好

image

六、 用户画像使用的技术方法

七、 用户画像标签体系的建立

1、什么是标签体系

    用户画像是对现实用户做的一个数学模型,在整个数学模型中,核心是怎么描述业务知识体系,而这个业务知识体系就是本体论,本体论很复杂,我们找到一个特别朴素的实现,就是标签。

    标签是某一种用户特征的符号表示。是一种内容组织方式,是一种关联性很强的关键字,能方便的帮助我们找到合适的内容及内容分类。(注:简单说,就是你把用户分到多少个类别里面去,这些类是什么,彼此之间有什么关系,就构成了标签体系)

    标签解决的是描述(或命名)问题,但在实际应用中,还需要解决数据之间的关联,所以通常将标签作为一个体系来设计,以解决数据之间的关联问题。

    一般来说,将能关联到具体用户数据的标签,称为叶子标签。对叶子标签进行分类汇总的标签,称为父标签。父标签和叶子标签共同构成标签体系,但两者是相对概念。例如:下表中,地市、型号在标签体系中相对于省份、品牌,是叶子标签。

|

一级标签

|

二级标签

|

三级标签

|

四级标签

|
| --- | --- | --- | --- |
|

移动属性

用户所在地

省份

地市

手机品牌

品牌

型号

 

 

业务属性

 

 

用户等级

普通

音乐普通会员

音乐高级会员

音乐VIP会员

        用户画像标签体系创建后一般要包含以下几个方面的内容

|

image

(1)标签分类

    用户画像标签可以分为基础属性标签和行为属性标签。
image
    由于基于一个目标的画像,其标签是在动态扩展的,所以其标签体系也没有统一的模板,在大分类上,与自身的业务特征有很大的关联,在整体思路上可以从横纵两个维度展开思考:横向是产品内数据和产品外数据,纵向是线上数据和线下数据。而正中间则是永恒不变的“人物基础属性”。

    如果说其他的分类因企业特征而定,那么只有人物特征属性(至于名字叫什么不重要,关键是内涵)是各家企业不能缺失的板块。

    所谓人物基础属性指的是:用户客观的属性而非用户自我表达的属性,也就是描述用户真实人口属性的标签。所谓非“自我表达”,举例来说,某产品内个人信息有性别一项,用户填写为“女”,而通过用户上传的身份证号,以及用户照片,用户购买的产品,甚至用户打来的客服电话,都发现该用户性别是“男性”。那么在人物基础属性中的性别,应该标识的是“男性”,但是用户信息标签部分,自我描述的性别则可能标注为女性。

(2)标签级别(标签的体系结构)

    分级有两个层面的含义,其一是:指标到最低层级的涵盖的层级;其二是指:指标的运算层级。其一非常好理解,这里重点说运算层级。

    标签从运算层级角度可以分为三层:事实标签、模型标签、预测标签。

    事实标签:是通过对于原始数据库的数据进行统计分析而来的,比如用户投诉次数,是基于用户一段时间内实际投诉的行为做的统计。

    模型标签:模型标签是以事实标签为基础,通过构建事实标签与业务问题之间的模型,进行模型分析得到。比如,结合用户实际投诉次数、用户购买品类、用户支付的金额等,进行用户投诉倾向类型的识别,方便客服进行分类处理。

    预测标签:则是在模型的基础上做预测,比如针对投诉倾向类型结构的变化,预测平台舆情风险指数。
image

(3)标签命名&赋值

    我们用一张图来说明一下命名和赋值的差别,只要在构建用户标签的过程种,有意识的区别标签命名和赋值足矣,不再赘述。
image

(4)标签属性

    标签属性可以理解为针对标签进行的再标注,这一环节的工作主要目的是帮助内部理解标签赋值的来源,进而理解指标的含义。如图所示,可以总结为5种来源:

1、固有属性:是指这些指标的赋值体现的是用户生而有之或者事实存在的,不以外界条件或者自身认知的改变而改变的属性。比如:性别、年龄、是否生育等。

2、推导属性:由其他属性推导而来的属性,比如星座,我们可以通过用户的生日推导,比如用户的品类偏好,则可以通过日常购买来推导。

3、行为属性:产品内外实际发生的行为被记录后形成的赋值,比如用户的登陆时间,页面停留时长等。

4、态度属性:用户自我表达的态度和意愿。比如说我们通过一份问卷向用户询问一些问题,并形成标签,如询问用户:是否愿意结婚,是否喜欢某个品牌等。当然在大数据的需求背景下,利用问卷收集用户标签的方法效率显得过低,更多的是利用产品中相关的模块做了用户态度信息收集。

5、测试属性:测试属性是指来自用户的态度表达,但并不是用户直接表达的内容,而是通过分析用户的表达,结构化处理后,得出的测试结论。比如,用户填答了一系列的态度问卷,推导出用户的价值观类型等。

image
    值得注意的是,一种标签的属性可以是多重的,比如:个人星座这个标签,既是固有属性,也是推导属性,它首先不以个人的意志为转移,同时可以通过身份证号推导而来。

    即便你成功了建立用户画像的标签体系,也不意味着你就开启了用户画像的成功之路,因为有很大的可能是这些标签根本无法获得,或者说无法赋值。

    标签无法赋值的原因有:数据无法采集(没有有效的渠道和方法采集到准确的数据,比如用户身份证号)、数据库不能打通、建模失败(预测指标无法获得赋值)等等。

2、标签体系结构

    标签体系可以归纳出如下的层级结构。
image

(1)原始输入层

    主要指用户的历史数据信息,如会员信息、消费信息、网络行为信息。经过数据的清洗,从而达到用户标签体系的事实层。

(2)事实层

    事实层是用户信息的准确描述层,其最重要的特点是,可以从用户身上得到确定与肯定的验证。如用户的人口属性、性别、年龄、籍贯、会员信息等。

(3)模型预测层

    通过利用统计建模,数据挖掘、机器学习的思想,对事实层的数据进行分析利用,从而得到描述用户更为深刻的信息。如通过建模分析,可以对用户的性别偏好进行预测,从而能对没有收集到性别数据的新用户进行预测。还可以通过建模与数据挖掘,使用聚类、关联思想,发现人群的聚集特征。

(4)营销模型预测

    利用模型预测层结果,对不同用户群体,相同需求的客户,通过打标签,建立营销模型,从而分析用户的活跃度、忠诚度、流失度、影响力等可以用来进行营销的数据。

(5)业务层

    业务层可以是展现层。它是业务逻辑的直接体现,如图中所表示的,有车一族、有房一族等。

3、标签体系结构分类

    一般来说,设计一个标签体系有3种思路,分别是:(1)结构化标签体系;(2)半结构化标签体系;(3)非结构化标签体系。

(1)结构化标签体系

    简单地说,就是标签组织成比较规整的树或森林,有明确的层级划分和父子关系。结构化标签体系看起来整洁,又比较好解释,在面向品牌广告井喷时比较好用。性别、年龄这类人口属性标签,是最典型的结构化体系。下图就是Yahoo!受众定向广告平台采用的结构化标签体系。
image

(2)半结构化标签体系

    在用于效果广告时,标签设计的灵活性大大提高了。标签体系是不是规整,就不那么重要了,只要有效果就行。在这种思路下,用户标签往往是在行业上呈现出一定的并列体系,而各行业内的标签设计则以“逮住老鼠就是好猫”为最高指导原则,切不可拘泥于形式。下图是Bluekai聚合多家数据形成的半结构化标签体系。
image

(3)非结构化标签体系

    非结构化,就是各个标签就事论事,各自反应各自的用户兴趣,彼此之间并无层级关系,也很难组织成规整的树状结构。非结构化标签的典型例子,是搜索广告里用的关键词。还有Facebook用的用户兴趣词。

** 4、用户画像标签层级的建模方法**

    用户画像的核心是标签的建立,用户画像标签建立的各个阶段使用的模型和算法如下图所示。
image
image

原始数据层。对原始数据,我们主要使用文本挖掘的算法进行分析如常见的TF-IDF、TopicModel主题模型、LDA 等算法,主要是对原始数据的预处理和清洗,对用户数据的匹配和标识。

事实标签层。通过文本挖掘的方法,我们从数据中尽可能多的提取事实数据信息,如人口属性信息,用户行为信息,消费信息等。其主要使用的算法是分类和聚类。分类主要用于预测新用户,信息不全的用户的信息,对用户进行预测分类。聚类主要用于分析挖掘出具有相同特征的群体信息,进行受众细分,市场细分。对于文本的特征数据,其主要使用相似度计算,如余弦夹角,欧式距离等。

模型标签层。使用机器学习的方法,结合推荐算法。模型标签层完成对用户的标签建模与用户标识。其主要可以采用的算法有回归,决策树,支持向量机等。通过建模分析,我们可以进一步挖掘出用户的群体特征和个性权重特征,从而完善用户的价值衡量,服务满意度衡量等。

预测层。也是标签体系中的营销模型预测层。这一层级利用预测算法,如机器学习中的监督学习,计量经济学中的回归预测,数学中的线性规划等方法。实习对用户的流失预测,忠实度预测,兴趣程度预测等等,从而实现精准营销,个性化和定制化服务。

不同的标签层级会考虑使用对其适用的建模方法,对一些具体的问题,有专门的文章对其进行研究。

**八、 用户画像基本步骤[F2] **

    根据具体业务规则确定用户画像方向后,开展用户画像分析,总体来说,一个用户画像流程包括以下三步。(1)用户画像的基本方向;(2)用户数据收集;(3)用户标签建模。
image
    另外,需要注意的是用户画像的时效性,构建画像的数据多为历史数据,但用户的行为、偏好等特征多会随着时间的推移而发生变化。

九、 用户画像验证

image

十、 用户画像的实际例子

    注:此处涉及到工作中的项目内容,由于保密,就不能分享了

十一、 用户画像平台&架构

用户画像平台需要实现的功能。

image
    用户画像系统技术架构
image

(1) 数据处理

a、数据指标的梳理来源于各个系统日常积累的日志记录系统,通过sqoop导入hdfs,也可以用代码来实现,比如spark的jdbc连接传统数据库进行数据的cache。还有一种方式,可以通过将数据写入本地文件,然后通过sparksql的load或者hive的export等方式导入HDFS。

b、通过hive编写UDF 或者hiveql根据业务逻辑拼接ETL,使用户对应上不同的用户标签数据(这里的指标可以理解为每个用户打上了相应的标签),生成相应的源表数据,以便于后续用户画像系统,通过不同的规则进行标签宽表的生成。

(2) 数据平台

a、数据平台应用的分布式文件系统为Hadoop的HDFS,因为Hadoop2.0以后,任何的大数据应用都可以通过ResoureManager申请资源,注册服务。比如(sparksubmit、hive)等等。而基于内存的计算框架的出现,就并不选用Hadoop的MapReduce了。当然很多离线处理的业务,很多人还是倾向于使用Hadoop,但是Hadoop封装的函数只有map和Reduce太过单一,而不像spark一类的计算框架有更多封装的函数(可参考博客spark专栏)。可以大大提升开发效率。

b、计算的框架选用Spark以及RHadoop,这里Spark的主要用途有两种,一种是对于数据处理与上层应用所指定的规则的数据筛选过滤,(通过Scala编写spark代码提交至sparksubmit)。一种是服务于上层应用的SparkSQL(通过启动spark thriftserver与前台应用进行连接)。 RHadoop的应用主要在于对于标签数据的打分,比如利用协同过滤算法等各种推荐算法对数据进行各方面评分。

c、MongoDB内存数据的应用主要在于对于单个用户的实时的查询,也是通过对spark数据梳理后的标签宽表进行数据格式转换(json格式)导入mongodb,前台应用可通过连接mongodb进行数据转换,从而进行单个标签的展现。(当然也可将数据转换为Redis中的key value形式,导入Redis集群)

d、mysql的作用在于针对上层应用标签规则的存储,以及页面信息的展现。后台的数据宽表是与spark相关联,通过连接mysql随后cache元数据进行filter、select、map、reduce等对元数据信息的整理,再与真实存在于Hdfs的数据进行处理。

(3) 面向应用

从刚才的数据整理、数据平台的计算,都已经将服务于上层应用的标签大宽表生成。(用户所对应的各类标签信息)。那么前台根据业务逻辑,勾选不同的标签进行求和、剔除等操作,比如本月流量大于200M用户(标签)+本月消费超过100元用户(标签)进行和的操作,通过前台代码实现sql的拼接,进行客户数目的探索。这里就是通过jdbc的方式连接spark的thriftserver,通过集群进行HDFS上的大宽表的运算求count。(这里要注意一点,很多sql聚合函数以及多表关联join 相当于hadoop的mapreduce的shuffle,很容易造成内存溢出,相关参数调整可参考本博客spark栏目中的配置信息)这样便可以定位相应的客户数量,从而进行客户群、标签的分析,产品的策略匹配从而精准营销。

十二、用户画像困难点、用户画像瓶颈

用户画像困难点主要表现为以下4个方面

image

资料搜集和数据挖掘

   在画像之前需要知道产品的用户特征和用户使用产品的行为等因素,从而从总体上掌握对用户需求需求

     创建用户画像不是抽离出典型进行单独标签化的过程,而是要融合边缘环境的相关信息来进行讨论

定量调研分析

用户标签画像

我们的用户标签包含基本特征、社会身份、顾客用户生命周期、类目偏好等等。比如说你怎么判断一个人是不是对女装感兴趣,假设我们有一个类目就是女装,那很好办,如果你购买都是女装,那会认为你这个人对女装比较感兴趣。

挑战

我们期间遇到了两方面的挑战:

亿级画像系统实践和应用

记录和存储亿级用户的画像,支持和扩展不断增加的维度和偏好,毫秒级的更新,支撑个公司性化推荐、广告投放和精细化营销等产品。

转自网络,感谢原作者

[图片上传失败...(image-8dadd6-1587028421193)]

这里讲解下用户画像的技术架构和整体实现,那么就从数据整理、数据平台、面向应用三个方面来讨论一个架构的实现(个人见解)。

数据整理:

1、数据指标的的梳理来源于各个系统日常积累的日志记录系统,通过sqoop导入hdfs,也可以用代码来实现,比如spark的jdbc连接传统数据库进行数据的cache。还有一种方式,可以通过将数据写入本地文件,然后通过sparksql的load或者hive的export等方式导入HDFS。

2、通过hive编写UDF 或者hiveql 根据业务逻辑拼接ETL,使用户对应上不同的用户标签数据(这里的指标可以理解为为每个用户打上了相应的标签),生成相应的源表数据,以便于后续用户画像系统,通过不同的规则进行标签宽表的生成。

数据平台

1、数据平台应用的分布式文件系统为Hadoop的HDFS,因为Hadoop2.0以后,任何的大数据应用都可以通过ResoureManager申请资源,注册服务。比如(sparksubmit、hive)等等。而基于内存的计算框架的出现,就并不选用hadoop的MapReduce了。当然很多离线处理的业务,很多人还是倾向于使用Hadoop,但是hadoop的封装的函数只有map和Reduce太过单一,而不像spark一类的计算框架有更多封装的函数(可参考博客spark专栏)。可以大大提升开发效率。

2、计算的框架选用Spark以及RHadoop,这里Spark的主要用途有两种,一种是对于数据处理与上层应用所指定的规则的数据筛选过滤,(通过Scala编写spark代码提交至sparksubmit)。一种是服务于上层应用的SparkSQL(通过启动spark thriftserver与前台应用进行连接)。 RHadoop的应用主要在于对于标签数据的打分,比如利用协同过滤算法等各种推荐算法对数据进行各方面评分。

3、MongoDB内存数据的应用主要在于对于单个用户的实时的查询,也是通过对spark数据梳理后的标签宽表进行数据格式转换(json格式)导入mongodb,前台应用可通过连接mongodb进行数据转换,从而进行单个标签的展现。(当然也可将数据转换为Redis中的key value形式,导入Redis集群)

4、mysql的作用在于针对上层应用标签规则的存储,以及页面信息的展现。后台的数据宽表是与spark相关联,通过连接mysql随后cache元数据进行filter,select,map,reduce等对元数据信息的整理,再与真实存在于Hdfs的数据进行处理。

面向应用

1、从刚才的数据整理、数据平台的计算,都已经将服务于上层应用的标签大宽表生成。(用户所对应的各类标签信息)。那么前台根据业务逻辑,勾选不同的标签进行求和、剔除等操作,比如本月流量大于200M用户(标签)+本月消费超过100元用户(标签)进行和的操作,通过前台代码实现sql的拼接,进行客户数目的探索。这里就是通过jdbc的方式连接spark的thriftserver,通过集群进行HDFS上的大宽表的运算求count。(这里要注意一点,很多sql聚合函数以及多表关联join 相当于hadoop的mapreduce的shuffle,很容易造成内存溢出,相关参数调整可参考本博客spark栏目中的配置信息) 这样便可以定位相应的客户数量,从而进行客户群、标签的分析,产品的策略匹配从而精准营销。

你可能感兴趣的:(【转载】用户画像原理、技术选型及架构实现)