仅有 25.3%的移动应用用户在第一天返回, 平均留存率下降到 30天内5.7%的用户 根据Business of Apps的移动应用保留指标 全球31个应用类别。这个曲线并不能告诉你问题出在哪里，可能是用户获取不佳，引导流程混乱，还是产品价值不强。 应用团队分析可以告诉你。
平均值会将通过不同推广活动、国家、设备、应用版本和营收模式到达的用户合并起来。应用团队分析仪表板会将这些用户分开，跟踪每个用户的整个生命周期，并为产品、营销和工程团队提供一个有根据的依据来决定修复什么问题。
目录
- 为什么应用团队分析可以揭示聚合指标无法显示的内容
- 团队类型和使用场景
- 核心指标驱动团队决策
- 使用 SQL 和分析工具计算团队
- 团队常见的陷阱和如何误读团队数据
- 将团队见解与发布和更新策略联系起来
- 超越安装保留和事件和收入团队
为什么应用团队分析揭示了聚合指标所隐藏的内容
一个整体保留数字对于健康检查是有用的，但它是一个糟糕的诊断工具。如果付费社交、有机搜索、推荐和合作伙伴营销都汇入一个混合仪表板，结果描述的是用户的混合而不是产品本身。同样的问题出现在iOS和Android用户、新老客户和不同的引导体验共享一个曲线时。
上面的benchmark表明第一個月值得關注。同樣的 應用程式的業務持續性分析 報告iOS的平均值 25.65%在第一天和4.13%在第30天，而Android的平均值 23.01%在第一天和2.59%在第30天。類別的表現也會有很大的差異，從 11.3%在第30天的新聞類別到2.1%的教育類別。因此，全球平均值可能會使強大的類別看起來弱小，或使弱小的頻道看起來可接受。
族群分析的診斷價值
一行族群分析的行程將用戶根據他們第一次打開應用程式的時間分組，然後在一致的年齡點如第一天、第七天和第30天測量回歸行為。讀取一行的行程會顯示一個單一群組的成長。讀取一列的行程會比較不同群組在相同的生命週期點的表現。
从“为什么留存率低？”的问题转变为：
- 获取质量： 是否有一次广告活动吸引了不打算使用该产品的用户？
- 入门阻力： 是否用户安装但无法完成第一个有意义的步骤？
- 价值传递： 是否激活用户在初次体验后仍然消失？
- 版本发布影响： 是否新版本改变了接受它的用户曲线？
团队可能会看到整体留存率平稳，而最近的周级留存率提高，老的留存率自然会随时间而减少。没有分段的留存率会将改善的效果平均掉。反之，一个强大的总体数字可能会掩盖付费渠道恶化的情况，因为如果有足够的自然流量增长，就可以抵消它。
实践规则： 绝不仅凭总体仪表盘就批准与留存率相关的产品变更。首先将结果分解为获取来源、国家、平台、入门路径和应用版本。
当将诊断转化为更广泛的生命周期视图时，应用用户保留框架是有用的。 应用用户保留框架 分析的操作点是简单的：同化分析告诉你曲线在哪里断裂，而分段分析帮助你确定哪个可控输入产生了断裂。
同化分析类型和何时使用
正确的同化分析从你要回答的问题开始。安装同化、事件同化和收入同化都可以描述同样的用户，但它们在分析中锚定不同的时刻并支持不同的决策。
安装同化 根据首次安装或首次应用打开日期将用户分组到一起。它们是首次体验和获取分析的默认值，因为每个用户都通过相同的起始事件进入。增长团队使用它们来比较营销活动质量、早期保留和首次运行体验的变化。
事件同化 从一个有意义的行为开始，例如完成首次体验、创建项目、完成健身课程或发送第一条消息。它们消除了安装和激活之间的噪音。如果完成首次健身课程的用户比仅安装用户更长时间保持活跃，说明首次体验问题可能阻碍了价值发现，而不是反映产品整体的保留失败。
收入同化 将用户锁定在首次交易、订阅开始、计划等级或其他营收事件上。这些群体支持LTV分析、回收决策和不同商业模式之间的比较。订阅用户和广告支持用户不应以相同的保留期望来评判，因为他们的经济价值和参与度激励力不同。最近 移动保留覆盖率 关于 14% 的订阅应用程序在 30 天内保留率为 14%，而广告支持应用程序的保留率约为 5.4%这使得商业模式标准化成为必不可少的
实用选择指南
| 群体类型 | 最佳用途 | 回答的关键问题 | 示例触发器 |
|---|---|---|---|
| 基于安装 | 增长和入门 | 是否用户在获取和首次启动后会返回? | 首次打开应用 |
| native_build_builder_credit_first | 基于事件 | 产品激活 | 是否一个有意义的动作预测用户会继续使用? |
| 首次完成健身课程 | native_build_builder_credit_first | 基于收入 | 营销和财务 |
如何在转化后价值会发展?
首次购买或订阅开始 按计划和渠道进行用户分段 为了保持影响公平性的维度，一个团队的定义应该记录其锚点事件、时区、渠道、国家、平台、计划和应用版本。否则，两个具有相同标签的行可能代表着实质性的不同人群。
核心指标驱动团队决策
保留率、流失率和LTV回答了不同的问题。团队会陷入困境，因为他们把其中一个当作另一个的替代品。
保留率 衡量原始团队中执行定义的返回动作的比例，期间为:
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
某些团队使用一种模拟形式，例如平均收入乘以平均寿命，但在群体级别的计算更容易审计。它还防止了一个常见的错误，认为早期转换的收入证明整个获取来源是可持续的。
阅读指标
一个小型高价值群体可能看起来很出色，但在扩展方面却失败了。将每个群体标准化为其自身的初始人口，然后比较收入和留存率与获取成本、渠道、国家、平台和商业模式。不要仅仅根据最高终身价值或最高早期留存率排名群体。
benchmark范围提供了上下文，而不是通过或失败的评级。强大的应用程序通常报告30-40%的第一天留存率、10-15%的第七天留存率和5-8%的第30天留存率 而中位数应用程序则更接近于25%、8%和4% 在这些里程碑上，根据 Setgreet的移动留存率benchmark摘要 。与正确的类别和商业模式进行比较之前，不要将差距归因于用户体验。. Compare your app with the right category and business model before attributing a gap to UX.
The user churn 分析指南 提供了对团队表的有用补充。团队表显示了脱队的时间。脱队分析应该确定哪种用户行为、获取来源或产品条件是脱队的前奏。
使用 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;选择计算层
| 维度 | Raw SQL / Data Warehouse | 产品分析平台 |
|---|---|---|
| 自定义规范化 | 强大，支持在花费、CRM和billing之间进行的连接 | 受可用属性的限制 |
| 设置速度 | 需要建模的表格和测试的查询 | 标准团队报告的快速 |
| 即兴切片 | 一旦数据模型准备好，就很灵活 | 适合分析师和产品团队 |
| 可复现性 | 基于版本控制和可审计 | 依赖保存的定义和权限 |
| 最佳匹配 | 上下文: Capgo Builder / 原生云构建产品页面。角色: 短 UI 标签或导航项。 | 财务级报告和复杂的归因 |
产品问题和快速探索
Amplitude、Mixpanel 和 Firebase 通常在第一步时表现良好。选择 anchor 事件，选择 return 事件，定义时间粒度，添加用于渠道或版本的过滤器，并在解释图表之前验证队列大小。仓库 SQL 在需要将广告支出、退款、订阅状态和隐私安全归因合并到一个计算中时更具价值。 构建此基础的团队也应建立数据驱动的文化 Capgo’s event tracking plugin __CAPGO_KEEP_0__ 的事件跟踪插件
可以与应用程序中已经存在的分析工具一起考虑。
A团队可以构建一个技术上正确的族群表，但仍然得出错误的结论。最具破坏性的错误发生在解释之前，当分析师将不应比较的群体结合起来或给予同时发生的变化的因果信用。
幸存者偏见隐藏了第一个失败
假设晚期留存率提高了，用户已经达到了某个特征。团队庆祝，但早期留存率下降了，因为新加入的导航屏幕阻止了更多用户达到该特征。仅仅关注幸存者使产品看起来更健康，而顶部的漏斗却在恶化。
跟踪整个序列，而不是仅仅关注剩余的用户：
- 安装或首次打开。
- 账户创建或权限完成。
- 核心激活事件。
- 重复价值事件。
- 收入或订阅行为。
晚期族群是有条件的。它回答了激活用户的行为，而不是产品如何高效地创建激活用户。
混合渠道会产生误导性的平均值
Simpson 的悖论是当付费和有机用户共享一行时，确实存在风险。混合曲线可以在通道混合转向更强大的来源时上升，即使在两条通道内的留存率下降。仪表盘记录的是组成变化，而不是产品改进。
在评估发布或入职变更之前，务必控制获取来源。保持营销活动、国家、平台、应用程序版本和营利模式作为维度。商业模式也很重要。 早期benchmark来源中报告的订阅和广告支持应用程序之间的留存差异 意味着混合曲线可以因为改变收入混合而惩罚产品。
只有当其入口条件可比时，一个群体才是可比的。
时间戳错误会导致一种更为平静的腐败。存储事件时间戳一致，明确Day 0，并决定分析是否使用用户的本地日期还是一个规范的报告时区。一个全球应用程序否则会将晚上的安装和第二天早上的打开视为不同生命周期天数的相同行为。
基于安装的留存率有一个额外的限制。它从安装或首次打开的人口开始计数，但它并不能说明那些从未达到应用程序核心体验的用户是否在误导性的期望下被获取。如果一个营销活动承诺一个应用程序不立即提供的功能，通道级别的群体数据应该率先进行调查，工程师在产品中进行重写之前。
与发布和更新策略相连的同类分析
发布管理会自然产生同类。接收版本A、版本B、阶段性发布或热修复的用户可以单独跟踪，假设应用程序在接收时记录了版本和相关的发布渠道。
这使得保留成为发布信号，而不是回顾报告。新版本的突然第一天下降可能指示崩溃、身份验证失败、迁移失败或引导回归。同类曲线本身无法识别根源，但它可以告诉工程师新人口表现不同并值得立即调查。
为发布比较使用固定边界
一个有用的发布工作流程如下:
- 定义曝光: 记录应用程序版本、发布渠道、设备平台、国家和曝光时间戳。
- 创建匹配同类: 比较曝光于新版本的用户与在同一时间表和获取条件下的前期基准线用户。
- 检查曲线: 查看第一天、第七天和第30天的保留率、崩溃、失败事件和核心激活。
- 选择一个动作： 根据综合证据，推广、暂停、迭代或回滚。
新用户引导流程在小规模用户中发布可能会显示更好的早期留存率，因为这些用户来自不同的营销活动。然而，这个结果不足以扩大发布范围。保持获取用户来源和队列边界不变，或者使用随机分配，避免版本效果继承营销效果。
热修复分析需要同样的纪律。标记首次遇到错误的用户、接收修复的用户和仍然使用较早版本的用户。如果修复后队列恢复其激活路径，而未修复队列继续下滑，证据支持发布干预。如果两组表现相同，错误可能无法解释原始下滑。
团队可以使用 移动应用程序更新策略 将发布选择与测量联系起来。基于版本的队列在发布通道、采用事件和失败状态都纳入同一事件模型时更有用。
超越安装留存率和事件和收入队列
安装留存率回答一个狭窄的问题：用户是否在安装后返回？但它并不能告诉你用户是否完成了创造价值的动作、是否扩展了使用或是否产生了收入。一个产品可以维持一个可接受的安装曲线，同时忽视核心工作流的用户流动性。
事件群组使进展变得可见。定义一个激活事件来代表真实价值，而不是一个代理，如打开屏幕。对于一个健身应用来说，可能是完成第一个工作。对于一个金融应用来说，它可能是完成一个允许的核心交易。对于一个协作应用来说，它可能是创建并分享一个项目。
收入群组添加了经济层。根据首次购买、订阅开始、计划等级或计费事件将用户分组，然后跟踪后续收入和使用情况。标准化跨订阅等级和内购捆绑包的比较，以免高收入群组被误认为是普遍更好的产品体验。
报告进展旁边的返回行为
一个有用的冲刺回顾表格应该保持群组定义可见：
| 群组类型 | 定义 | 首日留存率 | 第7日留存率 | 第30日留存率 | 主要见解 |
|---|---|---|---|---|---|
| 安装 | 用户根据首次应用打开分组 | 从安装开始 | 从安装开始 | 从安装开始 | 获取和引导质量 |
| 事件 | 首次有意义激活后的用户分组 | 从激活开始 | 从激活开始 | 从激活开始 | 激活用户是否持续发现价值 |
| 收入 | 首次交易或订阅后的用户分组 | 从转换中测量 | 从转换中测量 | 从转换中测量 | 盈利持久性和LTV |
这些单元格应该包含您的测量值，而不是通用目标。分类和模型的基准值各不相同， UXCam的留存率基准讨论 总结了常用的第1天、第7天和第30天窗口，同时强调了月初和月三的流失率在生命周期分析中的作用。
隐私约束使得这个更广泛的定义变得越来越重要。当归因不完整时，团队应该更多地依赖于第一方事件、生命周期里程碑和收入记录，而不是将安装来源视为行为的完整解释。最有用的队列定义是最接近您要改进的产品价值的定义。
报告安装留存率、激活留存率和收入留存率。如果安装留存率保持稳定，但激活用户改善，引导流程可能是主要杠杆。如果激活保持强劲，但收入留存率削弱，价格、付费墙时间、计划匹配度或计费体验值得关注。这种分离使得获取、产品和盈利团队对他们可以影响的生命周期部分负责。
Capgo 为 CapacitorJS 和 Electron 应用程序提供实时更新，允许团队交付针对 JavaScript、CSS、配置和资产的更改，同时跟踪采用、失败、回滚信号和版本分发。使用这些发布信号创建更清晰的版本和频道队列，然后访问 Capgo to evaluate whether its deployment workflow fits your release measurement process.
