互联网业务数据分析

互联网业务数据分析

Chap1 数据指标体系与建模方法

一、常用的数据指标

数据可以分为三类：用户数据、行为数据、业务数据(描述业务本身的发展)

1.用户数据

1.1 DAU MAU

• DAU（Daily Active User）：单日活跃用户量，反应产品短期用户活跃度

  • 一个自然日
    • Tips： 跨时区的产品，就是考虑24h

• MAU（Monthly Active User）：单月活跃用户量，反应产品长期用户活跃度

  • MAU不等于当月个日的DAU之和单纯将日活相加不具有参考价值，应该进行去重处理

• 定义活跃：

  1. 基于事件上报(产生了某种行为) -> 活跃
  2. 基于关键事件上报 - > 活跃
     • 事件列表：访问首页 / 访问商品详细页 / 访问抽奖页
     • 存在维护成本和沟通成本

• 定义：用户

  • 根据个人 -> 每个注册用户有一个唯一的专属ID，未登录的用户会被漏掉
  • 根据设备 -> 无法对应设备背后的用户

• 日活和月活的比值 DAU/MAU

  • **10%～30%**之间。如果低于10%，很可能已经处于衰退期；高于20%的留存还不错
  • 每天都使用产品的用户比例高，即使用频率高，用户对产品的依赖性强，
  • 同时也说明用户粘度较强。另一方面，也代表了用户的流失率低，留存率高
  • 日活和月活的比值低，用户使用频率低，依赖性弱，粘度较弱，用户流失率高，留存率低。

1.2 新增用户

新增用户怎么定义新增？

选择合适的节点，定义增用户完成某些行为算新增（比如完成注册或认证）；用合适的方法，判别新（基于设备和账号关联）。

1.3 留存率

T 日新增用户中，在第 n 日（即 T+n 日）再次活跃的用户，占 T 日新增用户的比例。

• 了解某一个渠道的质量——日留存

  • 以日为单位，衡量这个渠道来的用户当下&接下来的表现。以（X日日留存）作为比较标准时，可以避免其他日数据的干扰。常见的有次日留存和七日留存。七日留存分为：七日日留存、七日内留存。

  • 七日日留存，只关心到特定日的留存情况，避免了其他日数据的干扰。

    • 七日日留存=$\frac{第七天}{第一天}$

  • 七日内留存，引入了其他日数据，适用于有固定使用周期，且周期较长的业务。

    • 七日内留存：$\frac{第2天第7天去重后}{第一天}$

  • 首日留存：$\frac{第1天}{第0天}$ 常用于游戏行业

    • 设置第一天为第0天，可以实现分子分母的星期相同，某种程度上可以抵消
    • 新增当日为第0天，下一日为第一天，使第七日与新当日对齐，有利于抵消某些星期级别的周期性差异。

• 观察整个大盘——周留存/月留存

  • 以周/月为单位，衡量产品的健康情况，观察用户在平台上的粘性，务必要做去重。

• 提升留存率的大方向：

  • 一个就是增加产品的用户价值
  • 第二是找到用户流失的原因
  • 第三步就是解决用户流失的问题

1.4 渠道来源

2. 行为数据

2.1 PV / UV / 访问深度

• PV的(page view)，译为页面浏览量、访问量 -> 次数
• UV(unique view),指访问某个站点或点击某个网页的不同IP地址的人数 -> 去重的人数

2.2 转化率

转化率：流程转化（PV/PV，UV/UV），人均行为次数（PV/UV）

• eg.$详情页的评论转化率=\frac{发表评论的PV}{详情页的PV}$
• eg.人均页面查看次数=$\frac{详情页PV}{详情页UV}$

详情页：

• 算法一： 访问的次数
• 算法二：将网站的内容/功能分成几个层级

2.3 时长

• web时代=页面打开时长
• APP时代=前台驻留时长
• 通过统计特殊事件，支持业务需求。统计视频被消费程度，评价内容质量；记录暂停/关闭页面后的进度。

2.4 弹出率

弹出率用户来了立即就走了，只访问了一个页面，通常是统计整个网站产生的所有会话的弹出率。

3 业务数据

3.1 GMV || 访问时长

GMV：电商平台中的商品交易总额，包括已付款的订单和未付款的订单。可以用于研究客户的购买意向，退单的比例，实际成交的比例等等

3.2 ARPU / ARPPU || 人均访问时长

• **ARPU(Average Revenue Per User)*平均每个用户贡献的收入
  • 也可以是活跃用户：$ARPU=\frac{总收入}{活跃用户数}$
• ARPPU(Average Revenue Per Paying User): 每个付费用户的平均收益

3.3 付费人数 || 访问人数

3.4 付费率、付费频次 || 留存率

描述总体上的用户付费意愿，评判一个产品或服务的健康程度

3.5 SKU视角 || 被消费内容视角

描述总体上的用户付费意愿，评判一个产品或服务的健康程度

• SKU视角：被消费对象产生了多少用户行为，多少消费金额

二、选好数据指标的通用方法论

Step1. 从业务的最终目的出发 梳理业务模块

Step2. 判断业务模块所属类型

Step3. 根据业务模块所属类型 选择数据指标

1.从业务的最终目的出发 梳理业务模块

1.1 案例

• 卖货
  • 通过社区创作的优美的图文来卖货
  • 目的 <- 手段 <- 支撑手段的工具 <- 支撑手段的手段
• 广告收益
  • 通过大量自媒体 创建文章信息 实现 广告收入
• 学费
  • 为了便捷的学习系统和高效学习课程以及良好的社群服务 -> 支付学费

2. 判断业务模块所属类型

工具模块、内容浏览模型、交易模块、社区模块

3. 根据业务模块所属类型 选择数据指标

• 工具模块: 效率

  	描述了什么	举例	做好了就能怎样
  使用量	累积量，投入程度	拍照、笔记	用户粘性强
  目标达成率	是否正常运转	支付、搜索	满意度高
  频次	是否能让用户养成习惯	闹钟	养成固定习惯

• 内容浏览：质 & 量

  	描述了什么	举例	做好了就能怎样
  浏览数	累积量	头条类	有多少人阅读
  浏览广度	覆盖内容库存情况	视频网站多个频道	库存利用效率更高
  浏览时长	占据用户多少时间	快手、抖音	减少竞品的使用时间
  内容互动	用户对内容的情感	AB站	用户粘性

• 交易模块： 转化率

  	描述了什么	举例	做好了就能怎样
  详细页转化率	核心场景转化效率	电商	更容易卖出
  金额	总得交易规模	电商、知识付费	卖的更多
  客单价	单个用户价值	奢侈品海淘	卖出更高价
  复购率	收入的持久度	订阅式购物	卖更多次

• 社区模块：活跃

  	描述了什么	举例	做好了就能怎样
  发布量	用户创作内容的数量	贴吧 FB	更多的话题源头
  互动量	用户与用户之间的互动的次数	微博	社区更有活力
  关系密度	用户与用户的关系	微信	更有可能长期留存

---

Chap2 数据工具

数据使用流程：数据采集 → 指标建模 → 观测数据 → 数据分析 → 业务洞察

• 数据工具能够解决什么问题？

  计数、流量、内容、用户、业务

一. 选择数据工具

1. 根据业务划分

   • 用户导向 (懂球帝)
   • 内容导向(百度 → 贴吧)
   • 流量导向

2. 根据公司发展的阶段划分

   • 探索期：验证需求是否存在，产品是否能够满足需求
     • 计数
   • 成长期：规模化，实现用户的大量增长
     • 流量导向、内容导向、用户导向、业务导向
   • 成熟期：用户规模到达天花板，用户红利消失
     • 用户导向、业务导向
   • 衰退期：需求消失→ 找到新的有缺口 延长生命周期
     • 用户导向

   

二、数据工具的分类

1. 计数的工具

• 业务场景：单纯的计数和固定报表

• 通过脚本和代码统计日志

• 通过BI工具进行基本的分析

• 简单 便捷

2. 流量导向的工具

• 解.决的问题：流量依赖性业务
• 优势：能将流量入口分析的较为细致
• 需要解决的问题：

1. 谁来了

   用户的喜好 用户的来源 桌面端移动端

2. 流量从哪里来的

   直接访问、自然搜索流量、引荐流量、社交流量

3. 来干什么的

   访问的页面、统计交互行为

4. 有没有达到目标

   用户转化

3. 内容导向的工具

• 常见的场景：以内容为核心资源的，如媒体、视频网站
• 解决的问题：哪些资源被消费，被消费的情况如何，内容表现质量如何

4. 用户导向的工具

• 常见的应用场景：在乎用户的长期价值，企业核心资产的用户

5. 业务导向的工具

• 解决的问题: 业务逻辑复杂，需要跟踪周期长
• 流程是否顺畅: 漏洞分析 / 路径分析：用户的行为轨迹
• 规模/频次如何
• 问题、异常原因在哪: 通过设备端/省份分类
• 优势: 从商业逻辑上还原整个业务流程，可以接入线上 - 线下

---

Chap3 数据分析基础

一、 对比分析

1. 比什么

• 绝对值： 销售金额 阅读数 → 不易得知问题的严重性
• 比例值：活跃占比 注册转化率 → 容易收到极端值的影响

2. 怎么比

• 环比(Last Period): 与当前时间范围相邻的上一个时间范围对比
  • eg周环比：第2周的数据 与第1周的数据对比
  • 对短期内具备连续性的数据进行分析
  • 需要根据相邻时间范围的数字对当前时间范围的指标进行设定
• 同比(Same Period Last Year/M/D)：与当前时间范围的上层时间范围前一范围中同样位置数据对比
  • eg. 年同比(今年 vs 去年今日 ) 周同比(今天 vs 上周同日)
  • 可以去除周末季节的影响
  • 观察更为长期的数据集
  • 观察时间周期内有较多的干扰，希望某种程度上消除这种干扰

3. 和谁比

• 和自己比
  • 从时间维度
  • 从不同业务线
  • 从过往经验估计：
    • 和时间额度比较联系
• 和行业比
  • 自身因素还是行业趋势

二、多维度拆解

案例：每日穿搭推荐

对APP启动事件的划分：

• 主动点入的少；推送进入的多
• 有编辑运营的城市，启动率较高
• 日活整体不变

运行原理：指标/业务流程需要按照多维度拆分、来观察变动

1. 适用的场景：

• 分析单一指标的构成：
  • 分栏目的播放量
  • 新老用户比例
• 针对流程进行拆解分析
  • 不同渠道的浏览、购买转化率
  • 不同省份的活动参与 - 漏斗
  • 打赏主播的等级、性别、频道
• 需要还原发生行为时的场景

业务场景1:数据涨跌异动如何处理

案例：对收入跌10%的应对

• 问题是否严重 → 同比 环比 → 跌的原因
• 是否是服务器的原因 → 如果是，应该是断崖下降然后回升 → 按照小时查看流量规律
• 是不是渠道的问题：存在某个渠道远低于平时的流量
• 是否缺货

总结：发现异常 → 确定问题 → 确定原因 → 针对性解决问题 → 执行

2.常见的假设：⚡️

1. 活动影响：查对应活动页面以及对应动作的数据波动，活动是否有数据属性
2. 版本发布：以版本号作为维度，区分查看
3. 渠道投放：查看渠道来源变化
4. 策略调整：策略上线时间节点，区分前后关键指标波动
5. 服务故障：明确故障时间，按时间以维度进行小时/分钟级别的拆分

三、漏斗分析

漏斗 = 一连串向后影响的用户行为

1. 适用场景

• 适用：有明确的业务流程和业务目标
• 不适用：没有明确的流程、跳转关系且纷繁复杂的业务

2. 建立漏斗时容易掉的坑：

• 漏斗一定是有时间窗口的
• 漏斗一定有严格的顺序
• 漏斗的计数单位可以基于用户、可以基于事件
  • 用户：关心整个业务流程的推动
  • 事件：关心某一步具体的转化率，但无法获知事件流转的真实情况
• 结果指标的数据不符合预期
  • 自查：是否只有这一个漏斗能够达到最终目标

业务场景2：如何评估渠道质量，确定投放优先级

1. 常见的渠道划分

• 来源：具体的流量实体
  • 百度 头条 线下
• 媒介：SEM(搜索引擎营销) 自然搜索的结果 Banner

2. 渠道质量跟踪

   1. 选择关键事件

      选取反映产品目标人群会做的行为数据

   2. 查看产生关键事件的用户

四、分布情况

一个事件不仅只有累计数量这么可以观测的指标，还可以从该事件在不同维度的分布来观察

• 常见的群体划分：事件频率 / 一天内的时间分布 / 消费金额的区间
• 适用场景
  • 已经知道一群用户完成了指定事件，但需要对用户群体进行细分，按不同的维度和价值将他们划为不同群体，分别进行后续的维护或分析。
  • 已经知道单个事件的完成次数，希望知道这些次数拆分到不同维度上后的分布情况，以便更清晰地了解该事件的完成情况。

五、用户留存

1. 运作原理

1. 大盘留存：将某一时间段的用户ID与另一个时间段的用户ID做交叉去重

2. 精准留存：

   • 过滤进行指定行为的用户ID，再计算

   • 将用户分为不同的群体后，观察其之间留存的区别 (游戏行业)

适用场景：验证产品长期价值，评估产品功能粘性

业务场景3：功能/内容上线后，如果评估其短期效果/长期价值/未来潜力

1. 上线后的目标与价值明确

   • 漏斗分析(转化关系明确)

   • 借助用户分分群对比(转化关系较为复杂)

案例：漫画对付费会员的转化结果的效果评估

验证上线某批漫画对付费会员的影响

2. 上线后关注其对产品价值的提升

   • 借助精准留存对比

3. 上线后以探索更长期的产品潜力

   • 借助分布情况分析

   • 对比其是否优化了使用频次 / 场景的分布

六、用户画像

对用户各类特征进行标识 → 给用户贴上各类标签 → 通过这些标签、将用户划分为不同的群体 → 以便对不同的群体分别进行产品/运营动作

• Profile(用户档案) VS (Persona)用户画像
  • Profile 基于用户填写的资料
  • Persona 比较抽象，偏向感性
• 适用场景：市场营销、个性化运行、业务分析、用户研究

1. 标签的分类

1. 基础属性

   年龄、性别、生日、教育、收入、职业

2. 社会关系

   婚姻、有无小孩、性取向

3. 行为特征

   基础行为：注册时间、来源渠道

   业务行为：买过特惠商品、获得过优秀学员

4. 业务相关

   eg：健身类：体脂率 胖瘦高矮 日均8k+ 在练腿

2. 标签的来源

1. 直接填写

   注册填写、分类选择

2. 通过用户已有特征推导

   什么时候需要：做活动、简单的个性化运营、业务分析、用户研究

   案例：北京地区的女生节，对象为大学生

   • 买过女性服装 → 女生 ；收货地址：北京 → 地址北京 ；买过奢侈品 → 消费能力强

   • 常用IP在北京→ 地址北京；使用手机型号为新款 → 消费能力强；收获地址为大学 → 大学生

3. 通过用户身边的人推断

   • 距离相近：某种属性，周围的人都具备，用户也大概率具备
   • 行为相似：通过协同过滤，找到行为相似的目标用户

业务场景4： 了解数据背后的画像

• 高质量拉新

  1. 从现有用户找到真正的用户

     真正的用户： 高留存，核心行为频次、完成率高

  2. 找到真正用户的特征

     是谁：年龄 受教育程度 地域 消费能力 → 用户画像

     从哪里来：用户推荐 → 渠道来源

  3. 按照特征，找到类似用户

     用户画像：高校、科研院所知识密集型工作区域 / 消费倾向性社科类书籍

     渠道来源：人拉人还是广撒网 → 精准受众

• 精准运营

• 辅助产品设计

用户画像 + 行为序列

七、归因查找

找出时间发生的主要原因，对业务中明确的业务目标归因即可

• 将目标拆解到各个模块，方便统计各模块的贡献 → 绩效分配
• 获悉当前指标达成的主要原因，获得如何提升业务指标的洞察

1. 常见的归因方法

末次归因: 转化路径短，且事件关联性强的场景

递减归因：转化路径很长，非目标事件差异不大，没有完全主导的

​ - 从最后一步开始，向前归因

首次归因：强流量依赖的业务场景，拉人比后续的事情都重要(比如小额借款)

2. 精准运营推送

不同人在同一个运营资源位上得到不同的信息

需要在千人一面和千人千面中找到ROI(投资回报率)的平衡

2.1 运营资源盘活

• 常规做法：出台一套运营资源的使用规则

  • 例如：同一个类型的营销一周不重复推送…
  • 问题：整个公式的内部营销资源存在上限

• 推荐做法：精细化的用户分群运营

  • 针对用户画像，对不同标签推送不同的内容
  • 在ROI上找到平衡点，先选择容易出成绩的
  • 千人十面往往解决了80%的问题，7~8个标签就足够

如何选择最初的7~8个标签？

• 人口统计学意义上的标签，如性别、年龄或者地域。

  • 〔电商〕性别影响商品偏好
  • 〔K12教育〕地域影响教育水平、教材的选择、

• 考察的侧重点业务相关的标签

  • [K12教育〕年级影响所学的内容、关注的信息。
  • 〔健身〕 BMI影响用户对功能和内容上的诉求

  简单结合上述两类标签，往往已经能划分出七八个的群体了

2.2 推送内容与用户有关

基于用户的真实动作，调整推送内容

• 向我说话：利用之前留下的信息，在推送文案中使用对应名称
• 由我触发：通过挖掘用户的行为序列,将推送与你的某个行为挂钩
• 和我有关：这次推送的活动，真正和我的需求有关

八、路径挖掘

九、行为序列

1. 行为序列

• 流入、流出

适用场景：有明确的结果目标

路径挖掘的局限：只能反映一群人的大体趋势

业务场景5：如何找到羊毛党？

• 用户ID → 省份 设备类型 运营商 → 越狱

发现数据异常：流量监控、员工审核、人工举报

明确目的：刷量 薅羊毛 Spam(垃圾邮件 兜售信息)

观察特征：机刷 人肉刷 → 按照规则爬取，并人工审核

一网打尽：

• 封(封禁、屏蔽、定向屏蔽)

• 提高关键成本

  前：注册7后才可发帖 → 中：减少bug商品的库存 → 提高审核的要求

Chap4 数据采集

一、埋点

本质：在某件事情发生以后，告诉服务器发生了什么

埋点的困境：一是需要什么数据、什么属性；二是需要与研发沟通(前端口or后端采集)

需求 > 指标 > 埋点

1. 数据需求文档(DRD):

• 作为与研发沟通的凭借，沟通事件触发的机制、定义 / 属性取值的来源 / 背后隐藏的逻辑
• 管理数据埋点的当前状态和迭代中留下的判断逻辑和附件信息

1.1埋点需求

归纳需求：

• 产品自身的指标建模：交易总金额 详细页转化率
• 业务部门的分析需求：用户付费的转换率

1.2埋点实施过程中的细节

事件触发的机制、定义 / 属性取值的来源 / 背后隐藏的逻辑

a.选择适当的：

• 依据经验，预先按分析维度设计属性

  • 依赖经验；频繁添加埋点，则需要研发密切配合

• 根据讨论，预先设计埋点属性

  • WWWHW(Who when where how what)

    • WHO：认设备(web: cookie；IOS；Android) 认用户(用户Id)

    • When：哪一个时间点

    • 事件发生 > 事件上报 > 事件接受 > 事件入库 →

    • Where: GPS IP地址 自主填写

    • How: 4g 用的什么设备 什么版本

    • What: 购买 搜索 注册 投诉 申请退货

  • 活用属性(公共属性和事件聚类)

b. 埋点位置的选择

除非某个行为只在前端发生，否则永远建议在后端埋点

• 前端埋点的弊端：

  某些属性前端没有，where what how 的许多信息，往往只存在后端

  改动依赖产品发版：App store需要审核、web发版有排期，响应速度不如后端

  时间上报时机尴尬：需要在省流量、省电、及时性之间取舍

c. 埋点属性的来源

• 前端：调用API，取页面上的值，行为统计
• 后端：业务数据、查关联表、前端送来的数据、技术数据

1.3 埋点的流程

明确需求 > 埋点事件的确认 > 埋点属性拆解 > 触发时机 > 属性来源 > 与后端研发交流 > 数据核验 > …> 新需求

二、其他类型的数据采集

1. 全埋点 / 无埋点

• 适用场景：
  • 分析需求简单(只需要统计PV 和 点击)
  • 开发限制较因素多(临时活动，没有时间、资源部署)
• 限制：非浏览和点击时间无法采集，无法采集到what / how类的信息

2.跨越物理界限采集信息

• 线下数据采集
  • 教育行业：课程到课率
  • 金融行业：地推收集的信息如何和线上的数据联合起来(唯一的身份标识)

3. 竞品数据采集

• 明确采集目的

• 难以通过埋点实现

55344606)]

• 前端埋点的弊端：

  某些属性前端没有，where what how 的许多信息，往往只存在后端

  改动依赖产品发版：App store需要审核、web发版有排期，响应速度不如后端

  时间上报时机尴尬：需要在省流量、省电、及时性之间取舍

c. 埋点属性的来源

• 前端：调用API，取页面上的值，行为统计
• 后端：业务数据、查关联表、前端送来的数据、技术数据

1.3 埋点的流程

明确需求 > 埋点事件的确认 > 埋点属性拆解 > 触发时机 > 属性来源 > 与后端研发交流 > 数据核验 > …> 新需求

[外链图片转存中…(img-jxlrVhnY-1666055344607)]

[外链图片转存中…(img-EfZ17dOZ-1666055344609)]

二、其他类型的数据采集

1. 全埋点 / 无埋点

• 适用场景：
  • 分析需求简单(只需要统计PV 和 点击)
  • 开发限制较因素多(临时活动，没有时间、资源部署)
• 限制：非浏览和点击时间无法采集，无法采集到what / how类的信息

2.跨越物理界限采集信息

• 线下数据采集
  • 教育行业：课程到课率
  • 金融行业：地推收集的信息如何和线上的数据联合起来(唯一的身份标识)

3. 竞品数据采集

• 明确采集目的

• 难以通过埋点实现