マーケティング施策を振り返る Codatum Notebook

By Codatum Team
Cover image of the article

Contents

この記事は、業務ごとにCodatum Notebookの使い方を紹介する「Codatum Notebook活用シリーズ」の1本です。今回は、B2Bマーケティングの施策レビューで、広告費、リード、MQL、SQL、商談、施策メモを同じ流れに置く使い方を扱います。

B2Bマーケティングの施策レビューでは、広告費とリード数だけを見ていると、次にどこへ予算を寄せるべきかが見えにくくなります。

今月は検索広告のCPAが下がった。ウェビナー経由のリードは少ない。ホワイトペーパーのCVRはよかった。ここまでは広告管理画面やMAのレポートでも追えます。ただ、B2Bのマーケターや代理店が本当に知りたいのは、その先です。

そのリードはMQLになったのか。営業がSQLとして受け取ったのか。商談になったのか。パイプライン金額は積み上がったのか。LP変更やクリエイティブ差し替え、ウェビナー後のフォロー、営業からのフィードバックは、数字の変化とどうつながっていたのか。

施策レビューが広告費とリード数で止まると、翌月の予算配分は「CPAが安いチャネルを増やす」「リード数が多い施策を続ける」という話に寄りがちです。けれどもB2Bでは、リードの量よりも、商談に進む質と、その施策から何を学んだかが次の打ち手を決めます。

マーケティング施策レビュー Notebook の流れ

Codatum Notebookにマーケティング施策レビューをまとめると、広告費、リード、MQL、SQL、商談化率、チャネル別ROI、施策メモを同じレビュー単位で扱えます。DocPageで施策メモと実データを残し、GridPageでチャネル別KPIを見て、SQLやExplorerで気になる施策を深掘りし、Agentで週次変化のたたき台を作る。代理店やクライアントに共有する内容はReport/Guestとして整えられます。

この記事では、B2Bマーケター、代理店、RevOps、データチームが週次または月次で見る「Campaign Review」というNotebookを作る流れを扱います。

Campaign Review Notebook

広告費とリード数だけでは次の予算を決めにくい

広告運用の画面だけを見ると、施策の評価はどうしても入口の数字に寄ります。

  • spend

  • impressions

  • clicks

  • leads

  • CPA

  • CVR

これらは大事な数字ですが、B2Bの施策レビューでは入口だけでは足りません。検索広告でリード単価が下がっていても、営業がフォローした時点で対象外が多ければ、次月に同じだけ予算を増やす判断はしにくい。逆に、ウェビナーや比較資料のダウンロードはCPAが高く見えても、SQL化率や商談化率が高ければ、営業と一緒に伸ばす価値があります。

施策の良し悪しは、広告管理画面の中だけでは完結しません。

MAにはフォーム送信やMQL判定があり、CRMにはSQL、商談、受注、失注理由があります。代理店側には入札変更やクリエイティブ差し替えのメモがあり、マーケティングチームにはLP改善やメールフォローの記録がある。営業からは「このリードは検討度が高い」「このキーワード経由はミスマッチが多い」という感触も返ってきます。

これらが別々にあると、月次レポートは「今月の結果」にはなりますが、「次に何を変えるか」の材料として弱くなります。予算を増やす、止める、訴求を変える、営業フォローを早める、クライアントに追加検証を提案する。そうした判断には、数字と施策メモを同じ流れで読める場所が必要です。

施策レビューで同じ文脈に置くもの

最初のCampaign Review Notebookでは、すべての指標を詰め込むよりも、予算と商談の間にある流れを追える状態にします。

まず置きたいのは、広告費から商談までの基本の列です。

  • spend

  • clicks

  • leads

  • MQL

  • SQL

  • opportunities

  • pipeline amount

  • cost per SQL

  • pipeline ROI

ただ、数字だけを横に並べても、次の打ち手は出てきません。そこに、いつ何を変えたかのメモを重ねます。

  • 検索広告の入札を強めた

  • LinkedIn広告で役職ターゲティングを変えた

  • LPのファーストビューを差し替えた

  • ホワイトペーパーの訴求を業界別に分けた

  • ウェビナー後の営業フォローを翌営業日に早めた

  • 代理店が除外キーワードを追加した

  • 営業から「このチャネルは課題感が浅い」というコメントが出た

施策メモと数字が同じNotebookにあると、「今月はSQL化率が下がった」で終わらず、「何を変えたあとに、どのチャネルで、どの段階が落ちたのか」を追いやすくなります。代理店とクライアントが同じ画面を見ながら話す場合も、数値報告から次の検証仮説へ進みやすくなります。

Notebookにまとめると、施策レビューが次の打ち手に近づく

CodatumのNotebookは、MarkdownとSQLを組み合わせた分析ドキュメントで、ドキュメントページ(DocPage)とグリッドページ(GridPage)で構成されます。

マーケティング施策レビューでは、DocPageに施策メモ、集計条件、実データ、チャート、考察を残し、GridPageでチャネル別KPIのダッシュボードを見ます。GridPageで気になるチャネルを見つけ、DocPageでその背景を確認し、必要ならSQLやExplorerで深掘りする流れです。

たとえば、Campaign Reviewの最小構成はこのくらいで始められます。

  1. 今週の施策サマリー

  2. Channel KPI Grid

  3. Spend to Pipeline

  4. Campaign Deep Dive

  5. MQL / SQL Quality

  6. Agency Notes / Next Budget

冒頭には、今週または今月の見方を短く置きます。広告費とリード数の増減に加えて、予算配分に関わる変化が最初に読める形にします。

Paid SearchはCPAが12%下がった一方で、SQL化率が8.4pt低下した。LinkedIn Adsはリード数は少ないが、Enterprise segmentのSQL化率が高く、pipeline ROIは最も高い。来月は検索広告の広いキーワードを絞り、LinkedInの役職ターゲティングを2パターン追加検証する。

このサマリーがあると、レビュー参加者は最初に見るべき論点を揃えられます。代理店、マーケティング責任者、営業、RevOpsがそれぞれ別の数字を見て話し始める状態を避け、同じ問いからレビューに入れます。

Channel KPI GridPage

GridPageには、チャネル別にspend、leads、MQL、SQL、opportunities、pipeline amount、pipeline ROIを並べます。ここは固定ビューとして使い、毎週同じ形で状態を見られるようにします。

一方で、なぜその数字になったのかを確認する部分はDocPageに残します。LP変更、ウェビナー実施、クリエイティブ差し替え、営業フィードバック、代理店コメントが同じページにあると、KPIの増減を施策の記憶と一緒に読めます。

広告費からパイプラインまでを同じ画面で見る

チャネル別の評価で最初に確認したいのは、「費用がどこまで商談につながったか」です。

リード数が多いチャネル、MQL化率が高いチャネル、SQL化率が高いチャネル、商談金額が大きいチャネルは必ずしも一致しません。リード単価だけを見ると検索広告を増やしたくなるが、商談金額まで見るとウェビナーや比較資料を伸ばしたくなる、ということはよくあります。

たとえば、次のような集計から始めます。

このSQLを見せたい理由は、読者にSQLを書かせるためではありません。広告費から商談までをどの条件でつないだのか、担当者が後から確認できる状態にするためです。

実務では、MQLの定義、SQLとして扱う条件、商談作成までの期間、同一企業からの複数リードの扱い、代理店費用をどこまで含めるかが効いてきます。Notebookに集計条件と結果が残っていると、「なぜこのチャネルを増やすのか」をチームで説明しやすくなります。

Spend to Pipeline

ここで大事なのは、チャネルの勝ち負けを急いで決めないことです。

たとえばPaid Searchはリード数が多く、CPAも低いかもしれません。ただ、広いキーワードを増やした月にSQL化率が落ちているなら、入札や除外キーワードの見直しが必要です。LinkedIn Adsはリード数が少なくCPAも高く見えても、Enterprise segmentで商談金額が積み上がっているなら、役職ターゲティングや訴求をさらに試す価値があります。

施策レビューでは、安いリードを探すより、商談につながる学びを見つける方が次の予算に効きます。

施策別に深掘りして、質の違いを見る

チャネル別のGridPageで気になる数字を見つけたら、施策別に深掘りします。

同じPaid Searchでも、ブランドキーワード、課題キーワード、競合比較キーワードでは、リードの質が違います。同じホワイトペーパーでも、経営層向けの資料と実務担当者向けの資料では、MQL化率や商談化率が変わります。

Codatumでは、DocPageに残した実データを見ながら、SQLやExplorerで条件を切り替えて確認できます。

  • channel

  • campaign_name

  • landing_page

  • offer_type

  • company_size

  • job_title

  • industry

  • first_touch / last_touch

この切り口を最初から全部見る必要はありません。レビューの中で「LinkedIn Adsはなぜpipeline ROIが高いのか」「ウェビナー経由のSQL化率が落ちたのは、テーマの問題か、集客チャネルの問題か」といった問いが出たとき、同じNotebookの中で条件を変えて見られることが重要です。

Campaign Quality Deep Dive

MQLやSQLの質を見るときは、マーケティングだけで完結させない方が実務に合います。

営業から「このキャンペーンのリードは予算感が合わない」「この業界は課題が明確で商談化しやすい」というコメントが返ってきたら、そのメモを数字の近くに残します。代理店が「広いキーワードを止め、比較系のキーワードに寄せる」と判断したなら、その理由も残す。

こうしておくと、翌月に数字を見返したとき、単に「SQL化率が上がった」だけでなく、「営業コメントを受けてターゲットを絞った結果、SQL化率が上がった」と読めます。施策の学びが数字と一緒に残るので、次の打ち手の精度も上がります。

Agentは変化と前回メモを集める

マーケティング施策レビューでAgentを使うときは、「来月の最適予算を決めて」と任せるより、担当者が確認すべき変化を集める役割にすると使いやすくなります。

たとえば、週次レビューの前にAgentへ次のように依頼します。

今週のCampaign Reviewを要約してください。チャネル別のspend、leads、MQL、SQL、opportunities、pipeline ROIを確認し、前回のAgency Notesに書かれた施策変更と数字の変化が対応している箇所を挙げてください。ページ内の実データで裏付けられない主張は入れないでください。

この依頼で欲しいのは、最終判断ではありません。担当者が短時間でレビューに入れるように、変化の候補を集めることです。

Agentの出力は、次のような形でNotebookに残します。

LinkedIn Adsはspendが前週比18%増え、leadsは横ばいでしたが、Enterprise segmentのSQL化率が31%から39%に上がっています。前回メモでは「VP Marketing向け訴求に変更」と記録されています。Paid Searchはleadsが増えた一方でSQL化率が8.4pt低下しており、広い課題キーワードの追加とタイミングが一致しています。担当者は検索広告のquery mixと営業コメントを確認してください。

この要約だけで予算を決めないよう、すぐ下に実データ、施策メモ、営業コメント、代理店の次アクションがある状態にします。担当者はAgentの要約を入口にして、根拠を確認し、必要ならコメントで補足します。

Agent Summary and Next Budget

Agentは、過去のNotebookや施策メモを探す役割にも向いています。

「このLPの訴求は前にも試したはず」「比較キーワードを止めた理由は何だったか」「前回のウェビナーで営業が何をコメントしていたか」。こうした記憶は担当者や代理店の個人メモに残りがちですが、Notebookに残っていればAgentが探しやすくなります。

Agentには、担当者が次の予算や施策を決める前に見るべき事実をそろえる役割を持たせます。マーケティング施策レビューでAgentを使うなら、この距離感が現実的です。

Report/Guestで代理店とクライアントの合意形成につなげる

施策レビューは、社内で眺めて終わるものではありません。代理店とクライアント、マーケティングと営業、RevOpsと経営が、次にどこへ投資するかを合意できてはじめて意味があります。

たとえば、月次レビューで次のような判断を残します。

  • 検索広告は広い課題キーワードを抑え、比較系キーワードに予算を寄せる

  • LinkedIn AdsはEnterprise segment向けに役職ターゲティングを2パターン追加する

  • ウェビナーはリード数よりSQL化率を重視し、営業フォローを翌営業日に固定する

  • ホワイトペーパーは業界別LPを2本追加し、MQL化率とSQL化率を分けて見る

この判断がNotebookに残っていると、翌月のレビューで「前回どこまで決めたか」を追えます。Slackやスプレッドシートだけに残すより、数字と同じ場所に置いた方が、代理店の担当者が変わっても前回までの経緯を引き継ぎやすくなります。

クライアントや経営に共有する内容は、社内の深掘りとは分けて整えます。Codatumでは、Notebookでレビューと深掘りを行い、共有用にはReportとしてストーリーを整え、必要に応じてGuest共有で届ける流れを作れます。

社内向けには、営業コメント、代理店の運用メモ、未確定の仮説まで扱います。クライアント向けのReportでは、今月の変化、商談につながったチャネル、次月の予算配分、検証する施策に絞る。この切り分けがあると、月次レポートが「数値の提出」で終わらず、「次に何を一緒に試すか」を決める場になります。

週次レビューをチームの運用にする

Campaign Reviewは、月末だけに開くレポートにすると、どうしても後追いになります。

次のような条件は、Workflowで週次アラートにできます。

  • spendが前週比20%以上増えた

  • leadsは増えたがSQL化率が一定以上下がった

  • pipeline ROIが高いチャネルで予算消化が止まっている

  • Enterprise segmentのMQLが増えている

  • 前回のAgency Notesにあるnext actionが未完了のまま残っている

毎週月曜の朝に該当チャネルを抽出し、マーケティング責任者、代理店、RevOpsにSlackで送る。レビュー前に担当者がNotebookを開き、必要なコメントを残し、会議では判断と次アクションに時間を使う。

この流れができると、施策レビューは「月末に数字を説明する時間」から、予算配分と商談創出を毎週調整するリズムに変わります。

固定ビューと深掘りを分ける

マーケティング施策レビューでは、全員で同じ形を見る画面と、データチームやRevOpsが深掘りする場所を分けると使いやすくなります。

GridPageは、チャネル別KPIを固定ビューとして見る用途に向いています。spend、leads、MQL、SQL、opportunities、pipeline amount、pipeline ROIのような列を並べ、毎週同じ形で確認できるようにします。

DocPageは、なぜその数字になったのかを深掘りする場所です。施策メモ、集計条件、実データ、営業コメント、代理店メモを残します。

Report/Guestは、クライアントや経営に見せる内容を整える場所です。内部コメントや未確定の仮説は含めず、共有したい変化、学び、次月の予算配分、合意したアクションに絞ります。

同じマーケティング施策レビューでも、社内レビュー、深掘り、クライアント共有では見せる粒度が違います。Notebookの中で固定ビューと深掘りを持ち、共有用にはReportとして切り出すと、マーケティング、営業、代理店、クライアントがそれぞれ必要な情報を受け取りやすくなります。

まとめ

B2Bマーケティングの施策レビューでは、広告費とリード数を見るだけでは次の予算を決めきれません。

広告費、リード、MQL、SQL、商談化率、チャネル別ROI、施策メモ、営業コメントは、それぞれ別々に存在していても、次の打ち手を決める前にはひと続きで読める必要があります。CPAが安い理由、SQL化率が落ちた背景、商談につながったチャネル、次に試す施策が同じ場所にあると、レビューは数値報告から予算配分と商談創出のための会議に変わります。

Codatum Notebookでは、DocPageに施策メモ、集計条件、実データ、考察を残し、GridPageでチャネル別KPIを見られます。SQLやExplorerで施策別・チャネル別に深掘りし、Agentは週次変化や過去メモ参照に使い、担当者が根拠を確認する。Report/Guestで共有へ、Workflowで週次アラートへつなげると、施策レビューがチームの運用になります。

マーケティング施策レビューは、過去の数字をきれいに並べるためだけのものではありません。どのチャネルが商談につながり、どの施策から何を学び、次の予算をどこへ寄せるかを決めるための仕組みです。

毎週のレビューを1つのNotebookにするだけでも、マーケティング、営業、RevOps、代理店が同じ根拠を見て動きやすくなり、次の打ち手の精度を上げやすくなります。

次の一歩

施策レビューの形が見えてきたら、次は共有と定例運用に広げられます。社内の変化確認をSlackに流すならWorkflow、代理店からクライアントへ届けるならReport/Guestが次の候補になります。

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