モバイルアナリティクスにおけるコホート分析：定義、指標、実施手順

コホート分析とは？

コホート分析は、最初のターゲットイベント（アプリのインストールや登録など）を実行した時期に基づいてユーザーをグループ（コホート）に分割する分析手法です。DAUやMAUのような集計指標とは異なり、コホートは同じグループの行動を数週間から数ヶ月にわたって追跡し、リテンションとチャーンの傾向を明らかにします。

この手法の主な利点は、古いユーザーが新しいユーザーの問題を隠してしまう成長の幻想を取り除くことです。Amplitude Blog（2024）によると、コホート分析を採用した企業は、最初の90日間でユーザーチャーンを20～30％削減しています。

コホート分析は、UAキャンペーンの効果測定、アプリの異なるバージョン間の行動比較、そしてユーザー獲得における投資収益率の計算に活用してください。

コホート分析の主要指標

リテンション率（Retention Rate）

リテンション率は、インストールからN日後にアプリに戻ってきたコホートのユーザー割合です。これはプロダクト品質の主要指標です。ユーザーが戻ってこない場合、問題はオンボーディング、価値提案、またはアプリの安定性にあります。Statista（2025）によると、モバイルアプリの平均Day-1リテンションは25～30％、Day-7は10～15％、Day-30は5～7％です。

自社のコホートのリテンションをカテゴリのベンチマークと比較し、どのプロダクト変更がリターンを増加させたかを分析してください。

LTV — ライフタイムバリュー

LTV（Lifetime Value）は、観測期間におけるコホートの全ユーザーからの総収益です。この指標は、広告キャンペーンのROI評価やUA予算の拡大判断に重要です。Adjust Benchmarks（2024）のレポートによると、ゲームにおけるユーザーあたりの中央値LTVは3.50ドル、eコマースでは1.80ドル、ユーティリティでは0.40ドルです。

Day-30、Day-90、Day-180でコホートLTVを計算し、獲得したユーザーの長期的な価値を理解してください。

チャーン率（Churn Rate）

チャーン率は、アプリの使用をやめたコホートのユーザー割合です。初期の高いチャーンは、オンボーディングの問題や期待との不一致を示しています。Localytics（2024）によると、25％のユーザーが初回起動後にアプリを離脱し、90日目までに残るのは5％未満です。

チャーン率を毎週監視してください。コホートで5％の増加があった場合は、アンケートやセッション録画を通じてチャーンの原因を即座に分析する必要があります。

期間別コホートの種類

日次コホート

日次コホートは、同じ日にアプリをインストールしたユーザーです。最も詳細なレベルで、異常を検出できます。特定の日付でのリテンションの急激な低下は、技術的な障害や問題のあるクリエイティブキャンペーンを示している可能性があります。日次コホートは、毎日変更が行われる場合の運用監視やA/Bテストに使用されます。

週次コホート

週次コホートは、同じ暦週にアプリをインストールしたユーザーです。より安定したデータを提供し、日々の変動を平滑化します。定期的なレポートや広告チャネルのパフォーマンス比較に適しています。週次のステップは、週末にコンバージョンが異なる可能性がある曜日効果を中和します。

月次コホート

月次コホートは、同じ月にアプリをインストールしたユーザーです。長期的なトレンド、季節性、6〜12ヶ月の範囲でのLTV計算に最適です。プロダクト開発に関する戦略的決定のために、プロダクトマネジメントレベルで使用されます。

コホート分析の実施方法

コホート分析は、データ収集、コホートへのグループ化、期間ごとの指標計算、可視化の4つの段階で構成されます。最初に、ターゲットイベントを定義します。通常はインストール、サインアップ、または初回購入です。同じ期間にそれを実行したすべてのユーザーが同じコホートに属します。

次に、時間間隔（日、週、月）を設定します。その後の各期間（Day-1、Day-2、Day-3...）について、戻ってきたユーザーの割合を計算します。結果はコホートテーブルにまとめられ、各行がコホート、各列が期間、各セルが指標値となります。

3番目に、データを調整します。100ユーザー未満のコホートを除外し、季節性を考慮します。Mixpanel（2024）によると、50ユーザー未満のコホートは、誤差範囲が20％を超える統計的に意味のない結果をもたらします。4番目に、データをコホートテーブルまたはヒートマップとして可視化します。行（コホート）と列（期間）により、ステークホルダーにとってリテンションの傾向が明確になります。

正しい解釈のために、常に同じサイズのコホートを比較してください。50,000ユーザーのコホートと500ユーザーのコホートを比較することは許されません。指標は、絶対数ではなくコホートの初期サイズの割合として正規化してください。これにより、サイズの異なるグループを比較できます。また、新規性効果も考慮してください。大規模なマーケティングイベント後にアプリをインストールしたユーザーは、オーガニックインストールとは異なる行動をとる可能性があります。

コホート分析ツール

コホート分析ツールは、分析プラットフォームに組み込まれているものと、カスタムSQLソリューションに分類されます。AmplitudeとMixpanelは、クエリを記述する必要なく、自動的にRetentionとLTVを計算する既製のコホートレポートを提供します。Firebase Analyticsは、インストール日別の基本コホートを日、週、月単位で提供します。

カスタムコホートには、BigQueryやRedshiftでSQLクエリを使用します。これにより、指標と期間を完全に制御できます。Amplitude（2024）によると、カスタムSQLコホートを使用するチームは、標準レポートよりも35％多くの行動インサイトを発見します。BIツール（Tableau、Looker、Google Data Studio）を使用すると、定期的な監視のためのインタラクティブなコホートダッシュボードを構築できます。

ツールの選択は、チームの分析成熟度によって異なります。初期段階では、Firebase AnalyticsまたはAmplitudeの組み込みコホートで十分です。これらはコホート分析の80％のニーズをカバーします。チームが成長するにつれて、BigQueryのSQLコホートに移行してください。これにより、非標準の指標（インストール日ではなく初回購入日によるコホートなど）を定義する柔軟性が得られ、MLを使用した予測LTVモデルの構築が可能になります。可視化には、追加費用なしでBigQueryに直接接続するLooker Studioを使用してください。

SQLによるコホート分析の例

日次コホートを自分で計算するには、インストール日でセッションをグループ化するSQLクエリを使用します。以下は、各コホート内の日ごとのアクティブユーザー数を返すBigQuery用のクエリです。

SELECT
  install_date AS cohort_date,
  DATE_DIFF(session_date, install_date, DAY) AS day_number,
  COUNT(DISTINCT user_id) AS active_users
FROM user_sessions
WHERE install_date BETWEEN '2025-01-01' AND '2025-03-31'
GROUP BY cohort_date, day_number
ORDER BY cohort_date, day_number;

クエリを実行した後、Google SheetsまたはBIツールで集計テーブルを作成します。各行がコホート日、各列が日数（Day-1、Day-2など）です。アクティブユーザーの割合は、Day-0（インストール日）のactive_usersに対するN日目のactive_usersの比率として計算されます。

コホート分析のよくある間違い

1つ目の間違いは、小さなコホートで作業することです。コホートに100人未満のユーザーが含まれている場合、1人の離脱や復帰が割合を大きく歪めます。信頼できる結論を得るための最小コホートサイズは500ユーザーです。

2つ目の間違いは、季節性を無視することです。新年の前にアプリをインストールしたコホートは、1月中旬のコホートとは異なる行動を示します。常に同じ季節のコホートを比較するか、データの正規化を使用してください。Mixpanel（2024）によると、Day-1リテンションの季節変動は30～40％に達する可能性があります。

3つ目の間違いは、コホート分析と横断分析を混同することです。コホート分析は、ある時点での異なるグループの比較ではなく、時間の経過に伴う1つのグループを追跡します。同じコホートで繰り返し測定を行ってください。そうしないと、リテンションの成長について誤った結論を得ることになります。