コホート分析ツール比較｜GA4・Amplitude・Mixpanelの上限と選び方

コホート分析ツールを比べるとき、機能一覧を並べてもほとんど差は出ません。どのツールもリテンション表は描けるからです。実際に分析の可否を決めるのは、表示できるコホートの本数、遡れる期間、サンプリングが始まるイベント数といった数値上限のほうです。ここではGA4・Amplitude・Mixpanel・Adobe Analyticsの公式仕様から上限を突き合わせ、どの規模でどれを選ぶか、そしてどこからBigQueryへ移すべきかを整理します。

まとめ

ログインを持たないWebサイトで、14か月より前まで遡る必要がなければGA4の探索レポートで足ります。無料で、コホートデータ探索は最大60コホートまで表示できます。ただしGA4の探索はデータ保持の設定に縛られ、コホート分析が使うユーザー単位データは標準プロパティでもアナリティクス360でも14か月が上限です。加えて1回のクエリで扱うイベントが1,000万件を超えるとサンプリングが発生します。

プロダクト側でユーザーIDを持ち、機能単位の行動でコホートを切りたいならAmplitudeかMixpanelです。両者とも無料枠があり、Amplitudeは月200万イベント、Mixpanelは月100万イベントまで無料で使えます。課金の単位はユーザー数ではなくイベント数なので、費用はイベント設計の粒度で決まります。

14か月を超える長期のリテンションを見る、あるいはコホートの定義を自社の業務ロジックで組みたい場合、GA4を使い続ける前提での逃げ道はBigQueryエクスポートだけです。エクスポート先のテーブルには保持期間の上限が及びません。ただし標準プロパティの日次バッチエクスポートには1日100万イベントという別の上限があり、ここを超える規模ではストリーミングエクスポートか360の検討が必要になります。以降、この分岐を数値の根拠つきで見ていきます。

リテンション表の読み方とコホート分析の守備範囲

コホート分析は、同じ時期に同じ条件で発生したユーザーの集団（コホート）を、その後の時間軸で追いかける手法です。「6月に初回訪問したユーザーのうち、7月も戻ってきたのは何％か」を集団ごとに並べます。全体の継続率を1本の折れ線で見ると、新規流入の増減に紛れて定着の悪化が見えません。コホートに割ると、獲得月ごとに定着の質が違うことがそのまま表に出ます。

リテンション表が三角形になる理由と読む順番

コホート分析の出力は、行が獲得時期、列が経過期間の表になります。古いコホートほど経過期間の列が埋まり、直近のコホートは1列目しかない。だから表は右下が欠けた三角形になります。GA4のコホートデータ探索は表示できるコホートが60件までなので、日次の粒度を選ぶと約2か月で行が打ち止めになり、三角形の下半分しか見られません。四半期をまたいで比べるなら週次に落とす必要があります。

読む順番は2つあり、混ぜると読み違えます。横に読むと、ひとつのコホートが時間とともにどう減っていくかがわかります。リテンション曲線は初期の減衰が大きく、そこから先は緩やかになって一定の水準に落ち着く形をとります。この落ち着く水準がプロダクトの素の定着力です。縦に読むと、経過1期目という同じ条件で獲得月どうしを比べられます。縦方向の数字が月を追って下がっているなら、獲得チャネルの質が落ちているか、オンボーディングが劣化しています。施策の効果を見るのは縦です。

コホート分析とコーホート分析が指す対象の違い

検索するとき紛らわしいのが表記の揺れです。日本語では「コホート分析」と「コーホート分析」がどちらも使われますが、実務では指す対象がずれています。「コーホート分析」と書かれる場合、人口統計学に由来する世代効果・期間効果・年齢効果の3要素を分離する分析を指すことが多く、市場調査やリサーチ会社の用語集がこの意味で使っています。この3効果は「年齢＝調査年－出生年」という完全な線形従属の関係にあるため、線形成分は追加の仮定を置かないと一意に定まりません。ただし識別できないのは線形成分だけで、各効果の曲率（非線形成分）は仮定なしに推定できます。

一方、Webやアプリの文脈で「コホート分析」と言えば、本記事が扱うリテンション計測のことです。世代効果の話を探している場合はコーホート分析とは？基本概念とその重要性を解説を参照してください。以降はリテンション計測の意味で用語を統一します。

コホート分析ツールの上限比較

各社の公式ドキュメントと料金ページから、コホート分析の可否を実際に左右する数値だけを抜き出しました。金額と無料枠は改定が入るため、導入判断の直前には公式ページで最新を確認してください。

表で差がつくのは右の2列です。左の「無料枠」だけを見て選ぶと、遡れる期間の制約に後から気づいて作り直すことになります。とくにGA4 360は保持期間が伸びる印象で語られがちですが、コホート分析が使うユーザー単位データに限れば標準と同じ14か月です。

GA4コホートデータ探索の3つの上限

GA4の探索レポートにある「コホートデータ探索」は無料で使えますが、公式ヘルプに3つの上限が明記されています。第一に、表示されるコホートは最大60件までです。第二に、内訳ディメンションを適用したときに表示されるのは、そのディメンションの上位15個の値までです。チャネル別に定着を割るなら、15を超える分はまとめて扱われます。

第三が最も効きます。GA4のヘルプは「コホートはユーザーのデバイスデータのみに基づいています。User-ID はコホートの決定では考慮されません」と記載しています。つまりスマートフォンで登録したユーザーが翌週PCで戻ってきても、GA4のコホート表では同一ユーザーとして復帰扱いされません。ログインを伴うサービスほどリテンションが実態より低く出るということです。この過小評価はUser-IDを設定していても消えません。

コホートの粒度は毎日（午前0時から翌日午前0時）、毎週（日曜日から土曜日）、毎月（月初から月末）から選びます。コホートへの登録条件は初回接触・すべてのイベント・すべてのトランザクション・すべてのコンバージョン・その他（特定のイベント）から選択でき、リピートの条件も同様に指定します。探索レポート全体の作り方はGA4で使える探索レポートテンプレートと分析手法の種類を紹介にまとめています。

Amplitude・Mixpanelのイベント数課金と無料枠

プロダクト分析ツールの課金体系は、かつての月間トラッキングユーザー数（MTU）からイベント数ベースへ移っています。Amplitudeの料金ページは無料プランを「月200万イベント」、Plusを「最初の月200万イベントは無料」で最大7,000万イベントまでとしており、Plusには保存できる行動コホート20件が含まれます。Mixpanelは無料プランを月100万イベント上限とし、Growthでは100万イベントを超えた分に1,000イベントあたり0.28ドルが課金されます（大量利用ではボリュームディスカウントの設定があります）。

課金がイベント数で決まるということは、費用を押し上げるのはユーザー数ではなく計測イベントの粒度だという意味になります。画面スクロールやホバーまで全部イベントにしている状態で導入すると、ユーザー数が伸びていないのに請求だけが伸びます。導入前にイベント設計を絞り込むほうが、プラン交渉より効きます。

Adobe Analyticsコホート表の3タイプと上限

Adobe AnalyticsのAnalysis Workspaceにあるコホート表は、リテンションのほかにチャーン（リテンション表の逆で、時間とともにコホートから離脱したユーザーを表示）と待ち時間テーブル（インクルージョンイベントの発生前後の経過時間を測定）に対応しています。「コホートレポート」を探している場合、離脱側を見たいのか復帰までの時間を見たいのかで選ぶ表が変わります。

制約としては、指標は最大3個、フィルターは最大10個までです。GA4との実質的な差は、時間軸ではなく都市・チャネル・製品といった選択したディメンションでコホートを作れる「カスタムディメンションコホート」の有無にあります。前の列に基づいて計算する周期計算のほうは、GA4にも「ローリング」という名前で用意されているので差になりません。

表計算ソフト・BIツール・アプリ計測ツールを選ぶ条件

専用ツールを入れる前に済む場合もあります。会員数が数百人規模で、購入日や登録日がCSVで出せるなら、ExcelやGoogleスプレッドシートのピボットテーブルで十分にリテンション表が組めます。獲得月を行、経過月を列に置いて件数を数え、1列目で割るだけです。専用ツールが要るのは、イベントの発生量が手作業の集計を超えたときか、コホートの条件をアプリの行動で切りたいときです。

Looker StudioやTableauといったBIツールは、コホートを計算する道具ではなく、計算済みの表を配って共有する道具として位置づけるのが実務的です。集計そのものはBigQueryのSQL側で確定させ、BIには結果を表示させます。この分担にしておくと、定義を変えたときの修正箇所が1か所で済みます。構成例はGA4、BigQuery、Looker Studioの連携方法と活用事例で扱っています。

ネイティブアプリが主戦場なら、ストアの計測制約に対応したアプリ計測ツール（Adjust、AppsFlyer、Reproなど）が候補に入ります。Web解析ツールではインストール経路とアプリ内行動を同じユーザーとして接続できず、広告経由コホートの定着を追えないためです。逆にWebのみのサービスでこれらを入れる理由はありません。

GA4コホートデータ探索の設定手順

GA4での作成は探索メニューから始めます。実際の設定は次の順で進みます。

1. 「探索」を開き、テンプレートギャラリーから「コホートデータ探索」を選ぶ
2. 「コホートへの登録条件」で集団の定義を決める（新規獲得の定着を見るなら「初回接触（ユーザー獲得日）」）
3. 「リピートの条件」で「戻ってきた」と判定する行動を決める（購入を見るなら「すべてのトランザクション」）
4. 「コホートの粒度」を毎日・毎週・毎月から選ぶ
5. 「計算」を標準・ローリング・累計から選ぶ
6. 必要なら「内訳」にチャネルやデバイスカテゴリを入れる（表示は上位15値まで）

継続率の数字が最も変わるのは5番目の「計算」です。標準は各セルがその期間単独で条件を満たしたユーザーだけを数え、ローリングはその期間と全先行期間の条件を満たしたユーザー、累計は探索期間内のいずれかの期間で条件を満たしたユーザーを数えます。同じデータでも標準とローリングでは数字が別物になるため、社内で表を共有するときはどれを使ったかを必ず添えてください。

もうひとつつまずきやすいのが2番目と3番目の組み合わせです。登録条件を「すべてのイベント」にすると、期間中に何らかのイベントを起こした全ユーザーが毎期コホートに入るため、新規獲得の定着ではなく全体の再訪率に近い数字になります。獲得施策の評価が目的なら登録条件は「初回接触」に固定し、リピート条件のほうを施策に合わせて動かします。GA4そのものの導入や設定方針はGA4とは？仕組みとUAとの違い・導入と運用体制の判断まで解説で扱っています。

BigQuery SQLでのリテンション率算出

GA4の14か月制限を外し、コホートの定義を自社の業務ロジックに合わせたい場合は、BigQueryエクスポートの生データにSQLを書きます。エクスポートされたテーブルは探索レポートの保持期間の対象外で、データセットのデフォルトのテーブル有効期限を設定していなければ、テーブルを消さない限りデータは残ります。

ここで先に確認すべき上限があります。公式ヘルプは「標準の GA4 プロパティでは、BigQuery Export で 1 日（バッチ）にエクスポートできるイベント数の上限は 100 万件です」と定めており、「プロパティがエクスポートの上限を継続的に超えると、BigQuery の日次エクスポートは一時停止され、それ以前の数日間のエクスポートは再処理されません」と続きます。つまりサンプリングを避けようとしてBigQueryへ逃げた規模のサイトほど、バッチエクスポートが止まるリスクを抱えます。1日100万イベントを超える標準プロパティは、上限のないストリーミングエクスポートへ切り替えるか、360の契約を検討してください。

GA4のイベントエクスポートから月次コホートの継続率を出す最小構成が次のクエリです。user_first_touch_timestamp で獲得月を確定し、各イベント月との差を経過月数として集計します。

WITH first_touch AS (
  SELECT
    user_pseudo_id,
    DATE_TRUNC(
      DATE(TIMESTAMP_MICROS(MIN(user_first_touch_timestamp)), 'Asia/Tokyo'),
      MONTH) AS cohort_month
  FROM `myproject.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20250101' AND '20260630'
    AND user_first_touch_timestamp IS NOT NULL
  GROUP BY user_pseudo_id
),
activity AS (
  SELECT DISTINCT
    user_pseudo_id,
    DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), MONTH) AS active_month
  FROM `myproject.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20250101' AND '20260630'
),
sized AS (
  SELECT
    f.cohort_month,
    DATE_DIFF(a.active_month, f.cohort_month, MONTH) AS month_index,
    COUNT(DISTINCT a.user_pseudo_id) AS users
  FROM activity AS a
  JOIN first_touch AS f USING (user_pseudo_id)
  WHERE f.cohort_month >= DATE '2025-01-01'
  GROUP BY cohort_month, month_index
)
SELECT
  s.cohort_month,
  s.month_index,
  s.users,
  ROUND(SAFE_DIVIDE(s.users, b.users) * 100, 1) AS retention_pct
FROM sized AS s
JOIN sized AS b
  ON s.cohort_month = b.cohort_month AND b.month_index = 0
ORDER BY s.cohort_month, s.month_index

このクエリで最も事故が多いのがタイムゾーンです。公式スキーマでは event_date が「アプリの登録タイムゾーンにおける日付」であるのに対し、user_first_touch_timestamp はUTCのマイクロ秒です。DATE() にタイムゾーンを渡さずに書くと、日本時間の毎月1日0時から9時に初回接触したユーザーが全員ひとつ前の月のコホートに落ち、前月の継続率が過大に、当月の分母が過小に出ます。上のクエリで 'Asia/Tokyo' を明示しているのはこのためで、プロパティのレポート用タイムゾーンに合わせて書き換えてください。

残りの注意点は3つです。獲得月を別のCTEに切り出して MIN() で確定させているのは、user_first_touch_timestamp が同一ユーザーでも異なる値で送られることがあるためです。これをイベント行ごとに評価すると、同じ人が2つのコホートに二重計上されます。次に、_TABLE_SUFFIX の期間より前に獲得されたユーザーは経過0か月目の行を持たず、最後の内部結合で行ごと消えます。気づかないうちに古いコホートが欠けるのを避けるため、cohort_month の下限を明示して意図的に除外しています。最後に、user_pseudo_id はCookieやアプリインスタンスに紐づく識別子なので、GA4の画面と同じくデバイス単位の集計になります。会員IDを持つサービスでは COALESCE(user_id, user_pseudo_id) に寄せると実態に近づきますが、ログイン前の匿名イベントは user_id がNULLなので、同一人物を完全につなぐには匿名IDと会員IDの対応表を別途作る必要があります。

スキャン量を抑えるには _TABLE_SUFFIX での期間指定を必ず入れます。ワイルドカードテーブルを条件なしで参照すると全期間をスキャンし、そのまま従量課金に乗ります。

ツール選定で判断を誤らせる制約

ここまでの上限は、単なるスペック差ではなく分析結果そのものを歪めます。選定前に確認しておくべき点を挙げます。

デバイス単位集計によるリテンションの過小評価

GA4のコホートデータ探索がUser-IDを見ないことは前述しましたが、影響の大きさは業態で変わります。単一デバイスで完結するモバイルアプリなら誤差は小さい。逆に、スマホで会員登録してPCで購入するようなECやBtoBサービスでは、同一人物が別コホートの別ユーザーとして二重にカウントされます。この場合、GA4の数字は「デバイスの定着率」であって「ユーザーの定着率」ではありません。会員IDを持っているのにGA4画面の数字をそのままKPIに据えるのは避けるべきです。SQLかプロダクト分析ツール側で会員IDに寄せてください。

1,000万イベント超で発生するサンプリング

GA4のサンプリングは、レポートやデータ探索で使われたイベント数がプロパティの割り当て上限を超えると発生します。上限は標準プロパティでイベント1,000万件、アナリティクス360では最大10億件（初期デフォルトはクエリあたり1億件）です。ここで見落としやすいのは、この1,000万件が月間ではなく1回のクエリ単位だという点です。コホート分析は長期間を横断するため、月70万イベント程度のサイトでも14か月分を1つの探索で読めば約1,000万件に届きます。標準レポートでは問題なかったサイトで探索だけサンプリングされるのはこのためです。該当する規模なら、GA4画面の数字は概況把握に留め、意思決定に使う数字はBigQuery側で出す運用に切り替えてください。

コホート分析を導入すべきでない3つの条件

コホート分析が向かない場面もはっきりしています。まず、1コホートあたりの人数が数十人規模のとき。n=50なら1人の離脱で2.0ポイント動くため、表の色の濃淡が単なるノイズになります。この状態で週次コホートに割るのは意味がありません。粒度を月次に上げるか、コホート分析自体を後回しにしてサンプルが貯まるのを待つべきです。

次に、購入頻度が年単位のビジネス。不動産や自動車のように再購入までの間隔が長い商材で月次リテンションを追っても、2列目以降がほぼゼロの表が並ぶだけです。この場合はコホート表ではなく、初回購入からの経過期間を軸にした待ち時間の分析や、LTVの計算方法｜基本式からSaaS・サブスク（解約率）の算出までで扱う顧客生涯価値の推計のほうが判断材料になります。

最後に、イベント設計が固まっていない段階での導入。コホートの登録条件は計測イベントに依存するため、イベント定義を後から変えるとコホートの定義も遡って変わります。過去との比較ができない表を作り続けることになるので、計測要件を確定させてからツールを入れてください。

よくある質問

コホート分析ツールは無料のもので足りますか？

14か月を超えて遡る必要がなく、1回の探索で扱うイベントが1,000万件に届かない規模なら、GA4のコホートデータ探索で足ります。プロダクトの機能単位でコホートを切りたい場合は、Amplitudeの無料プラン（月200万イベント）やMixpanelの無料プラン（月100万イベント上限）が候補になります。無料枠の値は改定されるため、契約前に各社の料金ページで確認してください。

コホートレポートとコホート分析は違うものですか？

指しているものは同じで、呼び方がツール由来で分かれています。Adobe AnalyticsのAnalysis Workspaceでは「コホート表」、GA4では「コホートデータ探索」という名称です。Adobeのコホート表はリテンション・チャーン・待ち時間の3タイプを切り替えられるので、離脱側を見たい場合はチャーンを選びます。

GA4のコホート分析は何か月まで遡れますか？

標準プロパティ・アナリティクス360とも14か月です。GA4のデータ保持設定のうち、26か月・38か月・50か月という360専用の長期オプションはイベントデータに対するもので、ユーザー単位データは標準・360を問わず2か月または14か月の2択です。コホート分析はユーザー単位の集計なので、360を契約しても遡れる期間は伸びません。またこの保持設定が影響するのはデータ探索とファネルのレポートのみで、標準の集計レポートには影響しません。14か月を超える履歴が必要ならBigQueryエクスポートを設定してください。

コホートの粒度は日次と週次のどちらを選ぶべきですか？

1コホートあたりの人数で決めます。日次コホートは反応が速く見える反面、GA4では最大60コホートまでしか表示されないため約2か月分で打ち止めになります。週次なら同じ60件で1年強をカバーできます。1コホートが数十人しかいない規模なら月次まで上げないと数字がぶれます。

コホート分析とコーホート分析は同じ意味ですか？

文脈で異なります。Webやアプリの解析で言うコホート分析はリテンション計測を指します。市場調査やリサーチの文脈で「コーホート分析」と書かれる場合は、世代効果・期間効果・年齢効果を分離する人口統計由来の分析を指すことが多く、扱う課題が別物です。後者についてはコーホート分析とは？基本概念とその重要性を解説を参照してください。

関連記事

• GA4で使える探索レポートテンプレートと分析手法の種類を紹介
• GA4、BigQuery、Looker Studioの連携方法と活用事例
• LTVの計算方法｜基本式からSaaS・サブスク（解約率）の算出まで
• GA4とは？仕組みとUAとの違い・導入と運用体制の判断まで解説
• コーホート分析とは？基本概念とその重要性を解説