[🛠] 블로그 통계에서 봇 카운트 줄이기

✨ GPT-5.5의 요약 　

Cloudflare Worker 방문 집계에 클라우드 크롤러와 얇은 헤드리스 접근이 섞이던 문제를 줄이기 위해, ASN/조직 필터와 visible engagement 신호를 추가하고 잘못 막힌 통신사 ASN을 풀어낸 기록.

통계 숫자가 다시 이상했다.

공개 블로그 통계 페이지를 붙인 뒤에는 적어도 로컬 작업이 production 카운터를 더럽히지는 않게 됐다. 그런데 이번에는 다른 문제가 보였다.

사람이 읽었다기에는 리듬이 이상한 요청들이 들어왔다.

페이지를 열자마자 여러 경로를 훑고, 브라우저처럼 보이는 User-Agent를 달고, 그런데 실제 독자처럼 머무는 느낌은 없었다. 정적 블로그는 공개되어 있으니 크롤러가 오는 건 당연하다. 문제는 그 크롤러가 /track까지 때리면 공개 조회수와 방문자 수가 같이 부풀어 오른다는 점이었다.

처음 방문자 카운터를 붙일 때도 봇과 중복 방문은 적당히 막았다고 썼다. 그런데 막상 운영해보니 “적당히”의 기준을 조금 더 올려야 했다.

User-Agent만으로는 부족했다

기존 Worker에는 기본적인 봇 판별이 있었다.

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

이 정도면 노골적인 봇은 어느 정도 걸린다.

하지만 모든 크롤러가 bot이라고 적힌 User-Agent를 쓰지는 않는다. 어떤 요청은 일반 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을 둘 다 허용했다. 하나의 기본값으로 여러 변형을 잡기 위한 선택이었다.

3초 visible engagement를 넣었다

ASN 필터만으로 끝내면 너무 네트워크 중심의 규칙이 된다.

정상 독자도 특정 통신사나 회사망 뒤에 있을 수 있다. 반대로 크롤러도 흔한 네트워크에서 올 수 있다. 그래서 클라이언트 쪽 신호도 같이 봐야 했다.

이번에 클라이언트는 페이지가 실제로 보이는 상태로 일정 시간 지난 뒤에만 /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

이 두 조건이 정확히 맞지 않으면 client_signal_missing으로 무시한다.

여기서 중요한 건 hidden과 missing을 같은 계열로 본 점이다. /track은 공개 조회수를 올리는 endpoint다. 이 endpoint에 들어오는 요청은 “정상 페이지에서 정상 클라이언트가 보낸 요청”이어야 한다. 신호가 없으면 봐줄 이유가 없다.

결과적으로 /analytics 조회는 그대로 열려 있지만, /track은 더 까다로워졌다.

통계 읽기
-> 공개 가능

조회수 증가
-> production origin
-> visible engagement
-> 정상 viewport
-> bot/ASN/org 필터 통과

막는 값은 계속 재검토해야 한다

차단 목록은 무조건 넓히면 안 된다.

클라우드 크롤러를 잡으려다가 정상 통신사 ASN까지 기본 차단값에 들어가면, 실제 독자 기록도 빠질 수 있다. 그래서 기본 차단 ASN에서 잘못 들어간 값을 제거했다.

필터는 강할수록 좋아 보이지만, 통계에서는 false positive도 비용이다.

봇을 세면 숫자가 부풀어 오른다.
사람을 막으면 실제 독자를 지운다.

둘 다 문제다.

그래서 이번 기준은 이렇게 정리했다.

확실한 클라우드/크롤러 축은 Worker에서 막는다.
클라이언트 visible 신호는 필수로 받는다.
통신사처럼 사람 트래픽일 수 있는 축은 기본 차단값에 넣지 않는다.
의심스러운 값은 ignored_reason으로 남겨서 나중에 감사한다.

analytics_events에는 무시된 요청도 최소 정보와 ignored_reason을 남긴다. 이게 없으면 나중에 숫자가 왜 줄었는지, 무엇이 막혔는지 다시 볼 수 없다.

숫자는 바로 보여야 하지만 함부로 세면 안 된다

방문자 카운터는 이상한 균형 위에 있다.

너무 늦게 반영되면 고장난 것처럼 보인다. 그래서 방문자 카운터 작업 때는 GA baseline 위에 D1 증가분을 바로 더하는 구조를 만들었다.

그런데 너무 쉽게 세면 봇도 같이 센다.

여전히 3초 뒤면 정상 독자는 카운트된다. 하지만 즉시 스쳐 지나가는 자동화 요청, hidden document, 비정상 viewport, 알려진 클라우드 크롤러 축은 카운터에 들어가기 어렵다.

공개 통계는 정확한 분석 도구가 아니다.

그래도 최소한 “사람이 읽은 흔적”에 가까워야 한다. 숫자가 크다고 좋은 게 아니라, 숫자가 믿을 만해야 다음 판단을 할 수 있다.

visible engagement와 봇 차단 smoke를 확인했다

명령은 이렇게 돌렸다.

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"이 들어가는지 확인했다.

공개 숫자는 잘못 세면 바로 믿기 어려워진다. 이번에는 카운터를 더 크게 만든 게 아니라, 덜 쉽게 속게 만든 작업이었다.