この記事は、業務ごとに Codatum Notebook の使い方を紹介する「Codatum Notebook活用シリーズ」の1本です。今回は、B2B SaaS のプロダクトレビューで、実データ、考察、仮説、次アクションを同じ流れに置く使い方を扱います。

B2B SaaS のプロダクト分析では、数字を見ることそのものよりも、そこから得たユーザー理解を翌週へ積み上げていくところで難しさが出ます。

サインアップから初回価値到達までのファネルを見て、オンボーディング後のリテンションを見て、主要機能の利用率を見る。さらに、プラン、会社規模、導入経路、ユーザーのロールごとに落ち込みを確認する。

そこまでは、すでに見方が固まった KPI ビューでも確認できます。ただ、週次レビューではさらに、ユーザーがどこで迷い、どの行動が継続につながり、翌週どの施策を試すのかまで扱いたくなります。

実際には、この数字とユーザー理解が分かれがちです。

ファネルは BI ダッシュボードにあり、集計条件は別の場所にあり、考察は Notion にあり、PdM とデータチームの議論は Slack に流れていく。週次レビューのたびに同じ数字を見ているはずなのに、前回どのユーザー行動を問題だと見たのか、どの仮説を残したのかは後から追いにくくなります。

B2B SaaS の週次プロダクトレビューを Codatum Notebook にまとめると、ファネル、リテンション、機能利用率を同じ文脈で見ながら、実際のデータ、チャート、考察、コメント、Agent の支援をひとつのレビュー単位にできます。

同じ Notebook に数字だけでなく、定義、解釈、仮説、次アクションまで残しておくと、ユーザー理解が単発の調査で終わらず、週ごとに積み上がっていきます。

週次レビューでは、実際のデータで根拠を残し、チャートで変化を見て、Agent で要約し、コメントで次の仮説や施策を残します。この記事では、その最小構成として「Weekly Product Review」という 1 つの Notebook を作る流れを扱います。

なぜユーザー理解が積み上がりにくいのか

B2B SaaS のプロダクト分析が散らばる背景には、見るべき数字の多さだけでなく、指標同士の関係を同じ場所で見にくいという問題があります。関係が見えないと、「ユーザーはどこで迷っているのか」「どの行動が継続につながっているのか」という理解が毎週リセットされます。

activation rate が下がったとき、単純に「サインアップ後に初回価値へ到達した割合」を見れば、下がったことは分かります。原因を考える段階では、少なくとも次の観点を同時に見たくなります。

• どのファネルステップで落ちているのか

• 新規ユーザー全体の問題なのか、特定セグメントの問題なのか

• 会社規模、プラン、導入経路、ロールごとに差があるのか

• その変化は Week 1 retention や Week 4 retention に影響しているのか

• 主要機能の利用率と継続率に関係があるのか

• 先週打った施策やリリースとタイミングが合っているのか

固定化された KPI ビューは定点観測に向いていて、毎週同じ数字を見て、上がったか下がったかを確認する場面では力を発揮します。

一方でプロダクトレビューでは、「なぜ変わったのか」「どこまで調べたのか」「ユーザー行動について何を学んだのか」まで扱いたくなります。この部分は、数字を眺めるだけだと残りにくいところです。

Slack で「この数字、先週も落ちていましたっけ？」と聞かれ、BI を開き、集計条件を探し、過去のメモを探し、前回の議論を思い出す。こうした往復が増えると、プロダクト分析はユーザー理解を深める作業ではなく、文脈を掘り起こす作業になってしまいます。

Notebook 上で見るべきユーザー行動

週次のプロダクトレビューでは、最初からあらゆる指標を詰め込む必要はありません。見すぎると、むしろ「ユーザーについて何が分かったのか」がぼやけます。

B2B SaaS で最初に 1 つの Notebook にまとめるなら、中心は次の 4 つに絞ると、ユーザー行動の変化を追いやすくなります。

アクティベーションファネル

アクティベーションファネルでは、サインアップから初回価値到達までの流れを見ます。

たとえば、典型的なステップはこのあたりです。

1. サインアップ

2. ワークスペース作成

3. 初回クエリ実行

4. 初回チャート作成

5. 初回インサイト共有

どのステップで落ちているかを見ると、オンボーディングの課題が見えやすくなります。

「サインアップは増えているが、ワークスペース作成で落ちている」なら初期設定に課題がありそうです。「初回クエリ実行までは進むが、初回インサイト共有に進まない」なら、分析結果をチームに共有する体験を見直す余地があります。

activation は単一の率に丸めず、ステップごとに見る方がユーザーのつまずきに近づけます。

コホート別リテンション

リテンションでは、プロダクトの価値が継続して届いているかを見ます。

B2B SaaS では、日次リテンションよりも、Week 1、Week 4、Week 8、あるいは月次の継続を見る方が実務に合うことが多いです。利用頻度が毎日とは限らず、チーム導入や業務サイクルの影響を受けるためです。

Week 1 retention が高いのに Week 4 retention が低い場合、初回体験は成功しているが、継続利用のユースケースに入れていない状態が疑われます。逆に Week 1 が低い場合は、最初の価値到達までを見直す必要があります。

activation と retention は別々に見るのではなく、つなげて見ます。どの activation イベントを経験したユーザーが、その後残っているのか。どの機能利用が継続率と関係しているのか。ここまで見ると、施策に落とし込みやすくなります。

機能利用率

主要機能の利用率は、プロダクト価値の仮説を検証するために見ます。

「この機能を使ったユーザーは継続しやすいはず」「この操作を完了したチームは有料化しやすいはず」という仮説があるなら、週次レビューでその状態を確認します。

Codatum に限らず、B2B SaaS なら候補になる行動はこのあたりです。

• 初回セットアップを完了した

• 主要機能を初めて使った

• 作成した結果をチームに共有した

• コメントやレビューで共同作業した

• 定期実行や通知を設定した

• 過去の分析や作成物を参照した

Codatum であれば、SQL ブロック作成、チャート作成、Notebook 共有、コメント、Workflow 設定、Agent による過去 Notebook 参照などが候補になります。

機能利用率を見る目的は、「使われている機能ランキング」を作ることではなく、継続、拡張、チーム利用につながる行動を見つけることです。

セグメント深掘り

全体平均だけを見ると、問題が見えなくなることがあります。

activation rate が 42% で横ばいに見えても、従業員 50 名未満のスタートアップでは改善し、500 名以上のエンタープライズでは悪化していることがあります。あるいは、セルフサーブ登録経由では落ちているが、営業支援ありの商談では安定している、という分かれ方もあります。

プロダクトレビューでは、最低限のセグメントを決めておくと議論が進みやすくなります。

• プラン

• 会社規模

• 導入経路

• ユーザーロール

• 業界

• 利用開始週

毎週すべてを見る必要はありません。数字が動いたときにすぐ深掘りできるよう、Notebook 内の GridPage にセグメント別 KPI を置いておくと、レビューの手が止まりにくくなります。

1 つの Notebook にまとめると、分析が単発で終わらない

週次プロダクトレビューを Notebook にまとめる価値は、複数のページにまたがる数字と文脈を、同じレビュー単位であとから読み返せる形にできるところにもあります。

Codatum の Notebook は DocPage と GridPage からなります。DocPage に SQL、集計条件、実データ、チャート、考察を残し、GridPage では DocPage の結果をタイル状に並べて見られます。週次レビューなら、たとえば次の要素を 1 つの Notebook にまとめられます。

• 今週のサマリー

• ファネル分析の集計条件と実データ

• ファネルステップ別のチャート

• コホート別リテンションの集計条件と実データ

• Week 1 / Week 4 / Week 8 retention のチャート

• 機能利用率の集計

• セグメント別 KPI をチャートやテーブルで並べた GridPage

• Agent が生成した週次要約

• PdM とデータチームのコメント

• 次アクション

これらが別々の場所にあると、レビューは「リンク集」になりがちです。Notebook にまとまっていると、数字、根拠、解釈、次の行動を同じ流れで読めて、前回の問いと今回の結果もつながります。そうすると、ユーザー理解が毎週少しずつ厚くなります。

この形で特に効いてくるのが、実際のデータと考察が同じ場所に残ることです。

プロダクト分析では、数字だけでなく、その数字をどう定義したかが効いてきます。activation の定義、対象ユーザー、除外条件、期間、セグメントが見えないと、翌週同じ数字を見ても比較できません。

集計条件を Notebook に残しておくと、「このチャートはどの条件で作られたのか」を確認できます。裏側で SQL を使う場合でも、人間が定義や対象期間を確認し、その結果と考察を同じ DocPage に残せます。

1 つの Weekly Product Review で学ぶこと

最初に作る Notebook は、複雑にしなくてかまいません。週次レビューで毎回見る場所として使うなら、構成はこのくらいに絞る方が続きます。

1. 今週のサマリー

2. アクティベーションファネル

3. コホート別リテンション

4. 機能利用率

5. セグメント深掘り

6. 判断 / 次アクション

今週のサマリー

冒頭には、今週の結論を短く書きます。

ここでは数字を並べるよりも、「ユーザー行動のどこが変わったのか」「どこを見るべきか」を書く方が役に立ちます。

サマリーはこのくらい短くてかまいません。

アクティベーションは 42.8% まで改善した一方で、Week 4 retention は 31.6% のまま横ばい。最も大きな落ち込みは、サインアップから初回プロジェクト作成の間に残っている。共有 Notebook を 1 つ以上作成したチームは、Week 4 retention が高い。

このサマリーがあるだけで、レビュー参加者は最初に見るべき場所を揃えられます。

アクティベーションファネル

次に、ファネルの集計条件とチャートを置きます。

ここでは、ステップごとのユーザー数と遷移率を出します。

実際の記事では、この例をそのまま正解として使うというより、読者に「何を activation と見なすのか」を Notebook 上に残すイメージを持ってもらうために使います。

Notebook 上では、ステップごとの遷移率をテーブルやチャートで見せます。レビュー時には、最も落ちているステップにコメントを残し、ユーザーがどこで止まっているのかをセグメント別に深掘りします。

コホート別リテンション

リテンションは、コホートごとに見ると変化が分かりやすくなります。

signup week ごとに Week 1、Week 4、Week 8 の継続率を並べると、どの時期に入ってきたユーザーの変化なのかを追いやすくなります。

retention は単独で眺めず、activation とつなげて読みます。activation のどのステップを通過したユーザーが残っているのか、主要機能を使ったチームが残っているのかを見ると、プロダクト改善の仮説につながります。

Notebook では、リテンションのテーブルやチャートの下に、分析メモを残します。

Week 4 retention は全体では横ばいだが、従業員 50 名未満のスタートアップアカウントでは 4.1pt 下がっている。落ち込みは、初週に共有 Notebook を作成しなかったアカウントに集中している。

こうしたメモが残っていると、翌週のレビューで「前回はどこまで分かっていたか」をすぐ確認できます。リテンションの見方が、単なる継続率の確認から、ユーザーが価値を感じ続けている条件を探す作業に変わります。

機能利用率

機能利用率は、主要機能の利用と継続の関係を見るために置きます。

初回セットアップ、主要機能の利用、共有、コメント、定期実行などの行動を一覧にします。単に利用率が高い順に並べるのではなく、継続率や拡張率との関係を見るのがポイントです。

ここで見たいのは、機能の利用数そのものよりも、利用と継続の関係です。

• 初回セットアップを完了したユーザーは Week 4 retention が高いのか

• 作成した結果を共有したチームは継続しやすいのか

• コメントやレビューが発生した分析は、次週も参照されるのか

• 定期実行や通知を設定したチームは、週次アクティブアカウントとして残りやすいのか

ここまで見ると、「どの機能を伸ばすべきか」ではなく、「どの体験を初期オンボーディングに入れるべきか」を考えやすくなります。機能利用率が、ユーザー理解を更新する材料になります。

セグメント深掘り

数字が動いたら、全体平均から少し離れてセグメントを見ます。

activation の落ち込みが見えたときに、次の切り口でセグメント別の結果を置いておきます。Codatum では、DocPage で作った結果を GridPage にチャート、テーブル、BigNumber として並べ、固定 KPI ビューのように見られます。

• plan

• company_size

• acquisition_channel

• role

• first_use_case

GridPage でセグメント別 KPI を見ながら、気になる変化にコメントを残す。必要なら、その場で条件を変えて深掘りする。ここまで Notebook 内で完結できると、レビューの流れが途切れにくくなり、セグメントごとの学びも残ります。

Agent はたたき台と要約に使い、人が根拠を確認する

プロダクト分析に Agent を使うときは、いきなり「答えを出して」と任せるより、役割を分けた方が安定します。

週次レビューなら、たとえば次の場面で使いやすくなります。

集計のたたき台を作る

「直近 4 週間のアクティベーションファネルを、signup、workspace_created、query_run、notebook_shared のステップで見たい」と依頼し、Agent に集計のたたき台を作らせます。

その結果はそのまま結論にせず、イベント名、対象期間、除外条件、ユーザー粒度、アカウント粒度を人間が確認します。

Agent は最初の作業を速くするために使い、定義の最終判断はプロダクトチームとデータチームが行います。

週次変化を要約する

チャートと実際のデータが Notebook にある状態なら、Agent に今週の変化を要約させられます。

プロンプトは、このくらい具体的にします。

今週のプロダクトレビューを要約してください。アクティベーションファネルの変化、Week 4 retention、機能利用率、プロダクトチームの次アクションに絞ってください。このページの実データで裏付けられない主張は入れないでください。

要約は Notebook 上の結果に基づかせます。一般論ではなく、ページ内の実データ、チャート、メモを参照して、レビュー用の叩き台を作らせます。

過去 Notebook を探す

プロダクト分析では、同じ論点が何度も出ます。

「初回クエリ実行の定義は前に変えたはず」「このオンボーディングの落ち込みは先月も見た気がする」「エンタープライズアカウントだけ別集計にした理由は何だったか」。こうした過去の文脈を探す作業は、Agent と相性が良い領域です。

Notebook が蓄積されていれば、Agent に過去の分析や定義を探させ、今週のレビューに引き戻せます。

ここでも最終判断は人間が行います。Agent には過去の文脈を見つけて、人間がレビューできる場所に持ってくる役割を持たせます。

コメントと共同編集で仮説を残す

週次レビューでは、数字を見たあとにどんな仮説を置き、何を試すことにしたのかまで残しておくと、翌週の見方が変わります。

アクティベーションファネルの落ち込みについて、PdM が次のようにコメントします。

サインアップからワークスペース作成までの落ち込みは、先週追加したオンボーディングステップの影響かもしれない。50 名未満のアカウントでだけ悪化しているか確認したい。

データチームがそのコメントに対して、セグメント別の集計を追加します。

会社規模の区分（company_size_bucket）で分けると、50 名未満（under_50）の workspace_created rate が 6.2pt 下がっている。50-200 は横ばい。

このやり取りが Notebook に残っていると、次のアクションも決めやすくなります。

• 50 名未満（under_50）のオンボーディングステップを見直す

• 初回クエリ実行までのチェックリストを追加する

• 来週同じセグメントで再確認する

Slack だけに流すと後から探しにくく、チケットだけにすると数字の根拠から離れます。Notebook 上にコメントとして残すと、数字、根拠、解釈、仮説、意思決定を同じ流れで追えます。

週次レビューをレポート化・定例運用につなげる

週次プロダクトレビューの Notebook は、作って終わりにしません。

チームで毎週見るなら、Workflow で定期的にレビューの準備や通知につなげられます。毎週月曜朝に最新の KPI を実行してサマリーを Slack に送り、レビュー前に PdM が Notebook を開いて気になる変化にコメントし、会議後に「判断 / 次アクション」を更新する、という流れです。

経営会議や事業レビューに持っていくなら、Report として共有する選択肢もあります。社外向けに見せる必要がある場合は、Guest 共有や Signed Embed のような配布の形も考えられます。

Notebook を「分析作業の置き場」で止めず、チームのレビューリズムに組み込みます。毎週同じ場所に数字があり、集計条件があり、考察があり、コメントがあり、次アクションがある状態が続くと、プロダクト分析は単発の調査ではなく、ユーザー理解を積み上げる運用になります。

固定ビューと分析レビューを分けて考える

ここでいう固定ビューとは、見方が固まった KPI を多くの人が同じ形で確認する画面のことです。Codatum では、この用途を Notebook 内の GridPage で担えます。

経営陣、営業、CS、マーケティングなど、多くの人が同じ KPI を見る場合には、チャートやテーブルを固定したビューとして見せる方が分かりやすい場面があります。

一方で、プロダクトレビューの途中では、まだ問いも見方も固まりきっていません。セグメント別の結果、チャート、メモ、コメントを行き来しながら、「どこを次に見るか」を決めていきます。この段階では、Notebook の中で DocPage と GridPage を行き来し、分析の流れごと残す方が扱いやすくなります。

役割を分けるなら、次のようになります。

• 固定ビュー: 安定した指標の定点観測、広い共有、閲覧中心

• Notebook: DocPage と GridPage を束ねるレビュー単位

• DocPage: 集計条件、実データ、チャート、考察、コメントを残すページ

• GridPage: DocPage の結果をチャート、テーブル、BigNumber としてタイル状に並べるページ

週次プロダクトレビューでは、DocPage で問いを深掘りしながら GridPage で結果を横断的に見ます。見方が固まった KPI は GridPage に整え、必要に応じて Report として配布する。こうすると、分析の途中経過を残す場所と、安定した指標を配布する場所を分けられます。

まとめ

B2B SaaS のプロダクト分析では、ファネル、リテンション、機能利用率を別々に見るだけでは、ユーザー行動の変化を捉えきれません。

数字を同じ文脈で見て、なぜ変化したのかを深掘りし、ユーザー行動について何を学んだのかまで残していく必要があります。固定化された KPI ビューは定点観測には強いものの、集計条件、考察、コメント、意思決定の流れは散らばりやすく、週次レビューでは分析の流れまで残せる場所が必要になります。

Codatum の Notebook では、DocPage に集計条件、実データ、チャート、考察、コメントを残し、GridPage では DocPage の結果をタイル状に並べて、固定 KPI ビューのように見られます。Agent は集計のたたき台、週次変化の要約、過去 Notebook の参照に使い、人間が定義と結果を確認する。そうやって PdM とデータチームが同じ Notebook 上で議論できると、ユーザー理解と次アクションも更新しやすくなります。

プロダクト分析は、正しい数字を見るだけでは終わりません。チームが同じ文脈を見て、同じ根拠からユーザー行動を理解し、翌週に学びを引き継げるところまで含めて考える必要があります。

毎週のプロダクトレビューを 1 つの Notebook にするだけでも、数字、問い、仮説、判断がチームの中に残り、ユーザー理解を積み上げやすくなります。

次の一歩

週次レビューの形が見えてきたら、次は定期配信や共有の運用に広げられます。社内のレビューを Slack に流すなら Workflow、社外や顧客に届けるなら Report / Guest や Signed Embed が次の候補になります。

Notebook活用シリーズ / 関連記事

• 顧客ヘルスレビューで契約更新前の会話を整える例は、CSチームの顧客ヘルスレビュー — Codatum Notebookで扱っています。

• 広告費から商談までを見直す施策レビューの例は、広告費から商談までを見直す — Codatum Notebookで扱っています。

• Agent に分析を任せるときのレビュー設計は、Data Agent の失敗を分解した記事で詳しく扱っています。

• 週次レビューを Slack に流す運用は、KPI の定期配信でチームのリズムを作る — Codatum Workflowにつなげられます。

• 経営会議や顧客向け共有では、社外向け分析レポートを安全に共有する — Codatum Report / Guestが近いテーマです。

• プロダクトに分析画面を組み込む場合は、顧客向けダッシュボードをプロダクトに埋め込む — Signed Embedを参照してください。