CHAPTER 08
計測の検査|公開前・公開後に確かめること
この章で分かること
- サイトを直すたびに計測が壊れる理由と、改修の前に出しておく対応表
- 公開前6項目・公開後8項目の検査と、その記録の残し方
- 0件が続いたときに気づく仕組みと、壊れたときの復旧の手順
この章の目次(11)
- 1なぜ、直すたびに壊れるのか
- 2改修の前に、対応表を1枚出す
- 3公開前の検査(6項目)
- 4公開直後の検査(当日・15分)
- 5毎月の検査(30分)
- 6検査の分担(自社にしかできないものがある)
- 70件に気づく仕組み
- 8変更履歴は、1か所に集める
- 9壊れたときの手順
- 10よくある間違いを5つ
- 11この章の出口
計測は、壊れたときに音が鳴りません。 エラー画面も出ず、警告も届かず、件数が静かに0になるだけです。 0件は「今月は反応が悪かった」に見えるので、たいてい1〜2か月は気づかれません。気づいた頃には、比較に使える過去が消えています。 この章は、改修のたびの検査(公開前・公開直後)と、毎月繰り返す検査を手順にし、壊れたときに戻す道を用意するための章です。
この章で分かること
- サイトを直すたびに計測が壊れる理由と、改修の前に出しておく対応表
- 公開前6項目・公開後8項目の検査と、その記録の残し方
- 0件が続いたときに気づく仕組みと、壊れたときの復旧の手順
公開前の受入検査そのもの(原稿・事実の照合・表示崩れ・公開してよい状態か)は、サイト制作の教科書9章が扱っています。この章は、計測が数字を返すかだけを見ます。 2つは同じ日に行いますが、見る人も合格ラインも別です。
なぜ、直すたびに壊れるのか
計測は、サイトの作りに寄りかかっています。寄りかかっている先が変わると、黙って外れます。
なぜ黙って外れるのかというと、計測には「動かなかったこと」を検知する仕組みが無いからです。プログラムのエラーであれば、画面が白くなるか、エラーの文言が出るか、ログに残ります。計測は違います。送る条件に合致しなければ、何も送らずに正常終了します。何も起きていないので、警告を出す理由もありません。0件という結果だけが、正常な処理の結果として記録されます。
これが厄介なのは、0件がもっともらしく見える点です。問い合わせが減る理由はいくらでもあります。季節、競合、広告の停止、検索順位の下落——月次の会議で「今月は少なかったですね」と言われて終わる程度には、自然な数字に見えます。実際に当社が診断で入る案件では、壊れていた期間が1か月で済んでいることはほとんどありません。半年、1年というものもあります。
失われるのは、その期間の件数だけではありません。比較に使う過去が消えます。翌年に「前年同月と比べる」と決めても、比べる相手が0件では判断できません。10章で「比較の相手を先に決める」と書いていることが、その年だけ実行できなくなります。検査が費用対効果の高い作業なのは、壊れた期間の損失ではなく、その後の判断を守るためです。
| サイト側で起きたこと | 計測に起きること |
|---|---|
| 完了ページのアドレスが変わった | 成果が0件になる(4章・取り方A) |
| 「送信しました」の出し方を変えた | 成果が0件になる(取り方B) |
| フォームを別のサービスに替えた | 参照元も成果も消える(6章) |
| ページを作り直し、制作会社が新しくタグを入れた | 数字が2倍になる(2章・工程1) |
| 一部のページだけ新しい作りになった | そのページ群だけ計測が抜ける |
どれも「サイトは正常に動いている」状態で起きます。 だから、サイト側の検査では見つかりません。
この表は、改修の内容を見て「うちに関係あるか」を判断するために使います。左の列に1つでも近いことが起きるなら、公開前の検査を省略できません。とくに4行目——ページを作り直して制作会社が新しくタグを入れた——は、症状が0件ではなく2倍なので、気づき方が逆になります。件数が増えたときも疑ってください。増えて喜んでいる間に、広告の判断まで狂います。
右の列も読んでおくと役に立ちます。「0件になる」と「2倍になる」と「そのページ群だけ抜ける」では、後から気づいたときの復旧のしやすさが違います。最後の1つが最も厄介で、全体の件数は減っていないため、週1分の確認では見つかりません。ページ群ごとの内訳を一度も見ていない会社では、何年も気づかれないことがあります。
改修の前に、対応表を1枚出す
改修が決まったら、着手の前に次の表を埋めます。5分で終わり、事故の大半をここで防げます。
| 変わるもの | 紐づく計測 | 確認する人 | 公開後にやること |
|---|---|---|---|
/contact/thanks のアドレス |
成果(form_submit)・広告側の成果 |
◯◯ | 実送信 |
| 問い合わせフォームの作り | データレイヤーへの書き込み(5章) | 制作会社 | 実送信 |
| ヘッダーの電話番号 | tel_click のトリガー |
◯◯ | スマホで1回押す |
「変わるもの」の欄は、制作会社の見積書からそのまま写せます。 見積の行と計測を並べるのが、この表の狙いです。
公開前の検査(6項目)
テスト環境で行います。本番の宛先には送らないよう、送信先だけは確認してください。
| # | 見ること | 合格ライン |
|---|---|---|
| 1 | 対応表が埋まっている | 変わるページ・フォームと、紐づくタグが並んでいる |
| 2 | テスト環境で実送信した | 送信して、記録される場所をたどった |
| 3 | 完了ページのアドレス | 変わっていない/変わったなら設定を直した |
| 4 | タグの本数 | 変更後のページで、解析タグが1本 |
| 5 | 検証用の設定 | テスト用のタグ・フォルダが本番に混ざっていない |
| 6 | 戻し方 | 公開前の状態に戻す手順が決まっている |
テスト環境が無い場合は、公開直後の検査を必ず行ってください。 「テスト環境が無いので検査もしない」が、最も事故が多い形です。
テスト環境を用意してもらうか、公開直後の本番検査で済ませるかで迷ったら、後者を選んでください。テスト環境の構築は制作会社への依頼になり、費用も期間もかかります。しかも、テスト環境と本番では条件が違うことが多く、テストで通ったのに本番で動かない、という結果になりがちです。一方、公開当日に本番で1件送る作業は、費用ゼロで、その日のうちに終わります。壊れていた場合でも、被害は当日分に収まります。
テスト環境に投資する価値があるのは、フォームが何本もあり、改修の頻度が高く、1件あたりの金額が大きい会社です。問い合わせが月に数十件で、改修が年に数回という規模なら、公開当日の15分だけで足ります。この判断は「あったほうがいい」ではなく、「無いなら当日やる」という置き換えで考えてください。
公開直後の検査(当日・15分)
公開した日のうちにやります。 翌日以降にすると、壊れた状態のデータが1日分混ざります。
| # | やること | 合格ライン |
|---|---|---|
| 1 | 本番で1件送る(PCとスマホ) | 2章・工程2の6か所に現れた |
| 2 | 1件が1件か | 完了画面を2回更新しても増えない |
| 3 | 参照元 | 自社ドメインやフォームサービス名になっていない |
| 4 | 記録を残す | 日付・実施者・結果を1行書いた |
記録は、次の形の1行で十分です。
2026-09-20 / ◯◯ / 本番実送信(PC・スマホ)/ 6か所すべて○ / 参照元 google / organic
この1行が無いと、次に壊れたときに「いつまでは正常だったか」が分かりません。 段差の原因を特定できるかどうかは、この1行があるかで決まります。
毎月の検査(30分)
改修が無い月も、月1回は本番で1件送ります。 理由は、計測はサイトを触らなくても壊れるからです(ツール側の仕様変更、タグの公開取り消し、権限の失効、外部サービスの変更)。
| 頻度 | やること | 時間 |
|---|---|---|
| 毎週 | 成果の件数が0でないかを見る | 1分 |
| 毎月 | 本番で1件送り、6か所をたどる。記録を1行書く | 15分 |
| 毎月 | 突き合わせ表を埋める(6章・7章) | 15分 |
| 年1回 | 2章の14項目を通す | 60分 |
週1分の確認が、最も費用対効果の高い作業です。 見る人と曜日を決めてください。「気づいたときに見る」は、見ないことと同じです。
サイトを触っていないのに壊れる引き金
| 引き金 | 何が起きるか | 気づき方 |
|---|---|---|
| タグ管理ツールの公開が取り消された | ある日から全部止まる | 週1分の確認 |
| 担当者の退職で権限が失効した | 設定が確認できない/通知が届かない | 年1回の権限の見直し(12章) |
| 外部フォーム・予約サービスの仕様が変わった | 参照元が消える、完了ページに戻らなくなる | 月1回の実送信 |
| ドメインやページの構成を変えた | 完了ページのアドレスが変わる | 対応表 |
| ツール側の仕様変更 | 取得できる項目が変わる | 月1回の実送信と、年1回の2章 |
「うちはサイトを更新していないから大丈夫」は成り立ちません。 上の5つは、どれも自社が何もしていない日に起きます。
検査の分担(自社にしかできないものがある)
| 検査 | 自社 | 委託先 |
|---|---|---|
| 通知メールが届いたか | 自社のみ | できない(受信箱を開けない) |
| 台帳に1行増えたか | 自社のみ | できない |
| 解析ツール・タグの動作 | できる | 頼んでよい |
| 広告側に成果が渡っているか | できる | 頼んでよい |
| 記録を残す | 自社が持つ | 実施結果を受け取る |
この表は、委託先との打ち合わせでそのまま使ってください。読み方は、右の列が「頼んでよい」になっている行だけを依頼の範囲にする、というだけです。上2行を渡してしまうと、検査の報告は来るのに、実際の問い合わせは届いていない、という状態が起こり得ます。
たとえば、制作会社から毎月「計測は正常です」という報告が来ているとします。報告の内容は嘘ではなく、解析ツールの側には数字が入っている。届いていないのは、通知メールのほうです。フォームの差し替えのときに宛先の設定が旧担当者のままになり、その人はすでに退職している。解析ツールは件数を数えていて、誰も読んでいない受信箱にメールだけが積み上がっていく——これが何か月も続く、という形の事故が起こりえます。
この事故は、委託先の側からは原理的に見つけられません。受信箱を開く権限が無いからです。だからこの表の上2行は、能力の問題ではなく、立場の問題として自社に残ります。月1回の実送信で「通知メールが自分に届いたこと」を自分の目で確認する——それだけで防げます。
上2行は、発注側にしかできません(2章)。ここを委託先任せにすると、「計測は正常です」という報告と、実際には届いていない問い合わせが同時に存在します。
0件に気づく仕組み
人が毎日見るのは続きません。 仕組みで拾います。方法は3つあり、上から順に手軽です。
| 方法 | 内容 | 向く場合 |
|---|---|---|
| 週1回の目視 | 決めた曜日に、成果の件数だけを見る | まずこれ。費用ゼロで今日から始められる |
| 通知の設定 | 件数が閾値を下回ったときに知らせる(解析ツール側の機能。探す言葉:「異常検知 カスタムインサイト 通知」) | 件数が安定している場合 |
| 画面に置く | 見る画面の一番上に、今月の件数を置く(9章) | 毎月開く画面がある場合 |
3つのうち、まず1つ目だけを始めてください。表を上から順に並べているのは、手軽さの順であると同時に、確実さの順でもあるからです。通知の設定は、一度作れば自動で動くので魅力的に見えますが、閾値の決め方を誤ると鳴らないか、鳴りすぎるかのどちらかになります。鳴りすぎた通知は数週間で無視されるようになり、その後は「通知を設定したから大丈夫」という誤った安心だけが残ります。人が週に1分見るほうが、はるかに壊れにくい仕組みです。
通知は「0件になってから」では遅いことがあります。 前年の同じ月と比べて半分を下回ったら知らせる、くらいの緩さで十分です。通知が鳴りすぎると、誰も見なくなります。
変更履歴は、1か所に集める
段差の原因を追えるかどうかは、履歴が1か所にあるかで決まります。サイトの更新履歴、GTMのバージョン、広告の変更、フォームの差し替えが別々の場所にあると、突き合わせに半日かかります。
| 書く欄 | 例 |
|---|---|
| 日付 | 2026-09-20 |
| 触ったもの | サイト/フォーム/タグ/広告/設定 |
| 内容 | 完了ページのアドレスを /thanks から /contact/thanks に変更 |
| 実施者 | ◯◯(自社/制作会社名) |
| 計測への影響 | 成果の設定を変更。実送信で確認済み |
委託先が触った日も、同じ場所に入れてもらってください。 1行書くだけです。これを契約や発注時の約束に入れておくと、後で揉めません(12章)。
壊れたときの手順
慌てて設定を触ると、原因が分からなくなります。 順番を決めておきます。
| # | やること |
|---|---|
| 1 | いつから壊れているかを特定する(日別の件数で段差の日を探す) |
| 2 | 段差の日に何をしたかを、変更履歴で確認する |
| 3 | 自分で1件送り、6か所のどこで切れているかを見る |
| 4 | 直す担当を決める(2章の表:受信箱=制作側/成果の記録=計測担当/広告=広告担当) |
| 5 | 直したら、本番で1件送って確かめ、記録を1行書く |
| 6 | 壊れていた期間を、比較から除外すると決めて書き残す |
6が抜けやすい項目です。 壊れていた月の数字を、後から正常な月と比べると、効果の判断を間違えます。「2026-07 は計測が止まっていたため比較に使わない」と1行書けば、それは仕様になります。
よくある間違いを5つ
「サイトの公開前チェックはしたので、計測も大丈夫だと思った」 ——受入検査は表示と内容を見るもので、数字が返るかは見ていません。直し方:公開前の6項目と公開直後の実送信を、別の担当の作業として工程に入れる。
「壊れていることに、3か月後に気づいた」 ——週1分の確認が無い状態です。直し方:曜日と担当を決め、成果の件数だけを見る。通知は補助として後から足す。
「原因を探したが、何をしたか誰も覚えていなかった」 ——変更履歴が無い、または場所が分かれています。直し方:履歴を1か所にまとめ、委託先にも1行書いてもらう約束をする。
「テスト環境が無いので、検査そのものをやっていない」 ——テスト環境の有無は、公開直後に本番で送るかどうかと関係ありません。直し方:公開した当日に、本番で1件送る。テスト送信であることが分かるよう、件名に印を入れて台帳から引き算する。
「直したので、壊れていた期間の数字もそのまま報告に使った」 ——0件だった月を平均に入れると、判断を間違えます。直し方:壊れていた期間を比較から除外すると決め、レポートにも注記する。
この章の出口
手元に残っているべきものは4つです。
- 改修時の対応表(変わるもの/紐づく計測/確認する人)
- 検査の記録(日付・実施者・結果の1行が、直近3か月分)
- 変更履歴(1か所。委託先の行も入っている)
- 復旧の手順(6ステップ・連絡先つき)
数える仕組みは、これで維持できます。次は、使う番です。数字を毎回探しに行っている限り、月次の確認は続きません。開けば終わる画面を作ります。
この章の点検リストを開く(自社の状態を○×で判定する用)
点検リスト:計測の検査(14項目)
| # | チェック項目 | 合格ライン |
|---|---|---|
| 1 | 改修の前に、影響する計測の一覧を出した | 変わるページ・フォームと、紐づくタグの対応表がある |
| 2 | 公開前にテスト環境で実送信した | 記録がある |
| 3 | 公開直後に本番で実送信した | 記録がある(日付つき) |
| 4 | 完了ページのアドレスが変わっていない | 変わった場合は設定を直し、実測した |
| 5 | タグが二重になっていない | 1件送って1件 |
| 6 | テスト用の設定が本番に残っていない | 検証モード・検証用タグが解除されている |
| 7 | 月1回、本番で実送信している | 直近3か月の記録がある |
| 8 | 週1回、成果が0でないかを見ている | 見る人と曜日が決まっている |
| 9 | 0件が続いたときに気づく仕組みがある | 通知、または週次の確認が決まっている |
| 10 | 変更履歴がある | サイト・フォーム・タグ・広告を触った日が1か所にある |
| 11 | 検査の担当者が決まっている | 氏名が書いてある |
| 12 | 検査の記録を残している | 日付・実施者・結果 |
| 13 | 委託先が触った日も履歴に入る | 委託先に1行書いてもらう約束がある |
| 14 | 復旧の手順が決まっている | 誰に連絡し、どう戻すかが書いてある |
合格ライン=14項目中12以上。ただし 3・7・9 のどれかが×なら、点数に関係なく先に直します。
- 3が×:改修のたびに、壊れたまま公開している可能性があります。最も事故が多い瞬間です
- 7が×:サイトを触っていなくても計測は壊れます。月1回15分で、壊れている期間を1か月以内に抑えられます
- 9が×:壊れたことに誰も気づけません。気づいたときには、比較に使える過去が消えています
8と9は、費用ゼロ・当日開始できます。 曜日と氏名を決めるだけです。
更新日 2018年10月20日
