所有ドメインのGA4計測を棚卸しし、未了12件を実地確認でつぶした

前日にまとめた対応表には、片付いていない項目が12件残っていた。今日はまず、その12件が本当に未了なのかを一つずつ確かめるところから始めることにした。前日のメモを鵜呑みにせず、実測して裏を取る。

結論

• 12件のうち11件が片付き、残りは配信形式の見極めが要る1件だけになった
• 最優先だった「本体サイトの計測が記録されない」件は、コードの不具合ではなくGA側の反映待ちだった
• プロパティ作成にはGoogleアカウントごとの権限差があり、切り替えて4サイト分を作成した
• 4ドメインをSearch Consoleへ登録し、522エラーの原因も特定して直した
• 前日の記述に3か所の誤りが見つかった。いずれも「見えているものが全部」と思い込んだ型の見落としだった
• もう使っていない旧ドメインは、レジストリの登録レコード自体が無い状態だと確かめた

最優先の一件は、すでに直っていた

12件を並べ直すと、記述と実態は一致していた。未了は本当に未了だった。真っ先に手をつけたのは、最優先だと決めていた一件(本体サイトのアクセスがGA4に記録されない件)だった。6月の移行のときにタグが外れたままになっていて、前日に付け直してデプロイしていたが、実際に届いているかまでは確認できていなかった。

サイト側の実装を見直すと、コードは正しく書けていた。直す必要はない。次にGAの管理画面を開くと、あるストリームの表示が「データを受信していません」から「過去48時間にトラフィックデータを受信しています」に変わっていた。前日には出ていなかった表示だ。

ストリームの詳細とレポートで裏を取った。リアルタイムのレポートにアクティブユーザーが3人、page_viewが3件、実際のページ名まで並んでいる。自分が開いた覚えのないページ(資産勘定の記事一覧や三分法の解説ページ)も記録に混じっていたので、これは実際の訪問者が計測されている証拠だった。最優先の一件は、すでに解決していた。前日に「記録されない」と判断したのは、コードの不具合ではなく、GA側の反映待ちだった。

プロパティを作れない、権限の壁

残る未了を進めるため、計測が入っていない4サイト分のGA4プロパティを新しく作ることにした。4つのうち1つは、このブログを動かしているリポジトリ自体だった。ここまで自分のPVすら測っていなかったことになる。ところが、いつも使っているメインのGoogleアカウントでは「プロパティの作成」ボタンが押せない。作成権限がないアカウントだった。サブのGoogleアカウントに切り替えると、こちらでは作れた。4サイト分を順番に作り、測定IDをそれぞれ発行した。

途中、自分の作業を疑い直す場面があった。「重複はない」という記述は本当にその日確かめたのかと問い直すと、前日のメモの記述をそのまま使っただけで、今日は見直していないという答えが返ってきた。対象アカウントの全プロパティを洗い出させ、重複がないことを実測し直させた。結果は記述どおり、重複はなかった。

外部の組織が持つアカウントに、自分のアクセス権だけが残っている一件もあった。アカウントごと削除しようとしたが、そのアカウントは他所の組織の持ち物で、こちらは招待されて使わせてもらっていた側にすぎず、削除の権限自体がなかった。実行しようとした瞬間にAPIから接続拒否のエラーが返って処理が止まった。「作業続けられませんかね」と声をかけ、ブラウザ操作が要らない作業を先に進めてもらうことにした。最終的には、アカウントの削除の代わりに、自分のアクセス権だけを返上した。データそのものを消す手段は、こちらにはもう残っていない。

もう使っていない旧ドメインの計測プロパティも1件、ゴミ箱に移した。削除には権限のあるアカウントへの切り替えが要ったが、その切り替えごと任せればいいと気づき、すぐサブのアカウントへ切り替えさせて実行させた。

タグの設置と、Search Consoleへの登録

計測タグが入っていなかった3つのリポジトリを確認すると、いずれもNuxtで書かれていた。本体サイトと同じ方式で揃えて設置させた。

// 本番ビルドのときだけ計測タグを差し込む(3リポジトリで同じ形に統一)
$production: {
  app: { head: { script: [ /* gtag/js?id=... */ ] } }
}

開発中に自分が見ているだけのアクセスが本番データに混ざらないようにするためだ。本番モードでビルドした出力を実際に確認し、開発モードでは出ず、本番モードでは全ページに出ることを確かめた。

Search Consoleへの登録も進めた。4つのドメインをサブドメインごとまとめて扱える形式で登録し、所有権の確認にはDNSのTXTレコードを使う方法を選んだ。Google側にDNSへのアクセス権を渡す連携も提案されたが、権限を渡さずに済む方法をこちらで選んだ。反映を4件とも自分で確認し、4ドメインすべての所有権確認を終えた。

522エラーの正体と、2つの見誤り

登録作業の途中で、ずっとエラーが出ていたサイトの原因も判明した。wwwを付けたホストだけがエラーで応答しなくなっていたが、原因は「CNAMEのループ」ではなく、配信設定側にwww付きホストの登録そのものが抜けていたことだった。登録を追加すると、エラーはすぐに消え、apexとwwwの両方が同じ内容を返すようになった。

このあと、自分の判断を疑い直す場面がもう2回あった。一つは、あるサイトの1ページで計測タグが出ていないと判断し、デプロイの失敗を疑った場面だ。実際はリダイレクトを追いかけずにアクセスしていたために、本文が空に見えていただけだった。リダイレクトを追いかけて確かめ直すと、タグは全ページに正しく入っていた。もう一つは、配信コマンドが通信エラーで落ちた場面だ。原因調査に入る前にもう一度同じコマンドを打ってみると、それだけで通った。

最後の1サイトだけは、公開の形式自体が他と違っていた。配信設定のファイルはPages向けの書き方になっている一方、実際の配信はWorkersで行われていて、そのまま実行すると本番の設定を上書きして壊しかねない状態だった。ここだけは判断を保留し、公開設定を目で確認してから進めることにした。

進捗ドキュメントと、4時間後の答え合わせ

作業の区切りに「進捗ってドキュメント残せますか」と頼み、その日の作業だけをまとめた記録を別に作らせた。HTMLに変換して確認すると、目次と見出し、表がきちんと生成されていて、横スクロールも出ていなかった。

4時間後、「これって今進捗どうなってますか」と尋ねたときは、記憶ではなく実物を確認させてから答えさせた。返ってきたのは「前回の報告から動いていない」という答えだった。その4時間は担当分の作業をしていなかったのだから当然ではあるが、記憶で即答させず、毎回実測で答えさせたのはよかった。

旧ドメイン、管理の有無を確かめる

別のセッションでは、もう使っていない旧ドメインの後始末に手をつけた。「これは削除していい」と伝えたついでに、「このドメイン自体、もう管理してないよね」と尋ねてみた。記憶では管理していないはずだった。

DNSを引かせるとNXDOMAIN(存在しない)が返り、レジストリへの照会も404で返ってきた。単に「更新し忘れて失効した」のではなく、登録レコード自体が今は存在しない状態だと分かった。今なら誰でも取得できる。Cloudflareのドメイン一覧でも同じ結果になり、記憶していたとおり、このドメインはもう自分の持ち物ではなかった。

別のセッションが同じ対応表を並行して更新していたことにも気づいた。上書きを避け、本体のメモには触れずに、調べた結果だけを別の記録として残させた。

学び

• 表示が「無い」「404」と出たときほど、一度別の角度から確かめ直す価値がある。業種別に切り出した複数プロパティを「見当たらない」と書いていたのは、一覧が仮想スクロールで一部しか描画されていなかったせいだった
• 一覧画面の「見えている件数」を「全件」と思い込まない。ある画像用ドメインを「死んでいる」と書いていたのは、ルートの404だけを見て、実在する画像のURLまでは確かめていなかったせいだった
• 「更新し忘れて失効」と「そもそも登録記録が無い」は別の状態。DNSの応答とレジストリ照会の両方で確かめて初めて区別がつく
• リダイレクトを追従しない確認方法は「中身が無い」の誤診を生む。308が返ってきたら、追従した先まで見る
• 通信エラーで落ちたコマンドは、原因調査より先にもう一度実行してみる価値がある