Product Analytics
RUM と同じ SDK が集めた利用者の行動を、ファネルやリテンションの形で読み解く製品です。「速いか、壊れていないか」を見る RUM に対し、「誰が何をして、どこで離脱したか」に答えます。
何ができるか
ブラウザーとモバイルの SDK が記録するセッション、ビュー、アクションと、API で送るサーバー側イベントを材料に、機能の利用状況、コンバージョン率の推移、利用者の経路、セグメント別の定着を分析します。行動データは既定で 15 ヶ月保持され、RUM を設定済みなら再計装なしに有効化できます。
どのような場面で使うか
「新機能を出したが使われているのか」「申し込み導線のどの段階で人が消えるのか」「初週に離脱した利用者は何を踏んでいたのか」を数字で答えるときに使います。性能の遅さが離脱に効いているかを、同じセッションの RUM データと並べて確かめられるのが持ち味です。
身近な例え
店内の見回り (RUM) が「棚は倒れていないか、レジは動いているか」を確かめる仕事なら、Product Analytics は同じ売り場で客の動線を数える調査です。どの通路を通り、どこで手に取って棚に戻したかを集計し、レジまで来た人の割合を週ごとに追います。
RUM が答える問いと Product Analytics が答える問いは別物
RUM を入れると、ページの表示に何秒かかり、どこでエラーが出たかが利用者の実セッションから分かります。ところが「申し込みフォームの 3 ページ目で半分が消える」「先月リリースした機能を触った人は 1 割しかいない」という問いには、性能とエラーの数字だけでは答えられません。Product Analytics はこの問いを引き受ける製品で、公式ドキュメントは用途を、製品の採用状況の把握、コンバージョン率とその推移の追跡、主要な行動パターンの把握、利用者の操作の可視化、の 4 つで説明しています (2026 年 9 月時点・出典: Product Analytics)。材料は RUM と同じ SDK と同じ設定で集められ、RUM を設定済みのアプリなら再計装は不要です。有効化はアプリの設定画面で Enable を押すだけで、「速いか」と「使われているか」を同じセッション ID の上で突き合わせられる点が、別の解析ツールを横に置く構成との根本的な違いになります。
分析の道具はどれで何を答えるか
Product Analytics の画面は、答えたい問いごとに道具が分かれています。公式ドキュメントが挙げる機能と、それぞれが答える問いを並べます (2026 年 9 月時点・出典: Product Analytics)。
| 機能 | 答える問い | 公式ドキュメントの例 |
|---|---|---|
| Engagement | どの機能がどれだけ使われているか | 製品の採用状況の把握 |
| Funnel | 主要な導線のどの段階で離脱が起きるか | 性能の悪さで特定の段階から離脱していないか、工程を増やすと離脱率がどう変わるかを見る |
| Pathways | 利用者が実際にどの順でページを移動しているか | 全ての利用者経路を可視化し、主要な経路 (critical path) を分析する |
| Retention | 初回利用後にどれだけの人が戻ってくるか | 利用者がページや操作にどれだけ戻ってくるかを測る |
| Users & Segments | 共通の特徴を持つ利用者群は誰か | カートに入れたが購入しなかった人のセグメントを作り、後押しのメールを送る |
| Heatmaps | ページのどこがクリックされ、どこまでスクロールされたか | Click maps / Top elements / Scroll maps の 3 種を Session Replay のデータに重ねる |
この表で押さえたいのは、Funnel の例に「性能の悪さで離脱していないか」が入っている点です。離脱の原因が UI の設計なのか読み込みの遅さなのかは、行動データと性能データが別のツールにあると突き合わせに手間がかかります。Heatmaps が Session Replay の記録に重なるのも同じ発想で、「どこで止まったか」を数字と実画面の両方で見られます。
データの単位 - セッション / ビュー / アクション / サーバー側イベント
SDK が自動で集めるのは 3 段階の単位です。セッションは利用者がアプリを開いてから離れるまでの 1 回の訪問全体、ビューはその中で訪れた各ページや画面、アクションはクリック、タップ、スクロールといった操作を指します (2026 年 9 月時点・出典: Product Analytics)。セッションは無操作 15 分か連続 4 時間で終わり、Synthetics のブラウザテストによるセッションは課金から除かれます (出典: RUM Browser Data Collected)。数え方と課金への効き方は RUM の解説に委ねます。Funnel や Segments はアクションを段階や条件に選ぶため、「購入ボタンのクリック」のような業務上の意味を持つ操作に名前が付いているかが分析の質を決めます。決済完了や注文処理のようにブラウザーでは観測できない出来事は、Product Analytics API でサーバー側イベントとして送れます。別途課金で、単価は料金ページの記載に従います。
保持 15 ヶ月が行動データで意味を持つ理由
Product Analytics のデータは既定で 15 ヶ月保持されます (2026 年 9 月時点・出典: Product Analytics)。Retention は「初回利用から 1 ヶ月後、3 ヶ月後にどれだけ戻ってきたか」を利用開始月ごとの群 (コホート) で追うので (出典: Retention Analysis)、保持が短いと比較する群が揃いません。年に 1 回しか動かない導線 (年次更新のような手続き) は、前年同期の Funnel が残っていなければ改善を判定できません。個々のセッションを検索する RUM Investigate の保持が 30 日である (2026 年 8 月時点・出典: Datadog Pricing) のと対照的に、Product Analytics は集計して長く残す側に寄せた製品と読めます。有効化から 15 ヶ月分が貯まるまで Retention の一部が使えないため、導入の適期は「分析したくなった時」ではなくその 1 年前です。
課金は 1,000 セッション単位で、Session Replay と二重にならない
課金単位は 1,000 セッションで、単価は年契約・月契約・オンデマンドの 3 形態で異なります (2026 年 8 月時点の SKU 区分・出典: Datadog Pricing)。対象は全トラフィックで、行動データの保持は 15 ヶ月です。RUM 側の SKU と並べると位置づけがはっきりします。具体的な単価は Datadog 公式の料金ページで確認してください。
| SKU | 課金単位 | 対象と保持 | 主な注意点 |
|---|---|---|---|
| RUM Measure | 1,000 セッション / 月 | 全トラフィック / メトリクス 15 ヶ月 | 性能と安定性の計測に絞った層 |
| RUM Investigate | 1,000 セッション / 月 | フィルター後のセッションのみ / 30 日 | 深掘りする対象を絞った分だけ数える |
| Product Analytics | 1,000 セッション / 月 | 全トラフィック / 行動データ 15 ヶ月 | 本記事の対象。全セッションが基数 |
| Session Replay 追加 | 1,000 セッション / 月 | 再生 30 日 | RUM と Product Analytics の双方で使っても課金は 1 回 |
見積の要点は 2 つです。まず、Product Analytics は全トラフィックが対象なので、月間セッション数をそのまま 1,000 で割って単価を掛ければ月額が出ます。Synthetics のブラウザテストによるセッションは課金対象外です (出典: RUM Browser Data Collected)。次に、Session Replay を Heatmaps のために使う場合でも、RUM 側で既に Session Replay を契約していれば二重に払うことはありません。料金体系全体の読み方は料金体系の読み解き方に委ねます。
Web 解析ツールとの役割差はどこにあるか
Web 解析ツールはマーケティングの成果測定が出発点です。Product Analytics が答える問いはその一部と重なりますが、隣に置かれているデータが違います。同じセッションに RUM の表示時間とエラー、Error Tracking の Issue、APM のトレースが結び付いているため、「離脱率が上がった」という観測から「その週にこの API の遅延が増えていた」という原因側へ、ツールを跨がずに移れます。逆に、広告の流入経路ごとの成果や検索エンジンからの集客の分析は Web 解析ツールの本領で、Product Analytics が UTM 属性を持つとしても置き換えを狙う位置にはありません (UTM 属性の収集は 2026 年 9 月時点・出典: RUM Browser Data Collected)。役割の線引きは「利用者を連れてくるまで」と「連れてきた後にアプリの中で何が起きたか」で、後者を性能や障害の文脈と一緒に読みたい組織に向いた製品です。
入れるべきか、見送るべきか
導入の判断は RUM を既に使っているかどうかで大きく変わります。RUM が入っていれば計装は済んでおり、有効化の操作だけで始められます。
- 1. RUM を設定済みのアプリで Product Analytics を有効化する (再計装は不要)
- 2. 業務上の意味を持つアクション (購入、申し込み、保存) に名前を付け、Funnel を 1 本だけ定義する
- 3. 1 ヶ月分のデータで Funnel の離脱段階を確かめ、同じセッションの RUM 性能データと並べて原因を切り分ける
- 4. 離脱した利用者のセグメントを作り、対策後の同じ Funnel で効果を測る
- 5. Retention の比較に必要な期間 (数ヶ月〜15 ヶ月) を見込み、データが貯まるまでは Funnel と Pathways を主に使う
見送る条件も明確です。利用者の操作がほとんど無い静的な情報サイトでは、Funnel に置く段階が存在しません。セッション数が多くても、分析結果を受けて UI や導線を変える権限と体制が組織に無ければ、15 ヶ月分のデータは眺めるだけの資料になります。個人情報の扱いについては、収集する属性とマスキングの設計が Session Replay と共通の論点になるため、そちらの整理を先に済ませてから有効化する順序を勧めます。
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。機能名と画面構成は変わり得るため、迷ったら画面の表示と公式ドキュメントの記載を優先してください。
- 本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
- サーバー側イベントは Product Analytics のセッション課金とは別に課金されます (2026 年 9 月時点)。単価は公式料金ページで確認してください。