GA4の自分のアクセスを除外しようとしたら、地味に遠回りした話

きっかけは自分のアクセス。このブログのアクセス解析(GA4)を見ていて、自分自身のチェック用アクセスが数字に混ざっているのがずっと気になっていました。件数が少ないブログなので、自分が1回見るだけでもけっこう割合として効いてきます。せっかくならAPI経由でサクッと自動化したいと思って、Claudeに調べてもらったら、思ったより遠回りすることになりました。

「サービスアカウントに権限を渡せば自動化できるはず」と思い込んだ

解決策はすぐに浮かびました。設定名もそのままでした。GA4には「内部トラフィックの除外」という設定があって、特定のIPアドレスからのアクセスを解析対象から外せます。管理画面からポチポチ設定すればいいだけなんですが、どうせなら将来的にIPが変わった時のことも考えて、API経由で設定できるようにしておきたいと思いました。

手順は簡単そうに見えました。GA4にはAdmin APIというプロパティ設定を操作できるAPIがあります。サービスアカウントを作って、そのアカウントにプロパティの編集者権限を渡せば、内部トラフィックのルールもAPI経由でいじれるはずだと当たりをつけて、まずはClaudeに権限周りの設定から進めてもらいました。

権限は無事に通ったのに、肝心の機能が見当たらない

ここでつまずきました。権限は無事に通りました。サービスアカウントへの編集者権限付与自体はすんなり完了しました。ところが、Claudeに実際のAPIリファレンスを漁ってもらっても、内部トラフィックのルールに相当するエンドポイントがどこにも見当たりません。似たような名前のリソースもなく、検索しても「そもそもそんな機能名で存在するのか?」というところから怪しくなってきました。

迷路にはまりました。権限の設定ミスなのか、探し方が悪いのか、しばらく行ったり来たりしていました。権限が反映されるまでに時間がかかることもあると聞いていたので、少し時間を置いてから再度試してもらったり、サービスアカウントを作り直してもらったりもしたんですが、状況は変わりません。ここまでくると、権限周りの設定を疑うよりも先に、「そもそもこの機能、APIに存在しているという前提が正しいのか」を疑った方が早いと気づきました。

Discovery Documentを直接見たら、本当に無かった

確かめる方法は一つでした。GA4のAdmin API(v1alpha)には、APIが提供するリソースやメソッドを一覧できるDiscovery Documentという定義ファイルがあります。ここをClaudeに直接開いてもらって、`internalTrafficRules`や`dataFilters`に相当する項目があるかを確認してもらいました。

とんだ無駄骨。結果、本当にどこにも存在しませんでした。内部トラフィックの除外は、GA4の管理画面からしか操作できないUI限定の機能で、Admin APIには最初から用意されていなかったというオチです。似た名前の`dataStreams`やプロパティ設定系のリソースは大量に出てくるので、「探し方が甘いだけで、きっとどこかにあるはず」という思い込みをなかなか手放せませんでした。ここでようやく、サービスアカウントに編集者権限を付与する作業自体が無駄足だったと分かりました。

本末転倒でした。「APIで自動化できるはず」という思い込みだけで進めてしまい、肝心の一次情報(公式のAPI定義)を確認するのを後回しにしていたのが原因でした。結局、内部トラフィックの除外は手動で管理画面から設定し直すことになりました。データストリームの設定画面から自宅のIPアドレスを登録し、データフィルタ側でそのフィルタを有効化する、という数クリックの作業です。API経由で自動化しようとあれこれ試行錯誤していた時間を考えると、最初からこちらを選んでいれば数分で終わっていた話でした。

これで万事解決とはいきません。ただ、これで自分のアクセスを完全に防げたわけではありませんでした。後日、この設定をすり抜けたアクセスがまた別の形で数字に紛れ込んでいることに気づくことになります(GA4の滞在時間が長すぎる。掘ったら正体は自分だった)。

おまけ: 外出先のアクセスも除外できないか考えた

次に気になったのはスマホでした。ついでに、外出先のスマホからチェックした分もノイズになるので除外できないか検討しました。Cookieでの識別も考えたんですが、iPhoneのChromeは見た目こそChromeでも、中身はSafariと同じWebKitエンジンで動いています。つまりSafariと同じITP(Intelligent Tracking Prevention)の対象になり、Cookieは7日で自動的に消えてしまいます。

結論は見送りでした。たまにしか外出先からチェックしないなら、7日で消えるCookie対策をわざわざ組む費用対効果は薄いと判断して、こちらは見送ることにしました。仮にCookieを使った識別の仕組みを頑張って組んだとしても、1週間ノータッチが続けば勝手にリセットされてしまうので、常に完璧に機能する保証がありません。中途半端な対策に時間をかけるくらいなら、外出先で見た数字は「多少ノイズが混じっているかもしれない」と割り引いて読む方が、結果的に手間対効果が良いという判断です。全部を完璧にノイズ除去しようとせず、頻度と手間を天秤にかけて割り切るのも大事だなと思った判断でした。

まとめ

原因は思い込み一つ。「APIがあるはず」という思い込みで作業を進めてしまうと、肝心の根拠を後回しにしたまま遠回りしてしまいます。今回のように、公式のAPI定義(Discovery Document)のような一次情報に当たれば、数分で「そもそも存在しない」と分かる話でした。何かのAPIを探す時は、まず存在を一次情報で確認してから権限周りの作業に入る、という順番を今後は徹底したいと思います。

この記事の内容を、YouTube Shortsでも紹介しています

この記事を書いた人

Web制作歴10年近く。WordPressのテーマカスタマイズやコーディングを中心に、副業・本業ともにweb制作に携わっています。このブログでは、実際に手を動かして分かったことを書いています。

Cat's Handをフォローする

この記事が参考になったら、応援クリックをお願いします

タイトルとURLをコピーしました