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