月間アクティブユーザー数を水増しせずにカウントする方法
月間アクティブユーザー数を計算するには、30日間のウィンドウ内で、あらかじめ定義された「アクティブ」イベントを少なくとも1回記録した、重複のないユーザー識別子の数を数えます。そのウィンドウは、固定された暦月（例：4月1日〜30日）または、ローリング30日間（例：今日から過去30日間）のいずれかです。核となる仕組みは重複排除です。50回訪れるユーザー1人でも、MAUは1人です。重複排除のステップをスキップすると、ユーザーではなくセッションを測定していることになります。
私が初めてモバイルゲームのダッシュボードを構築したとき、このことを痛感しました。生のイベントテーブルには、1か月で210万件のアクティビティ行がありましたが、最初はそれをMAUとして報告しました。実際の重複排除後の数は34万でした。この6倍のギャップは、ステークホルダー会議で私を恥ずかしい思いにさせましたが、何よりも先にCOUNT(DISTINCT user_id)を書く習慣を身につけさせてくれました。
「アクティブ」の定義：ほとんどのチームが急いでしまうステップ
アクティブユーザー数を計算する前に、あなたの製品にとって「アクティブ」が何を意味するかを定義する必要があります。B2Cソーシャルアプリでは、アプリを開くことが該当するかもしれません。B2B分析ツールでは、クエリを実行したりレポートを作成したりするユーザーだけをカウントすべきです。MAUについて誰も教えてくれないことは、この指標はこの定義と同じだけ正直であるということです。
フィンテッククライアントのダッシュボードを監査したとき、彼らはあらゆるページビューをアクティブとしてカウントしていました。それにはボットや、一晩中開いたままの忘れられたタブも含まれていました。「アクティブ」を完了した資金移動またはMFAを使用したログインに制限した後、彼らのMAUは一夜で22%減少しました。それはユーザーの喪失ではなく、ノイズの修正でした。
実用的な計算のために、各製品サーフェスを最小限の価値あるアクションにマッピングします。イベントスキーマでテーブルまたは列挙型を使用します。この明確さは、複数の機能にわたるアクティブユーザーを計算する方法という一般的な質問にも役立ちます。アクションごとにユーザーを合計し、その後ユーザーレベルで再度重複排除します。
暦月 vs ローリング30日間のMAU：トレードオフ
ほとんどの競合他社は「1か月のユニークユーザーを数える」と言及しますが、根本的に異なる2つのウィンドウについては触れません。暦月のMAUは1日にリセットされ、ローリング30日間のMAUは毎日スライドします。それらは異なるビジネス上の質問に答えます。
固定された暦ウィンドウ
暦月のMAUは、財務および取締役会への報告と整合します。安定しており、月ごとに比較可能で、説明が簡単です。欠点は、3月31日と4月1日にアクティブだったユーザーが両方の月でカウントされ、解約を隠す重複が生じることです。私は、成長チームが「連続成長」を祝っているのを見たことがありますが、それは単なる暦の境界によるアーティファクトでした。
ローリング30日間ウィンドウ
ローリングMAUは季節性を平滑化し、現在のエンゲージメントを反映します。運用アラートに適しています。しかし、同じ期間の暦月MAUよりも5〜15%高くなることがあります。これはコホートが重複するためです。ほとんどの人は、ローリングウィンドウが月ごとの差分を小さくし、主要な数値だけを見ているとゆっくりとした漏れを隠す可能性があることに気づいていません。
ここに、私がクライアントと使用する簡単な決定マトリックスを示します：
- 暦月MAUを選択：役員に報告する場合、月レベルの比較可能性が必要な場合、または指標を請求サイクルに結び付ける場合。
- ローリングMAUを選択：成長実験を実行する場合、毎週のリテンションを監視する場合、または最近のアクティビティに基づいてライフサイクルキャンペーンをトリガーする必要がある場合。
- 両方を追跡する：分析帯域幅がある場合。それらの間のギャップ自体が解約シグナルです。
ステップバイステップ：生のイベントデータからMAUを計算する
イベントをウェアハウス（Snowflake、BigQuery、Postgres）に保存している場合、MAUを直接計算できます。以下は、重複排除を備えたイベントレベルのMAUのためのコピーペースト可能なSQLクエリです。これは、user_id、event_time、event_nameという列を持つテーブルeventsを前提としています。
暦月MAUクエリ
特定の月の重複のないアクティブユーザーを数えるにはこれを使用します：
SELECT
DATE_TRUNC(‘month’, event_time) AS month,
COUNT(DISTINCT user_id) AS mau
FROM events
WHERE event_name IN (‘app_open’,’complete_profile’,’purchase’)
AND event_time >= ‘2024-01-01’
AND event_time < ‘2024-02-01’
GROUP BY 1;
イベントリストを、自分で定義したアクティブアクションに置き換えます。COUNT(DISTINCT user_id)は譲れない行です。これがないと、ユーザーではなくイベントを測定していることになります。
ローリング30日間MAUクエリ
今日で終わるローリングウィンドウの場合：
SELECT
COUNT(DISTINCT user_id) AS rolling_mau
FROM events
WHERE event_name IN (‘app_open’,’complete_profile’,’purchase’)
AND event_time >= DATEADD(day, -30, CURRENT_DATE)
AND event_time < CURRENT_DATE;
BigQueryでは、DATEADDをDATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)に置き換えます。ロジックは同じです。ローリングMAUの日次シリーズが必要な場合は、ウィンドウ関数または日付スパイン結合でラップします。
小規模データセットのためのスプレッドシート方式
ユーザーIDとタイムスタンプのリストをCSVにエクスポートする場合、ExcelまたはGoogle Sheetsを使用します：ユーザーIDを行とするピボットテーブルを作成し、日付範囲とアクティブイベントにフィルタリングし、=COUNTUNIQUE(A2:A10000)でユニークIDを数えます。これは10万行を超えると扱いにくくなりますが、初期段階の検証には機能します。それより大きい場合は、当社の月間アクティブユーザー（MAU）計算ツールが重複排除を自動的に処理します。
クロスデバイスと匿名ユーザーの重複排除
MAU計算における最大の隠れたエラーは、デバイスを切り替えたために同じ人間を2回カウントすることです。B2Cアプリでは、iPhoneとウェブのユーザーは1つのMAUであり、2つではありません。安定したアイデンティティグラフが必要です：ログイン済みのuser_idまたは確率的マッチングのいずれかです。
あるB2B展開では、SSOアカウントと匿名トライアルセッションがありました。匿名セッションを一時的なCookieキーを介して最終的に変換されたアカウントにステッチするまで、MAUは18%過大評価されていました。修正は、ログイン後にdevice_idをaccount_idにマッピングする毎週のアイデンティティ解決ジョブでした。
プライバシーに配慮した重複排除では、同意の取り消し後にデバイスIDだけに依存しないようにしてください。詳細は以下で説明します。
信頼できるMAUのためのイベントスキーマ設計
月間アクティブユーザー数をきれいに計算できるかどうかは、計装から始まります。私は最低3つの列を主張します：user_id（認証済みの場合は決してnullにしない）、anonymous_id（ログイン前用）、event_name（列挙型）。ウェアハウスがこれらを混在させると、苦労することになります。
あるプロジェクトではフリーテキストのイベントラベルを使用していました。6か月後、「purchase」と「purchased」が別々にカウントされ、コホートが分割されました。管理された語彙を使用してください。これは地味ですが、効果の高い修正であり、ほとんどの記事が省略しています。
業界ベンチマーク：月間アクティブユーザー数の平均はいくらか？
「月間アクティブユーザー数の平均はいくらか？」という質問には、規模がビジネスモデルによって異なるため、単一の答えはありません。個人開発者のアプリは500 MAUかもしれませんが、公開ソーシャルネットワークは数十億を報告します。実用的な文脈を提供するために、私のコンサルティング業務と公開情報から、セクター別の典型的なMAU範囲をまとめました。
SEC提出書類によると、MetaのFacebookプロパティは2023年後期に約30.7億の月間アクティブユーザーを報告しており、消費者向けソーシャルの上限を示しています。対照的に、中堅B2B SaaSは通常5,000〜50,000 MAUです。以下の表は、私の作業用ベンチマークを示しています：
| 業界 | 一般的なMAU範囲（確立された製品） | 備考 |
|---|---|---|
| 消費者向けソーシャル | 100万 – 30億以上 | ネットワーク効果が巨大な規模を生む；平均値は大手企業によって歪められる |
| B2B SaaS（ミッドマーケット） | 5,000 – 5万 | シート単位の製品；MAUは総アカウント数より低いことが多い |
| Eコマースマーケットプレイス | 1万 – 1億 | 季節的なスパイク（第4四半期）でMAUが2倍になることがある |
| モバイルゲーム（ミッドコア） | 5万 – 2,000万 | 解約率が高い；ローリングMAUが推奨される |
| フィンテックアプリ | 2万 – 5億 | 規制対象；アクティブ＝検証済みのアクション |
これらは方向性を示すものであり、確定値ではありません。特定の業界の平均MAUは、資金調達段階、地理的要因、非アクティブなログインセッションをカウントするかどうかによって異なります。常に、まず自社のコホートリテンションとベンチマークを取ってください。
B2B vs B2C：計算を変えるニュアンス
B2Cでは、MAUはしばしば到達可能な総オーディエンスに近似します。B2Bでは、「アカウント」に200シートあっても、1か月にアクティブなユーザーは30人だけかもしれません。ユーザーレベルでアクティブユーザーを計算することが重要です。アカウントレベルのアクティビティを報告すると、低い採用率が隠れてしまいます。
かつて私は、MAUの90%がアカウントの10%から来ているDevOpsツールを担当しました。単純なMAUは12,000で健全に見えましたが、その集中度は解約リスクが高いことを意味していました。誤った安心感を避けるために、MAUをアカウント規模でセグメント化してください。
また、B2Bのアクティビティは断続的です。ユーザーは毎日ではなく、週次でレポートを見るためにログインします。30日間ではなく、7日間のローリングウィンドウがより診断的かもしれません。消費者向けのテンプレートをエンタープライズデータに押し付けないでください。
プライバシー、同意、そしてMAU精度の静かな侵食
AppleのApp Tracking Transparencyフレームワークが展開されて以来、プライバシーに関するドキュメントに記載されているように、デバイスレベルの識別子はクロスアプリの重複排除には信頼できなくなりました。GDPRおよび類似の法律は、GDPR.euに従い、同意なしに個人データを記録することを制限しています。
実際的な影響：ユーザーが離れたからではなく、戻ってくる匿名訪問者を認識する能力を失ったために、MAUが静かに減少する可能性があります。ほとんどのチームは製品の衰退を責めてパニックになります。修正策は、ファーストパーティのログイン戦略と、認証済みアクションのみをカウントする同意対応のイベントスキーマです。
測定計画で透明性を確保してください。クッキーIDを法的に処理できない場合は、コンプライアンス違反のリスクを冒すのではなく、MAUから除外してください。過小カウントでも合法的な指標は、過大カウントの違法な指標に勝ります。
一般的なMAU計算エラー：実務者のチェックリスト
MAUレポートを公開する前に、このチェックリストを使用してください。私はこれを分析Wikiにピン留めしています：
- イベントをユーザーとして二重カウント – 常にuser_idでDISTINCTを使用する。
- カレンダーとローリングウィンドウの混在 – チャートの軸に明示的にラベルを付ける。
- 曖昧な「アクティブ」の定義 – SQLのWHERE句で許可されたイベント名をリストする。
- クロスデバイス結合の無視 – カウント前にIDを解決する。
- ボットや内部スタッフのカウント – 既知のIPとサービスアカウントをフィルタリングする。
- タイムゾーンのずれ – UTCまたはローカルを一貫して選択する；2時間のずれでユーザーが月の境界をまたぐことがある。
- プライバシー非準拠 – 同意のない識別子をドロップする。
これらのいずれかがMAUを二桁変動させる可能性があります。最も危険なのは静かなものです：タイムゾーンとボットフィルターは、エラーをスローしないためです。
DAU/MAU比率：MAUだけが誤解を招く理由
MAUは到達範囲を示しますが、深さは示しません。粘着率（DAUをMAUで割ったもの）はエンゲージメントの質を明らかにします。ソーシャルアプリでは50%が優れており、B2Bでは10〜20%が正常です。アクティブユーザーを毎日と毎月同じ定義で計算すると、比率は信頼できるものになります。
かつて私は12%のMAU成長を提示しましたが、素晴らしく見えましたが、DAU/MAUは30%から22%に低下しました。その成長は低意図のユーザーから来ていました。常にMAUを深さの指標とペアにしてください。
MAU数値の検証：実務者向けの3つのテスト
公開前に、私はこれらのチェックを実行します：
- DISTINCTチェック： COUNT(*)とCOUNT(DISTINCT user_id)を比較する；近い場合はフィルターが壊れている。
- 境界テスト：月の1日にアクティブなユーザーをカウントし、カレンダーを使用する場合は隣接する両月に表示されることを確認する（期待される）が、厳密な未満を使用するローリングの場合は表示されないことを確認する。
- 真実のソーステスト：製品DBと分析ウェアハウスからMAUを照合する；5%を超える差異は調査が必要。
これらは10分で完了し、何度も誤ったナラティブから私を救ってきました。
ケーススタディ：マーケットプレイスで30%膨張したMAUの修正
工芸品を販売するクライアントが120,000 MAUを報告しました。監査で、3つの問題が見つかりました：ボットクローラー（15%）、重複デバイスID（10%）、および月をまたぐ購入者を二重カウントするカレンダーウィンドウ（5%）。チェックリストを適用した後、真のMAUは84,000でした。
創業者は最初パニックになりましたが、私たちは再構成しました：クリーンな数値はLTVモデリングの現実的な基盤を与えました。支出計算ツールを使用して収益を正確に予測しました。6か月後、正直なMAUは95,000に成長しました—アーティファクトではなく、本当の成長です。
計算ツールを使用する場合と独自のクエリを作成する場合
迅速な健全性チェックが必要な創業者であれば、月間アクティブユーザー（MAU）計算ツールを使用すると、SQLなしで生のイベント数と重複排除の前提を入力できます。収益化モデリングには、月間支出 vs フリートゥプレイ計算ツールがMAUを収益シナリオに変換するのに役立ちます。
ただし、イベントレベルのデータがあり監査可能性が必要な場合は、クエリを自分で書く方が優れています。アクティブの定義を制御し、ロジックをバージョン管理できます。私のルール：計算ツールはブレインストーミング用、SQLは取締役会の資料用です。