用户画像理论和搭建过程

一、定义

用户画像是根据目标用户的社会属性、生活习惯和其他行为信息，抽象出一个标签化的用户模型。

标签是名词性的、碎片式的，比如说当我们在使用互联网的时候，那些给我们提供服务的公司都在给我们打标签，你的任何一个行为都有可能被它贴上一个小标签。你购买了任何一件产品，你浏览了任何一条新闻，你都可能被打上了一个小标签，你都不知道你身上已经悄悄地被它贴上了几十个甚至几百个这样的小标签。这些小标签就像是一个密码，当你被贴上了几百个这样的小标签的时候，它就好像是加了密的电文，机器就能够用这些小标签逐渐地合成一个形象，随着你的浏览、你的购买行为越来越多的时候，这些标签会越来越多。用我们通常的话来说，你的颗粒会越来越多，颗粒度会越来越细，你在那边形成的画像的像素就会越来越高，它就会成为世界上最了解你的人，对你的了解程度超过你的亲戚、朋友、你的配偶，甚至超过你自己。

二、常用场景

2.1 产品设计

开发前期的产品定位设计。

 

2.2 产品运营和营销

指导运营，分析用户进行流失、投诉、推送活动、个性化推荐。

2.3 产品决策 

对产品的发展现状和趋势进行预测，及时调整产品发展路线。

三、生产方式

3.1 统计标签

可以从数据中直接提取出来的标签，包括用户的自然属性、行为统计。

3.2 规则标签

自定义规则进行建模标签，根据业务过程提取需要统计的标签。

3.3 算法模型标签

根据机器学习算法对用户行为预测分类，具有不确定性，开发周期长，成本高等特点。

四、搭建流程

用户画像的搭建流程有以下几步：数据采集→指标建模→观测数据→数据分析→业务洞察

4.1 数据采集

4.1.1 埋点数据

众所周知，日志采集多是为了后续的数据分析。移动端的数据采集，一是为了服务于开发者，协助开发者分析各类设备信息；二是为了帮助各APP更好地了解自己的用户，了解用户在APP上的各类行为，帮助各应用不断进行优化，提升用户体验。

埋点有3种方案，一般采用前端埋点和服务端埋点相结合的方式，因为有些数据流分析需要跨前-后端取值，比如用户点击支付按钮，前端埋点可能统计有2000人的点击，而后台确定的订单人数只有200人，这中间用户点击支付以后，需要选择支付方式，填写银行卡之类的信息，后台才会收到第三方网关支付成功的确认后才会统计，如果只统计前端的话数据误差较大，只统计后端的话又不知道支付的平均停留时长（只有客户端才知道），故只有跨前-后端埋点，才会获取全部数据。

我们就埋点方案的前端埋点着重说一下，无线客户端的日志采集采用采集SDK来完成。根据不同的用户行为分成不同的事件，“事件”是无线客户端日志行为的最小单位，一个行为产生一条日志，如一次浏览、一次点击等。基于常规的分析，事件分为页面事件（页面浏览）和控件点击事件，页面事件和控件点击事件的日志触发时机、日志内容和实现方式有差异之处：

事件分类-页面事件

每条页面事件日志记录三类信息：

①设备及用户的基本信息，主要包括：城市、地址、年龄、性别、经纬度、账号类型、运营商、网络、设备等等；

②被访问页面的信息，主要是一些业务参数：商品详情页的商品ID、所属的店铺等；

③访问基本路径（如页面来源、来源的来源等），用于还原用户完整的访问行为等。

实现页面事件的三种方法：

①无痕模式：采集SDK在页面创建时即发送日志；

②手动模式：提供两个接口，分别在页面展现和页面退出时调用，当用户进入一个商品详情页时，调用页面展现的接口，该接口会记录页面进入时的一些状态信息，但此时不发送日志，当从详情页离开时（可能在详情页点击某个商品到了对应的商品详情页，也可能退出了APP，抑或是点击返回，返回到了之前的一个页面），调用页面退出的接口，该接口会发送日志；

③页面扩展信息的接口，在页面离开前，使用该接口提供的方法给页面添加相关参数，比如给商品详情页添加店铺ID、店铺类型等。

上述三种接口方法必须配合使用，即页面展现和页面退出方法必须成对使用（方便计算停留时长），而页面扩展信息的接口必须在使用页面展现和页面退出方法的前提下使用。为了平衡采集、计算和分析的成本，在部分场景下我们选择采集更多的信息来减少计算及分析的成本。采集SDK提供透传参数功能。所谓透传参数，即把当前页面的某些信息，传递到下一个页面甚至下下一个页面的日志中。举个例子，首页搜索“连衣裙”，进入搜索List页面，然后点击某个商品进入商品A详情页。如果分析“连衣裙”这个关键词，或者商品A的来源搜索词，此时就需要把“连衣裙”这个关键词带入到搜索List页面日志、商品A详情页日志中，这样一来，分析搜索词的效果就显而易见了，通过透传机制将参数带入到下一步甚至下下一步的浏览页面，整个用户行为路径还原轻松实现。

事件分类-控件事件

控件点击事件，比页面事件要简单得多，点击即发送日志，他记录两类信息：

①设备及用户的基本信息；

②记录控件所在页面名称、控件名称、控件的业务参数等。

埋点管理

①新增埋点设计

在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事，你想要的数据有哪些，定义这些数据的字段包括但不限于以下字段：

埋点位置

埋点事件

事件变量定义

其他说明

指标变更日志备注

平台类型

一级模块

二级模块

三级模块

四级模块

事件显示名

触发时机

事件英文变量

事件变量

变量显示名

变量值示例或说明

变量值类型

埋点形式

埋点版本

                                                                                                                                     埋点指标定义
上图字段，分别解释下：         
埋点位置：平台类型覆盖了APP（分安卓或者ios端，因为有一些交互安卓与ios不同所以要做区分）、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；                                                  功能模块，分四级：

一级模块：APP的话指下方的标签菜单，比如首页、通讯录、发现...，Web的话指首页菜单；

二级模块：一级模块下的全部页面，比如课程列表页、详情页、购课单页、banner详情页····

三级模块：二级模块全部页面中的全部按钮，

每一个按钮都有唯一一个id，这个id组成是一级模块、二级模块、三级模块的id串联

比如点击事件 11-001-001，

其中11是指“我”一级模块

其11-001是指一级选课模块下的“设置”

其中11-001-001是指一级选课“我”模块下的“设置”的“关于”选项

这样每一个页面每一个按钮都有条理的排列下来了，其中，比较难处理的是每个模块的浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑。

事件变量定义：用来定义事件的参数，也可以理解为事件维度。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标越精简越好，便于理解和管理，但可能对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。

举一例，电商产品，商品详情页的事件变量怎么设计，见下图：

 

埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：

②通用埋点设计

③数据指标地图

④版本迭代功能埋点管理

 

参考资料：

埋点的设计、管理与应用

埋点—这一篇文章就够了

4.1.2 业务数据

4.1.3 采集方法

4.2 用户维度

 

4.3 维度标签化

 

4.4 标签映射，接口封装

 

4.5 用户画像评估

①

②

③④⑤⑥

参考链接：用户画像规划流程和方法

吴伯凡：字节跳动为什么能持续出爆品？

阿里巴巴：《大数据之路：阿里巴巴大数据实践》