仅有 25.3% 的移动应用用户在第一天返回, 平均留存率下降到 5.7% 到第 30 天 根据 Business of Apps 提供的移动应用留存率benchmark, 全球 31 个应用类别中 。这种曲线并不能告诉你问题出在哪里，是否是用户获取不佳、引导流程混乱还是产品价值不强。应用团队分析可以告诉你。 平均值会将通过不同推广活动、国家、设备、应用版本和营销模式到达的用户合并起来。应用团队分析仪表板会将这些组分开，通过相同的生命周期跟踪每个组，并为产品、营销和工程团队提供一个有根据的理由来决定修复什么。
目录
为什么应用团队分析会揭示聚合指标所掩盖的内容
- 团队分析的诊断价值
- 各类用户群组及其使用场景
- 驱动用户群组决策的核心指标
- 使用 SQL 和分析工具计算用户群组
- 常见陷阱和团队如何误读用户群组数据
- 将用户群组洞察力与发布和更新策略联系起来
- 超越安装保留率和事件和收入用户群组
为什么应用程序团队分析揭示了聚合指标无法揭示的内容
一个整体的保留率数字对于健康检查是有用的，但它是一个糟糕的诊断工具。如果付费社交媒体、有机搜索、推荐和合作伙伴活动都汇入一个混合仪表板，结果描述的是用户的混合而不是产品本身。同样的问题出现在iOS和Android用户、新用户和重复用户、不同的引导体验共享一个曲线时。
应用程序团队分析 上面的benchmark显示为什么第一个月值得关注。同样的 应用程序团队分析 报告iOS平均值为25.65%在第1天和4.13%在第30天 ，而Android平均值为23.01%在第1天和2.59%在第30天 。分类性能也会有很大的差异，2026benchmark范围从11.3%在第30天的新闻到2.1%在教育中的第30天
一行的诊断价值
安装团队根据用户首次打开应用的时间将用户分组，然后在一致的年龄如第1天、第7天和第30天测量回归行为。 读取一行中的内容可以了解一个小组如何成长。 读取一列中的内容可以比较不同小组在同一阶段的表现。
这种区别会将问题从“留存率低”改为：
- 获取质量： 是否有一个营销活动吸引了那些从未打算使用产品的用户？
- 安装流程中的阻力： 是否用户安装但无法完成第一个有意义的步骤？
- 价值传递： 是否激活用户在初始体验后仍然消失？
- 发布影响： 是否新版本改变了接受它的用户曲线？
A团队可能会看到整体保留率平稳，而最近的周度小组却在改善，较旧的小组自然会老化。没有小组边界，改善的效果会被平均掉。反之，一个强大的总体数字可能会掩盖一个恶化的付费渠道，如果有足够的自然流量可以抵消它。
实用规则： 绝不仅凭总体仪表盘就批准与保留率相关的产品变更。首先将结果分解为获取来源、国家、平台、引导路径和应用版本。
这个 应用用户保留框架 在将诊断转化为更广泛的生命周期视图时有用。操作点很简单：小组分析告诉你曲线在哪里断裂，而分段分析则帮助确定哪个可控输入产生了断裂。
小组类型和何时使用
正确的小组从你要回答的问题开始。安装小组、事件小组和收入小组都可以描述同一用户，但它们在分析中定位在不同时刻并支持不同的决策。
基于安装的小组 根据首次安装或首次应用打开日期将用户分组到一起。他们是引导和获取分析的默认值，因为每个用户都通过相同的起始事件进入。增长团队使用它们来比较推广质量、早期保留和首次运行体验的变化。
基于事件的小组 从有意义的行为开始，例如完成引导流程、创建项目、完成工作或发送第一条消息。他们在安装和激活之间移除一些噪音。如果完成第一份工作的用户比仅安装的用户更长时间保持活跃，引导流程问题很可能阻碍了价值发现，而不是反映产品级别的留存失败。
基于收入的群体 将用户锁定在第一笔交易、订阅开始、计划等级或其他营收事件上。这些群体支持LTV分析、回收决策和不同商业模式之间的比较。订阅用户和广告支持用户不应以相同的留存期望来评判，因为他们的经济价值和参与动机不同。最近 移动留存覆盖 关于 14% 的 30 天留存率与订阅应用相比，约为 5.4% 的广告支持应用,这使得商业模式标准化变得至关重要。
实用选择指南
| 群体类型 | 最佳用途 | 回答的关键问题 | 示例触发器 |
|---|---|---|---|
| 基于安装 | 增长和引导 | 用户是否在首次启动后返回? | 首次打开 |
| context | Page/area: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Message key `native_build_builder_credit_first` (Native Build Builder Credit First). | 基于事件 | 产品激活 |
| 一个有意义的动作是否预示着持续使用? | 首次完成 | context | 首次购买或订阅开始 |
A 健身应用可能会发现，用户在第一天完成第一份健身计划的用户比全员安装的用户更好地保留。这个发现并不能证明健身计划会导致保留，但它为产品团队提供了一个可测试的激活假设。接下来要做的是减少到达健身计划的路径，然后比较受控的分组。
使用 按计划和渠道进行用户分段 保留用户分段的维度。一个用户分段的定义应该记录其锚定事件、时区、渠道、国家、平台、计划和应用版本。否则，两个具有相同标签的行可能代表着实质性的不同人群。
核心指标
驱动用户分段决策的指标
保留率 衡量原始用户分段中执行定义的回归动作的比例，期间为：
Retention Rate = Active Users in Cohort in Period / Total Users in Cohort × 100
对于一个安装用户分段，回归动作可能是打开应用。对于一个事件用户分段，它可能是完成健身计划或创建文档。定义该动作在查看结果之前。若回归事件在报告之间发生变化，曲线不再提供可靠的比较。
流失率 描述在同一期间丢失的用户：
Churn Rate = 1 - Retention Rate
对于订阅产品来说，这种逆向分析尤其有用，因为失去的客户会影响到持续收入。一个高的第一天结果后面跟着一个30天的陡峭下降，表明第一天的体验比长期价值更好。一个稳定的曲线表明核心用户已经找到了一种重复的理由来回来。
生命周期价值 衡量一个群体的累计收入，除以群体大小：
LTV = Total Cohort Revenue / Cohort Size
一些团队使用一个模拟的形式，例如平均每用户收入乘以平均生命周期，但群体级别的计算更容易审计。它也避免了一个常见的错误，即把早期转化的收入当作整个获取来源都是可行的证明。
读取指标
一个小的高价值群体可能看起来很出色，但在规模化方面却失败了。将每个群体与其自身的初始人口进行归一化，然后比较收入和留存率与获取成本、渠道、国家、平台和商业模式。不要仅仅根据最高的LTV或最高的早期留存率来排名群体。
benchmark范围提供了上下文，而不是通过或失败的评级。强大的应用程序通常报告出 30-40%的第一天留存率、10-15%的第七天留存率和5-8%的30天留存率，而中位数的应用程序则更接近于 25%、8%和4% 在这些里程碑上，根据 设置Greet的移动留存基准总结在比较应用程序之前，务必选择正确的类别和商业模式，以避免将差距归因于用户体验。
The 用户流失分析指南 用户流失分析指南提供了对团队表的有用补充。团队表显示了流失发生的时间。然后，流失分析应该确定哪种用户行为、获取来源或产品条件是其前奏。
使用SQL和分析工具计算团队
可靠的SQL工作流程始于每个用户的一行，包含团队锚点。不要从每个活动行中计算锚点，因为后续事件可能会将用户移动到错误的起始周期。
假设一个 events 表格中 user_id, event_name, 和 event_at 字段。以下模式创建了每周安装团队，并衡量每个用户是否在选择的生命周期年龄时生成了活动事件：
WITH first_open AS (
SELECT
user_id,
MIN(event_at) AS cohort_at
FROM events
WHERE event_name = 'app_open'
GROUP BY user_id
),
activity AS (
SELECT DISTINCT
f.user_id,
DATE_TRUNC('week', f.cohort_at) AS cohort_week,
DATE_DIFF('day', CAST(f.cohort_at AS DATE), CAST(e.event_at AS DATE)) AS age_day
FROM first_open f
JOIN events e
ON e.user_id = f.user_id
AND e.event_name = 'app_open'
AND e.event_at >= f.cohort_at
)
SELECT
cohort_week,
COUNT(DISTINCT CASE WHEN age_day = 1 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_1_retention,
COUNT(DISTINCT CASE WHEN age_day = 7 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_7_retention,
COUNT(DISTINCT CASE WHEN age_day = 30 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_30_retention
FROM activity
GROUP BY cohort_week
ORDER BY cohort_week;SQL语法因仓库而异，尤其是日期差函数。重要的结构保持不变：建立第一个事件，连接后续活动到锚点，计算年龄，并将不同返回用户的数量除以原始团队人口。
对于激活的队列，替换锚点事件而不是添加表面层次的过滤器：
WITH onboarding_complete AS (
SELECT
user_id,
MIN(event_at) AS cohort_at
FROM events
WHERE event_name = 'onboarding_complete'
GROUP BY user_id
)
SELECT
DATE_TRUNC('week', cohort_at) AS cohort_week,
COUNT(DISTINCT CASE
WHEN e.event_name = 'app_open'
AND DATE_DIFF('day', CAST(o.cohort_at AS DATE), CAST(e.event_at AS DATE)) = 7
THEN o.user_id END) * 1.0 / COUNT(DISTINCT o.user_id) AS day_7_retention
FROM onboarding_complete o
LEFT JOIN events e
ON e.user_id = o.user_id
AND e.event_at >= o.cohort_at
GROUP BY cohort_week;选择计算层
| 维度 | 原始SQL / 数据仓库 | 产品分析平台 |
|---|---|---|
| 自定义归一化 | 强大，支持在支出、CRM和计费中进行的连接 | 受可用属性的限制 |
| 设置速度 | 需要建模的表格和测试的查询 | 标准队列报告的快速 |
| 即时切片 | 数据模型准备后灵活 | 适合分析师和产品团队 |
| 可复现 | 版本控制和可审计 | 依赖保存的定义和权限 |
| 最佳匹配 | 财务级报告和复杂的归因 | 产品问题和快速探索 |
通常Amplitude、Mixpanel和Firebase在第一轮分析中表现良好。选择锚点事件，选择返回事件，定义时间粒度，添加通道或版本的过滤器，验证小组大小之前解释图表。仓库SQL在需要将广告费、退款、订阅状态和隐私安全归因合并到一个计算中时更有价值。
建立此基础的团队也应 建立数据驱动的文化因为只有当产品、营销、财务和工程团队信任定义时，生命周期小组仪表板才会改变决策。对于自定义生命周期事件, Capgo的事件跟踪插件 可以与应用程序中已经有的分析工具一起考虑。
常见的陷阱和团队如何误读团队数据
一支团队可以构建一个技术上正确的团队表格，但仍然得出错误的结论。最具破坏性的错误发生在解释之前，当分析师结合不应比较的群体或同时发生的变化给予因果信用。
幸存者偏见隐藏了第一个失败
假设晚期保留率提高了，用户已经达到某个特征。团队庆祝，但早期保留率下降了，因为新用户导航屏幕阻止了更多用户达到该特征。仅仅关注幸存者使产品看起来更健康，而顶部的漏斗却在恶化。
跟踪整个序列，而不是仅仅关注剩余的用户:
- 安装或首次打开。
- 账户创建或权限完成。
- 核心激活事件。
- 重复价值事件。
- 收入或订阅行为。
A较晚阶段的用户群是有条件的。它回答的是激活用户如何行为，而不是产品如何高效地激活用户。
混合渠道会产生误导性的平均值
辛普森悖论是当付费和免费用户共享一行时的真正风险。混合曲线可以在渠道混合转向更强大的来源时上升，甚至在渠道内的留存率下降时。仪表盘记录的是组成变化，而不是产品改进。
在评估发布或登录变化之前，务必要控制获取来源。保持营销活动、国家、平台、应用程序版本和营利模式作为维度。商业模式也很重要。 the earlier benchmark source means a blended curve can penalize a product for changing its revenue mix.
A cohort is only comparable when its entry conditions are comparable.
Timestamp errors cause a quieter form of corruption. Store event timestamps consistently, define Day 0 explicitly, and decide whether the analysis uses the user’s local date or a canonical reporting time zone. A global app can otherwise count a late-night install and a next-morning open as different lifecycle days for similar behavior.
基于安装的留存率有一个限制。它从安装或首次打开的人口开始计数，但它并不能解释那些从未体验到应用核心功能的用户是否在误导性的期望下被获取。 如果一个营销活动承诺一个功能，但应用并没有立即提供，频道级别的同类数据应该在工程重写产品之前引导调查。
连接同类见解到发布和更新策略
发布管理会创建自然的同类。接收版本A、版本B、分阶段发布或热修复的用户可以单独跟踪，假设应用在接触时记录了版本和相关的发布频道。
这使得留存率成为一个发布信号，而不是一个回顾报告。新版本的突然第1天下降可能指示应用崩溃、身份验证失败、迁移失败或引导流程回归。同类曲线本身无法识别根本原因，但它可以告诉工程师新人口的行为不同，值得立即调查。
为发布比较使用固定边界
一个有用的发布工作流程如下:
- 定义接触: 记录应用版本、发布频道、设备平台、国家和接触时间戳。
- 创建匹配的同类: 与同一时间段和获取条件下的新版本用户进行比较，了解与之前基准组用户的差异。
- 查看曲线： 查看第1天、第7天和第30天的留存率、崩溃、失败事件和核心激活。
- 选择行动： 根据综合证据，推广、暂停、迭代或回滚。
新版引导流程发布到小规模观众中可能会显示出更好的早期留存率，因为观众来自不同的推广活动。然而，这个结果不足以扩大发布范围。保持获取来源和队列边界不变，或者使用随机分配，避免版本效果继承推广效果。
热修复分析需要同样的纪律。标记首次遇到bug的用户、接收修复的用户和仍然使用早期版本的用户。如果修复后队列恢复其激活路径，而未修复队列继续下滑，证据支持发布干预。如果两组表现相同，bug可能无法解释原始下滑。
团队可以使用 移动应用程序更新策略 来连接部署选择与测量。基于版本的队列在发布通道、采用事件和失败状态都纳入同一事件模型时更有用。
超越安装留存率和事件和收入队列
安装保留率回答一个狭窄的问题：用户是否在安装后返回？它并不能告诉你他们是否完成了创造价值的动作，是否扩展了使用，还是是否产生了收入。一个产品可以维持一个可敬的安装曲线，同时却无法将用户推进到其核心工作流中。
事件群组使这一进展可见。定义一个激活事件，它代表真正的价值，而不是一个代理，如打开屏幕。对于一个健身应用来说，这可能是完成第一个工作。对于一个金融应用来说，它可能是完成一个允许的核心交易。对于一个协作应用来说，它可能是创建并分享一个项目。
收入群组添加了经济层。根据首次购买、订阅开始、计划等级或计费事件将用户分组，然后跟踪后续收入和使用。标准化跨订阅等级和内购捆绑包的比较，以免高收入群组被误认为是普遍更好的产品体验。
报告进展与返回行为并列
一个有用的冲刺回顾表格应该将群组定义保持可见：
| 群组类型 | 定义 | 首日留存率 | 第7日留存率 | 第30日留存率 | 主要见解 |
|---|---|---|---|---|---|
| 安装 | 首次打开应用的用户分组 | 从安装开始 | 从安装开始 | 从安装开始 | 获取和引导质量 |
| 事件 | 首次有意义激活的用户分组 | 从激活开始 | 从激活开始 | 从激活开始 | 是否激活用户持续发现价值 |
| 收入 | 按首次交易或订阅分组的用户 | 从转化开始计算 | 从转化开始计算 | 从转化开始计算 | 盈利持久性和LTV |
单元格中应包含您的测量值，而不是通用目标。根据类别和模型，benchmark会有所不同， UXCam的留存率benchmark讨论 总结了常用的第1天、第7天和第30天窗口，同时强调了月初和月三的流失率在生命周期分析中的作用
隐私约束使得这个更广泛的定义变得越来越重要。当归因不完整时，团队应该更多地依赖于第一方事件、生命周期里程碑和收入记录，而不是将安装来源视为行为的完整解释。最有用的队列定义是你要改进的产品价值最接近的那个。
报告安装留存率、激活留存率和收入留存率。如果安装留存率保持平稳但激活用户改善，引导体验可能是主要杠杆。如果激活保持强劲但收入留存率削弱，价格、付费墙时机、计划匹配度或计费体验值得关注。这种分离使得获取、产品和营销团队对他们可以影响的生命周期部分负责。
Capgo 为 CapacitorJS 和 Electron 应用程序提供实时更新，允许团队向目标 JavaScript、CSS、配置和资产进行交付，同时跟踪采用、失败、回滚信号和版本传播。使用这些发布信号来创建更清洁的版本和频道队列，然后访问 Capgo 到评估其部署工作流是否符合您的发布测量过程。
