惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Y
Y Combinator Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
罗磊的独立博客
博客园_首页
量子位
雷峰网
雷峰网
GbyAI
GbyAI
小众软件
小众软件
酷 壳 – CoolShell
酷 壳 – CoolShell
D
DataBreaches.Net
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The Cloudflare Blog
IT之家
IT之家
WordPress大学
WordPress大学
人人都是产品经理
人人都是产品经理
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品经理要懂的数据分析——指标建模(上)
Darcy ZHAO · 2022-06-23 · via 人人都是产品经理

编辑导语:在产品经理的工作中,要结合具体业务、数据分析、数据工程这三个方面来进行数据分析,而其中所涉及的步骤工具又可以分为6个模块。本文作者对其中的一个模块——指标建模进行分析阐述,一起来看一下吧。

产品经理所要进行的数据分析要结合3个方面来进行——具体业务、数据分析、数据工程,而整个数据分析所涉及的步骤工具等又可以分为6个模块——指标建模、数据工具、数据处理、数据分析基础、数据分析进阶、数据采集。今天我们来讲一下指标建模模块。

一、指标建模概述

笔者先提出几个问题作为本文的引子——什么是数据指标?常用的数据指标有哪些?它们是怎么定义的?日常工作中查看这些指标会碰到哪些坑?如何选择数据指标?选择数据指标会遇到哪些坑呢?

选好数据指标的常用方法论:

如果老板问到:“刚上线的社区产品,最近表现如何?”

新人产品:“很不错——日活每天都在涨,新增也很多。”

资深产品:“现状堪忧——日活按设备数看一直在涨,但如果按注册用户数看并不乐观。新增用户转化成注册用户的只有20%,说明我们社区现在还没有促使用户注册的动机。”

三个月后,老板想知道是否要开始推广?

新人产品:“最近日活平稳,新增用户减少,要不要推广拿不准。”——表现平平

资深产品:“最近日活虽然上涨趋势不大,但:1. 用户人均发帖量相比刚上线时翻了一番,2. 用户间的好友密度月环比上涨30%,我觉得社区氛围已经形成,3. 这个从新用户次日留存由上个月的35%增长到50%也能得到验证。因此,认为可以开始大规模推广。”——十分靠谱

二、认识常见的数据指标

什么是数据指标?即对当前业务有参考价值的统计数据。进一步说明,当前业务+有价值——不是所有的数据都叫指标,与当前业务无关的,也意义不大;可统计——数据不是凭空产生的,不能脱离现实。

举一个直白的小例子,老板为了提高自己小卖部的营业额搞了促销活动,为了衡量促销效果,他首先记录了一天中小卖部门口的路过人数为3,进店人数为2,购买人数为1,这些即是统计数据(可被观测、统计、记录);随后计算出进店率为67%,购买率为50%,这就是对业务有参考价值的数据(衡量活动是否有效)。

常见的数据指标有哪些?即如何量化“谁干了什么,结果怎样”这句话,谁——用户数据,干了什么——行为数据,结果怎样——业务数据。

1. DAU/MAU

DAU/MAU=Daily/Monthly Active User

1)理解Daily/Monthly

2)理解Active

方法一:数据统计系统的定义

基于事件上报判定活跃:有事件上报->该用户活跃。

tips:上报可能有坑——假定了事件上报一定来自用户主动操作;谨防活跃暴增,其他数据并无显著增加的情况。

预制报表的统计系统(友盟、百度统计、GA、……)都是基于事件上报进行统计,其统计逻辑是:今天上报过事件(->用户进行了主动操作)->这个用户是活跃的。

然而有时上报并不说明用户的真实行为,如手机收到PUSH后上报事件,这属于后台回报消息,并非用户行为。

这个坑的终极来源可能是运营一周前向RD提出需求:“我要统计发下去的PUSH,的指导有多少条PUSH是到达了用户设备上的,不然无法优化推送转化。”RD采用如下解决方案:“我在后台给你写一个Service,APP收到PUSH的时候,我就给友盟上报一个事件说我收到了。”

方法二:业务上的定义

基于关键事件上报:用户执行了关键事件->该用户活跃。

tips:存在维护成本——需不断维护日活事件列表;存在沟通成本——团队内外对[活跃]的认知需统一。

这需要制作日活事件列表,定义哪些事件需要上报。比如:

3)理解User

认人:每位注册用户一个唯一ID,但未登录的用户会被漏掉。

具体操作:给每位用户一个唯一的专属ID,只适合强注册/登录环境,用户数=访问过服务的ID数。

认设备:每台设备一串唯一标识符,但无法对对应设备背后的用户。

具体操作:在网页cookie中买下一段长随机字符串,作为设备唯一标识符,用户数=访问过服务的设备数。

关于到底是认人还是认设备,笔者总结方法如下:

2. 如何定义新增

每个人都在提[新增],每个人嘴里面讲的新增其实都不一样。

  • 渠道商:“只要点了你们产品的下载按钮,就算一次新增了”
  • 运营:“总得下载成功了才算吧,而且一个用户一天最多算一次”
  • 产品:“我们按启动算吧。没打开APP也算,数据质量太差了”
  • RD:“注册了才叫新增[用户],否则后台根本没这条数据”

所以需要根据具体业务统一[新增的定义]。

1)增——选择合适地节点,定义[增]

因为渠道商往往强势,所以在哪个节点结算应该谈清楚。

2)新——用适当的方法,判别[新]

  • 基于设备:IOS、Android、web各有门道
  • 基于账号关联:与后台已有账号比对匹配

3. 如何理解留存

为什么要看留存,这个表格可以简明概括留存的作用。

举例:以7日日留存的三种算法为例来评估某渠道的质量。

算法一:(第七天/第一天)x100%——7日日留存,只关心到特定日的留存情况,避免了其他日数据的干扰。比如比较渠道在Day7的留存情况时,引入Day2~Day7的用户数据,反而影响判断。

算法二:(第二天~第七天去重后/第一天)x100%——7日内留存,引入了其他日数据,适用于有固定使用周期,且周期较长的业务。有些时候恰恰需要引入Day2~Day7的数据,比如,有些情况下用户访问特别集中(如kfc疯狂星期四,大量肯德基APP访问集中在星期三、四),只看Day7来评价,往往不能反映真实情况。此时,关注7日内活跃情况,更能描述渠道质量。

算法三: ( 第七天/第0天)x100%——7日日留存,新增当日为第0日,下一日为1日,使第7日与新增当日对齐,某种程度上能抵消某些星期级别的周期性差异。

同理,当不再以日为统计单位,而是以更长时间周期来统计时,就得到了周留存/月留存,此时可以更好观察整个大盘。注意,在计算时务必将用户去重,公式如下:

无论使用哪一种算法,公司内部结合业务特性达成彼此认同时最重要的。

4. 渠道来源怎么看?

关于“用户从哪儿来的?”这个问题,我们通常可以看渠道来源这一指标解决。在实际工作中,产品经理会通过公司合作的数据机构给出的各类报表查看。在这里笔者简单总结几种主要渠道。

不同的网站统计工具与分析工具对网站流量获取的渠道各有差异,但基本上可分为几个渠道:

  • 直接访问(Direct)
  • 引荐流量(Referral)
  • 搜索引擎自然流量(Organic Search)
  • 付费搜索流量(Paid Search)
  • 社交媒体(Social)

直接访问(Direct):指的是用户直接访问网站,而不是从其他网站或搜索引擎进入。包括但不限于:用户在地址栏输入网址访问网站、从浏览器收藏夹访问、用户点击聊天工具里的链接如QQ聊天记录里的链接。

引荐流量(Referral):从用户非搜索引擎与社交网站点击进入网站。比如友链互惠网站、百度贴吧等站外社区论坛。

搜索引擎自然流量(Organic Search):从搜索引擎自然搜索结果链接进入网站的流量。区别于Paid Search,自然流量时搜索引擎自然排名结果的链接,通俗讲就是非竞价非付费的搜索引擎排名页面链接。另外值得一提的是,某些有中国特色的搜索引擎如百度,出了提供搜索引擎服务外,也提供很多的内容产品服务比如百度贴吧、百度知道等,从这些非搜索引擎搜索页面进入的流量并不归属于自然流量,而是引荐。

付费搜索(Paid Search):即搜索引擎竞价,很多没有搜索引擎优化资源的网站,短平快的流量获取方式。在国内,竞价流量已经成为众多网站流量获取的主要渠道。

社交媒体(Social):社交网站流量在绝大多数国产网站统计工具中并没有单独列出来。但是,全球最大的搜索引擎谷歌搜索的排名因素中,社交媒体因素已经占有超过10%的权重,所以也要引起重视。

还有在国内互联网圈不太提的几类:Email、展示广告、其他广告。另外,许多数据工具如果统计不到用户的渠道来源,会默认其为直接访问(Direct)。

5. PV UV 转化率 访问深度

PV(Page Views),即次数;UV(Unique Visitors),即人数。然而在衡量完成目标行为的潜力时,通常会用PV/PV表示该页面引发下一行为的能力;UV/UV表示用户的行为倾向;PV/UV表示人均行为次数。

1)PV/PV;UV/UV

2)PV/UV

3)访问深度

算法一:用户对某些关键行为的访问次数。

算法二:将网站内容/功能分成几个层级,以用户本次访问过最深的一级计算。

6. 访问时常

1)为何要统计访问时长

通过统计特殊事件,支持业务需求。比如,记录暂停/关闭页面后、播放器中视频进度条当前的位置,可以统计视频被消费程度,评价内容质量。

2)如何统计访问时长

  • Web时代,直接统计页面打开时长(但如果我一直没关,或是上了个洗手间……)
  • APP时代,统计前台驻留时常(如果我开着APP中途被叫去聊天……)
  • 通过瞳孔与注意识别,即摄像头观察,瞳孔是否注视屏幕(需要外设和隐私授权……)

总之,采用何种方式统计访问时长一定要回归业务本身。

7. 业务相关的数据指标

举例:小卖部老板想知道,一共卖了多少钱?消费水平怎么样?来了多少人?有多少人买东西了?有多少人是老顾客?我们的商品好不好卖?……这些涉及总量、人均、付费数、付费率,通常要看业务数据指标。

8 弹出率(Bounce Rate)

通俗理解即,用户一点开某个页面就马上退出,不进行任何下一步操作的比率。一般统计的是整个网站产生的所有会话的弹出率。

本文由 @DarcyAI 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。