[🛠] ブログ統計でボットのカウントを減らす

✨ GPT-5.5の要約 　

Cloudflare Workerの訪問集計にクラウドクローラーや薄いheadlessアクセスが混ざる問題を減らすため、ASN/組織フィルターとvisible engagement信号を追加し、誤ってブロックしたISP ASNを外した記録。

統計の数字がまた変だった。

公開ブログ統計ページを付けたあと、少なくともローカル作業がproductionカウンターを汚す問題は止まった。でも別の問題が見えた。

人が読んだとは思いにくいリズムのリクエストがあった。

ページを開いてすぐ複数のpathをなぞり、ブラウザのようなUser-Agentを付けている。でも読者がページに滞在している感じではない。公開静的ブログなのでクローラーが来るのは当然だ。問題は、そのクローラーが/trackまで叩くと、公開閲覧数と訪問数も一緒に膨らむことだった。

最初に訪問者カウンターを付けたときも、ボットと重複訪問はある程度防いだと書いた。実運用では、その「ある程度」の基準を少し上げる必要があった。

User-Agentだけでは足りなかった

既存Workerには基本的なボット判定があった。

bot user-agent
Cloudflare verified bot
Cloudflare bot score
dedupe window

露骨なボットはこれである程度引っかかる。

ただ、すべてのクローラーがUser-Agentにbotと書くわけではない。普通のChromeのように見えるリクエストもある。User-Agentだけでは、人なのか薄い自動化ブラウザなのか見分けにくい。

Cloudflareのrequest.cfにはASNとASN organizationがある。だから/trackを受けるときにこれも見るようにした。

TRACK_BLOCKED_ASNS
TRACK_BLOCKED_AS_ORGS

環境変数で完全に上書きするのではなく、Worker内の基本値に環境変数の値を追加する方式にした。明らかにブロックすべき軸はコードに残し、運用中に見つけた値は環境変数で足せるようにするためだ。

組織名は完全一致だけでは弱かった。

Huawei Cloud
Huawei-Cloud-HK
Huawei Cloud Singapore POP
Huawei Clouds Singapore

このように表記が少しずつ変わる。そこで組織名比較はexact matchとcontained stringの両方を許した。1つの基本値で複数の変種を拾うためだ。

3秒のvisible engagementを入れた

ASNフィルターだけだとネットワーク中心の規則になりすぎる。

正常な読者もISPや会社ネットワークの後ろにいることがある。逆にクローラーも普通に見えるネットワークから来ることがある。だからクライアント側の信号も見る必要があった。

今回、クライアントはページが実際に見えている状態で一定時間が過ぎてからだけ/trackを送る。

track_delay_seconds = 3

3秒は長くない。読むつもりの人にはほとんど気にならない。でも開いてすぐ閉じるリクエスト、バックグラウンドタブでDOMだけ拾うような動きは減らせる。

クライアントは/track payloadにこれらの値を送る。

engagementMs
visibilityState
documentHidden
viewportWidth
viewportHeight

Workerはこの値を再検証する。

クライアントJSが待ったからといってそのまま信じない。サーバー側でengagementMsが基準より短ければclient_visible_too_shortで無視する。viewportが0や不正ならclient_viewport_invalidで無視する。

visible信号は任意ではなかった

最初の実装は少し緩かった。

visibilityStateとdocumentHiddenがあれば確認し、なければ通る可能性があった。これだと新しいクライアントは厳しくなるが、フィールドを抜いて直接/trackを叩くリクエストは残る。

そこでWorker条件をさらに固めた。

visibilityState === "visible"
documentHidden === false

この2つが正確に合わなければclient_signal_missingとして無視する。

ここで重要なのは、hiddenとmissingを同じ系統として扱ったことだ。/trackは公開閲覧数を増やすendpointだ。このendpointに来るリクエストは、正常なページから正常なクライアントが送ったものに見えるべきだ。信号がないなら通す理由はない。

結果として、/analyticsの読み取りは開いたままだが、/trackはかなり厳しくなった。

統計を読む
-> 公開可能

閲覧数を増やす
-> production origin
-> visible engagement
-> 正常viewport
-> bot/ASN/orgフィルター通過

ブロック値は見直し続ける必要がある

今回もう一つ学んだのは、ブロックリストは広げればよいものではないということだ。

クラウドクローラーを捕まえようとして、正常なISP ASNまで基本ブロック値に入れると、実読者の記録も落ちる。だから誤って入った値を基本ブロックASNから外した。

フィルターは強いほどよく見えるが、統計ではfalse positiveにもコストがある。

ボットを数えると数字が膨らむ。
人をブロックすると実読者を消す。

どちらも問題だ。

今回の基準はこう整理した。

明らかなクラウド/クローラー軸はWorkerで止める。
クライアントvisible信号は必須にする。
ISPのように人のtrafficになり得る軸は基本ブロック値に入れない。
疑わしい値はignored_reasonで残して後から監査する。

analytics_eventsには無視されたリクエストも最小情報とignored_reasonを残す。これがないと、あとで数字がなぜ減ったのか、何が止められたのか見直せない。

数字はすぐ見えたいが、簡単に数えてはいけない

訪問者カウンターは妙なバランスの上にある。

反映が遅すぎると壊れて見える。だから訪問者カウンター作業ではGA baselineの上にD1増分をすぐ足す構造を作った。

でも簡単に数えすぎるとボットも一緒に数える。

今回の作業は、そのバランスを少し慎重な側へ寄せたものだ。正常な読者は今でも3秒後に数えられる。ただ、即座に通り過ぎる自動化、hidden document、不正viewport、既知のクラウドクローラー軸は入りにくくなる。

公開統計は正確な会計帳簿ではない。

それでも、少なくとも「人が読んだ痕跡」に近くあるべきだ。数字が大きいことが目的ではない。信じられる数字だから次の判断ができる。

確認したこと

作業中に確認したのはこれだ。

node --check cloudflare/ga-stats-worker.js
node --check assets/js/custom/visitor-stats.js
git diff --check
bundle exec jekyll build
Cloudflare Worker deploy
GitHub Pages deploy

Worker smokeも見た。

/analytics?range=today
-> trackDelaySeconds: 3

/track without visibilityState
-> ignored, client_signal_missing

/track with visibilityState="hidden"
-> ignored, client_signal_missing

/track with documentHidden=true
-> ignored, client_signal_missing

デプロイ済みのホームHTMLにもdata-track-delay-seconds="3"が入っていることを確認した。

派手な修正ではない。

でも公開数字を置くなら、こういう防御が必要になる。閲覧数は目に見える機能だからなおさらだ。間違って数えると信頼がすぐ壊れる。今回はカウンターを大きくしたのではなく、だまされにくくした作業だった。