WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Optimize your monetization with App Analytics

Optimize your monetization with App Analytics

App StoreDistribution & Marketing
观看原视频

Highlight

主讲人 Max Martynov 用一个虚构的运动 app “Exercise” 演示了 App Analytics 的全面升级，新增 100+ 指标、cohort 分析视图、peer group benchmark 和两份订阅报告，把分析视角从总量推进到了”用户什么时候付费、付完是否留下”。

核心内容

很多开发者打开 App Store Connect 的 Analytics 时，看到的都是总量：今日下载多少、本月收入多少、订阅活跃多少。这些数字能告诉你”现在好不好”，却很难告诉你”为什么好”或”为什么不好”。一个跑步 app 的开发者可能花钱买流量、上线 custom product page、推出订阅，最后却只能看到一条上下波动的总收入曲线，分不清问题出在拉新、转化、还是留存。

WWDC25 这场 session 把答案拆开了。Apple 把 App Analytics 整体搬进了 Apps tab 内的新 Analytics 入口，按客户旅程（acquisition → monetization → subscription → offer）重排导航，新增 100+ 指标，并把 cohort 视图作为一等公民。主讲人 Max Martynov（00:07）用一个虚构 app “Exercise”——卖一对一跑步和骑行训练的 In-App Purchases，再加两个 custom product page（一个面向跑者、一个面向骑行者）——一步一步把数据问题转成数据回答：跑者下载得不少，但 Download-to-Paid Conversion 只有 1.3%（07:38），远低于平均 3%（05:44）；可一旦订阅，跑者反而比平均更长寿（11:08）。结论很清楚：跑者获客没问题，转化是瓶颈，引入 intro offer 是正确动作。

详细内容

新主页与筛选能力（01:15）。Analytics 移入 Apps tab，左侧 sidebar 把指标分为 acquisition、monetization、subscription、offer 等区块。Metrics 页面允许同时叠加 7 个 filter（之前是 3 个），每个 filter 还能多选值。例如可以一次筛选”US + Canada × iPhone + iPad × iOS 18 × 某个 custom product page”，看哪个 referrer 来源在这个组合下转化最好（02:31）。

Monetization section（04:08）。带 IAP 的 app 会出现新的 Monetization 区块。Sales 视图顶部是熟悉的 proceeds、paying users、IAP 总数；下方两个 cohort 指标是这次的重点：

  • Download-to-Paid Conversion：用户从下载到第一次付费要多久。
  • Average Proceeds per Download：下载之后累计多少收入，按天展开。

两个指标都直接挂着 peer group benchmark，把 25th / 50th / 75th percentile 画在你的曲线旁边。Exercise app 在 35 天的 conversion 是 3%，落在 25th–50th 之间，“略低于平均”（05:44）。但 Average Proceeds per Download 持续增长且高于 benchmark，说明会付费的用户买得多——问题在转化漏斗，不在 ARPPU。

Cohorts 页面（05:07）。点 Cohorts 进入矩阵视图：行是下载月份，列是天数，单元格是该队列在 N 天后累计付费比例。9 月的 58,000 下载里，2.9% 在 7 天内付费（06:45）。顶部一行是各天数的整体平均；颜色梯度让”何时付费”一目了然。叠一个 “Running 主题 custom product page” filter，35 天 conversion 立刻掉到 1.3%（07:38），定位完成。

Subscription section（08:23）。新增 50+ 订阅指标，分两类：

  • State 指标：某一时刻的快照——多少 plan 在 offer 期、多少在付全价、多少有 billing issue、多少已 churn（09:42）。
  • Event 指标：某天/周/月的状态迁移——activation、reactivation、voluntary churn、involuntary churn（10:10）。

Net Paid Plans 图把 plan starts（激活 + 重新激活）和 churn（自愿 + 非自愿）画在同一张图上，方便一眼看出净增长来自获客还是来自留存改善。Subscription Retention 也接到了 Cohorts 视图：6 个月的整体平均是 73%（10:41），同样能按 custom product page 拆分。

Offers section（11:46）。Exercise app 给跑者上线一个 1 个月免费试用 offer 之后，Offers summary 直接显示 active offers、new offers、conversion-to-paid 的曲线。Cohorts 里选 “Subscription Retention by offer start”，左列是 offer→paid 转化，顶行是后续留存。免费试用的 67% 转付费、3 个月留存 78%、6 个月留存 73%（12:59），决定 offer 是否值得保留就有了具体数字。

Reports API（13:31）。Analytics Reports API 现在覆盖 8 类报告，本年新增 subscription state report 和 subscription event report，将逐步替代旧的 Sales and Trends 订阅报告，并且在隐私友好的前提下把下载来源和订阅表现关联起来（14:19）。要订阅这两份新报告，可通过 App Store Connect API 的 analyticsReportRequests 端点发起请求：

# 创建一个 ONGOING（每日刷新）的 analytics report request
curl -X POST \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  "https://api.appstoreconnect.apple.com/v1/analyticsReportRequests" \
  -d '{
    "data": {
      "type": "analyticsReportRequests",
      "attributes": { "accessType": "ONGOING" },
      "relationships": {
        "app": { "data": { "type": "apps", "id": "1234567890" } }
      }
    }
  }'

关键点：

  • Authorization: Bearer $JWT：App Store Connect API 用基于 ES256 的 JWT 鉴权，$JWT 由开发者后台下发的私钥配合 iss / kid / exp 声明签出。
  • accessType: "ONGOING"：声明这是持续刷新的报告订阅，每天自动产出新一批 instances；另一种取值是 ONE_TIME_SNAPSHOT，用于回填历史。
  • relationships.app.data.id：把请求绑定到具体 app，id 即 App Store Connect 中的 Apple ID。
  • 创建成功后返回的 analyticsReportRequest id，需要再调用 /v1/analyticsReports?filter[category]=APP_USAGE 列出可用的 report，再用 /v1/analyticsReportInstances/{id}/segments 拿到 CSV 下载链接，新增的 subscription state / event report 会出现在 category 列表中。

更详细的字段定义见 Analytics Reports 文档。

核心启发

  • 做什么：把 Download-to-Paid Conversion 设为产品周报的固定指标

    • 为什么值得做：peer group benchmark 给了一条客观基线，落在 25th percentile 以下意味着拉新预算不该再加，问题在转化漏斗。
    • 怎么开始：在 Cohorts 页面选 Download-to-Paid Conversion，记录当前在 25th / 50th / 75th 的位置，每周对照一次，比对照绝对值更稳定。

  • 做什么：把 custom product page 当作 cohort 的 filter，而非落地页 A/B

    • 为什么值得做：custom product page 不只是创意素材，本质是用户来源标签——session 中跑者的 1.3% 对比平均 3%，正是用 product page 反查渠道差异。
    • 怎么开始：每个主要获客渠道分配一个 custom product page；跑数据时在 Cohorts 里同时叠加 product page filter 和 Subscription Retention，看哪个渠道带来的用户终身价值最高。

  • 做什么：用 State / Event 指标搭建订阅看板

    • 为什么值得做：总订阅数掩盖了”流入快但流出也快”的危险信号；State 看截面、Event 看流动，两者放在一起才能判断净增长来自哪里。
    • 怎么开始：State 选 plans in offer / paying full price / billing issue / churned，Event 选 activations / reactivations / voluntary churn / involuntary churn，按周更新。

  • 做什么：上线 intro offer 之前先用 Cohorts 验证瓶颈

    • 为什么值得做：offer 解决的是”想买不敢买”，对”不想买”无效。如果 Subscription Retention 已经低于 benchmark，问题在产品而非定价，offer 只会拉来薅羊毛用户。
    • 怎么开始：先用 Subscription Retention cohort 看 6 个月留存是否高于 peer group——高就上 intro offer，低就先改 onboarding。

  • 做什么：接入 subscription state / event report 做离线分析

    • 为什么值得做：网页 dashboard 适合定期巡检，但与 app 内行为数据（关卡、内容消费、推送响应）的交叉分析必须落到自有 BI。
    • 怎么开始：用 Analytics Reports API 拉取这两份新报告，按订阅 ID 与自有事件流 join，识别”哪类 in-app 行为最能预测续订”。

关联 Session

评论

GitHub Issues · utterances