株式会社COTSUBU

CHAPTER 08

計測の検査|公開前・公開後に確かめること

この章で分かること

  • サイトを直すたびに計測が壊れる理由と、改修の前に出しておく対応表
  • 公開前6項目・公開後8項目の検査と、その記録の残し方
  • 0件が続いたときに気づく仕組みと、壊れたときの復旧の手順
この章の目次(11)
  1. 1なぜ、直すたびに壊れるのか
  2. 2改修の前に、対応表を1枚出す
  3. 3公開前の検査(6項目)
  4. 4公開直後の検査(当日・15分)
  5. 5毎月の検査(30分)
  6. 6検査の分担(自社にしかできないものがある)
  7. 70件に気づく仕組み
  8. 8変更履歴は、1か所に集める
  9. 9壊れたときの手順
  10. 10よくある間違いを5つ
  11. 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. 改修時の対応表(変わるもの/紐づく計測/確認する人)
  2. 検査の記録(日付・実施者・結果の1行が、直近3か月分)
  3. 変更履歴(1か所。委託先の行も入っている)
  4. 復旧の手順(6ステップ・連絡先つき)

数える仕組みは、これで維持できます。次は、使う番です。数字を毎回探しに行っている限り、月次の確認は続きません。開けば終わる画面を作ります。

次の章へ:9章 Looker Studioのダッシュボードに何を置くか

この章の点検リストを開く(自社の状態を○×で判定する用)

点検リスト:計測の検査(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は、費用ゼロ・当日開始できます。 曜日と氏名を決めるだけです。

読んでも決めきれないところは、一緒に決めます

30分の相談は無料です。いまの計測が信用できるかの点検から引き受けます。引き受けられる範囲はアクセス解析・計測設計にまとめています。

30分相談を予約する

更新日 2018年10月20日