满足运营的需求
请听题：某短视频平台，游戏直播业务的日活用户1000万左右，但90%观看时间不足10分钟，运 营希望尽可能多的让用户观看10分钟以上，请分析下该干哪些事情
牢记灵魂三问（自己问自己哦）
问1：这是个啥层级问题？ A．战略级 B．战术级 C．战斗级
问2：这是个啥类型的问题 A．是多少 B．为什么 C．怎么做
问3：当前状态下要输出什么成果 A．给几个数 B．报表 C．专题报告 D．模型 E． ABtest
| 问题层次 | 说明 | 举例 |
|---|---|---|
| 战略层次 | 做了哪个方向 | 我们要抓DAU指标?观看人数?观看次数?这个指标目标多少，要提高多少? |
| 战术层 | 已经选择了方向，具体做什么事情 | 我们决定了要抓观看时长，尽量让用户观看10分钟以上。那么问题是:我要找更优质的用户呢﹖还是改进直播体验呢?还是找一些大牛主播呢? |
| 战斗层 | 已经决定做什么事，事情做的大小、多少 | 我们决定了签约主播，那么市面上有哪些主播可以签，签哪些游戏的主播?签来要播多少次，要不要搞个对抗赛让主播show一把，啥时候… |
这是个典型的战术级问题，第一题答案：B
| 问题层次 | 问题层次 | 问题描述 | 备注 |
|---|---|---|---|
| 直 | 是多少 | 今天直播观看10分钟以上的人数是多少 | 不只是一个数,搭建数据指标体系也算“是多少” |
| 接 | 是什么 | 今天观看10m+人数70万一一不满意啊! | “是什么”的关键是评价标准!找标准也是工作之一 |
| 解 | 为什么 | 为啥90%的人都看不到10分钟? | 找原因的方法很复杂，需要配合测试和长期观察 |
| 决 | 会怎样 | 如果我做了Xx工作,观看人数会增加吗? | 做预测的方法也多,很复杂,经常用到算法 |
| 又如何 | 上个抽奖，人数增加了，可其他指标降了呀! | 高大上的叫法叫:综合评价问题，常涉及复杂评估 | |
| 间 | 想不想 | 要不要去签约几个美女主播回来? | 转化为:列出支持想法的理由，用数据验证/否定 |
| 接 | 能不能 | 让美女主播露白花花的大腿，会被查封不? | 转化为:〈黑箱〉数据测试（白箱〉收集过往结果 |
| 解 | 会不会 | 我到底该怎么做,才能合理合法的让 | 转化为:从问题出发找原因/从手段出发找可行性 |
| 决 | 该不该 | 我还是决定签美女.该不该现在做 | 转化为:（事后）评估效果（事前）验证逻辑 |
第二题选C。这个问题是个典型的“怎么做”问题。注意，这个问题连方向都没有，因此落到执行层 面，要先解决“做哪些”的大类 问题
数据分析的产出物有很多，每一类产出有特定用途（如下图），结合本次目标，最好先输出一个专 题报告
| 适用层次 | 适用场合 | 投入成本 | 产生效果 | |
|---|---|---|---|---|
| 临时取数 | 战斗层 | “这个数据老板要,下班以前得给到，干不完就别睡觉” | 看似投入少，需求一多，非常耗力 | 几乎没有效果,从来不会有人念你的好 |
| 报表 | 战略层、战斗层 | 跟踪固定指标，发现问题 | 建指标体系耗时，后续维护简单 | 长期内大家都会看，但总觉得看不出啥 |
| 专题分析 | 战略层、战术层 | 针对专项问题，寻找办法 | 无论啥时候都费时费力 | 短期印象深刻，过两天就忘记可 |
| 数据模型 | 战术层、战斗层 | 适合模型解决的特定问题(然而经常被当起死回生丸） | 非常吃数据质量,想实现效果需要营销渠道配合 | 如果没做好，就不是露脸,而是露屁股了 |
| Abtest | 战斗层 | 有具体业务方案情况下做测试 | 需要大量前期准备,有可能需要准备很多个版本,开发压力大 | 短期非常明显,干多了非常累,大事小事都想测 |
| 数据产品 | 战略层、战术层 | 有经费/人力/时间的话尽量都做成产品，直观，好用 | 非常多经费/人力/时间投入 | 短期非常明显，长期内 要培养用户习惯 |
互联网企业常用指标科普
SOP，是 Standard Operating Procedure标准作业程序
PV （Page View），通常又叫浏览量
UV（Unique Visitor），独立访问用户
VV（Video View），也就是用户观看视频的数量
每日活跃用户数DAU（Daily Active Users）、每月活跃用户数MAU（Monthly Active Users）
平均每用户贡献的收入 ARPU（Average Revenue Per User）
这个分母包括了所有用户，有时候也只统计活跃用户。分母也可以只是产生了付费的用户，也即ARPPU（Average Revenue Per Paying User)——平均每付费用户贡献的收入
GMV是Gross Merchandise Volume的缩写，指的是一段时间内（通常是一年或一个季度）电商平台或在线市场销售的货物总价值，不包括退款、折扣和运费等因素
toB和toC业务，数据分析有何异同
首先，toB和toC业务是完全不同两大场景。toC业务面对的是个人的衣食住行的需求，离我们的生活很近。经常我们把自己当做消费者思考一下，就能理解toC业务是做什么的。而toB业务则是服务企业生产经营
toB类业务数据记录往往很少。toB类本质上就是“谈生意”。谈生意，就需要大量的线下沟通，越大的客户，要求越多，越不能指望客户在一个APP里戳两下就把几千万上亿的钱掏出腰包。而很多toB企业的数字化程度很低，沟通过程基本都靠销售自己完成，导致过程数据严重缺失。数据缺失，自然导致数据分析师很难分析出啥东西了
在toC业务里，线上业务和线下业务是两大有差异场景。
线上业务：APP、H5、小程序
线下业务：店铺、业务员、电话推销、短信
线上业务与线下业务的最大区别在于数据量。线下业务数据量很少，很多时候，连基础的RFM分析都做不了（因为没有用户ID），相当多的线下业务，是基于订单、工单、采购单等单据进行分析的，这一点让习惯了线上数据的同学们非常难受。不过线下业务的分析，都有其成熟、固定的逻辑和套路，是可以通过学习掌握的。
在一个企业内，根据工作流程不同，分析的场景有明显差异，简单的可以分成：
1、前台：直接面向用户的，产生收入，获取客户的（销售、推广、增长）
2、中台：对前台起辅助作用，增加收入，减少损失的（品牌、营销、运营、风控）
3、后台：支持前台、中台工作，交付产品/服务的（研发、生产、设计、供应、客服）
前台的分析大多可以用：人、货、场的逻辑来描述。因为直接产生收入，所以相对容易通过拆解构成收入的指标，来区分出影响收入的因素，进而找出问题来源。
中台的分析就复杂一些。因为是叠加在销售之上增加收入，减少损失。所以各种因素相互交织，较难分析清楚。
比如：
- 剔出“自然增长率”“季节变化”，才能看到真实效果
- 间接手段（比如广告、社群、内容）产生效果的逻辑梳理
- 间接手段（比如广告、社群、内容）产生效果的逻辑梳理
这使得中台的数据分析，分析逻辑都很复杂，并且需要多角度，多批次的测试和对比，才能见效
后台的分析则更纠结。
一方面，后台的采购、供应、生产，受生产线、交通等客观条件限制，短时间内有能力上限；
另一方面，后台的供应量又受到前端影响，需求预测不准，需求反复变动，都让后台乱成一锅粥，分析也不会准。
所以，虽然后台也有类似EOQ模型（ 经济订货批量 economic order quantity (EOQ)）、分配与网络模型这些科学算法，但是还是得结合前台的一起看，该拍脑袋还得拍。
当然，如果和toC/toB、线上/线下结合，能产生的场景就更多了。比如都是在线上卖商品，平台电商（入驻天猫、抖音、拼多多等平台）自营电商（自建APP并推广）就是完全不同两个场景。数据来源，运营方式，分析思路都不同。
