App 统计 App 的新增、活跃、留存，
连哪个版本在崩溃都一目了然
所有端合在一个概览里：新增、DAU、启动、次日留存和崩溃率同屏；版本、渠道和安装归因一步点开。网站、App、小程序在同一个项目，不用再切后台。
- iOS、Android、鸿蒙
- Flutter、React Native、uni-app
- 留存和崩溃放在一起看
- 与网站同一个项目
新增用户
6,120
▲ 9.1%
DAU
42,093
▲ 12.4%
启动次数
128,460
▲ 8.3%
次日留存
41.6%
▲ 1.8 pts
崩溃率
0.42%
▼ 0.08 pts
日活跃用户
本期上期安装渠道
描述一个 App 的六个数
全部由 SDK 自动上报的启动和页面算出来，不需要先写埋点方案。第一个版本发出去，这六个数就有了。
新增用户
6,120▲ 9.1%
本期第一次打开 App 的设备。可按平台、版本和安装渠道拆开看。
活跃用户
42,093▲ 12.4%
DAU、WAU、MAU 并排，附 DAU/MAU 黏性比，看用户是不是天天来。
启动次数
128,460▲ 8.3%
每天的冷启动与热启动，以及人均启动次数。启动涨、DAU 不涨，说明是用得更重，不是人更多。
次日留存
41.6%▲ 1.8 pts
新增用户第二天再次打开的比例。7 日、30 日留存在下方的留存矩阵里。
人均时长
4 分 12 秒▲ 22 秒
每位活跃用户每天在前台的平均时长，并给出分布，免得少数重度用户盖住大多数人的真实情况。
崩溃率
0.42%▼ 0.08 pts
每次启动的崩溃比例，旁边是 ANR 和无崩溃用户比例。按版本拆开，坏版本几小时内就能看出来。
谁回来了、谁沉默了、谁又被拉回来了
留存决定安装费能不能赚回来。TapCub 给出新增留存、活跃留存，以及沉默用户——和那些在一次推送或新版本之后重新回来的人。
- 新增留存按天、周、月分群：D1、D3、D7、D14、D30
- 活跃留存：上周活跃的人，这周还有多少回来
- 沉默用户（7 天未启动）、回流用户、流失风险人群
- 任何一个群组都能点成分群，看他们做了什么
示例场景： 9月15日群组的次日留存 49%，但 7 日留存只有 35%。筛到 Google Play，这一渠道只有 28%——那边的付费投放带来的安装几乎没有人回来。
安装群组 · 按天留存
| 群组 | 安装 | D0 | D1 | D3 | D7 | D14 | D30 |
|---|---|---|---|---|---|---|---|
| 8月25日–31日 | 1,204 | 100% | 44% | 38% | 33% | 29% | 24% |
| 9月1日–7日 | 1,318 | 100% | 47% | 40% | 35% | 30% | |
| 9月8日–14日 | 1,276 | 100% | 51% | 43% | 37% | ||
| 9月15日–21日 | 1,402 | 100% | 49% | 42% | |||
| 9月22日–28日 | 1,366 | 100% | 53% |
活跃留存 · 按周
沉默与回流 · 7 天
- 按版本和渠道看留存同一张矩阵筛到某个版本或某个商店——4.2 更新有没有留住人、某个渠道带来的安装是不是从不打开第二次，一眼就知道。
- 沉默的定义由你定默认 7 天没有启动算沉默。可以按 App 调整，并在沉默人群增长快于新增时告警。
- 从一个格子到一群人点一下某群组的 D7，就得到一个分群——可以直接做漏斗、看路径，或导出做召回。
看清装的是哪个版本，哪个渠道值得继续花钱
版本占比说明修复有没有真正到用户手里。渠道质量矩阵把新增和留存放在一张图上，只带安装不带二次打开的商店，立刻就能看出来。
- 版本覆盖按天：新版本铺开多快、长尾藏在哪
- 升级路径：从哪个版本升上来，谁还卡在旧版本
- 渠道质量矩阵：新增 × 7 日留存，每个商店或活动一个点
- App Store、Google Play、华为、小米、OPPO、vivo 和直接安装都是渠道
- 六天后已在当前版本
- 58%
- 六天后已在当前版本
- 默认跟踪的商店渠道
- 5
- 默认跟踪的商店渠道
- 表现靠前渠道的 7 日留存
- 31%
- 表现靠前渠道的 7 日留存
版本占比 · 全部平台
4.2.1 六天内覆盖到 58%。4.1.x 的长尾主要是旧系统上的 Android 设备。
渠道质量 · 新增 × 7 日留存
右下角：安装多、留存低。付费预算就是从这里漏掉的——继续花钱之前先查素材和落地承诺。
示例场景： 一次付费社交投放一周带来 1,900 次安装——图上最大的那个点——但 7 日留存只有 12%。团队暂停了它，把预算挪到留存 31% 的邮件订阅。
用多久、多频繁、几点钟，以及在 App 里走到哪
会话时长、使用频率、时段热力和屏幕路径，同一个 SDK 给出。不用配置：页面自动命名，之后可以改名。
会话时长
大多数会话在一到三分钟。超过十分钟的长尾是结算和客服。
活跃时段
工作日晚上 20 点是高峰。周末开始得晚、结束得也晚——推送时间可以参考。
每周活跃天数
三分之一的用户每周只打开一天。14% 的人天天打开。
屏幕路径
从首页出发，44% 去了商品页，30% 去了搜索，26% 离开。高亮那条带是以付款结束的路线。
示例数据
崩溃、ANR 和启动耗时，按版本归类
稳定性数据和增长数据在同一个后台，坏版本就摆在它损失的留存旁边。每一组崩溃都带着页面名、版本和设备类型。
- 崩溃率与无崩溃用户比例每次启动的崩溃比例，以及从未遇到崩溃的用户占比。后一个数才是商店评分跟着走的。
- ANR 与启动耗时Android 的无响应事件，以及每个版本冷启动的 p50 和 p75。
- 按版本、页面和设备每组崩溃是一个签名，附带发生的页面，知道该回滚还是热修。
- 版本一退步就告警按版本监控崩溃率，一小时内通知到发版群，不用等差评先到。
稳定性 · acme.app
最近 7 天 · 全部平台崩溃率
0.42%
较上期 ▼ 0.08 pts
ANR 率
0.11%
仅 Android
冷启动 · p75
1.8 秒
4.2.1 之后 ▼ 0.3 秒
无崩溃用户
99.3%
▲ 0.2 pts
主要崩溃组
- NSInvalidArgumentException · CheckoutViewModel结算 · iOS 4.2.01860.91%
- NullPointerException · ImageLoader.decode首页 · Android 4.1.8940.38%
- SocketTimeoutException · OrderApi.pay支付 · Android 4.2.1610.21%
- EXC_BAD_ACCESS · FeedCell.layout信息流 · iOS 4.2.1380.14%
- ANR · MainActivity.onResume首页 · Android 4.2.1270.11%
接收归因平台的结果，和留存放在一起看
TapCub 自己不做安装指纹归因。它通过 AppsFlyer、Adjust 等归因平台的回传接收归因结果，把媒体来源和活动挂到每个新增用户上。从这里往下，每个活动的留存和收入都能看到。
- 接收 AppsFlyer、Adjust 的回传；其他平台走服务端 API
- 媒体来源、活动、广告组存为用户属性
- 留存、启动、付款按活动拆开
- 自然安装单独一行，不会被盖掉
| 媒体来源 | 活动 | 安装 | D1 | D7 | 付费 | 来源 |
|---|---|---|---|---|---|---|
| Meta Ads | summer_launch_ios | 4,820 | 46% | 31% | 8.4% | AppsFlyer |
| 百度营销 | brand_search_cn | 3,106 | 42% | 27% | 6.1% | Adjust |
| Google Ads | retarget_cart | 1,984 | 58% | 39% | 12.6% | AppsFlyer |
| 腾讯广告 | wechat_moments | 1,410 | 37% | 22% | 4.3% | Adjust |
| 自然安装 | organic | 12,640 | 49% | 34% | 7.2% | 商店 |
- 只展示事实，不替你猜显示的是归因平台判定的结果，并在每一行标出来源。TapCub 不会重新归因，也不会自己认领安装。
- 每个活动的付费转化付款是同一项目里的事件，所以一行活动能同时看到安装、留存和付费比例。
- 没有归因平台？走服务端 API从后端发一个安装来源属性，这张表一样会填满。
App 的数字只是开头，为什么要去数据分析里找
每个 App 用户也是数据分析里的一个人。漏斗、路径、分群和跨端时间轴，看的都是同一批人。
启动一次，启动、页面和崩溃自己进来
六个原生与跨端 SDK 共用一套接口：用站点 Key 启动，业务动作需要固定名字时再发命名事件。页面、会话和崩溃自动采集。
import TapCub
// 尽早启动一次
TapCub.start(siteKey: 'SITE_KEY')
// 业务动作需要固定名字时发命名事件
TapCub.track('order_paid', props: [
"amount": 74, "currency": "USD"
])import com.tapcub.sdk.TapCub
// 尽早启动一次
TapCub.start(this, 'SITE_KEY')
// 业务动作需要固定名字时发命名事件
TapCub.track("order_paid", mapOf(
"amount" to 74, "currency" to "USD"
))import { TapCub } from '@tapcub/harmony'
// 尽早启动一次
TapCub.start(this.context, 'SITE_KEY')
// 业务动作需要固定名字时发命名事件
TapCub.track('order_paid', {
amount: 74, currency: 'USD'
})import 'package:tapcub/tapcub.dart';
// 尽早启动一次
await TapCub.start(siteKey: 'SITE_KEY');
// 业务动作需要固定名字时发命名事件
TapCub.track('order_paid', {
'amount': 74, 'currency': 'USD'
});import TapCub from '@tapcub/react-native';
// 尽早启动一次
TapCub.start({ siteKey: 'SITE_KEY' });
// 业务动作需要固定名字时发命名事件
TapCub.track('order_paid', {
amount: 74, currency: 'USD'
});import TapCub from '@tapcub/uni-app'
// 尽早启动一次
TapCub.start({ siteKey: 'SITE_KEY' })
// 业务动作需要固定名字时发命名事件
TapCub.track('order_paid', {
amount: 74, currency: 'USD'
})支持哪些平台？
iOS、Android、鸿蒙原生，以及 Flutter、React Native、uni-app。每个平台一把站点 Key，全部汇到后台里同一个 App。网页和小程序 SDK 见数据采集页。
哪些数据是自动采集的？
启动（冷、热）、会话、页面浏览、崩溃、ANR、启动耗时、设备、系统和 App 版本。注册、下单、付款这类业务事件，由你用一行代码命名。
崩溃报告和专门的崩溃工具有什么区别？
TapCub 按签名、页面、版本和设备归类崩溃，让你看到哪个版本退步了、损失了多少留存。它不替代专业崩溃工具的符号化堆栈——很多团队两者一起用。
TapCub 做安装归因吗？
不做。TapCub 通过回传接收 AppsFlyer、Adjust 等平台的归因结果，并把媒体来源和活动放在留存与收入旁边。你也可以通过服务端 API 自己发送安装来源。
哪个套餐包含 App 统计？
网站统计每个套餐都有。App 和小程序统计从 Pro（每月 $9，年付 6 折）起包含。见定价。
App 数据保留多久？
免费版 6 个月，Pro 12 个月，VIP 24 个月起。保留期按项目算，网站和 App 的数据同一个期限。
从新建项目到看见第一次启动，只隔一个版本
不需要先写埋点方案，也没有发布门槛。接上 SDK、发版，概览自己填满。
-
1
创建项目
免费，不需要信用卡。一个项目可以同时放网站、App 和小程序。
-
2
添加 App
选择平台，每个要发布的平台各得到一把站点 Key。
-
3
接入 SDK 并启动
一个依赖、一行启动。页面、会话和崩溃自动采集。
-
4
发出版本
第一个用户打开新版本后约一分钟，启动就会出现。业务事件边做边命名。
已经在用别的 SDK？保留即可，TapCub 与之并行，不读取它的数据。 安装指南