プロダクト利用データを機能アダプションレポートに変換する方法 (2026)

利用状況のエクスポートデータは、ユーザーID、イベント名、タイムスタンプ、そして1つか2つのプロパティといった、イベントの長いリストにすぎません。一方で、機能採用レポートに表示されるのは、たった1つのパーセンテージです。この両者の間を埋めるのは、数式ではなく、3つの意思決定です。

どのユーザーを分母に含めるべきか。何をもって機能を使用したとみなすか。And over what window you are measuring.

これらのいずれか1つを変更するだけで、数値は数十パーセントも変動します。それでもレポートは正しく見えてしまうこと、それこそが問題なのです。

このガイドでは、最初に決めるべきこと、3つの手動のアプローチ、そしてそれぞれのアプローチがどこで破綻するかについて解説します。

始める前に必要なもの

事前に集計されたサマリーではなく、イベントレベルの行データが必要です。ユーザー識別子とタイムスタンプが含まれる、1イベントにつき1行のデータです。

実際にその機能を表すイベント名が必要です。ほとんどの機能は複数のイベントを発生させるため、これは言葉で言うほど簡単ではありません。機能採用の数値の精度は、このマッピングの精度に完全に依存します。

また、誰がその機能を使用できたのかを知る必要もあります。機能が機能フラグの裏で一部のアカウントにのみリリースされた場合、それ以外のユーザーは分母に含めるべきではありません。

事前に簡単な整合性チェックをしておくと、後で1時間を無駄にせずに済みます。エクスポートデータ内の一意のユーザー数をカウントし、把握しているアクティブユーザー数と比較してください。もし大きく異なる場合、気づかないうちにエクスポートデータにフィルターがかかっている可能性があります。

数値を左右する3つの意思決定

分母。 すべての登録ユーザー、月間アクティブユーザー、あるいはその機能を利用可能なユーザーのみ。これらは、同じイベントデータから3つの異なるパーセンテージを生み出します。機能採用の数値はすべて分数であるため、計算を始める前に分子と分母の両方を明確に定義してください。

新しくリリースされた機能の場合、通常は「利用可能なユーザー」を分母にするのが最も誠実な選択です。「すべての登録ユーザー」を分母にすると数値は最も低くなりますが、保守的な見積もりとして最も説明がつきやすい数値でもあります。

「使用した」の定義。 イベントを1回発生させた、2回発生させた、あるいは2つの異なるセッションで発生させた、など。チュートリアル中の1回のクリックは採用とは言えません。多くのチームが、手痛い経験からこのことを学びます。

しきい値を決めて、レポートに明記しましょう。「異なる2日間に2回使用したこと」は、一般的で説得力のあるルールです。

期間（ウィンドウ）。 採用は一時点のデータではありません。特定の期間内にそのアクションを行った利用可能なユーザーの割合であるため、期間も定義の一部となります。

ツールの手法をそのまま真似る前に、知っておくべきドキュメント上の微妙な違いがあります。Amplitudeの継続率（リテンション）に関するドキュメントでは、その計算方法が説明されています。それによると、「開始イベントの日付と、指定したリターンイベントの日付を比較して継続率データを計算する」となっています。

日付範囲は最初のイベントにのみ適用されます。Amplitudeは、「ユーザーが分析に表示されるために、その期間中にリターンイベントをトリガーする必要はない」と明確に述べています。

これは合理的な挙動ですが、多くの人を驚かせます。両方のイベントを同じ期間でフィルタリングするスプレッドシートの計算結果は、このツールの数値とは一致しませんが、どちらかが間違っているわけではありません。

手動で行う方法

オプション1：一意のユーザー数をカウントし、割り算する

生のイベント数は採用者数ではないため、まずは重複排除から始めます。UNIQUE関数を使用して、ユニークユーザーのリストを抽出します。

次に、イベント名と日付範囲を指定してCOUNTIFS関数を使用し、それらのユーザーのうち何人が機能イベントを発生させたかをカウントします。それを、利用可能なユーザー数で割ります。

2つのカウント値は、1つの数式にネストするのではなく、目に見えるセルに分けて配置しておきましょう。「分母は何だったか」と聞かれたときに、すぐに指し示せるようにするためです。

この方法の限界は、詳細な内訳のない、ただ1つの数値しか得られない点です。18%が採用したことは分かっても、それが「誰なのか」については何も分かりません。

オプション2：ユーザーレベルのフラグテーブルを作成する

利用可能なユーザーごとに1行、質問ごとに1列を作成します。イベントを発生させたか、何回発生させたか、そして何日（重複なし）発生させたか、といった項目です。

これでデータをスライスできるようになります。プラン別、登録コホート別、アカウント規模別、オンボーディングを完了したかどうか別などで、採用率を分析できます。

ここで、機能採用は単なる「報告用の数値」から「アクションを起こせるデータ」へと変わります。全体の平均値が18%であっても、新規ユーザーの採用率が40%で、昨年からのユーザーの採用率が4%であるという事実が隠されているかもしれないからです。

そのギャップこそが、発見です。当社のコホート分析に関するガイドでは、ユーザーの行動が変わっていなくても、登録数が変動するだけで全体の平均値が変動してしまう理由を説明しています。

この方法の限界は、データ量と結合です。100万行のエクスポートデータにアカウントテーブルを結合するとなると、数式で快適に処理できる限界を超えてしまいます。

オプション3：数値の横に定義タブを用意しておく

イベント名、しきい値、期間、分母、そして誰が利用可能だったかを書き留めておきます。

これにより、翌月も比較可能なレポートを作成できます。しかし、誰かが「10分以内に数値が必要だ」と言い出したときに、真っ先に無視されるタブでもあります。

限界は、定義をドキュメント化しても、それが自動的に適用されるわけではないという点です。結局、誰かが毎サイクル同じ5つのフィルターを再作成することになります。

共通の限界。 3つのアプローチはいずれも、イベント名が整理されていることを前提としています。リファクタリング後に同じアクションが3つの異なる名前で発生するようになった場合、カウントを始める前にそれらを調整することこそが、本当の重労働になります。

手動ルートが停滞する原因

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

プロダクトが変更されると、イベント名も変わります。コードベースでの名称変更は、チャート上では急激な下落として現れ、まるでユーザーがその機能を使わなくなったかのように見えます。その結果、機能採用チャートは顧客の意思決定ではなく、コードの変更を報告するものになってしまいます。

ロールアウトの変更は分母を崩壊させます。機能が100%のアカウントに適用されると、利用可能なユーザー数が3倍に増えるため、採用率は低下したように見えます。

そして、最も長く残り続けるカウントミスがあります。一意 of ユーザー数ではなくイベント数を合計してしまうと、一握りのパワーユーザーがその機能を使い倒すたびに、採用率が不自然に膨れ上がってしまいます。

締め切り間際にしか見えてこないコストがもう1つあります。誰かに「この数値は良いの？」と聞かれたとき、1つのパーセンテージだけでは答えられず、比較対象を作るためにまた別の作業が発生してしまいます。

Powerdrill Bloomでレポートを作成する方法

ステップ1：利用状況のエクスポートデータをアップロードする

イベントのエクスポートデータ、またはイベントファイルとアカウントファイルを一緒にアップロードします。Powerdrill Bloomはアップロード時に対象の列をプロファイリングするため、パーセンテージを計算する前に、一貫性のないイベント名や欠落しているユーザーIDを検出できます。

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

ルールを構築するのではなく、言葉で説明します。イベント名、しきい値、期間、そしてどのユーザーが利用可能かを指定します。

次に、落とし穴を回避するための質問を投げかけます。重複に近いイベント名がないか、発生したイベント数に対して一意のユーザー数は何人か、そして登録月によって機能採用率がどのように異なるか、などを質問します。

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

採用の推移、セグメント別の表、あるいは数値と定義がセットになったスライドなどを出力します。

毎サイクル再作成するよりも優れている理由

	手動ルート	Powerdrill Bloom
イベントからのユーザー重複排除	ファイルごとの作業用列の作成	一意のユーザー数を指示するだけ
コホートやプラン別の分割	テーブルを結合して再構築	内訳を指示するだけ
リリース後のイベント名変更	後からチャートを見て気づく	アップロード時に検出
利用可能なユーザー層の変更	分母を再計算	新しいルールを指示するだけ

3行目こそが、正確性の分かれ目です。イベント名の変更と実際の利用減少は、折れ線グラフ上ではまったく同じに見えますが、プロダクト側での対応が必要なのは片方だけです。

よくある間違い

ユーザー数ではなくイベント数をカウントしている。 200人による10,000回のイベントは、採用とは言えません。常に、まずは重複を排除してください。

フラグ付きの機能に対して、すべての登録ユーザーを分母にしている。 アカウントの3分の1しかその機能を表示できない場合、残りの3分の2は「採用しなかった人」ではなく、「利用資格がない人」です。

1回のクリックを採用とみなしている。 オンボーディング中の1回限りのイベントは、単なる「接触」にすぎません。数値に意味を持たせたい場合は、異なる日に複数回使用することを条件にしてください。

月をまたいで全体の平均値を比較している。 新規ユーザーと既存ユーザーでは採用率が異なるため、その比率が変わるだけで数値自体が変動します。結論を出す前に、コホートごとに分割してください。

イベント名の変更を無視している。 リファクタリングによって、解約のように見える急激な下落が発生します。ユーザーの行動を調査する前に、イベント辞書を確認してください。

ツールの期間設定の仕組みを理解せずに真似している。 ドキュメント化された継続率の期間設定では、最初のイベントのみをフィルタリングすることが多いため、両方のイベントをフィルタリングするスプレッドシートとは数値が一致しなくなります。

定義を添付せずにパーセンテージだけを報告している。 分母としきい値がなければ、その数値には意味がありません。優れたKPIダッシュボードが指標にラベルを付けるのと同じように、チャートにその両方を記載してください。

結論

利用可能なユーザー層を決定し、使用のしきい値を設定し、期間を固定し、割り算の前にユーザーの重複を排除する。これら4つのステップを踏むことで、機能採用率はプロダクトチームがアクションを起こせる価値あるデータへと変わります。

これを困難にしているのは、プロダクトの変更に合わせて定義を維持し続けなければならない点です。イベント名の変更やロールアウト範囲の拡大は、レポートに手を加えなくても数値を変動させてしまいます。

もしレポート作成サイクルでそのような問題に直面しているなら、利用状況のエクスポートデータを使ってPowerdrill Bloomをお試しください。また、コホート継続率チャートの作成方法に関するガイド、プロダクト分析向けAIツールのまとめ、およびCSV AI assistantのページもあわせてご覧ください。

よくある質問

機能採用（フィーチャーアドプション）とは何ですか？

定義された期間内に機能を使用した、利用可能なユーザーの割合のことです。イベント数ではなく、一意のユーザー数で測定されます。この定義は、分母と使用のしきい値が明記されている場合にのみ成り立ちます。

イベントのエクスポートデータからどのように計算すればよいですか？

指定した期間内に機能イベントを発生させた一意のユーザー数をカウントし、それを資格のあるユーザー数で割ります。1人のユーザーが数百のイベントを発生させる可能性があるため、必ず最初に重複を排除してください。

分母はすべてのユーザーにすべきですか、それともアクティブユーザーにすべきですか？

実際にその機能にアクセスできたユーザーである「利用可能なユーザー層」を使用してください。「すべての登録ユーザー」を分母にすると保守的な数値になりますが、ロールアウトフラグの裏にある機能の採用率を過小評価することになります。

測定期間はどのくらいにすべきですか？

通常の利用サイクルに合わせるのに十分な長さにします。毎日使うプロダクトであれば週単位、定期的に使うものであれば月単位などです。期間を変更すると数値が変わってしまうため、レポート間で固定するようにしてください。

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

通常は、期間設定または重複排除のルールが原因です。ドキュメント化された継続率の計算では、日付フィルターを最初のイベントにのみ適用することが多いため、両方のイベントに基づいて作成されたスプレッドシートではその数値を再現できません。