数据运营
2024-07-24 14:42:53 0 举报AI智能生成
登录查看完整内容
数据运营是一种通过分析和管理数据以优化业务决策、提高效率和推动创新的方法。它涉及到数据采集、清洗、分析和可视化等多个环节。数据运营能够帮助企业更好地了解客户需求，发现市场趋势，优化业务流程，提高产品竞争力。在数据驱动的时代，数据运营已经成为企业核心竞争力的重要来源。
作者其他创作
大纲/内容
对业务有价值
可统计
数据指标：对当前业务有参考价值的统计数据
自然日
跨时区（如全球服务）则关心最近24h
DAU：日活跃用户
MAU≠当月各日DAU之和
务必去重，才有观察意义
MAU：月活跃用户
存量
统计简单，离激活环节最远，转化率太差
适用于量级不大/免费渠道，不需要做精细结算
1.点击渠道页面链接
反应用户的实际意愿
数据源可信度存疑，无法避免刷量
适用于渠道依赖应用商店且没有更好的渠道
2.进入应用商店下载
离「激活」最近，便于统计
渠道不一定配合，仍然无法避免刷量
适用于自己较强势，可给渠道制定统计规则
3.安装/启动app进入应用首页
最真实的数据
渠道费用激增，统计复杂
适用对用户质量要求很高且产品ARPU高
4.激活（完成注册）
选择合适的节点，定义【增】
基于设备
基于账号关联，和后台已有账号比对匹配
如何定义【新】
新增用户
增量
算法一：第七天活跃用户/第一天新增用户*100%
新增当天为第0天
分子分母星期相同，某种程度能抵消星期级别的波动
算法二：第七天活跃用户/第0天活跃用户*100%
计算方法
了解某渠道质量，以天为单位，衡量渠道用户当下&接下来的表现
以【X日日留存】作为比较标准时，可以避免其他日数据干扰
7日日留存率
计算方法：第二天—第七天去重后活跃用户/第一天新增用户*100%
用户访问特别集中，只看Day7不能反应真实情况（如用户集中在周六周天使用），此时需关注7日内留存
7日内留存率
以周/月为单位，衡量产品第健康情况，观察用户在平台上的粘性
算法：指定周（月）活跃用户数/第1周（月）活跃用户数*100%
计算时务必去重！
周/月留存率
留存
健康程度
直接访问
引荐流量
搜索引擎自然流量
搜索引擎付费流量
社交媒体等
渠道来源
从哪儿来
用户数据（谁）
Page Views 页面访问量（次数，不去重）
PV
Unique Visitors 独立访问数（人数，去重）
UV
算法一：用户对某些关键行为的访问次数
算法二：将网站内容/功能分成几个层级，以用户本次访问过最深的一级计算
访问深度
次数/频率
关注功能：PV/PV
关注业务：UV/UV
PV/UV不是转化率，是（关键功能/动作的）人均触发次数
转化率
路径走通程度
e.g统计视频被消费程度，评价内容质量，可以记录暂停/关闭页面后，播放器中视频进度条当前的位置
通过统计特殊事件，支持业务需求
具体的访问时长统计难度高，且不具有真实意义（不确定用户是否真实访问）
访问时长
做了多久
用户来了只访问一个页面，没有任何行为立马就走了
弹出率
质量
行为数据（干了什么）
GMV：描述交易的金额总规模
总量
ARPU：人均付费，平台总收入/总用户数
ARPPU：付费用户人均付费，平台总收入/平台付费用户数
ARPU/ARPPU
人均访问时长
人均
付费人数
观看人数
人数
付费率/付费频次
观看率等
SKU/被消费内容视角
被消费对象
业务数据（结果怎样）
常见数据指标
常见数据指标定义
1. 指标的选取必须和商业发展的核心目标契合，且不同时期关注的指标不一样
2. 关注的指标必须反应用户的核心价值
3. 数据必须能够汇总
数据指标选择原则
通过最终目的反推梳理业务模块
如何搞大/搞频繁（手段）
有什么困难，通过什么特色方式解决（工具）
确定最终目的
1.拆解业务模块
省时间
产品对用户的价值来自产品本身
工具模块
杀时间
内容浏览模块
产品对用户的价值来自「连接」其他资源
交易模块
社区模块
2.判断模块类型
使用量
目标达成率
频次
浏览数
浏览广度
浏览时长
内容互动
详情页转化率
金额/GMV
客单价
复购率
发布量
互动量
关系密度
3.根据模块类型，选取数据指标
数据指标选取步骤
数据指标建模
计数
流量
内容
用户
业务
数据工具解决问题
核心问题：公司缺了什么，最要命？
如规模化电商，更倾向流量快速变现，选择流量导向工具
奢侈品电商，更倾向用户维系，选择用户导向数据工具
根据核心业务选择合适的数据分析工具
1.根据业务核心划分
业务问题：刚起步不完善，流程未定型，常变动
待解决需求：验证业务是否可行，需求是否存在
数据工具：计数导向
探索期
业务问题：追求增长
待解决问题：寻找用户量和业务量规模化增长的方法
数据工具：流量导向、内容导向、用户导向、业务导向
成长期
业务问题：稳定，没有新的突破点
待解决问题：业务流程理的更顺、用户群体拆的更细
数据工具：用户导向、业务导向
成熟期
业务问题：用户对产品渐渐失去兴趣，开始流失
待解决问题：延长产品生命周期，尽力挖掘用户剩余价值及可能的新需求
数据工具：用户导向
衰退期
2.根据公司阶段划分
如何选择合适的数据工具
如何选择合适的数据分析工具
通过脚本与代码统计日志
通过BI工具进行基本的分析
计数统计：快速验证
谁来了
从哪里来
来了干什么
有没有达成目标
解决问题
解决问题：流量依赖性业务，如电商，或一锤子买卖
优势：能将流量入口分析的较为细致
流量导向工具
流量导向：渠道依赖
哪些资源被消费
被消费的情况如何
内容表现质量如何
解决问题：以内容为核心资源的，如媒体、视频网站
优势：能从内容的角度描述其表现
内容导向工具
内容导向：质量第一
来了干什么：用户行为路径
还会不会再来：留存分析
在哪流失：漏斗分析
用户都是什么样的：用户画像
解决问题：需关注隐藏在报表、总量下面的用户具体的行为
优势：从用户视角描述单个用户的行为轨迹
用户导向工具
用户导向：用户为王
业务流程是否顺畅
规模/频次如何？
异常原因在哪
解决问题：业务逻辑复杂，需要跟踪周期长
优势：从商业逻辑上去还原整个业务流程，可接入线上-线下
业务导向工具
业务导向：商业本质
常见数据分析“套路”
数据分析工具
插入空白列—选中—数据下的「分列」—分隔符号
分列脏数据处理：因空格导致的分列使用「查找」—「替换」，将空格替换
数据分列
筛选
去重
排序
数据清洗
函数语法结构：VLOOKUP（查找的值，查找范围，找查找范围中的第几列，精准匹配还是模糊匹配）
数据查询：「VLOOKUP」函数（计算用户留存）
条件判断：IF函数
SUMIF语法结构：SUMIF（条件范围，条件，求和范围）
条件求和：SUMIF（单条件）、SUMIFS（多条件）函数
COUNTIF语法结构：COUNTIF(条件范围，条件)
COUNTIFS语法结构：COUNTIFS（条件范围1，条件1，条件范围2，条件2……条件范围N，条件N）
条件计数：COUNTIF（单条件）、COUNTIFS（多条件）函数
函数语法结构：LOOKUP（查找的值，查找的条件，返回值的范围）
逆向查询：LOOKUP函数
函数语法结构：TEXT（MID（数据范围，第几位数开始，符号长度，字符格式））
提取出生年月（身份证）：TEXT+MID函数
计算年龄（身份证）：DATEDIF函数
数据二次处理
数据透视表
折线图：适合连续性时间纬度对比
柱状图：单类别对比
柱状堆积图（比例）：有两种纬度对比，其中一种纬度还需按照不同比例进行观察
饼图：不关心绝对数量，关心单类别在总量中的占比
二维面积图：连续时间段内，各类别产品对销售总量的贡献占比和趋势
Excel
Circle Packing：分类分析
超链接
Beeswarm Plot（蜂群图）：http://rawgraphs.io/learning/how-to-make-a-beeswarm-plot/
产品链接：https://rawgraphs.io
其他图表使用介绍：https://rawgraphs.io/learning/
RAWGraphs
产品介绍—「Map Lab（数据可视化）」
点类型
热力图
提升：1.多体验和分析相似甚至不同类型的产品，接触不同类型的用户，尤其是小众奇葩用户
产品链接：https://lbs.amap.com
高德地图开放平台
数据可视化
数据处理
销售额
阅读数
绝对值：本身具备【价值】的数字
活跃占比
注册转化率
比例值：在具体环境中看比利才具备对比价值
比什么
对短期内具备连续性的数据进行分析
需要根据相邻时间范围的数字对当前时间范围的指标进行设定
环比：与当前时间范围相邻的上一个时间范围对比
观察更为长期的数据集
观察的时间周期里有较多干扰，希望某种程度上消除这些干扰
同比：与当前时间范围上层时间范围的前一范围中同样位置数据对比
怎么比
从时间纬度
从不同业务线
从过往经验估计
和自己比
是自身因素还是行业趋势
都跌，能否比同行跌的少
同涨，是否比同行涨的慢
和行业比
和谁比
对比分析
运作原理：指标/业务流程需要按照多维度拆分，来观察变动
分栏目播放量
新老用户比例
分析单一指标的构成
不同渠道的浏览、购买转化率
不同省份的活动参与漏斗
针对流程进行拆解分析
打赏主播的等级、性别、频道
是否在Wi-Fi或4g环境下
还原行为发生时的场景
适用场景
多维度拆解
漏斗：一连串向后影响的用户行为
按天：对用户心智对影响只在短期内有效（如短期活动）
按周：业务本身复杂/决策成本高/多日才能完成（如理财/美股开户）
按月：决策周期更长（如装修买房）
1.漏斗一定是有时间窗口的
不能用「ABCDE」的漏斗，看「ACE」的数据
2.漏斗一定是有严格顺序的
基于【用户】：关心整个业务流程的推动
基于【事件】：关心某一步具体的转化率
3.漏斗的计数单位可以基于【用户】、也可以基于【事件】
自查：是否只有这一个漏斗能够到达最终目标？
4.结果指标的数据不符合预期
漏斗建立容易掉的坑
运作原理：通过一连串向后影响的用户行为来观察目标
适用：有明确的业务流程和业务目标
不适用：没有明确的流程、跳转关系纷繁复杂的业务
漏斗分析
运作原理：从事件在不同纬度中的分布来观察，以便理解该事件除了累计数量和频次外，更多纬度的信息
事件频率
一天内的时间分布
消费金额的区间
常见划分
已经知道一群用户完成了指定事件，但需要对用户群体进行细分，按不同纬度和价值将他们划分不同群体，分别进行后续的维护或分析
已经知道单个事件的完成次数，希望知道这些次数拆分到不同纬度上后的分布情况，以便清晰的了解该事件的完成情况
分布分析
过滤进行过指定行为的用户ID，再计算
将用户分为不同的群体后，观察其之间留存的区别
精准留存
评估产品功能粘性
将某时间段与另一时间段的用户ID交叉去重计算
大盘留存
验证产品长期价值（月留存）
用户留存
运作原理：通过对用户各类特征进行标识，给用户贴上各类标签，通过这些标签将用户分为不同的群体，以便对不同群体分别进行产品/运营动作
基础属性：年龄、性别、生日、星座、教育、收入、职业等
社会关系：婚姻、有无孩子、有无老人、性取向等
行为特征：注册行为、来源渠道、买过特惠商品、曾获优秀学员等
业务相关：胖瘦高矮、体脂率、在练胸、收藏100份健身计划等
常见特征
直接填写
通过用户自己的已有特征推得
通过用户身边的人推断
标签来源
1.找到现有用户中表现最好的一批用户
2.提炼这批用户特征
3.照此特征，找到类似用户
高质量拉新
市场营销
个性化运营
业务分析
用户研究
精准运营推送
辅助产品设计
用户画像
运作原理：将事件拆解，并根据业务性质，确定影响事件完成的关键部分
首次归因：强流量依赖的业务场景，拉人比后续所有事情都重要
递减归因：转化路径长，非目标事件差异不大，没有完全主导的事件
末次归因：转化路径短，且事件间关联性强的场景
将目标的达成拆分到各个模块，方便统计各模块的贡献
获悉当前指标达成的主要因素，获得如何提升业务指标的洞见
归因查找
运作原理：逐级展开某一事件的前一级（后一级）事件，观察其流向
有明确的起始场景，希望观察这个场景它之后发生了什么
有明确的结果目标，希望观察来的用户是如何到达的
路径分析
运作原理：将单一用户的所有行为以时间线的形式进行排列
观察掩盖在统计信息下更细致的信息，还原用户具体的使用场景
通过观察具体的行为特征，找到提升产品价值的机会点
行为序列分析
发现异常
同比、环比确定是否存在问题
确定问题
活动影响：查对应活动页面及对应动作的数据波动，关注活动是否有地域属性
版本发布：将版本号作为纬度，区分查看
渠道投放：查看渠道来源变化
策略调整：策略上线时间节点，区分前后关键指标波动
服务故障：明确故障时间，按时间为纬度进行小时或者分钟级别的拆分
常见假设
数据是验证假设的支撑工具
确定原因
针对性解决问题
执行
数据涨跌异常处理
借助漏斗分析对比（转化关系明确时）
借助用户分群对比（转化关系较为复杂时）
上线后的目标与价值清晰明确
借助精准留存对比
上线后关注其对产品价值的提升
借助分布情况分析，对比其是否优化了使用频次/场景的分布
上线以探索更长期的产品潜力
功能/内容上线后，如何评估短期/长期价值
异常高且无理由的流量
工作人员观察
人工举报
发现数据异常
找到【1】
刷量
薅羊毛
apam垃圾广告
明确其目的
机刷
人肉刷
观察其特征
找到模式
RD爬取并人工审核
找到【N】
封禁/封禁权限
前：注册7日后方可发帖
中：减少存在bug的商品的库存
后：提高提现的审核力度/周期
提高关键成本
根据roi决定是否需要进行处理
不做处理
一网打尽
查出羊毛党
常见业务处理
数据分析方法
认设备
认人：UID、微信等第三方Union ID等
Who
哪个节点的时间
上报时间时，带时区
使用Unix时间戳
哪个时区的时间
When
需要通过API取得详细地址信息（国家/省/市/街道）
GPS
统一分配给运营商，相对较粗略，可通过三方反查所属地
IP
相比用户真实位置，更关心用户希望在哪儿，如装修买房
自主填写
Where
用的什么设备
装的哪个版本
操作系统是什么
用的哪个浏览器
用4G还是WI-FI
从哪个页面跳过来
……
How
商品名称、类型、购买数量、购买金额、付款方式等
购买
搜索关键词、搜索类型等
搜索
注册渠道、注册邀请码等
用户注册
投诉内容、投诉对象、投诉渠道、投诉方式等
用户投诉
退货金额、退货原因、退货方式等
申请退款
What
明确数据埋点
调用API
取页面上的值
行为统计（如前台timer，自行触发&记录页面时长）
属性来源
某些属性前端没有：where/what/how 的许多信息，往往只存在后端
App Store需审核、web发版也需排期，响应速度不如后期
改动依赖产品发版
需要在省流量/省电和及时性之间取舍
事件上报时机略尴尬
弊端
前端
业务数据
查关联表
前端送来的数据
技术数据（如单次事件响应时间）
后端
埋点位置
形成数据需求文档（DRD）
数据采集
数据运营分析
0 条评论
回复 删除
下一页
