product-analytics-setup

プロダクト分析のセットアップ

シニア PM とアナリストのための、プロダクト分析を最初から正しく計測するための実践ガイドです。

多くのプロダクト分析のセットアップは、引き継がれた誤り、乱立するダッシュボード、誰も信頼していないイベントが組み合わさったものです。チームが新機能をリリースし、期限に追われながら計測を後付けし、命名規則がばらつき、プロパティに一貫性がなくなります。6 か月後には、どのイベントを信頼するかによって答えが変わるため、誰も簡単な質問に答えられなくなります。

このスキルは、そうした問題を防ぐための規律です。何を測定するかという戦略的な問いにはすでに答えていることを前提とします（analytics-strategy を参照）。また、ツールを接続済みであることも前提とします（Mixpanel、Heap、PostHog、Amplitude、または BigQuery、Snowflake、dbt を介したデータウェアハウスネイティブのツール）。難しいのは、命名規則、プロパティ設計、スキーマのバージョン管理、ファネルの構築、コホートの定義、リテンションの測定といった、体系的な実行です。

このスキルを使う場面：プロダクト分析をゼロからセットアップするとき、既存の計測を監査するとき、「データはあるが信頼できない」という問題を解決するとき、新機能の計測を設計するときです。

---

このスキルの目的

このスキルでは、計測の実行を幅広く扱います。測定戦略（analytics-strategy を使用）、実験結果の解釈（experimentation-analytics を使用）、有料メディア分析（ads-performance-analytics を使用）、プラットフォームの選定（experimentation-platform-orchestrator を使用）は対象外です。使用するツールに応じて、関連するインテグレーションのマイクロサイトと併用してください。

analytics-strategy との明確な違いは次のとおりです。このスキル（グロースカテゴリ）は戦略、つまり何をなぜ測定するか、KPI の階層、ダッシュボードの構成、アトリビューションモデルを扱います。このスキル（プロダクトカテゴリ）は実行、つまりプロダクトを実際に正しく計測する方法を扱います。この 2 つは組み合わせて使えます。まず analytics-strategy を読んで何が重要かを決め、次にこのスキルを読んで計測してください。

---

計測の階層

基本となる考え方です。あらゆる分析のセットアップは、複数の層が積み重なった構造です。各層が正しく機能するには、その下の層が正しく整っている必要があります。

• イベントは基本的な事実です：user_signed_up、checkout_completed、feature_x_used。
• プロパティはイベントを説明します：誰が、何を、どこで、いつ、どのような状況で行ったか。
• IDはイベントを個人に紐づけます：anonymous_id、user_id、account_id。
• コホートはイベント全体に適用するフィルターです：「3 月に有料経由で獲得したユーザー」。
• ファネルはイベントの連続です：サインアップ、次にアクティベーション、その次に初めての有料アクション。
• リテンションは行動の反復を測定します：N 週目にもアクティブなままのサインアップユーザー数。

下位の層が正しくなければ、上位の層を構築することはできません。質の悪いイベントからは、質の悪いファネルが生まれます。大切なのは、下から積み上げることです。「データはあるが信頼できない」という問題の多くは、下から 2 つの層に原因があります。

---

イベント分類の設計

イベント設計には3つのルールがあります。

1. 過去形で、アクションを表す。 checkout_complete や completing_checkout ではなく、checkout_completed を使います。過去形にすることで、状態ではなく「これが起きた」と伝わります。
2. オブジェクト＋アクションの形式にする。 名詞を先に、動詞を後に置きます。video_played、form_submitted、email_opened のようにします。イベント名を声に出して読んだとき、何が起きたかが伝わるようにします。
3. 粒度は細かく、重複させない。 ボタンのクリックではなく、ユーザーの個別のアクションを追跡します。完了した時点で checkout_completed を1回だけ発火させます。submit_button_clicked と checkout_completed の両方を発火させてはいけません。UI イベントはノイズであり、意味のあるイベントはシグナルです。

動詞と状態を混同する落とし穴。

• 動詞はイベントです。checkout_completed、subscription_canceled、account_upgraded のようにします。
• 状態はイベントではなく、プロパティです。user_status: active はユーザーのプロパティであり、イベントではありません。イベントで状態を設定する（「status_changed_to_active」）のは、二重カウントを引き起こすコードの臭いです。

設計するイベントの数について。一般的な SaaS 製品では、30～50件がちょうどよい範囲です。20件未満では計測が不十分で、100件を超える場合は、ほとんどの場合、UI のノイズを追跡しているか、異なる形式でイベントを重複させています。

詳しい説明と標準イベント仕様については、references/event-taxonomy-template.md を参照してください。

---

プロパティ設計：イベントレベルとユーザーレベル

プロパティには2種類あり、分けて扱います。

イベントレベルのプロパティは、このイベントについて説明します。checkout_completed イベントには、cart_value、item_count、payment_method、discount_code などのプロパティがあります。これらはイベントのペイロードに含まれ、一度発火すると変更できません。

ユーザーレベルのプロパティは、時間の経過に伴うユーザーについて説明します。subscription_tier、lifetime_value、acquisition_channel などです。ユーザープロフィールに一度設定すると、分析ツールがそのユーザーのすべてのイベントに結合します。ユーザーの変化に応じて、時間とともに更新されます。

よくある落とし穴は、ユーザーレベルのプロパティをすべてのイベントに含めてしまうことです。subscription_tier をすべてのイベントペイロードで追跡してはいけません。ユーザープロフィールに一度設定し、結合に任せてください。イベントに含めると、ペイロードが肥大化し、値が変わったときにスキーマが不整合になり、セッション中にユーザーがアップグレードした場合のレポートも分かりにくくなります。

データ型のルール。

• 文字列は列挙値に使います。ステータス、ティア、チャネル、地域など、値の集合が限られているものです。
• 数値は実際の数値にのみ使います。件数、値、期間、スコアなどです。数値データに文字列を使ってはいけません（「無料トライアルの7日目」は trial_day: 7 とします）。
• ブール値は実際に真偽を表す値に使います。is_admin、has_trial、is_new_user などです。値は2つだけで、それ以外はありません。
• タイムスタンプは常に ISO 8601 形式にします。必ずです。日付形式の不統一が引き起こすバグの数は、数え切れません。
• 配列はめったに使いません。配列プロパティがある場合、通常はイベントごとに項目を1つずつにして、複数のイベントに分割すべきという兆候です。

product_viewed イベントの正しい設計と誤った設計を示す例については、references/property-design-patterns.md を参照してください。

---

命名規則

規則を1つ選び、徹底してください。選ぶ価値のある規則を3つ紹介します。

• イベントとプロパティには snake_case：user_signed_up、cart_value。ほとんどのプラットフォームのデフォルトであり、変更を求めるメリットはほとんどありません。
• イベントには「オブジェクト_アクション」形式：user_signed_up、video_played。名前を読むだけで何が起きたかがわかるようにします。
• ユーザープロパティには動詞_名詞形式（または名詞のみ）：subscription_tier、is_admin、last_active_at。

避けるべきこと。

• イベント間で大文字・小文字の形式を混在させること。同じプロジェクト内に user_signedUp、User Signed Up、userSignedUp が共存している状態です。規則を1つ選び、移行してください。
• イベント名やプロパティ名にスペースを使うこと。「Sign Up Completed」は、あらゆるURLエンコードのケースで問題を引き起こし、あらゆるツールを混乱させます。
• 動詞の使い方に一貫性がないこと。同じプロジェクトに user_signed_up、completedCheckout、VIEW_PRODUCT があると、調べない限りイベント名を予測できません。
• イベント名にブランド名を含めること。Customer.ioに切り替えたとき、mailchimp_email_opened はすぐに古びます。

命名規則のリファレンスファイルには、スタイルガイドの全容が記載されています。チームのデータコントラクトで参照してください。

詳細は references/naming-convention-reference.md をご覧ください。

---

スキーマのバージョン管理

スキーマの変更は避けられません。以下にパターンを示します。

追加的な変更は安全です。新しいイベント、既存イベントへの新しいプロパティ、列挙型への新しい値などです。そのままリリースできます。既存のダッシュボードは引き続き動作します。

破壊的変更には移行が必要です。イベント名の変更、プロパティの削除、プロパティ型の変更、列挙型の値の範囲の縮小などです。これらは下流のダッシュボードに影響するため、移行計画も変更の一部です。

バージョン管理のパターン。

• 意味が変わるイベントには _v2 を付けます。移行期間中は checkout_completed_v2 と checkout_completed を並行して発火させます。
• 移行期間中は古いイベントも発火させ続けます（通常は90日間です）。両方のバージョンを発火させ、分析クエリを徐々にv2へ移行します。
• v1を廃止する前にダッシュボードをv2へ移行します。その後、ドキュメントに注記してv1を明示的に非推奨にします。

データコントラクトの考え方。

• 正式なスキーマをコードで文書化します。TypeScriptのインターフェース、JSON Schema、またはProtobuf定義を使用します。
• スキーマの変更はすべてコードレビューを行います。スキーマはプロダクトの一部であり、後付けではありません。
• CIのリントでスキーマ違反を検出し、本番環境に到達する前に拒否します。誤った型のイベントを追加するデプロイは、ビルドに失敗します。

詳細は references/schema-versioning-patterns.md をご覧ください。

---

ファネルの設計

ファネルは、一連のステップを経て進む過程を測定します。4つのルールがあります。

1. 順序が重要です。 A、次にB、次にCというファネルは、B、次にA、次にCというファネルとは異なります。プラットフォームは順序に応じて異なるコンバージョン率を算出します。
2. 期間が重要です。 ほとんどのファネルでは、最初のイベントから1～30日の期間を設定します。期間は明記してください。「登録を完了し、かつアクティベートしたユーザー」は、「14日以内に」がなければ意味をなしません。
3. 離脱の解釈は困難です。 ステップ2でユーザーの80％が離脱した場合、ファネルの設計（対象者が適切でない）、対象者（タイミングが適切でない）、またはプロダクト（実際の離脱）が原因かもしれません。結論を出す前に調査してください。
4. 起点イベントのパターン。 すべてのファネルは、登録、トライアル開始、主要機能の利用など、意図の強いアクションから始めます。page_view や session_start のような見栄えだけのイベントは使いません。見栄えだけのイベントを起点にしたファネルでは99％が離脱し、何も分かりません。

よくあるファネルの間違い。

• 自動的に発生するイベントを含むファネル。session_started は訪問のたびに発生します。これをステップとして使うと分母が膨らみ、ファネルの残りが意味をなさなくなります。
• 長すぎるファネル（10ステップ以上）。2つか3つの短いファネルに分けてください。10ステップのファネルでは、最初から最後までのコンバージョン率がほぼゼロになり、解釈が困難です。
• 同じイベントを複数の位置に含むファネル。プラットフォームでの処理は適切でなく、アナリストによる処理はさらにうまくいきません。
• 1つのファネル内で異なる期間を混在させること。「7日以内に登録し、かつ30日以内にコンバージョンしたユーザー」は、異なる2つのコホート定義を無理につなげたものです。

一般的なファネルの形と期間のガイダンスについては、references/funnel-design-templates.mdを参照してください。

---

コホートの定義

コホートとは、属性または行動を共有するユーザーのグループです。役立つパターンを紹介します。

• 獲得コホート。 X月に獲得したユーザーです。リテンション分析の標準です。
• 行動コホート。 Yのアクションを完了したユーザーです。アクティベーション分析に役立ちます（「第1週に初めてメッセージを送信したユーザー」など）。
• プロパティコホート。 subscription_tier: pro を持つユーザーです。セグメント単位の分析に役立ちます。
• 複合コホート。 3月に登録し、オンボーディングを完了し、かつEUにいるユーザーです。実際の分析業務で最もよく使われます。

コホートの運用ルール。

• コホートを再利用できるように、コード内で（またはツールの保存済みコホート機能で）定義してください。
• 基準を変更したらバージョン管理してください。同じ条件で比較できます。
• リテンションについて、経過30日のコホートと経過365日のコホートを比較しないでください。古いコホートは、定義上、リテンションのための期間がより長くなっています。

詳細については、references/cohort-definition-patterns.mdを参照してください。

---

リテンションの測定

リテンションとは、時間の経過とともに繰り返される行動です。3つの種類があります。

• N日リテンション。 ユーザーXが特定の7日目、14日目、30日目に戻ってきたかを測定します。特定の1日だけではノイズが大きくなりますが、サイクルの短いプロダクトには役立ちます。
• 期間リテンション。 ユーザーXが7～13週目の期間中に一度でも戻ってきたかを測定します。N日リテンションより安定しており、リテンション曲線も読み取りやすくなります。
• 無期限（ローリング）リテンション。 ユーザーXが登録後いつでも戻ってきたかを測定します。週単位の頻度では実態を捉えにくい、サイクルの長いプロダクトに役立ちます。

ほとんどのSaaSプロダクトでは、期間リテンションを標準とするのが適切です。7日目のリテンションはノイズが大きく、第2週のリテンション（期間）はより安定しています。1日目のリテンションは、プロダクトマーケットフィットの兆候よりも、オンボーディングの影響を強く反映することがほとんどです。

リテンション曲線の解釈。

• 初期に急落し、その後横ばいになる。コアユーザーはいる一方で、残りのユーザーはすぐに離脱します。ほとんどのSaaSプロダクトでよく見られます。
• 横ばいにならず、数週間にわたって徐々に低下する。定着しているユーザーはいません。通常は価値提案またはオンボーディングに問題があり、プロダクトが継続的な価値を提供できていません。
• 低い割合で横ばいになる。少数ながら熱心なユーザー層を持つ、パワーユーザー向けのプロダクトです。問題ではなく、異なる形状というだけです。

詳細については、references/retention-measurement-patterns.mdを参照してください。

---

北極星指標と補助指標

北極星指標（NSM）の選定ルール。

• 企業価値だけでなく、ユーザー価値を反映している。
• 伸びればビジネスも成長する、中核となるアクションを捉えている。
• 時間を通じて一貫して測定できる。
• 数値を操作しにくい。

不適切なNSM。サインアップ数（見栄えだけの指標で、多くのユーザーはサインアップしても利用を開始しません）。売上（遅行指標であり、アクションに直結せず、構成によって変動します）。DAU（エンゲージメント主導の製品でのみ有用で、月単位の利用サイクルの製品では誤解を招きます）。

より適切なNSM。週間アクティブ編集者数（Figma）。予約された宿泊数（Airbnb）。1日あたりの送信メッセージ数（Slack）。ワークスペースあたりの週次作成製品数（Linear）。いずれも、ビジネスの成長につながるユーザー価値の高いアクションを表しています。

補助指標のフレームワーク。

• NSMは1つ。
• NSMを動かす入力指標は3〜5個。「週間アクティブ編集者数」の場合、週あたりのサインアップ数、サインアップからアクティブへのコンバージョン率、週次アクティブ継続率などが考えられます。
• 問題を知らせる健全性指標は5〜10個。月次解約率、アカウント単位の集中度、サポートチケット数などです。

詳しい説明と製品タイプ別の例は、references/north-star-metric-selection.md を参照してください。

---

信頼できるダッシュボードの原則

次の4つの条件を満たすと、ダッシュボードは信頼できるものになります。

1. 各指標の定義が明確であること。 定義がインラインで記載されています。「アクティブユーザー」ではなく、「過去7日間にいずれかのイベントを発火させたユーザー。user_idで重複を除外し、従業員を除く」とします。
2. 各指標のデータソースが明確であること。 「データウェアハウスから」ではなく、「過去30日間のfct_ordersをdim_customersに結合したもの」とします。
3. 各指標の注意事項が明確であること。 モデル化されたiOSのコンバージョンは除外されます。社内の従業員は除外されます。QAアカウントのテストユーザーは除外されます。
4. 各指標を再現できること。 同じクエリを明日実行しても、同じ期間に対して同じ数値が得られます。

古いダッシュボードが引き起こす問題。2年前に作成されたダッシュボードが現在も使われています。基盤となるスキーマが変更され、ダッシュボードのクエリが、存在しなくなった列や、意味が変わった列を参照しています。チームは壊れた数値をもとに意思決定を行い、何かが大きく破綻するまでそのことに気づきません。

予防策。すべてのダッシュボードにオーナーと更新頻度を定め、四半期ごとに監査します。オーナーのいないダッシュボードは廃止します。90日間更新されていないダッシュボードも廃止します。ダッシュボードの半減期は、製品の半減期より短いものです。

---

計測の負債

手を抜くことで、コストは積み重なっていきます。

• 新機能を計測なしでリリース：1時間を節約。
• 6か月後：「機能Xはうまく機能しているのか？」に誰も答えられない。
• 後から計測を追加するコスト：20時間（再デプロイ、バックフィル、検証）。
• その間に失われる意思決定のコスト：追跡はできませんが、確実に存在します。データではなく直感に基づいて意思決定が行われ、ときにはその直感が間違っています。

計測の負債は実在し、技術的負債と同じように積み重なります。必要な取り組みは次のとおりです。

• 新機能に関するすべてのPRに計測を含めます。PRテンプレートで「どのイベントを発火させますか？」と尋ね、回答が「なし」の場合はPRを却下します。
• 四半期ごとにスキーマを監査します。孤立したイベント（発火しているものの、どのダッシュボードやクエリでも使われていないイベント）を特定して廃止します。欠落箇所（イベントのない機能）を特定して補います。
• 「測定できないものはリリースしない」を原則とし、計測コストがデータの価値を上回る真に実験的な機能については、明示的な例外を設けます。

詳しくは、references/instrumentation-audit-checklist.md を参照してください。

---

よくある失敗パターン

プロダクト分析の設定では、12のパターンが繰り返し見られます。要点は以下のとおりです。

• 「データはあるのに、信頼できません。」命名とスキーマのずれが原因です。スキーマを監査し、命名規則を徹底して解決します。
• 「ファネルでは80％が離脱していますが、実際のコンバージョンは問題ありません。」アンカーイベントまたは期間の設定が誤っています。ファネルの定義を見直してください。
• 「リテンション曲線が5％で横ばいです。」多くの場合、問題ではありません。パワーユーザー向けのプロダクトでは、実際にエンゲージメントの高いユーザー層が小さいことがあります。改善対象と判断する前に、ビジネスの実態と照らし合わせてください。
• 「Mixpanelではコンバージョンが1000件ですが、データウェアハウスでは800件です。」アトリビューションとIDの統合方法に不一致があります。正規の数値を得るには、データウェアハウスと照合してください。
• 「ダッシュボードの読み込みに30秒かかります。」範囲が広すぎるクエリ、インデックスのないプロパティ、またはスキーマの肥大化が原因です。プロファイリングしてリファクタリングしてください。
• 「MAUの定義が人によって違います。」正規の指標を定義した文書がありません。文書を作成し、全員が同じ定義を使うよう徹底してください。
• 「すべてのボタンクリックをトラッキングしています。」UIのノイズです。監査を行い、どのダッシュボードやクエリでも使われていないイベントを削除してください。
• 「イベント名が3回も変わりました。」バージョン管理がありません。バージョン管理のパターンに移行し、それ以上の名称変更は凍結してください。
• 「分析ツールではiOSユーザーのコンバージョン率が3％ですが、データウェアハウスでは5％です。」SafariのIntelligent Tracking Prevention（macOSを含むすべてのAppleプラットフォーム）と、モデル化されたコンバージョンが原因です。Safariのプラットフォームデータは特に慎重に扱ってください。
• 「簡単な質問にも答えられません。」計測が不十分か、抽象化レイヤーが適切ではありません。チームが尋ねている質問とイベント一覧を照らし合わせて監査し、不足分を補ってください。
• 「アナリスト2人が異なるMAUを算出しています。」IDの統合方法が異なります。正規のIDレイヤーを1つ選び、全員がそこからクエリするようにしてください。
• 「理由もなく、前四半期から数値が変わっています。」基盤となるスキーマがバージョン管理なしで変更されました。ダッシュボードがひそかに壊れていましたが、差が大きくなるまで誰も気づきませんでした。

詳細はreferences/common-failures.mdをご覧ください。

---

フレームワーク：信頼できるプロダクト分析のための12の考慮事項

プロダクト分析を設計または監査する際は、以下の12の考慮事項を順に確認してください。どれか1つでも抜けると、チームは誰も信頼しないデータを抱えることになります。

1. イベント分類。 過去形で、オブジェクトとアクションを組み合わせ、細かくしつつ重複を避けます。動詞はイベント、状態はプロパティです。
2. プロパティの設計。 イベントレベルかユーザーレベルかを決めます。型を厳密に管理します。タイムスタンプにはすべてISO 8601を使います。
3. 命名規則。 1つ選び、徹底します。特に理由がなければsnake_caseを使います。
4. スキーマのバージョン管理。 追加的変更と破壊的変更を区別します。移行中は_v2のサフィックスを使います。データコントラクトをコードで管理します。
5. IDの統合。 匿名から認証済みへの移行、デバイス間、ツール間の統合に対応します。正規のIDレイヤーを1つにします。
6. ファネルの設計。 インテントの高いイベントをアンカーにします。期間を文書化します。自動発火するイベントをステップに含めないでください。
7. コホートの定義。 再利用可能で、バージョン管理され、同じ条件で比較できるようにします。コードまたはツール内で定義します。
8. リテンションの測定。 安定性を高めるため、N日間の範囲で測定します。経過期間をそろえてコホートを比較します。
9. ノーススター。 ユーザー価値を捉え、不正操作が難しい指標にします。NSMは1つ、入力指標は3～5個、健全性指標は5～10個にします。
10. ダッシュボードの管理。 定義、データソース、担当者、更新頻度を明記します。古くなったダッシュボードは廃止します。
11. 計測の負債。 すべてのPRに計測を含めます。四半期ごとに監査します。
12. 信頼できる唯一の情報源。 取締役会向け指標にはデータウェアハウスを使います。進行中の最適化にはツールを使います。数値が一致しない場合は照合します。

このフレームワークから、トラッキングプランが作成されます。各プロパティを含むイベントの一覧、正規のユーザーID、名前付きコホート、名前付きファネル、リテンション測定方法の選択、名前付きNSM、ダッシュボードの担当者が記載されます。プランはコードで管理し、ほかのプロダクト仕様と同様にレビューします。

---

必要なデータを入手できない場合

このスキルの出力は、それ自体では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められる出力は、何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを明記した成果物です。成果物を完成させるために、必要な数値を捏造、推定、または補間することは、決して認められません。欠落を明記すれば、それだけで完全な回答です。

---

参照ファイル

• references/event-taxonomy-template.md - 一般的な SaaS 向けの標準イベント仕様：アカウント、ユーザー、アクティベーション、エンゲージメント、コンバージョン、リテンションのイベントと必須プロパティ。
• references/property-design-patterns.md - イベントレベルとユーザーレベルのパターン。型の規律。実例：product_viewed の適切な例と不適切な例。
• references/naming-convention-reference.md - 完全なスタイルガイド。snake_case、過去形、オブジェクト-アクション形式。ブール値の接頭辞。金額はセント単位。_at サフィックスを付けたタイムスタンプ。推奨事項と非推奨事項の対比。
• references/schema-versioning-patterns.md - 追加変更と破壊的変更。_v2 サフィックスのパターン。TypeScript のデータ契約。CI のリントパターン。
• references/funnel-design-templates.md - アクティベーション、コンバージョン、エンゲージメント、機能採用のファネル。時間枠、アンカーイベント、離脱の解釈。
• references/cohort-definition-patterns.md - 獲得、行動、プロパティ、複合コホート。SQL の例とツール固有の例。
• references/north-star-metric-selection.md - プロダクトの種類別の例を含む NSM のルール。アンチパターン。NSM を変更する際の移行パターン。
• references/instrumentation-audit-checklist.md - 四半期ごとの監査手順：スキーマレビュー、イベント量の妥当性確認、ダッシュボードの鮮度、担当者の監査、廃止候補の特定。
• references/common-failures.md - 症状、根本原因、修正、予防策を含む 12 の失敗パターン。

---

まとめ：迷ったら、計測を減らす

多くのプロダクト分析の設定は、計測が不足しているのではなく、過剰です。すべてのボタンのクリックを追跡すると、ノイズがシグナルをかき消します。「念のため追跡しよう」と言うよりも、「それを追跡する必要はありません」と言うほうが難しいものです。基本的には、計測を減らしましょう。

手元にないデータは、後から追加できます。過剰に収集したデータは、ダッシュボードのパフォーマンス、スキーマの複雑さ、シグナル対ノイズ比という形で、いつまでもコストになります。適切に設計した 30 個のイベントと少数の名前付きコホートでリリースするチームは、200 個のイベントを用意しながらコホートの規律がないチームを上回ります。

イベントを追加するかどうかでチームの意見が分かれたとき、問うべきなのは「役に立つ可能性があるか？」ではなく、「このイベントは具体的にどのような意思決定に役立つのか。そして、その意思決定は計測コストに見合うのか？」です。答えが「知っておきたいと思うかもしれない」なら、その問いへの答えは「いいえ」です。