ユーザーアクティベーションレポートの作成方法：完全ガイド

2つのチームが同じプロダクトデータを見て、それぞれ22%と61%のアクティベーション率を報告しています。

どちらも計算ミスをしたわけではありません。異なるイベント、異なるウィンドウ、そして異なる分母を選択したのです。

これこそが、この指標の難しさのすべてです。計算式は割り算であり、すべての議論はその中身に何を代入するかを巡って行われます。

本ガイドでは、レポートに含めるべき内容と、数値を決定する3つの選択肢について解説します。さらに、スプレッドシートの数値が分析ツールと一致しない理由や、イベントのエクスポートデータからレポートを作成する方法についても説明します。

アクティベーションレポートに含めるべきもの

見出しとなるパーセンテージはわずか1行にすぎません。レポートとは、その1行の数値を正当化するための文脈（コンテキスト）です。

同じビューに含めるべき要素は5つあります。アクティベーションイベント、ウィンドウ、コホートの定義、分母となるカウント数、そして率そのものです。

これらのいずれかが欠けても、その数値は検証不可能なものになってしまいます。誰かが取締役会向けの資料にその数値を引用しても、他の誰もそれを再現できなくなります。

6つ目の項目としてトレンドを追加しましょう。1回限りの測定値は単なるデータ点にすぎませんが、定義を変更せずに3回連続で測定した数値は、初めて行動を起こす価値のある情報となります。

数値を決定する3つの選択肢

それぞれの選択肢が単独で結果を左右しますが、最終的なパーセンテージを見ただけでは、どの選択肢が選ばれたのかは分かりません。

選択肢	決定される内容	変更した場合の影響
アクティベーションイベント	何をもって成功とするか	より後ろの工程のイベントにすると、すべてのコホートで率が低下する
アクティベーションウィンドウ	ユーザーに与えられる期間	ウィンドウを長くすると率は上昇するが、レポート作成が遅れる
分母	誰を測定対象とするか	コホートがずれると、率が100%を超えることがある

選択肢1：アクティベーションイベント

これは最も重要な判断であり、エクスポートされたデータを眺めているだけでは答えは出ません。

アクティベーションイベントは、ユーザーの再訪を予測できる最も初期のアクションであるべきです。測定のしやすさや、イベントの実装が容易であるかどうかは基準になりません。

新規登録の完了がアクティベーションイベントになることは、ほぼありません。新規登録はファネルの入り口にすぎず、プロダクトがユーザーの役に立ったという証拠にはならないからです。

プロダクトがその価値を最初に提供するアクションを選択してください。レポート作成ツールであれば「最初のレポートの公開」、メッセージングツールであれば「他のユーザーへの最初のメッセージ送信」などが考えられます。

選択した理由を1行で書き残しておきましょう。その1文があることで、次の四半期に定義がブレてしまうのを防ぐことができます。

選択肢2：アクティベーションウィンドウ

本格的な分析ツールはすべてこれをパラメータとして扱います。つまり、これはあなた自身が決定すべき事項です。

Mixpanelのファネルに関するドキュメントには、コンバージョンウィンドウは「ユーザーがファネルに入った後、そのすべてのステップを完了するまでに与えられる時間」を決定すると明記されています。

デフォルトは最初のステップから7日間です。最大値は366日間、またはセッションベースのウィンドウの場合は12セッションです。

注意すべき細かい仕様があります。Mixpanelは、ウィンドウが「ファネルへのエントリーごとに、ステップ1のイベントが最初に発生した時点で開始される」と指摘しています。そのイベントが後から再度発生しても、タイマーがリセットされることはありません。

そのため、新規登録した後に1ヶ月間姿を消し、その後戻ってきてアクティベートしたユーザーは「失敗」とカウントされる可能性があります。これは短いウィンドウを設定している場合には正しい挙動ですが、レポートを読む人を驚かせることになるでしょう。

選択肢3：分母

分母となるのはコホートです。コホートは、ユーザーがいつアクションを起こしたかではなく、いつ到達したかによって定義されます。

特定の期間内に新規登録したすべてのユーザーを抽出します。そのリストを固定した上で、ウィンドウ内に何人がアクティベーションイベントに到達したかを測定します。

Mixpanelのユニークカウント方式も同様に機能し、「選択した期間内にユーザーが最初にステップ1をトラッキングしたとき」にユーザーをエントリーさせます。その後に再度エントリーしても、カウントが増えることはありません。

陥りがちな罠は、異なる期間を混ぜてしまうことです。分母を「今月の新規登録者数」、分子を「今月のアクティベーション数」にしてしまうと、それ以前に新規登録したユーザーによるアクティベーションまでカウントしてしまいます。

この方法で計算された指標は100%を超えることがあり、それが間違いのサインとなります。コホートを最初に固定しなければならない理由については、コホート分析に関する解説記事で詳しく説明しています。

スプレッドシートの数値が分析ツールと一致しない理由

この数値の突き合わせ作業は、多くのチームで半日を潰してしまう原因になります。そのため、問題が発生する前にその理由を理解しておく価値があります。

ツール内部の3つの設定は、出力結果には表示されません。それは、ウィンドウの長さ、カウント方法、およびステップの順序です。

Mixpanelはデフォルトで特定の順序を適用し、次のステップに進む前に前のステップを完了することを求めます。また、ステップを固定しない限り、任意の順序でカウントする「順不同」のオプションも提供しています。

スプレッドシートで計算を再現しようとすると、これら3つの設定に対して暗黙的に独自の定義を選択することになります。その結果、どちらの計算も正しいにもかかわらず異なる数値になり、どちらが間違っているわけでもないという状況が生まれます。

解決策は地味ですが効果的です。レポートにこれら3つの設定を記録しておき、同じ条件同士でのみ比較するか、さもなければ比較自体を行わないようにすることです。

手動で作成する方法

オプション1：2つのカウントと1つの割り算

対象期間内に新規登録したすべてのユーザーをリストアップし、UNIQUE関数を使って識別子の重複を排除します。

そのリストをCOUNTA関数でカウントして分母とします。次に、COUNTIFS関数を使用して、同じリストの中からウィンドウ内にアクティベーションイベントが発生したユーザーをカウントします。

両方のカウント数を表示されたセルに残しておきます。最後に1回だけ割り算を行うことで、誰でも2つの入力値を個別に検証できるようにします。

ただし、この方法ではすぐに限界に達します。得られるのは1つのウィンドウに対する1つのパーセンテージだけであり、誰がアクティベートしなかったのかを把握することはできません。

オプション2：ユーザーごとに1行

コホート内のユーザーごとに1行を割り当てたテーブルを作成します。列には、新規登録日、最初のアクティベーションイベント日、その間の日数、そしてウィンドウ内であるかどうかのフラグを設定します。

遅い方の日付から早い方の日付を引いて、日数の差を計算します。Microsoft公式のDATEDIF関数に関するガイドでは、この関数が「特定のシナリオで誤った結果を計算する可能性がある」と警告しており、日数のカウントには単純な引き算を使用することを推奨しています。

これで、レポートをさまざまな切り口で分析できるようになります。プラン別、獲得チャネル別、登録週別、あるいは企業規模別などです。

通常、重要な発見はこの分析の切り口から得られます。全体の平均値だけを見ていると、あるチャネルでは順調にアクティベートしている一方で、別のチャネルでは全くアクティベートしていないという事実が見落とされがちです。

この方法の限界は、データの結合とボリュームにあります。イベントのエクスポートデータとユーザーテーブルの照合は、数十万行を超えたあたりから非常に困難な作業になります。

オプション3：定義タブ

アクティベーションイベント、ウィンドウ、コホートのルール、およびカウント方法を記録します。さらに、社内アカウントやテストユーザーなど、除外対象とするものも記録しておきます。

社内トラフィックは、気づかないうちに数値を歪める要因になります。30人のチームが毎週プロダクトをテストしているだけで、規模の小さいコホートの率が数パーセント引き上げられてしまうことがあります。

この方法の限界は、ルールを書き留めただけでは自動的に適用されない点です。来月になれば、また誰かが手動で同じフィルターを再作成することになります。

共通の限界： これら3つのオプションはすべて、エクスポートデータに信頼できるユーザー識別子と、整理されたイベント名が含まれていることを前提としています。四半期の途中でイベント名が変更された場合、その整合性を取る作業こそが実際の主な業務になってしまいます。

手動ルートで行き詰まるポイント

最初のレポート作成には半日かかります。しかし、4回目のレポート作成にはそれ以上の時間がかかるようになります。なぜなら、その頃には定義が変わってしまっているからです。

最も一般的な原因はイベント名の変更です。トラッキングの整理によって1つのイベントが2つに分割されると、ユーザーの行動自体には変化がないにもかかわらず、アクティベーション数が減少してしまいます。

コホートの期間もずれていきます。誰かが前四半期のファイルに今四半期の日付フィルターを適用して再実行し、会議でその2つの異なる数値が比較されてしまうといったことが起こります。

さらに、毎回のように発生する要望もあります。「同じ率をチャネル別に見たい」と誰かが言い出し、すべてのフィルターを手動で再構築することになるのです。

プロダクト分析に最適なAIツールのまとめ記事では、この問題に対するツール側の解決策を解説しています。

Powerdrill Bloomで作成する方法

ステップ1：イベントのエクスポートデータをアップロードする

イベントファイル、またはイベントファイルとユーザーファイルを一緒にアップロードします。Powerdrill Bloomはアップロード時に対象の列を分析するため、ユーザー識別子の欠落、イベント名の不整合、範囲外のタイムスタンプなどの問題が、率を計算する前に明らかになります。

ステップ2：自然言語で定義を記述する

ルールを構築する代わりに、言葉で指定します。アクティベーションイベント、日数単位のウィンドウ、コホート期間、および除外するアカウントを指定します。

次に、境界条件を明らかにする質問を投げかけます。ウィンドウが閉じた1日後にアクティベートしたユーザーの数や、期間の一部にしか現れないイベント名について質問します。さらに、チャネル別や登録週別の率のブレイクダウンを求めます。

ステップ3：チャート、レポート、またはスライド資料をエクスポートする

分母を伴う率、登録日からの経過日数ごとのアクティベーション曲線、あるいは数値の横に定義が記載されたスライド資料などを出力します。

よくある間違い

新規登録をアクティベーションイベントに設定している。 新規登録はファネルの入り口です。アクティベーションは、プロダクトが何らかの価値を提供した瞬間でなければなりません。

分母を示さずに率を報告している。 基準が不明なパーセンテージは単なる飾りにすぎません。数値の隣にコホートの規模を表示しましょう。

コホート期間を混同している。 以前の新規登録者によるアクティベーションを今月の基準に対してカウントすると、率が不当に高くなり、100%を超える原因になります。

ラベルを変更せずにウィンドウを変更している。 7日間の数値と30日間の数値は異なる測定値です。どちらかに固定し、レポートに明記してください。

自社の数値を公開されているベンチマークと比較している。 他社は異なるイベントやウィンドウを選択しています。まずは自社の過去のトレンドと比較しましょう。

コホートに社内アカウントを残している。 スタッフやテストユーザーのアクティベーション率は100%に近くなります。規模の小さいコホートでは、これが数値を大きく歪める原因になります。

名前が変更されたイベントを無視している。 トラッキングの変更により、ユーザー行動に変化がなくてもカウントが減少することがあります。数値の低下を説明する前に、イベント名を確認してください。

結論

アクティベーションイベントを選択し、ウィンドウを固定し、コホートを確定させ、その隣に分母を添えて率を報告します。これら4つの決定を行うことで、人々が行動を起こせる数値が生まれます。

パーセンテージそのものが成果物ではありません。チャネル別や登録週別のブレイクダウンこそが、来月どこにリソースを投入すべきかを教えてくれるのです。

もしそのブレイクダウンの再構築に毎回追われているなら、イベントのエクスポートデータを使ってPowerdrill Bloomをお試しください。また、プロダクトの使用データを機能採用レポートに変換する方法に関するガイドや、AIレポートジェネレーターのページもあわせてご覧ください。

よくある質問

アクティベーション率の計算式は？

コホート内のユーザーのうち、ウィンドウ内にアクティベーションイベントに到達したユーザーの数をカウントします。それをコホートの総ユーザー数で割り、100を掛けます。

アクティベーションウィンドウの長さはどのくらいにすべきですか？

通常の行動を捉えるのに十分な長さであり、かつ行動を起こしやすいように十分に短い期間にします。Mixpanelはコンバージョンウィンドウをデフォルトで7日間に設定しており、最大366日間まで設定可能です。

どのイベントをアクティベーションとみなすべきですか？

ユーザーの再訪を予測できる最も初期のアクションです。候補となるイベントを実行したユーザーが、その後の週に再訪しているかどうかに基づいてテストを行います。

なぜ私の数値は分析ツールの数値と異なるのですか？

通常は、ウィンドウ、カウント方法、またはステップの順序が原因です。これら3つの設定はツール内部に存在し、エクスポートされた数値には表示されません。

アクティベーション率が100%を超えることはありますか？

コホートの定義が崩れている場合にのみ発生します。この結果は、以前に新規登録したユーザーのアクティベーションが、それより後の期間の分母に対してカウントされていることを意味します。