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、そして 2 種類のサブスクリプションレポートが追加され、分析の視点が「総量」から「ユーザーがいつ課金し、課金後に残るのか」へと一歩進みました。

主要内容

App Store Connect の Analytics を開いたとき、多くの開発者が目にするのは総量データです。今日のダウンロード数、今月の売上、アクティブなサブスクリプション数。これらの数字は「現在の調子が良いか悪いか」は教えてくれますが、「なぜ良いのか」「なぜ悪いのか」までは答えてくれません。あるランニング app の開発者が、広告予算を投入し、custom product page を公開し、サブスクリプションをローンチしたとしても、最終的に見えるのは上下に揺れる総売上の折れ線一本だけ。問題が獲得・コンバージョン・リテンションのどこにあるのかは判別できません。

WWDC25 のこのセッションは、その答えを分解して見せてくれます。Apple は App Analytics 全体を Apps tab 内の新しい Analytics 入口に移し、ナビゲーションをカスタマージャーニー（acquisition → monetization → subscription → offer）に沿って再構成しました。100 以上の指標が追加され、cohort ビューが一級市民として組み込まれています。スピーカーの Max Martynov 氏（00:07）は、架空の app「Exercise」——1 対 1 のランニングおよびサイクリングトレーニングを In-App Purchases で販売し、加えて 2 種類の custom product page（ランナー向けとサイクリスト向け）を持つ app——を題材に、データの問いをデータの答えへと一歩ずつ変えていきます。ランナーのダウンロードは少なくないものの、Download-to-Paid Conversion はわずか 1.3%（07:38）で、平均の 3%（05:44）を大きく下回っています。一方、いったんサブスクライブしてしまえばランナーの方が平均より長く継続する（11:08）。結論は明快で、ランナーの獲得自体に問題はなく、ボトルネックはコンバージョン。intro offer を導入するのが正しい打ち手だと分かります。

詳細

新しいホームとフィルター機能（01:15）。Analytics は Apps tab に統合され、左サイドバーで指標が 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 総数が並び、その下に置かれた 2 つの 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）。最上行には経過日数ごとの全体平均が並び、グラデーションカラーで「いつ課金しているのか」が一目で把握できます。ここに「ランニングテーマの custom product page」filter を重ねると、35 日時点の conversion は一気に 1.3% まで落ち（07:38）、原因の特定が完了します。

Subscription section（08:23）。50 以上の subscription 指標が追加され、2 つのカテゴリに分類されます。

  • State 指標：ある時点のスナップショット——offer 期間中の plan 数、定価で課金中の plan 数、billing issue を抱えている plan 数、すでに churn した plan 数（09:42）。
  • Event 指標：ある日／週／月における状態遷移——activation、reactivation、voluntary churn、involuntary churn（10:10）。

Net Paid Plans のグラフは、plan starts（activation + reactivation）と churn（voluntary + involuntary）を同じチャートに重ねて描画してくれるので、純増がユーザー獲得から来ているのか、リテンション改善から来ているのかが一目で分かります。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 のサブスクリプションレポートを段階的に置き換えていく予定で、プライバシーに配慮したかたちでダウンロード経路と subscription performance をひもづけて見られるようになります（14:19）。これら 2 つの新レポートを購読するには、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 を、ランディングページの A/B テストではなく cohort のフィルターとして使う

    • なぜ価値があるのか：custom product page はクリエイティブの素材というだけでなく、本質的にはユーザー流入元のタグです。セッション内のランナー 1.3% vs 平均 3% は、まさに product page を経由してチャネル差を逆引きした結果です。
    • どう始めるか：主要な獲得チャネルごとに custom product page を 1 つずつ用意します。データを見るときは Cohorts で product page filter と Subscription Retention を同時に重ね、どのチャネルから来たユーザーの LTV が最も高いかを確認します。

  • やること：State / Event 指標で subscription ダッシュボードを組む

    • なぜ価値があるのか：総 subscription 数は「流入は速いが流出も速い」という危険信号を覆い隠してしまいます。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 を取り込んでオフライン分析を行う

    • なぜ価値があるのか：Web ダッシュボードは定期巡回には適していますが、app 内行動データ（ステージ、コンテンツ消費、プッシュ反応）とのクロス分析は自社 BI に落とし込まないと成立しません。
    • どう始めるか：Analytics Reports API でこれら 2 つの新レポートを取得し、subscription ID をキーに自社のイベントストリームと join して、「どの種類の app 内行動が継続課金を最もよく予測するか」を特定します。

関連セッション

コメント

GitHub Issues · utterances