「ダッシュボードが使われない」を解決する

パワー・インタラクティブでは、GA4の行動データ・Salesforceのリード/商談・Marketoのナーチャリング履歴をBigQueryに集約する作業を先行して進めてきた。購買シグナルの可視化も、この基盤の上に成り立っている。
「集める」段階は一段落した。次の問いは「集めたデータをどう見せるか」だ。可視化ツールとして選んだのはLooker Studioだった。GoogleがBigQueryなどと合わせて無償提供しているBIサービスで、GA4やGoogleスプレッドシートとの接続が簡単なうえ、BI未経験者でもドラッグ操作で画面を組み立てやすい。BigQueryを基盤に選んだ流れからすれば、立ち上げ時の選択としては自然なものだった。
しかし、運用を始めてみると予期しない壁に突き当たった。

ダッシュボードが使われなくなる理由を、私たちは運用の中で二つ特定した。どちらも「ツールの問題」ではなく「設計の問題」だ。

原因①　指標の変化スピードに更新が追いつかない
月ごと・テーマごと・会議の議題ごとに「見たい指標」は変わる。新しい指標を1つ追加するたびにLooker Studio側でデータソース設定の見直し・計算項目の再定義・レイアウト調整が発生し、変化に追従できなくなった。「見たいものが見られない」状態が続けば、ダッシュボードはやがて開かれなくなる。

原因②　立場が違えば「見るべきもの」が違う
候補となる指標を洗い出すと、すぐに二桁を超えた。しかもマーケ担当者が知りたいのは「どのチャネルが商談に効いたか」、営業・ISが知りたいのは「どの企業の誰がフォローされていないか」——立場が変われば視点が変わる。1つのダッシュボードに収まる量でも粒度でもなかった。

「指標の数の多さ」と「立場ごとに違う視点」が同時に存在していた——これが本当の課題だった。ツールを変えても、この二つを解決しない限り同じ問題は繰り返す。

Looker Studioでの単一ダッシュボード構築を一度立ち止まって見直し、「マーケティング視点」と「ABM視点」で2系統に分割し、それぞれの内部に複数ページを持たせる構成で再設計した。
実装ツールもLooker Studioの設定画面から、Google Apps Script（GAS）による内製に切り替えた。クエリと描画ロジックをコードで管理することで、新しい指標やページの追加を短いコード変更でこなせるようになり、「指標の変化スピードへの追従」という原因①を構造的に解消した。

設計の根本的な問いは「どうツールを使うか」ではなく「誰が・何の判断をするために・何を見るか」だ。読み手の問いに合わせて設計したダッシュボードは、会議に自然に組み込まれ、運用が定着する。

マーケティングダッシュボード：「どの施策が効いているか」を問いの中心に

マーケティングダッシュボードは、BigQueryに集約したGA4の行動データを起点に、複数の問いに複数のページで答える構成だ。

流入チャネル別セッション・CV状況
どのチャネルからどれだけ来て、どれだけコンバートしているか。週次・月次でチャネルミックスの変化を追う。

ランディングページのパフォーマンス
各LPの閲覧数・直帰率・CV率を並べ、「効いているページ」と「改善が必要なページ」を即判断できる。

ターゲット企業からの流入確認
LBC（企業情報解析ツールplus）は、Webサイトへのアクセスログに対して「どの企業からの訪問か」という企業属性情報を付与するツールだ。このLBCをGA4と連携させることで、匿名だったアクセスデータに企業名・業種・規模などの属性が紐づく。その結果、マーケティングダッシュボード上で「ICPとして定義したターゲット企業が実際にサイトを訪れているか」「どのページに関心を持っているか」を、流入チャネルやCV状況と同じ画面で確認できる。

LookerStudioで感じていた「指標の組み合わせや並び順がレイアウトに縛られる」部分を、GAS実装に切り替えたことで自由に組み立てられるようになった。マーケのレビュー会で「今月どこから来て、何に転換したか」を5分で共有できる状態が実現している。

ABMダッシュボード：「次に動くべき相手」を主役にする

ABMダッシュボードは、BigQueryで結合したGA4・Salesforce・Marketoのデータを起点に、「取りこぼし」を見つけるための画面だ。ここで最も重要な設計判断を一つ紹介する。

主役のページに置いたのは「リード一覧」ではなく「フォロー漏れ一覧」だ。一般的なダッシュボードは「全体像を見せる」ことに寄りがちだ。しかし現場が本当に欲しいのは「次に動くべき相手」だ。Marketoの行動シグナル（資料ダウンロード・特定ページ閲覧・メール開封）とSalesforceのリードステータス・最終接触日を結合し、「明確に動いているのに営業の手がまだ伸びていないリード」を浮かび上がらせる。

ABMダッシュボードは複数ページで構成し、それぞれ「いま見たい切り口」に素早くたどり着けるよう設計した。

フォロー漏れ一覧（主役ページ）
行動シグナルが上がっているのに、一定期間営業アクションがないリードを自動抽出。週次営業会議の冒頭で「今週誰に動くか」が即決できる。

ラストタッチ＋手前の接点確認
ラストタッチで効いている経路と、その手前のウェビナー・メール・コンサル接点を合わせて確認。BtoBの長い検討期間では「最後のクリック」だけでなく手前の積み重ねが商談につながるため、同一アカウントの文脈で読む。

コンサル接点との重複確認
コンサルタントがすでに関わっているリードかどうかを可視化。同一企業への重複アプローチや連絡漏れを構造的に防ぐ。

「誰がフォローされていないか」という問いは、一見するとオペレーション上の管理の話に見える。しかしBtoB購買の現場では、担当者1人だけを追っていると、その背後で動いている決裁者や関係部署への接触が抜け落ちる。フォロー漏れの正体は多くの場合、「その企業内で本来アプローチすべき人物に、まだ届いていない」という状態だ。誰が関わっているかを把握し、まだ接触できていない人物を特定して動く——これは購買に関わる組織全体を「面」で捉えるアプローチと、同じ考え方の上に成り立っている。ダッシュボードの「フォロー漏れ一覧」は、そのための実務的な入口だ。

設計時は指標選びに時間を使った。しかし運用が始まると、論点は「会議のどこで開くか」「誰が責任を持つか」に移った。ダッシュボードは作った瞬間に完成するのではなく、会議の構造に組み込まれた瞬間に初めて機能し始める。

この運用の形に落ち着いたのは、試行錯誤の結果だ。最初から設計通りに定着したわけではない。「どの会議で・誰が・何を決めるために見るか」を何度か調整して初めて、ダッシュボードは組織のリズムに噛み合った。

定量的なインパクトの検証は継続中だが、運用定着と同時に会話の質・判断の構造が変わった。

「マーケと営業の会話の質が変わった」「営業会議の冒頭5分でその週の優先連絡先が決まるようになった」——地味な変化に見えても、毎週の意思決定に効くという意味では小さくない手応えがある。

この実践から得た示唆を、他社が応用できる形で整理する。

示唆①
基盤の上に「小さな画面」を置く
BigQueryなどのデータ基盤が整っていれば、可視化レイヤーは後から差し替えられる。壮大なBIシステムではなく、目の前の問いに合わせた「小さな2〜3枚」から始める発想が定着への近道。

示唆②
「全体像」より「次のアクション」を主役にする
フォロー漏れ一覧を主役にしたことが、運用定着の最大の要因だった。ダッシュボードの価値は「データを見せること」ではなく「判断を速めること」。何を主役にするかという編集判断が、使われるかどうかを左右する。

示唆③
既製BIツールとの棲み分けを先に決める
全社で長期運用する標準レポートや複雑なBIワークロードは専用ツールに任せる。GASによる内製ダッシュボードは「自社の問いに合った、自分たちの順番の画面」をBigQueryの上に重ねるもの。用途の境界を最初に引くことが重要。

本稿の要点を整理する。

①ダッシュボードが使われなくなる根本原因は「指標変化への追従不能」と「立場ごとの視点の違い」の2つ。ツールの問題ではなく設計の問題だ。
②Looker Studioの単一構築から、マーケ系・ABM系の2系統GAS内製へ切り替え。目的別の複数ページ構成にすることで追従性と視認性を両立した。
③ABMダッシュボードの主役を「リード一覧」ではなく「フォロー漏れ一覧」にしたことが、運用定着の最大の要因だった。「次に動くべき相手」を主役にする編集判断が鍵。
④会議への組み込み方を決めること——「誰が・どの会議で・何を決めるために見るか」——がダッシュボード定着の最終条件だ。

データ基盤をお持ちの企業様には、壮大なBIシステムではなく、目の前の問いに合わせた小さな2〜3枚から始めることをお勧めしている」——これが、私たちが実践から得た最もシンプルな結論だ。

データ活用の「次の一歩」を考えている方へ
パワー・インタラクティブでは、BigQuery基盤をすでにお持ちの企業様の目的別ダッシュボード設計・構築支援はもちろん、「まだBigQueryを導入していない」という段階からの基盤構築支援にも対応しています。「データは集まっているが活用できていない」「どこから手をつければいいか分からない」という状況でも、お気軽にご相談ください。
▶ 無料相談・お問い合わせはこちら　https://pages.powerweb.co.jp/consultant.html