WebサイトのKPI設計で経営ダッシュボードを作る | 大阪府堺市・東京のWEBサイト制作会社

Webサイトの数字があるのに、意思決定に使えない。従業員10〜300名規模で計測が未整備な企業ほど、ここでつまずきます。理由は、Webサイトの指標が「経営が判断したいこと」と直結する形に設計されていないからです。

本記事では、KPI＝重要業績評価指標（目標に対する進捗を測るための指標）を、経営ダッシュボード＝経営判断に必要な指標を一画面で追える可視化画面に落とし込むための設計手順を解説します。あわせて、計測設計＝何をどのルールでデータ化するかを決めること、GA4＝Google Analytics 4（Web行動を計測する分析ツール）、タグ＝計測用のコード片の扱いに触れ、後工程で失敗しない前提を整理します。

ゴールはツール操作の説明ではなく、投資判断（何に、どの順で）を下せる状態を作ることです。そのために、効果だけでなく体制（責任の置き方）とリスク（数字が信用できない・運用されない）も含めて設計します。

マーケティング＝見込み顧客を増やすための施策設計と実行のことです。

経営視点で「見る数字」が揃わない理由

経営者や事業責任者が見たいのは、売上や受注だけではありません。「来月以降の先行きはどうか」「施策のどこが詰まっているのか」「どの投資が効いているのか」といった、打ち手の選択に直結する情報です。ところがWebサイトのレポートは、ページ閲覧数や流入経路など“行動の記録”に偏りがちで、判断材料に変換されていないケースが多いです。

よくある原因は次の4つです。

1つ目は、目的が曖昧なまま計測だけ始まることです。「問い合わせを増やす」「認知を上げる」だけだと、どの行動を成果として扱うか決めきれず、指標が増えて散らかります。
2つ目は、指標の定義が部署で揃っていないことです。例えば「問い合わせ」は、フォーム送信だけを指すのか、電話タップや資料請求も含めるのかで数が変わります。
3つ目は、計測の抜け・二重が混ざることです。タグが増え続けたり、サイト改修のたびに計測が途切れたりすると、数字の信頼性が落ち、最終的に見なくなります。
4つ目は、BtoB＝企業向け取引中心の商流に合わせた設計がないことです。検討期間が長く、関与者も増えやすいので、短期の行動指標と中長期の商談・受注指標をつなぐ設計が必要です。

この問題を解くカギは、「どの会議で」「誰が」「何を決めるために」数字を見るのかを固定することです。最低限、次の4点を揃えると、数値の議論が前に進みます。

指標名：会議で口にする名前を統一する
定義：何を含むか、いつ確定するか
更新頻度：毎日・週次・月次のどれで見るか
責任者：原因の切り分けと次の打ち手に落とす担当

KPI設計の全体像：目的→指標→定義→運用

KPI設計は、次の4ステップで考えると破綻しにくくなります。

1. 目的を“経営の言葉”で具体化する

目的は「売上を伸ばす」だけでなく、どの事業・どの顧客層・どの獲得手段で伸ばすのかまで落とし込みます。ここが曖昧だと、後から指標を追加して帳尻合わせになり、運用コストが膨らみます。
あわせて、KGI＝最終的に達成したい目標指標（売上や受注など）を1つ置き、KPIはその手前の進捗として設計します。

2. 目的に対する主要KPIを絞る

ダッシュボードは“見せたい数字の一覧”ではなく、“判断のための最小セット”です。主要KPIは意思決定の頻度が高いものから選び、補助指標は深掘り用に分離します。経営向けの主要KPIは、片手で数えられる範囲に収めると会議で迷子になりにくくなります。

3. 算出・定義を決め、データ源を特定する

同じ言葉でも計算式が違うと議論が崩れます。定義には「何を含むか」「いつの時点で確定するか」「例外はどう扱うか」を含めます。
データ源はWeb計測だけで足りないことが多く、営業側の管理データと役割分担が必要になります。Webの成果（問い合わせ）と営業の成果（商談・受注）をつなぐためのキー（例：問い合わせIDや発生日）を持てるかが重要です。

4. 運用（見る・直す・更新する）を仕組みにする

KPIは作って終わりではありません。週次・月次で誰が見るか、異常値が出たときに誰が原因を切り分けるか、タグ変更やサイト改修時に誰がテストするかまで決めて初めて機能します。

以下は、目的別にKPIを整理するためのテンプレです。まずはこの形で社内の言葉を揃えると、後工程（計測設計・ダッシュボード構築）の手戻りが減ります。なお、LP＝ランディングページ（広告や検索から最初に到達する専用ページ）です。

目的（最終目標）	主要KPI	算出・定義	使う場面
受注を増やす	商談化数	問い合わせのうち、営業が商談として登録した件数	月次の投資配分、営業/マーケティング連携
問い合わせの質を上げる	有効問い合わせ率	問い合わせ全体のうち、対象業種・規模など条件を満たす割合	施策の当たり外れ判断、LP改善
既存顧客のアップセル	既存顧客の再訪→接点数	既存顧客向けページの再訪と問い合わせ/資料請求の合計	コンテンツ更新、メール施策の評価
採用を強化	応募到達数	採用ページ閲覧から応募完了まで到達した数	採用導線の改善、媒体投資判断

BtoBで使いやすいKPIツリー例

KPIツリー＝最終目標から逆算して、手前の行動指標を階層化した設計図です。BtoBでは「受注」までをWebだけで完結させないことが多いため、Webで観測できる先行指標と、営業側で確定する結果指標を一本の流れとして設計します。

例えば、受注を最終目標に置く場合、構造は次のように考えます（会社の業種や提供形態で中身は変わります）。

KGI：受注数（または受注金額）
- KPI：商談数
  - KPI：有効問い合わせ数
    - KPI：問い合わせ到達数（フォーム送信、電話タップ、資料請求など）
      - KPI：主要コンテンツ接触（価格・事例・機能などの閲覧）
        
        KPI：対象セグメント流入（セグメント＝条件で区切った顧客の分類）

各階層が次の階層を増やすための打ち手に対応していることが重要です。最初は意思決定に必要な最小セットを先に作り、計測の信頼性と運用の習慣を固めてから粒度を上げる方が、TCO＝導入後の運用費も含めた総コストを抑えやすくなります。

計測設計：GA4で何をどう計測するか

KPIを決めても、計測が不安定だと意思決定に使えません。計測設計は「誰が見ても同じ数字になる状態」を作る工程で、後から直すほど手戻りが大きくなります。目的に対して何を観測し、どのルールで記録するかを先に固定します。

計測設計の成果物を先に決める

揉めやすいのは「言葉は同じだが中身が違う」状態です。そこで、作るべき成果物を最初に定義します。

KPI定義書：指標名、含む/含まない、確定タイミング、算出式
イベント設計書：イベント＝GA4で記録するユーザー行動の単位、の一覧
パラメータ辞書：パラメータ＝イベントに付与する追加情報（例：資料種別、ボタン位置）を定義した表
テストシナリオ：計測が正しいかを検証する操作手順と期待値
変更ルール：タグ追加やサイト改修時の申請・承認・検証の流れ

この5点が揃うと、マーケ・制作・分析・営業で「どの数字が正しいか」を議論する時間が減り、改善の議論に時間を使えます。同時に、指標の更新頻度（週次・月次）を定義書に入れると、会議体ごとの見るタイミングが揃います。

BtoBで優先度が高い計測ポイント

BtoBは検討期間が長く、最終成果がサイト内で完結しないケースが多いです。そのため途中の重要行動も押さえます。マイクロコンバージョン＝最終成果（問い合わせや応募など）に至る途中の重要行動、を設けると打ち手が作りやすくなります。

問い合わせ：フォーム送信、電話タップ、メールリンク、チャット起動
資料・事例：資料ダウンロード、事例詳細の閲覧、価格ページなどの主要ページ閲覧
採用：募集要項閲覧、応募開始、応募完了

イベント名とパラメータの設計ルール

イベント名は、一度運用に入ると変えづらい資産です。次のルールで設計すると、改修に強くなります。

行動を中心に命名し、ページ名変更に引きずられないようにする
似た行動はイベント名を統一し、違いはパラメータで持つ
運用開始後の追加は、既存定義との重複を必ずチェックする

フォームや予約が別ドメインの場合は、クロスドメイン＝複数ドメイン間で同一ユーザーの行動を途切れさせずにつなぐ設定、が必要です。ここを見落とすと成果が分断されます。

GA4イベント設計例（BtoBサイト）

次の表は、よくあるBtoBサイトでのイベント設計例です。実装の都合よりも、KPIと改善アクションに直結するかを基準に取捨選択します。

ユーザー行動	GA4イベント	パラメータ例	注意点
問い合わせフォーム送信	generate_lead	form_type, company_size	送信完了ページだけに頼らず、送信成功で発火させる
フォーム到達（入力開始）	form_start	form_type, page_type	到達数と送信数の差で離脱要因を見やすくする
資料ダウンロード	file_download	file_name, asset_category	外部ストレージの場合は発火条件を確認する
電話タップ	click_tel	cta_position	スマートフォンのみ発生するため分母の取り方を統一する
メールリンククリック	click_mail	cta_position	運用でリンク先が変わる場合は台帳で管理する
主要ページ閲覧（価格/事例など）	view_key_page	page_type, content_id	ページ種別で集計できるようにする

数字の信頼性を担保するチェック

計測の信頼性は、実装直後だけでなく運用で落ちます。最低限、次のチェックを仕組みにします。

内部トラフィック＝自社社員など分析対象外のアクセス、を除外する
二重計測を防ぐ（同じ行動で複数タグが発火しない状態にする）
リリース前後でテストシナリオを実行し、主要KPIが取れていることを確認する

同意管理＝ユーザーの追跡許可の状態を管理する仕組み、を導入している場合は、同意状態によって計測範囲が変わります。法務・情報システムと連携し、許可のない計測を避けつつ、意思決定に必要な最小限のデータが残る設計にします。

タグ設計：実装・変更・品質管理の考え方

タグは増えるほど壊れやすくなります。運用を前提に「増やし方」と「守り方」を設計します。GTM＝Google Tag Manager（タグの追加や更新を管理する仕組み）を使う場合でも、ルールがないと属人化します。コンテナ＝GTMでタグやトリガーをまとめて管理する箱、をプロジェクト単位で分け、権限と変更履歴を追えるようにします。

タグ設計で決めるべき3点

1つ目は台帳です。タグ台帳＝どのタグが何の目的で、どこで発火し、誰が責任を持つかを一覧化した管理表、を作ります。
2つ目は命名です。イベント名・タグ名・トリガー名を揃えます。トリガー＝タグを発火させる条件、です。
3つ目はデータ受け渡しです。データレイヤー＝ページ上で計測用データを受け渡す共通の入れ物、を用意すると改修に強くなります。

変更管理と品質管理をルール化する

「変更のたびに数字が揺れる」状態は避けたいです。そこで、次の運用ルールを最初に置きます。

変更申請：追加・変更の理由、影響するKPI、リリース日
テスト：ステージング＝本番公開前に検証する環境、で確認してから公開
監査：定期的に不要タグを整理し、台帳と実態を一致させる

改修に強い体制の作り方

担当者が替わっても回る状態が重要です。編集権限を絞り、作業手順とテスト観点を文章化します。さらに、制作フローに受け入れテスト＝リリース前に要件どおりに動くか確認する検証、を組み込みます。

経営ダッシュボード設計：役割別に必要な画面を分ける

経営ダッシュボードは「全データの集約」ではなく、「意思決定のための最小セット」を、継続して見られる形に落とし込むことが要点です。設計で最初に決めるのは、次の3つです。

1) 誰が見るか

同じ会社でも、経営とマーケと分析担当では欲しい粒度が違います。1画面に詰め込むほど、誰にも刺さらなくなります。

2) 何を決めるために見るか

ダッシュボードの役割は「報告」ではなく「判断」です。判断に直結しない数字は、深掘り画面に追いやるのがコツです。

3) どの頻度で見るか

更新頻度が合わないと、会議で使われません。週次は先行指標、月次は商談・受注などの結果指標、のようにリズムを分けると運用が安定します。

以下は、役割別に「意思決定」と「主要指標」を揃えるための要件整理シート例です。ここを固めると、作ってから揉める確率が下がります。

見る人（役割）	意思決定	主要指標	更新頻度
経営者／事業責任者	投資配分・重点施策の選択	有効問い合わせ数、商談数、主要チャネル別の貢献	月次
マーケ責任者	施策の継続／停止、改善優先順位	問い合わせ到達数、主要ページ接触、チャネル別の効率	週次
Web担当者／制作	導線・フォーム・コンテンツ改善	フォーム到達→送信の遷移、主要導線クリック	週次
分析担当	数字の信頼性担保、深掘り分析	計測の抜け/二重、定義逸脱、セグメント別傾向	随時

費用と投資判断：内製/外注/ハイブリッドの比較

投資判断で重要なのは、初期構築の費用だけでなく、運用で目減りするコスト（更新・監査・改修時の確認）まで含めて見積もることです。TCO＝導入後の運用費も含めた総コスト、の観点で比較します。

コストが発生するポイント

KPI定義・合意形成：会議体と意思決定を揃える作業
計測設計：イベント設計・パラメータ辞書・テストシナリオ作成
タグ実装：GTM設定やデータ受け渡しの実装
検証：リリース前後のテスト、二重計測や欠損の確認
ダッシュボード構築：画面設計、権限設計、更新ルール整備
運用：タグ追加・改修時の影響確認、定期監査、ドキュメント更新

内製/外注/ハイブリッドの選び方

内製が向く：分析担当やWeb担当がいて、運用を回せる体制がある／施策数が多く変化が激しい
外注が向く：計測が未整備で、まず「正しい数字」を早く作りたい／社内に設計経験がない
ハイブリッドが向く：定義・設計は外部の伴走で固め、運用は社内で回していきたい

ポイントは「最初から完璧を狙う」より、「意思決定に必要な最小セットを短いサイクルで安定させる」ことです。作り込みを先にやり過ぎると、合意形成と実装の負荷が増え、使われないリスクが上がります。

体制と進め方：承認フローと運用ルール

体制設計では、担当者名よりも役割を固定します。担当者が変わっても運用が続くことが目的です。

最低限そろえる役割

最終承認：経営者／事業責任者（見る指標の最終決定）
オーナー：マーケ責任者（施策と数字をつなぐ責任）
実装：Web担当者／制作（タグ・導線・フォーム改修）
品質管理：分析担当（定義・計測の監査、逸脱の検知）
連携先：営業（商談・受注の定義と連携キーの管理）

進め方の型

目的とKPIの固定（会議体・更新頻度・定義）
計測設計（イベント設計書、パラメータ辞書、テストシナリオ）
実装（タグ、データ受け渡し、内部アクセス除外など）
検証（想定どおり取れるか、二重や欠損がないか）
ダッシュボード構築（役割別の画面、深掘り導線）
運用設計（変更申請、テスト、定期監査、更新ルール）

この順番が崩れると、ダッシュボードは作れても「数字の信頼性」か「運用」どちらかが崩れがちです。

リスクとトラブル：よくある失敗と防ぎ方

指標が増えすぎて誰も見ない

防ぎ方は、主要KPIと深掘り指標を分離し、経営画面は最小化することです。深掘りは分析担当やマーケ担当の画面へ寄せます。

定義が部署ごとにズレる

防ぎ方は、KPI定義書を唯一の正として管理することです。変更が出たら履歴を残し、会議で確認する運用にします。

改修のたびに計測が壊れる

防ぎ方は、受け入れテスト＝リリース前に要件どおりに動くか確認する検証、を制作フローに組み込むことです。テストシナリオを「人が替わっても回せる文章」にしておくと強いです。

施策と商談・受注がつながらない

BtoBでは、Webの成果（問い合わせ）と営業の成果（商談・受注）が別管理になりやすいです。つなぐために、UTM＝流入元や施策を識別するためURLに付与するパラメータ、などのルールを揃え、問い合わせIDや発生日をキーに連携できる形を検討します。

ダッシュボードが報告用で止まる

防ぎ方は、会議で「数字→仮説→打ち手→検証」を固定化することです。画面だけ整えても、運用の型がないと形骸化します。

成果の出し方：改善サイクルとレポーティング

成果を出す運用は、数字を見る頻度と意思決定の単位を合わせることから始まります。

週次で見るもの

先行指標（フォーム到達、主要ページ接触、チャネル別効率など）を中心にし、異常値が出たら原因を切り分けます。例えば「フォーム到達は増えたのに送信が増えない」なら、フォーム入力の負荷やエラー、導線の分かりにくさが疑われます。

月次で見るもの

商談数や有効問い合わせなど、営業側で確定する指標も含めて振り返ります。ROI＝投資に対する利益の割合、を見たい場合も、まずは「効率が良い流入・コンテンツが何か」を特定できる粒度に揃えることが先です。

レポートを「行動の指示書」にする

数字だけで終わらせず、最低限これだけをセットにします。

変化した主要KPI（前月比・前年差など）
変化の要因候補（どのチャネル／どのページ種別／どの導線か）
次に試す打ち手（1〜3個に絞る）
次回の確認ポイント（どの指標がどう動いたら成功か）

相談時に整理しておく項目と依頼の流れ

計測が整っていない企業ほど、最初に要件をそろえるだけで一気に前に進みます。相談時は、次の項目が整理されていると、設計が早く固まります。

整理しておく項目

目的：売上／問い合わせ／採用など、今回の優先ゴール
見たい結果指標：商談数、有効問い合わせなど（営業側の定義も含む）
現状の計測環境：GA4の有無、タグ管理の有無、ドメイン構成、フォームの仕様
データ連携の前提：営業管理データとの接続可否、問い合わせIDの扱い
運用体制：誰が見るか、週次/月次の会議体、更新担当の想定
リスク制約：同意管理の状況、社内ルール

依頼の流れのイメージ

現状把握（既存設定・タグ・主要導線の確認）
KPI設計（会議体と定義の固定、ダッシュボード要件の確定）
計測設計（イベント・パラメータ・テストシナリオ）
実装と検証（タグ、内部アクセス除外、二重/欠損の解消）
ダッシュボード構築（役割別画面、深掘り導線、運用ルール）
運用開始（定期監査、改善サイクルに組み込み）

株式会社みやあじよとしては「成果（売上・問い合わせ・採用）に結びつく問題解決」を前提に、目的の具体化から設計し、言語化して関係者の認識を揃えるところまで含めて支援範囲に入れます。

まとめ

WebサイトのKPI設計と経営ダッシュボードは、見た目の整ったレポート作りではなく、経営と現場が同じ定義の数字で判断できる状態を作る取り組みです。
そのために、目的→指標→定義→運用の順で固め、GA4の計測設計とタグ設計で数字の信頼性を担保し、役割別に必要な画面を分けて運用へ落とし込みます。
投資判断では、初期構築だけでなく運用コストまで含めて比較し、最小セットから安定稼働させて改善サイクルへつなげるのが現実的です。