なぜ「GA4のデータ品質」が経営課題になるのか
GA4とは、Webサイトの行動データを計測して分析するためのGoogleの解析ツールです。
データ品質とは、欠損・重複・誤分類が少なく、同じ条件なら同じ解釈ができる状態です。
経営者・事業責任者が困るのは「施策の良し悪し」そのものより、良し悪しを判断できない状態が続くことです。たとえば、問い合わせ数が月によって急に増減する、広告とSEOを比べたいのに条件が揃わない。SEOとは、検索エンジンからの流入を増やすための最適化です。こうなると、改善のスピードが落ち、意思決定の根拠が弱くなります。
BtoBは母数が少ない分、重複や欠損の影響が大きくなります。まずは再現性のある数字に整えることが、最短の改善ルートになります。
数字がズレると起きる3つの損失
1つ目は、投資配分の誤りです。成果が過大に見えるチャネルに予算を寄せ、実際に伸びるチャネルを見落とすリスクが高まります。
2つ目は、現場の学習が止まることです。仮説検証（仮説検証＝仮説を立て、データで確かめ、次の打ち手に反映する一連の流れです。）が回らないと、打ち手が属人的になります。
3つ目は、社内の信頼コストです。「数字が信用できない」状態は、マーケだけでなく営業や経営の協力を得にくくし、改善の推進力を削ぎます。
みやあじよが制作で重視しているのは、表現よりも目的達成に直結する“問題解決”です。計測も同じで、見栄えの良いレポートより先に「何を成果とし、何を根拠に意思決定するか」を決める必要があります。
計測設計の全体像：目的→指標→イベント→検証の順で考える
計測設計とは、目的に照らして「何を」「どのルールで」計測し、意思決定に使える形に整える設計です。
KPIとは、目的達成度を測るための重要指標です。
順番を誤ると、設定は終わっていても判断に使えません。目的→指標→イベント→検証の順に、成果物を先に言葉で固めます。成果物が揃うと認識ズレが減ります。
1) 目的：Webサイトで「何を増やすか」を具体化する
BtoBでは「問い合わせ」でも質が違います。たとえば、採用問い合わせと営業問い合わせ、既存顧客のサポート連絡が混ざると、数字は増えても事業成果に直結しません。まずは成果の定義を切り分け、増やしたい成果を明確にします。
2) 指標：経営が見る指標と現場が動かす指標を分ける
トップ指標は少なく、現場指標は行動に落ちる形にします。例として、経営は「月次の有効問い合わせ数」、現場は「重要ページ到達率」や「フォーム到達率」を見る、という切り分けです。ダッシュボード（ダッシュボード＝指標を定点観測できるように可視化した画面です。）も、この役割分担があると継続しやすくなります。
3) イベント：成果に関係する行動だけを計測する
イベントとは、クリックや送信などユーザー行動を記録する単位です。
コンバージョンとは、問い合わせ送信や資料請求など成果につながる行動です。
「計測できること」ではなく「判断に必要なこと」から逆算します。イベントが増えすぎると運用が破綻し、少なすぎると改善が止まります。最初は、成果（送信）と主要導線（フォーム到達・電話クリックなど）に絞り、運用に耐える形で増やします。
4) 検証：正しいかどうかを確認する手順を設計に含める
テストは“最後の作業”ではなく、設計の一部です。誰が、どの画面で、どの条件で確認し、いつ合格にするかを決めておくと、改修のたびに数字が揺れにくくなります。
計測設計で作る成果物（一覧）
| 成果物 | 決まること | 例 | 関与部門 |
|---|---|---|---|
| 目的・成果定義 | 何を成果とするか | 営業問い合わせのみを成果にする | 経営,マーケ |
| KPI設計 | 追う指標の優先順位 | 月次：有効問い合わせ数／週次：フォーム到達率 | 経営,マーケ |
| イベント設計書 | 何を計測するか | 送信完了、フォーム到達、電話クリック | マーケ,制作/開発 |
| 命名規則 | 名前の付け方 | event名を動詞_対象で統一 | マーケ,制作/開発 |
| 実装仕様 | タグの実装方法 | 発火条件、重複防止、例外条件 | 制作/開発 |
| テスト手順 | 検証のやり方 | テストケース、合否基準、記録方法 | マーケ,制作/開発 |
| レポート設計 | どう見るか | 週次/⽉次の定例用ビュー | 経営,マーケ |
データ品質を落とす典型パターンと、先に決めるルール（命名・重複・除外）
タグとは、計測や広告連携のためにサイトに実装するコードです。
命名規則とは、イベントや項目名の付け方を統一するルールです。
データ品質を落とす原因は「現場の変更でズレる」ことに集中します。特に多いのは次の3つです。
パターン1：成果の定義が揺れて、数字の意味が変わる
同じ「問い合わせ」でも、フォーム改修で項目が増えたり、完了ページの仕様が変わったりすると、過去と比較できなくなります。対策は、成果の定義を文章で固定し、変更時は影響範囲（いつから比較できないか）を明記することです。
パターン2：重複計測で成果が水増しされる
ボタンの二重クリック、戻る操作、タグの二重発火などで、送信が複数回カウントされることがあります。対策は、発火条件を「一度だけ」に寄せる、例外条件を持つ、テストケースに“連打・戻る”を入れる、の3点です。
パターン3：不要なアクセスが混ざり判断がブレる
社内アクセスや制作検証のアクセスが混ざると、ページ改善の評価が歪みます。内部トラフィック（内部トラフィック＝自社社員など運用側のアクセスです。）を除外し、検証用の環境は本番と分ける運用ルールを決めます。加えて、流入判定が崩れやすいUTMパラメータ（UTMパラメータ＝流入元をURLで識別するための付加情報です。）は、付け方のルールと管理表を用意すると事故が減ります。
デザインが「言語化できるストーリー」から強くなるのと同様に、計測も“言葉にして合意する”ほどブレにくくなります。数字はコミュニケーションの共通言語なので、早い段階で定義とルールを文章化して共有するのが近道です。
実装の要点：タグ設計とテスト手順で“数字がズレる”を減らす
GTMとは、サイトに入れる計測タグを一元管理し、配信条件をまとめて制御するツールです。
「とりあえず動く」実装は早い一方、改修が続くとズレが積み上がります。実装の要点は、タグを増やすことではなく、再現性のあるルールで計測を維持することです。
タグ設計は「増やさない」ために行う
タグ設計とは、どのタグを、どの条件で、どの情報を付けて送るかを決める設計です。
要点は3つです。
- 計測の入口を統一する
直書き（直書き＝ページのソースコードに計測コードを直接埋め込む方法です。）とGTMが混在すると、重複や責任所在の不明確さが起きやすくなります。原則を決め、入口を揃えます。 - イベントは「成果に近い順」に絞る
クリック全部を計測すると運用が破綻します。成果（送信）と主要導線（フォーム到達、電話クリック、資料の閲覧など）から始め、改善に必要な粒度で増やします。 - 付与する情報を固定する
パラメータ（パラメータ＝イベントに付ける追加情報です。）を場当たりで増やすと、レポートが読めなくなります。最低限、ページ種別、施策区分、コンテンツ名など、判断に必要な情報だけを設計書で固定します。
“数字がズレる”を防ぐ実装の基本
ズレは「二重に送っている」「送れていない」「分類が違う」の3系統に分けると切り分けが早くなります。
二重送信の代表例は、クリックと送信完了の両方を成果にしてしまうケースです。成果は一箇所に寄せ、補助イベントは別名にします。送信完了ページがないフォームは、送信結果を条件にするなど、発火条件を厳密にします。
欠損は、ページ改修でボタンの識別情報が変わり、クリック条件が外れることで起きがちです。制作側の改修があっても壊れにくい条件を選び、変更点が出るたびにテストが回るようにします。
分類違いは、流入の付け方やページの正規化（正規化＝表記ゆれを統一して同じものとして扱えるように整えることです。）不足が原因になります。URL（URL＝Webページの場所を示すアドレスです。）の末尾スラッシュやパラメータの扱い、UTMパラメータ（UTMパラメータ＝流入元をURLに付けて識別するための情報です。）の運用ルールを固定します。
テスト手順は「チェックリスト化」で継続する
デバッグビューとは、送信したイベントをほぼ即時に確認できるGA4の検証画面です。
テストは手順の有無で品質が決まります。次のように、いつでも同じ結果になる形にします。
- テストケースを固定する（通常操作、戻る、連打、別ブラウザ）
- 合格条件を明文化する（送信回数、イベント名、パラメータの値）
- 記録を残す（実施日、対象ページ、変更点、結果）
この3点が揃うと、改修のたびに「どこでズレたか」を短時間で追えます。
体制と進め方：経営・マーケ・制作の役割分担と合意形成
計測が整わない要因は、責任分界と合意の不足です。役割を分け、成果物で合意します。
経営・事業責任者が決める範囲
- 成果の定義（何を成果と見なすか）
- 優先順位（今期は何を伸ばすか、何を捨てるか）
- 投資の上限（どこまで整えるかの線引き）
経営がここを握ると、現場は迷わず設計できます。
マーケ側が担う範囲
- 施策とKPIの対応付け（どの施策がどの指標を動かすか）
- 命名規則と運用ルール（誰が見ても同じ解釈になる形）
- レポート設計と定例の運用（見る頻度、見る人、アクション）
制作・開発側が担う範囲
- 実装方式の統一（GTMの管理、直書きの排除方針）
- 変更時の影響把握とテスト（改修前後の差分確認）
- 例外処理（フォーム仕様や動的ページなどの特殊要件）
外部パートナーが関わる場合は、設計書とテスト結果を納品物に含めると、引き継ぎが成立します。
リスクとトラブル回避：変更管理・監視・権限設計
ステージング環境とは、本番前に動作確認を行う検証用サイトです。
計測は、変更とともに崩れます。崩れる前提で、変更管理・監視・権限設計をセットで用意します。
変更管理で「いつからズレたか」を追えるようにする
- 変更ログを残す（いつ、誰が、何を変えたか）
- リリース時のチェックを固定する（主要導線のテストを毎回実施）
- 設計書の版管理をする（最新版がどれか迷わない状態）
監視は“異常を早く見つける”だけに絞る
アノマリーとは、通常と比べて異常な変化です。
細部を追うより、重要指標の急変だけを検知し、原因調査に時間を使う方が効果的です。
データ品質チェックリスト（切り分け用）
| チェック項目 | 起きがちな症状 | 主な原因 | 対処 |
|---|---|---|---|
| 成果が急増 | 前週比で不自然に増える | 二重発火、完了判定の緩さ | 発火条件の見直し、連打・戻るのテスト追加 |
| 成果が急減 | ほぼゼロに落ちる | 改修で条件が外れた、計測コード停止 | 変更点確認、タグ配信状態の確認、再テスト |
| フォーム到達はあるが送信がない | 到達率だけ高い | 送信イベント未設定、完了ページなし | 送信条件の実装、完了判定の方式を再設計 |
| 流入元が不明に偏る | 流入元が判別できない区分が過大 | UTMパラメータ運用不備、転送設定、参照元欠損 | UTMパラメータのルール整備、転送設定の確認、参照除外の見直し |
| 特定ページの数値だけ変 | 1ページだけページ表示数が急増 | 計測の二重読み込み、計測対象外の想定漏れ | タグの重複確認、除外条件の追加 |
| 社内アクセスが混ざる | 平日日中だけ増える | 内部除外未設定 | 内部トラフィックの定義と除外を設定 |
| レポートに欠損が出る | 一部の項目が空欄 | パラメータ送信漏れ、表記ゆれ | パラメータ設計の固定、正規化の実施 |
| 数値が見えない | 行が表示されない | しきい値、権限不足 | 指標の粒度調整、権限の付与と管理 |
しきい値とは、プライバシー保護のために一部の集計が表示されない状態です。
権限と表示制限の可能性も含めて切り分けます。
権限設計は“触れる人”を減らす
権限設計とは、誰が何を変更できるかを役割で決める運用です。
GA4とGTMの両方で、管理者権限を最小化し、変更はレビューを通す形にします。
費用・投資判断：内製/外注の考え方と見積もりの論点
経営判断に必要なのは、金額そのものより「何にコストが乗るか」を把握することです。計測は“設定”より“運用”で差が出るため、見積もりは作業項目で分解して比較します。
費用が増えやすい論点は、主に次のとおりです。
- 対象範囲：ドメイン（ドメイン＝Webサイトの住所のうち、組織を表す部分です。）が複数、フォームが複数、会員エリアがある
- 実装難易度：動的ページやSPA（SPA＝ページ遷移を伴わず画面を書き換えるWebの作り方です。）で、標準計測だけでは判断に必要な情報が取れない
- 同意管理：同意管理（同意管理＝Cookie等の利用同意を取得し、計測可否を制御する仕組みです。）と計測を整合させる必要がある
- 既存資産：過去のタグが散在し、どれが成果に関係するか不明で棚卸しが必要
- 体制：制作・開発・広告運用が別で、調整コストが発生する
内製と外注は、優劣ではなく「社内に残すべき責任」と「社外に任せるべき作業」を分けて決めるのが現実的です。みやあじよが制作で重視する“問題解決”の観点では、判断材料を言語化し、合意できる形に落とすことが土台になります。
内製と外注の比較
| 観点 | 内製 | 外注 | 判断の目安 |
|---|---|---|---|
| スピード | 担当がいれば速い | 窓口・優先度で変動 | 週次で改修が多いなら内製寄り |
| 品質 | 属人化しやすい | 設計書とテストで担保しやすい | 設計・検証を仕組みにしたいなら外注寄り |
| 継続運用 | 社内知見が残る | 運用設計を納品物に含めると残る | 引き継ぎ前提なら「成果物の残り方」を比較 |
| リスク | 退職・異動で止まりやすい | 依存しすぎると判断が遅れる | 役割分担（誰が決め、誰が作るか）を明文化 |
成果の出し方：ダッシュボードと定例レビューで改善を回す
Looker Studioとは、複数のデータを可視化して共有できるレポート作成ツールです。
ダッシュボードは「作ったら終わり」になりがちなので、使い方まで設計します。
おすすめは、見る人と頻度で3層に分けることです。
- 経営向け（月次）：成果KPIと主要チャネル（チャネル＝広告や検索など、流入経路の区分です。）の推移だけを確認する
- マーケ向け（週次）：導線KPI（到達率など）と施策別の学びを確認する
- 調査用（随時）：異常値の原因を掘るための詳細ビュー
定例レビュー（定例レビュー＝決まった頻度で数字と打ち手を確認する会議運用です。）は、次の型にすると迷いにくくなります。
- 先月/先週のKPIの差分
- 差分の要因仮説（流入・導線・訴求のどこが動いたか）
- 次のアクション（担当者と期限まで決める）
- 次回の確認ポイント（どの指標で効いたか判定するか）
「ストーリーが初見で伝わる構成」を意識するというデザインの考え方は、レポートにもそのまま当てはまります。見る人が迷わない順番で並んでいるほど、意思決定が速くなります。
相談時に用意すると進みやすい情報
ランディングページとは、広告などから最初に到達させる目的特化ページです。
相談段階で揃っていると、初回の棚卸しと方向性の合意が短時間で進みます。
- 目的・成果定義（営業問い合わせ、採用、資料請求など）
- 現在のGA4とGTMの権限状況（誰が管理者か）
- 計測している成果一覧（問い合わせ、電話、資料の閲覧など）
- 主要導線（ランディングページ、フォーム、重要ページ）のURL一覧
- 流入施策の全体像（広告、SEO、メール、ソーシャルメディアなど）
- 同意管理ツールの有無と設定状況
- 定例で見たい指標（経営会議用/マーケ定例用）
みやあじよでは、GA4設定・計測設計、タグ設計、アクセス解析、ダッシュボード構築までを一気通貫で整理し、判断に使える形に整えるご相談を受けています。
まとめ
GA4の課題は「設定ができていない」よりも、「数字の意味が揃っていない」ことにあります。目的→指標→イベント→検証の順で合意し、命名・重複・除外のルールを先に決めると、データ品質は安定します。
そのうえで、実装とテストを仕組みにし、役割分担と変更管理を整えると、改修が続いても数字が揺れにくくなります。
最後に、ダッシュボードは作るだけでなく、見る人と頻度に合わせて設計し、定例レビューで改善を回すところまでが投資回収（投資回収＝投資したコストを成果で取り戻す考え方です。）の要点です。
