ただし モバイルアプリのユーザーは1日目に25.3%しか戻ってこない、平均的な保持率は 30日以内の5.7% 31のアプリカテゴリで世界中のモバイルアプリの保持率ベンチマークによると Business of Appsによると。 その曲線は、問題が不十分なアクイジション、混乱したオンボーディングフロー、または弱い製品価値であるかを判断するには十分ではない。 アプリコホート分析は。
平均値は、異なるキャンペーン、国、デバイス、アプリバージョン、モノライゼーションモデルを通じてユーザーを組み合わせる。コホートダッシュボードは、各グループを同一のライフサイクルを通じて追跡し、製品、マーケティング、エンジニアリングチームに、修正することのための論理的な根拠を与える。
目次
- コンテキスト: Capgo マーケティング ウェブサイト。役割: 短い UI ラベルまたはナビゲーションアイテム。見られる場所: page blog/[slug].astro。メッセージキー `table_of_contents` (目次)。
- コホート行の診断価値
- 実用的な選択ガイド
- SQLと分析ツールを使用したコホートの計算
- コホートデータを誤解するチームの共通の誤り
- リリースとアップデート戦略にコホートの洞察を結びつける
- インストールの保持率とイベント、収益のコホートの外側
アプリのコホート分析は、集計メトリクスが隠すものを明らかにする
総合的な保持率の数字は、健康チェックとして役立ちますが、診断ツールとしては劣ります。有料のソーシャル、オーガニック検索、リファラル、パートナーキャンペーンがすべて、1つのブレンドダッシュボードに流れ込む場合、結果はユーザーのミックスを説明するのではなく、製品を説明するのではなく、製品を説明します。iOSとAndroidのユーザー、新規と再訪の顧客、または異なるオンボーディングエクスペリエンスが1つの曲線を共有する場合に同じ問題が発生します。
上記のベンチマークは、最初の月に注意を払う理由を示しています。同様に アプリのユーザー保持分析 iOSの平均 1日目は25.65%、30日目は4.13%、Androidの平均 1日目は23.01%、30日目は2.59%。カテゴリのパフォーマンスも大幅に異なり、2026年のベンチマークでは ニュースの30日目に11.3%の保持率から教育の2.1%まで。グローバル平均は、強いカテゴリを弱く見せたり、弱いチャネルを受け入れられるように見せたりする可能性があります。
コホート行の診断価値
コホート分析では、ユーザーを最初にアプリを開いた時期でグループ化し、一定の年齢（1日目、7日目、30日目）で帰還行動を測定します。1行を横に読むと、1つのグループがどのように成長するかがわかります。1列を下に読むと、同じライフサイクルにおける異なるグループを比較できます。
その区別は質問を「維持率が低いのはなぜ？」から「獲得の質」に変える。
- 獲得の質: キャンペーンがユーザーを引き付けたが、製品を使用する意欲がなかったか?
- オンボーディングの抵抗: ユーザーがインストールしたが、最初の意味のあるステップを完了できなかったか?
- 価値の提供: 有効化されたユーザーが初期体験後も消えていったか?
- リリースの影響: 新しいバージョンがユーザーに受け付けた曲線を変えたか?
チームは、全体的な維持率が一定のままであるのに、最近の週間コホートが改善し、古いコホートが自然に老化しているとみるかもしれない。コホートの境界がなければ、改善は平均化される。逆に、強い総合的な数字は、有料チャネルが悪化しているのに、オーガニックトラフィックが十分に増加しているため、隠しているかもしれない。
実用的なルール: 維持率に関連する製品の変更を、総合ダッシュボードだけでは承認しない。まず、獲得元、国、プラットフォーム、オンボーディングパス、アプリバージョンを分解してみること。
The アプリユーザーロイヤルティフレームワーク 診断をより広いライフサイクルビューに変換する際に便利です。オペレーショナルポイントは単純です: コホート分析は曲線が折れる場所を教えてくれます。分割は、折れ曲線が生じた原因となる制御可能な入力を特定するのに役立ちます。
コホートの種類と使用するタイミング
正しいコホートは、答えを求める質問から始まります。インストールコホート、イベントコホート、収益コホートはすべて同じユーザーを表すことができますが、分析を開始する時点とサポートする決定が異なります。
インストールベースのコホート ユーザーを最初のインストール日または最初のアプリを開いた日でグループ化します。オンボーディングとアクイジション分析のデフォルトです。ユーザーはすべて同じスターティングイベントから入ります。成長チームはキャンペーンの質、初期のロイヤルティ、初回実行時の変更を比較するのに使用します。
イベントベースのコホート 意味のある行動から始めます。例えば、オンボーディングを完了したり、プロジェクトを作成したり、ワークアウトを完了したり、最初のメッセージを送ったりします。インストールとアクティベーション間のノイズを削減します。ワークアウトを完了したユーザーが、単にインストールしたユーザーよりも長くアクティブである場合、オンボーディングの問題は製品全体のロイヤルティの失敗を反映しているのではなく、価値の発見を妨げている可能性があります。
収益ベースのコホート 最初のトランザクション、サブスクリプションの開始、プランの階層、または他の収益イベントにアンカーするユーザー。これらのコホートは、LTV分析、還元決定、ビジネスモデル間の比較をサポートします。サブスクリプションユーザーと広告サポートユーザーは、同等の保持期待で評価されるべきではない。経済的価値とエンゲージメントのインセンティブは異なるためです。最近の モバイル保持カバレッジ コホート分析の サブスクリプションアプリの14%の30日目保持率と、広告サポートアプリの約5.4%の保持率についての、これはビジネスモデルを標準化する必要性を示しています。
実用的な選択ガイド
| コホートの種類 | 最適な用途 | 回答される主な質問 | 例のトリガー |
|---|---|---|---|
| インストールベース | 成長とオンボーディング | ユーザーはアクイジションと最初の起動後に戻ってくるか? | 初回アプリ起動 |
| イベントベース | 製品活性化 | 意味のあるアクションは継続的な使用を予測するか? | 初回トレーニング完了 |
| 収益ベース | 収益化と財務 | 変換後の価値はどのように発展するか? | 初回購入またはサブスクリプション開始 |
フィットネスアプリでは、初日以内に初回トレーニングを完了したユーザーは、フルインストールコホートよりも多くのユーザーが保持されることがわかりました。 その発見は、トレーニングが保持を引き起こすことを証明するものではありませんが、製品チームにテスト可能なアクティベーションヒポテシスを提供します。 次のステップは、トレーニングまでのパスを短縮し、適切に制御されたコホートを比較することです。
使用 プランとチャンネルによるユーザー分割 公平性を考慮するために影響を受ける次元を保存するために。コホートの定義は、アンカーイベント、タイムゾーン、チャンネル、国、プラットフォーム、プラン、アプリバージョンを記録する必要があります。そうしないと、同じラベルを持つ2つの行は、実質的に異なる集団を表すことになります。
コホートの決定を導く基本指標
リテンション率、脱退率、LTVは異なる質問に答える。チームが1つを他のものの代用品として扱うとトラブルになることがある。
リテンション率 定義されたリターンアクションを実行した元のコホートのシェアを測定します。インストールコホートの場合、リターンアクションはアプリを開くことかもしれません。イベントコホートの場合、リターンアクションはワークアウトを完了したりドキュメントを作成したりすることかもしれません。結果を確認する前にそのアクションを定義してください。リターンイベントがレポート間で変更されると、曲線が信頼できる比較を提供しなくなります。
Retention Rate = Active Users in Cohort in Period / Total Users in Cohort × 100
脱退率
同じ期間内に失われたユーザーを説明します。 この逆は、サブスクリプション製品では、失われた顧客が繰り返し収益に影響を与えるため、特に有用です。初日が高く、30日目が急激に下がる結果は、初期体験が長期的な価値提案よりも効果的であることを示唆しています。曲線が安定すると、コアグループが繰り返し理由を見つけたことを示唆しています。
Churn Rate = 1 - Retention Rate
ライフタイム価値
コホートの総収益をコホートサイズで割ったものを測定します。 measures cumulative revenue generated by a cohort, divided by the cohort size:
LTV = Total Cohort Revenue / Cohort Size
チームはモデルの形を使用することがあります。たとえば、平均ユーザー収益を平均生存期間で乗算したものですが、コホートレベルの計算はより簡単に検証できます。 また、早期に変換されたユーザーからの収益を、すべてのアクイジションソースが利益を生み出しているという証拠として扱うことを防ぎます。
指標を読み取りましょう。
小規模で高価なコホートは、スケールを果たせずに優秀に見えることがあります。各コホートを独自のスターティングポピュレーションで標準化し、収益とリテンションをアクイジションコスト、チャネル、国、プラットフォーム、ビジネスモデルと比較してください。 LTVや早期のリテンション率でコホートをランク付けするのではなく、
基準範囲は、合格または不合格の判定ではなく、コンテキストを提供します。強力なアプリは通常、 30–40%のDay 1リテンション、10–15%のDay 7リテンション、5–8%のDay 30リテンションを報告します。 ただし、 25%、8%、4% のメディアンアプリは、 Setgreetのモバイルリテンション基準サマリーに基づいて、
のマイルストーンに近いです。 それぞれのカテゴリとビジネスモデルを比較して、UXのギャップを特定するのではなく、 ユーザーチャーン分析ガイド コホート表の有用な補完として、コホート分析は脱落時期を示します。次に、ユーザー行動、獲得元、製品条件がそれに先行したかどうかを特定する必要があります。
SQLと分析ツールを使用したコホートの計算
信頼できるSQLワークフローは、1行あたりのユーザーにコホートのアナーカーを含むものから始まります。すべてのアクティビティ行からアナーカーを計算しないでください。後続のイベントは、ユーザーを間違った開始期間に移動させる可能性があります。
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;__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
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;__CAPGO_KEEP_0__
| __CAPGO_KEEP_0__ | Raw SQL / Data Warehouse | Product Analytics Platform |
|---|---|---|
| カスタムの正規化 | 強力、スパンド、CRM、請求書の間でジョインをサポート | 利用可能なプロパティによって制限される |
| セットアップのスピード | モデルのテーブルとテストされたクエリが必要 | 標準コホートレポートの場合に高速 |
| アドホックのスライシング | データモデルが用意されている場合に柔軟 | 分析家や製品チームにとって優れ |
| 再現性 | バージョン管理されたもので、監査可能 | 保存された定義と権限に依存 |
| ベストフィット | コスト管理レベルでのレポートと複雑なAttribution | 製品に関する質問と迅速な探索 |
Amplitude、Mixpanel、Firebaseは、最初のパスとしてよく機能します。アンカーイベントを選択し、リターンイベントを選択し、時間粒度を定義し、チャネルまたはバージョンにフィルタを追加し、コホートサイズを確認する前にグラフを解釈することから始めます。ウェアハウスSQLは、1つの計算で広告費用、返金、サブスクリプション状態、プライバーサーフェイスAttributionを組み合わせる必要がある場合に、より価値があります。
この基盤を構築しているチームは データ駆動型の文化を構築することも、製品、市場、財務、エンジニアリングが定義を信頼する場合にのみ、コホートダッシュボードは決定を変更します。カスタムライフサイクルイベントの場合 Capgoのイベントトラッキングプラグイン は既存のアプリの分析インストルメンテーションとともに検討できます。
コモンプチフォールズとチームがコホートデータを誤読する方法
チームは、技術的に正しいコホートテーブルを作成しでも、間違った結論に達することができます。 最も損害を与えるミスは、解釈前に発生し、分析者が比較すべきではない集団を組み合わせたり、同時に発生する変化に因果関係を与えたりします。
サバイバーの偏見は最初の失敗を隠します。
ユーザーが特定の機能に到達した場合、後期の保持率が向上したと仮定すると、チームは祝福しますが、早期の保持率は低下していることがわかります。 これは、新しいオンボーディング画面が機能に到達するユーザーをブロックするためです。 ただし、機能に到達したユーザーだけを観察すると、製品がより健康的なように見えますが、トップのフンボールが悪化しています。
全てのシーケンスを追跡するのではなく、残っているユーザーだけを追跡するのではなく:
- インストールまたは初回開放。
- アカウント作成またはパーミッションの完了。
- コアアクティベーションイベント。
- 繰り返し価値イベント。
- 収益またはサブスクリプションの行動。
後期のコホートは条件付きです。 これは、有効化されたユーザーがどのように行動するかを答えるのではなく、製品が有効化されたユーザーを効率的に作成するかどうかを答えるものです。
混合チャネルは誤解を招く平均を生み出します
Simpsonのパラドックスは、有料と有料以外のユーザーが同じ行に含まれる場合に実際のリスクです。チャンネルミックスが強いソースにシフトすると、チャンネル内でリテンションが低下しても、ブレンドされた曲線は上昇することがあります。ダッシュボードは、組成の変化を記録しますが、製品の改善ではありません。
リリースまたはオンボーディングの変更を評価する前に、獲得ソースを制御する必要があります。キャンペーン、国、プラットフォーム、アプリバージョン、モノライゼーションモデルを維持しておく必要があります。ビジネスモデルも重要です。サブスクリプションと広告サポートのアプリ間のリテンションギャップが報告された 前回のベンチマークソース では、ブレンドされた曲線は製品が収益構成を変更した場合にペナルティを与える可能性があります。
コホートは、エントリ条件が比較可能な場合にのみ比較可能です。
タイムスタンプのエラーは、静かな形の汚染を引き起こします。イベントタイムスタンプを一貫して保存し、Day 0を明確に定義し、分析がユーザーのローカル日付または標準的なレポート時刻帯を使用するかを決定する必要があります。グローバルアプリでは、遅い夜のインストールと翌朝のオープンを同様の行動として数えることができません。
インストールベースのリテンションには、1つの制限があります。インストールまたはファーストオープン人口から数えますが、ユーザーがアプリのコアエクスペリエンスに到達しなかった場合に、獲得された期待が誤解を招く可能性があることを説明しません。キャンペーンがすぐに実装されない特徴を約束した場合、チャンネルレベルコホートデータは、エンジニアリングが製品を書き直す前に調査する必要があります。
バージョン間のコホートの洞察をリリースとアップデート戦略と接続する
リリース管理は自然のコホートを生成します。バージョンA、バージョンB、ステージドロールアウト、またはホットフィックスを受け取るユーザーは、エクスポージャーの時点でアプリがバージョンと関連するリリースチャネルを記録している場合に別々に追跡できます。
リテンションはリリース信号であるのではなく、後退検証レポートであるべきです。新バージョンの突然のDay 1の減少は、クラッシュ、認証失敗、破損したマイグレーション、またはオンボーディングのリグレッションを示唆しています。コホート曲線は、原因を自己で特定することはできませんが、新しい人口が異なる動作を示しており、即時の調査が必要であることをエンジニアに知らせることができます。
ロールアウトの比較の固定境界を使用する
有効なロールアウトワークフローは次のようになります。
- エクスポージャーを定義する アプリバージョン、ロールアウトチャネル、デバイスプラットフォーム、国、エクスポージャータイムスタンプを記録する
- マッチしたコホートを作成する 新バージョンにエクスポージャーされたユーザーと、同じカレンダーとアクイジション条件の下で前のベースラインのユーザーを比較する
- 曲線を検査する Day 1、Day 7、Day 30のリテンション、クラッシュ、失敗したイベント、コアアクティベーションをレビューする
- アクションを選択してください: プロモーション、ポーズ、繰り返し、またはロールバックを、組み合わせた証拠に基づいて実行してください。
新しいオンボーディングフローを小規模なアウディエンスにリリースした場合、早期の保持率が良好である可能性があります。ただし、その結果は拡大するための十分な証拠ではありません。アクイジションソースとコホートの境界を一定に保つ、またはランダム化された割り当てを使用して、バージョン効果がマーケティング効果を継承しないようにしてください。
ホットフィックス分析には同じ規律が必要です。最初にバグに遭遇したユーザー、修正を受けたユーザー、以前のバージョンに留まっていたユーザーをタグしてください。修正後のコホートが再びアクティブ化パスを回復し、修正されていないコホートが引き続き衰退しているとき、証拠はリリース介入を支持します。両方のグループが同じ行動をとっているとき、元のドロップを説明するバグが存在しない可能性があります。
モバイルリリースを管理するチームは モバイルアプリの更新戦略 を使用して、展開の選択と測定を関連付けることができます。バージョンに基づくコホートは、リリースチャネル、採用イベント、失敗状態が同じイベントモデルの一部である場合に、より有用になります。
インストール保持率とイベント、収益コホートを超えて
インストール保持率は、ユーザーがインストール後に戻ってきたかどうかを回答しますが、ユーザーがコアワークフローを通じて使用を拡大したか、または収益を生成したかどうかを知ることはできません。製品は、インストール曲線が健全であると同時に、ユーザーをコアワークフローを通じて進めることができない場合もあります。
イベントコホートはその進捗を視覚化します。実際の価値を表すアクティベーションイベントを定義してください。画面を開くなどのプロキシではありません。フィットネスアプリの場合、最初のワークアウトを完了するかもしれません。金融アプリの場合、許可されたコアトランザクションを完了するかもしれません。コラボレーションアプリの場合、プロジェクトを作成して共有するかもしれません。
収益コホートは経済層を追加します。ユーザーを最初の購入、サブスクリプション開始、プラン階層、または請求イベントでグループ化し、次に追跡する収益と使用状況をトラックします。サブスクリプション階層とインアプリ購入パッケージの比較を正規化して、高収益コホートが普遍的に良質な製品体験と間違えられないようにします。
リターン行動の横に進捗を報告します。
有用なスプリントレビュー表は、コホート定義を表示してください:
| コホートタイプ | 定義 | 1日目留まる率 | 7日目留まる率 | 30日目留まる率 | 主な洞察 |
|---|---|---|---|---|---|
| インストール | 最初のアプリを開いたユーザーをグループ化します | インストールから測定 | インストールから測定 | インストールから測定 | 獲得とオンボーディングの質 |
| イベント | 最初の有意義なアクティベーションでグループ化されたユーザー | アクティベーションから測定 | アクティベーションから測定 | アクティベーションから測定 | アクティベーションしたユーザーが価値を見つけることができるか |
| 収益 | 最初のトランザクションまたはサブスクリプションでグループ化されたユーザー | 測定された変換から | 測定された変換から | 測定された変換から | 収益性の持続性とLTV |
セルには、測定値を含むものでなく、一般的な目標を含まないようにしてください。ベンチマークはカテゴリとモデルによって異なります。 UXCamの留意期間ベンチマークの議論 一般的に使用される1日目、7日目、30日目ウィンドウを強調しながら、ライフサイクル分析における1か月目と3か月目の流れ落ちの役割を説明しています。
プライバシー制約により、このより広い定義はますます重要になります。Attributionが不完全な場合、チームは、インストール元を行動の完全な説明として扱うのではなく、より多く第一パーティーイベント、ライフサイクルマイルストーン、収益レコードに頼るべきです。最も役立つコホート定義は、改善しようとしている製品価値に最も近いものです。
インストールの留意期間を、有効化の留意期間と収益の留意期間とともに報告してください。インストールの留意期間が平らなままである場合、オンボーディングが主なレバーである可能性があります。有効化が強固なままである場合、収益の留意期間が弱まる場合、価格、ペイウォールのタイミング、プランのフィット、請求経験に注目する必要があります。その区別により、獲得、製品、収益化チームは、それぞれが影響を与えるライフサイクルの一部に対して責任を負うことができます。
CapgoはCapacitorJSとElectronアプリ向けにライブアップデートを提供し、チームがターゲット化されたJavaScript、CSS、構成、資産の変更を提供し、採用、失敗、ロールバック信号、バージョン拡散を追跡できるようにします。ロールアウト信号を使用して、よりきれいなバージョンとチャンネルコホートを作成し、次に Capgo そのデプロイワークフローがリリース測定プロセスに適合するかどうかを評価するために
