序章：数据产品要做哪些事情
在工作中做什么？
- 数据采集
- 数据加工
- 看数据
- 分析数据
- 应用数据
1、数据采集模块
数据的价值体现在决策上，所有业务系统的数据最终都是为了决策，你得先有数据。
(1) 如果是C端中后台或者B端产品，本身业务系统就会存储这些数据，我们在使用这些数据时候直接同步到数仓即可
由业务库同步到数仓的过程就是数据采集
(2) 如果是ToC端或ToB的Saas产品，我们经常需要通过用户行为数据去做活动分析、用户分析、留存分析等等，这些数据从哪里来？数据产品需要基于业务场景拆解指标，进而梳理埋点文档。
这是采集用户行为数据
(3) 如果支撑比如企业关系分析、企业风控场景，内部没有这些数据，那我们可以通过爬取天眼查或者企查查这种数据来支撑我们的业务
(4) 有一些新零售企业在第三方直播平台卖货，想拿到自己的数据进行深度分析，可以从短视频平台的开放平台中找到对应的API接口并梳理不同场景下的取数逻辑
2、数据加工
什么是数据处理能力？
- 数据处理能力包括数据存储、数据整合、数据安全等能力。这些内容都属于数仓的知识体系
所以至少需要掌握SQL能力
3、搭建数据看板
搭建数据看板需要掌握数据可视化能力，数据可视化可以帮助我们更好地决策。因此，需要掌握至少一款BI工具，能够搭建数据看板离不开数据的采集与数据加工
4、分析数据
什么是数据分析？
- 我们看到一个图可以观察到数据的波动、趋势、对比等，但是数据为什么这么表现，我们需要更深层次的进行多角度的分析，最后得出结论指导我们的产品迭代或者业务方向、运营策略的能力就是数据分析能力
5、数据应用
有了数据，我们可以进行精细化运营。
什么是精细化运营？
- 在合适的时机给用户推匹配的产品，或者说我们有了用户画像就可以为用户提供更好的服务。这其中需要梳理用户标签体系：
| 什么是用户画像？ | 1. 什么是用户 2. 用户画像的作用：洞察需求、指导设计 3. 常见问题（伪需求）：浅、偏、僵 |
| 第一步：用户调研 | 1. 调查问卷 2. 焦点小组 3. 数据埋点 产出：丰富呈现用户状态的乱序标签（记录） |
| 第二步：用户角色 | 1. 用户角色PERSONA 2. 直觉第一印象 3. 动机与能力：B=MAT 4. 环境影响 5. 与他人关系 产出：一个用户决策表 |
| 第三步：用户建模 | 1. 标签组合与交叉分析 2. 四层标签体系：静态+动态+偏好+预测 3. 用户画像：自动标签 产出：结构化用户画像（四层标签体系+规则） |
| 第四步：指导设计 | 1. 推荐系统：高频高动态 2. 定价策略：判断价格敏感 3. 设计爆款：带动效应 4. 提升体验：找到关键点 产出：产品设计方向（辅助决策） |
一、设计数据埋点
1.1 常见埋点方式
| 前端埋点 | 后端埋点 | |
|---|---|---|
| 埋点方式 | 1. 代码埋点 2. 可视化埋点 3. 无埋点 | |
| 前端 后端 埋点 | 主要在客户端埋点，收集前端数据，如用户事件行为，界面变化等 | 主要在服务端埋点，收集数据在服务端进行（http request发生时的数据），比如业务逻辑数据交互等 |
| 如何选择 | 业务处于运营初级阶段，产品功能相对简单。 需要分析与后端没有交互的前端行为的时候，选择前端埋点 | 1. 在各行业中有特殊业务需求的数据优先考虑后端埋点 2. 追求精细化运营，需多维数据分析 3. 包含重要业务数据的网站或APP 4. 对数据安全要求比较高 |
前端埋点-代码埋点
- 主要由前端在程序中编写代码，调用埋点SDK的函数，在需要埋点的业务逻辑功能位置调用接口上报埋点数据
| 优点 | 缺点 |
|---|---|
| 1. 能够设置自定义属性、自定义事件 2. 能够控制发送的时机和发送的方式 3. 控制数据的准确性 | 1. 工程量大，控件埋点都需要添加代码 2. 人力成本高，需开发写代码 3. 埋点更新或漏埋点，需要依赖下一次APP发版才能进行修复 |
前端埋点-可视化埋点
- 把核心代码和配置、资源分开，在可视化页面对埋点区域和事件进行设定，从而在用户操作时，对用户的操作行为进行记录
| 优点 | 缺点 |
|---|---|
| 1. 简单、方便、快速埋点 2. 无需版本更新，节省人力和更新成本 3. 新增埋点在所有版本生效，不存在迭代问题 | 1. 上报的行为信息有限 2. 不能自定义交互事件的属性 3. 不支持可以不断加载的内容瀑布流交互 |
前端埋点-无埋点
- 通过SDK，前端会自动全量采集全部事件并上报埋点数据，当用户触发任何事件时，会自动上报数据
| 优点 | 缺点 |
|---|---|
| 1. 在解决数据回溯的问题上更有优势，适合做页面点击热力图 2. 技术门槛低，部署简 单 | 1. 自定义属性不灵活，传输时效性差 2. 数据形式非业务导向型 3. 增加服务器负载，兼容性不佳，数据存储空间大 |
1.2 如何选择埋点方式
| 代码埋点 | 可视化埋点 | 无埋点 |
|---|---|---|
| 对埋点事件进行传参等自定义属性设置 | 分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置 | 分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置 |
| 较复杂，但功能最完善，覆盖了埋点中的不同业务需求 | 频繁上线或更新的H5类型的运营活动 | 针对快速，频繁上线和迭代的H5类型的运营活动的评估 |
1.3 如何设计埋点
- 前端埋点：不仅是Key-Value形式，不同场景，会更复杂
- 后端埋点：使用Key-Value形式进行埋点
1.3.1 如何设计前端埋点
设计埋点事件的原则：
- 同种属性的多个事件要命名成一个埋点事件ID并以Key-Value的形式区分。
- 不同属性的多个事件应该命名成多个埋点事件ID此时也尽量不用Key-Value的形式埋点。
Key-value形式的埋点设计规划：
- Key一般表示某个事件
- Value代表相对应的值
- 一个Key可以对应一个Value或者多个Value
1.3.2 美团案例
背景： 美团上线了活动A和活动B两个活动都在酒店和旅游的入口页面进行了Banner展示，想知道这两个活动的用户访问情况。
问题： 经过梳理指标体系和指标字典，明确了要分析活动入口的点击量等数据，如何对活动入口的点击量进行埋点统计?
1.3.2.1 方案1：每一个埋点代表一个事件
活动A-酒店入口按钮 → 事件ID1
活动A-旅游入口按钮 → 事件ID2
活动B-酒店入口按钮 → 事件ID3
活动B-旅游入口按钮 → 事件ID4
埋点方案：
| 功能 | 用户行为 | 事件类型 | 事件ID | 描述 | 备注 |
|---|---|---|---|---|---|
| 活动A | 活动A点击酒店入口 | 点击 | ActivityA_Hotel_EnterPage | 点击活动A的酒店入口，点击一次记录一次数据 | |
| 活动A | 活动A点击旅游入口 | 点击 | ActivityA_Travel_EnterPage | 点击活动A的旅游入口，点击一次记录一次数据 | |
| 活动B | 活动B点击酒店入口 | 点击 | ActivityB_Hotel_EnterPage | 点击活动B的酒店入口，点击一次记录一次数据 | |
| 活动B | 活动B点击旅游入口 | 点击 | ActivityB_Travel_EnterPage | 点击活动B的旅游入口，点击一次记录一次数据 |
1.3.2.2 方案2：Key-Value方式
graph TD
事件ID --> 页面来源page --> 活动A
页面来源page --> 活动B
事件ID --> 元素类型source --> 酒店入口按钮
元素类型source --> 旅游入口按钮
埋点方案：
| 功能 | 用户行为 | 事件类型ActionType | Key | Value | 描述 | 备注 |
|---|---|---|---|---|---|---|
| 统计酒店和旅游两个按钮的点击事件 | 在不同页面点击酒店和旅游按钮 | Click | page | ActivityA | 进入页面A记录一次 | 通过指定Page, Source和事件类型的值来查询数据。 例如查询点击酒店按钮 进入页面A可通过： Page = ActivityA and Source = HotelButton and ActionType = Click来查询数据 |
| ActivityB | 进入页面B记录一次 | |||||
| source | HotelButton | 点击酒店按钮记录一次 | ||||
| TravelButton | 点击旅游按钮记录一次 |
优点：
- 维护成本低，更简单高效，新增时只需要在更新埋点文档时加一个Value参数即可
- 减少沟通成本，提高其他业务人员、数据分析师根据埋点日志进行查询分析的效率
- 扩展性好，对未来上线新活动或者业务的调整等更加灵活，可在原有基础上扩展
1.4 埋点设计实例
1.4.1 前端代码埋点设计实例：曝光事件
曝光事件： 主要记录页面被用户浏览的次数，是埋点时记录页面流量最常用的事件
上报机制： 当用户成功地进入一个页面时记录一次曝光事件，刷新一次页面时也会上报一次。如果通过手机HOME键（很多手机已经没有了）切换出去，则不会上报事件
| Key | Value | 字段含义 |
|---|---|---|
| action-type | OPENPAGE | 打开页面 |
| page-name | HOTEL-MAINPAGE | 页面名称 |
1.4.2 前端代码埋点设计实例：点击事件
点击事件： 用户点击页面某个对象触发的事件，通常用于评估页面对象的使用情况
上报机制： 当用户点击一次页面上的某个对象，都会记录上报一次数据
| Key | Value | 字段含义 |
|---|---|---|
| action-type | CLICK | 点击事件 |
| entity-type | BUTTON | 点击对象类型 |
| entity-name | HotelButton | 点击对象名称 |
| page-name | APPMAINPAGE | 点击对象所在页面 |
1.4.3 前端代码埋点设计实例：页面停留时长
页面停留时长： 主要用来记录用户在某页面的停留时间，用来评估用户对页面或功能的粘性
计算规则： 根据记录的用户进入页面时间t1和离开时间t2计算
| Key | Value | 字段含义 |
|---|---|---|
| action-type | LEAVE-PAGE | 离开页面 |
| page-name | MONTHCARD-RENEWAL | 页面名称 |
1.5 埋点设计的误区
- 埋点没那么重要，简单设计即可
- 在业务中都使用无埋点方式
- 所有业务都使用同一套埋点采集方案
二、设计指标字典
2.1 什么是指标字典
指标字典 是对业务指标成体系化的汇总，用来明确指标的口径、维度、指标取数逻辑等信息，并能快速获取到指标的相关信息。
- 业务数据标准化的基础
- 对指标进行统一管理
- 方便统一修改、共享和维护
什么是指标?
指标是衡量目标的方法，由维度、汇总方式和量度组成
维度 从哪些角度去衡量
- 维度是看待事物的视角与方向
- 维度决定了根据什么角度去衡量指标
汇总方式 用哪些方法衡量
- 汇总方式是统计汇总数量的方式
- 常用的汇总：求和、求均值
量度 目标是什么
- 量度是对一个物理量的测定，常以 数字+计量单位 表示
- 量度是数据的重要组成部分，用来明确数据的计量单位
示例：
订单总金额：用户在统计周期内完成支付的订单金额总和。
（按照支付时间统计，不考虑订单是否取消，而种为人民币，计量单位为元）
指标的类型
| 基础指标 | 复合指标 | 派生指标 |
|---|---|---|
| 主要指不能再拆解的指标，通常表达业务实体原子量化属性的且不可再分的概念集合 | 建立在基础指标之上通过一定运算规则形成的计算指标集合 | 指基础指标或复合指标与维度成员、统计属性、管理属性等相结合产生的指标 |
| 如：订单数、销售金额 | 如：平均订单金额 = 订单总金额 / 订单数 | 如：近30天订单金额 = 用户在过去30天完成支付的订单总金额 |
2.2 指标字典要达到的要求
指标字典示例
人民币人民币人民币| 模块 | 指标 | 指标口径 | 维度 |
|---|---|---|---|
| 订单 | 订单量 | 一段时间内用户在统计周期内完成支付的订单数总和 （按照支付时间统计，不考虑订单是否取消） |
时间（日/周/月） |
| 订单总金额 | 用户在统计周期内完成支付的订单金额总和 （按照支付时间统计，不考虑订单是否取消，币种为人民币，计量单位为元） |
时间（日/周/月） |
指标字典的要求
- 命名规范
- 规范维度和量度命名，命名规则尽量做到明确、易懂
- 例：订单总金额，统一命名，规范维度为时间，量度为元
- 定义清晰
- 对维度和量度统一计算口径，避免歧义，明确指标取数逻辑
- 例：订单总金额定义为用户在统计周期内完成支付的订单金额总和，按照支付时间统计，不考虑订单是否取消
- 覆盖范围广
- 涵盖尽可能多的核心维度和量度，确保指标字典里覆盖的维度可区分、指标可统计
- 例：明确订单总金额是可以统计到的，时间维度是能够区分出来的
- 可拓展性强
- 将指标字典的维度和量度注入元数据中心，并接入指标提取工具，这样不需要写SQL便可完成自助查询分析
- 例：指标易于接入元数据中和数据提取工具
2.3 如何设计指标字典
timeline
title 如何设计指标字典
确定分析指标 : 运用GSM模型确定分析指标
明确指标的维度与口径 : 先从单维度、粗维度分析
: 再细拆维度，自外而内地看问题
指标评审 : 纠正描述不明确
: 或者有分歧的指标达成一致
运营指标字典 : 指标字典培训
: 指标字典推广
案例： 你要做一个商品的促销活动，想要分析活动的效果，如何设计指标字典?
用GSM模型确定分析指标
| 1. 识别目标 | 2. 推导相应的用户表现 | 3. 找出关键指标 |
|---|---|---|
| 产品的目标是什么？ 用户的目标是什么？ | 一定有哪些现象发生？ 会有哪些信号出现？ | 具体哪些指标可以衡量表现？ 根据数据应该采取怎样行动？ |
| 分析专题活动活动效果，购买情况 | 访问人数增加，用户粘性提高，转化率提升 | 页面访问人数 用户停留总时长 用户平均停留时长 购买转化率 |
明确指标维度和口径
根据指标字典要达到的要求和业务需求，分别在汇总方式维度和量度上来梳理指标字典
以页面访问人数为例，明确页面访问人数的指标口径和维度：
| 指标 | 指标口径 | 维度 |
|---|---|---|
| 页面访问人数 | 一段时间内，浏览活动页面的人数 | 平台/应用版本 时间（日/周/月） |
2.4 指标字典产品化
指标字典产品化需要具备的功能：
- 展示和搜索功能
- 更新记录和通知功能
- 指标留言回复功能
- 打通数据分析功能
2.5 设计指标字典常见误区
- 业务主题并非设计越多指标越好，核心指标一般设计3-5个即可
- 上线指标字典后不等于完成了任务
- 指标字典产品化不限于具体的产品形态，不一定要开发系统功能，可直接维护在文档中
