GA4 가짜 방문자 412명, 호스트 이름 허용 목록 하나로 끊었습니다
실시간 보고서 사용자 세 배의 정체는 우리 홈페이지를 통째로 베껴 간 사이트였습니다. 제외 목록을 아홉 번 고치다 허용 목록으로 갈아탄 기록.
화요일 밤에 크롬 개발자도구를 열고 체크박스 하나를 눌렀습니다. 제가 3년째 혼자 굴리는 생활정보 블로그의 글 한 편이 순식간에 빨간 상자로 뒤덮였습니다.
빨간 상자는 전부 광고였습니다. 휴대폰 화면 기준으로 보니 본문보다 빨간색이 먼저 눈에 들어오는 구간이 있었습니다.
그 체크박스는 9월 15일에 크롬이 광고 밀도를 숫자로 공개하면서 같이 생긴 기능입니다. 애드센스로 밥값 정도를 버는 입장이라 그냥 넘길 수가 없었습니다.
크롬 사용자 경험 보고서, 흔히 CrUX라고 부르는 데이터에 광고 지표 네 개가 추가됐습니다. 실제 크롬 사용자가 그 사이트에서 광고를 얼마나 보고 있는지를 모아서 보여주는 겁니다. 크롬 팀은 이렇게 적었습니다. 과한 광고는 누구나 보면 알지만 수치로 재기는 어려웠다고요. (Chrome for Developers 블로그)
네 지표 모두 ‘실험용’ 딱지가 붙어 있습니다. 코어 웹 바이탈에 들어가는 것도 아니고 좋음·나쁨 기준선도 없습니다.
그런데도 발표 다음 날 해외 SEO 컨설턴트 글렌 게이브는 광고를 많이 붙인 사이트라면 오늘 당장 확인해 보라고 했습니다. (Search Engine Roundtable) 저도 그 말을 보고 개발자도구를 열었던 거고요.
공식 문서를 읽으면서 제 식으로 정리한 표입니다. API에서 쓰는 이름도 같이 적었습니다.
| 지표 | API 키 | 무엇을 재나 |
|---|---|---|
| 광고 개수(Ad Count) | experimental_ad_count | 화면 안에 동시에 보이는 광고 수의 평균 |
| 광고 밀도(Ad Density) | experimental_ad_density | 화면 면적 중 광고가 차지한 비율의 평균(%) |
| 광고 무게: CPU | experimental_ad_cpu | 광고 프레임이 쓴 자바스크립트 실행 시간(ms) |
| 광고 무게: 네트워크 | experimental_ad_kilobytes | 광고가 내려받은 데이터 양(KB) |
재는 방식이 생각보다 단순합니다. 크롬이 1초에 한 번씩 화면을 찍고 그 순간 광고가 몇 개, 얼마만큼 보였는지 기록합니다. 페이지를 떠날 때 그 평균을 냅니다.
문서에 나온 예시가 이해하기 쉬웠습니다. 광고가 화면 절반을 덮은 채로 5초를 읽고, 스크롤을 내려 광고 없는 구간을 5초 읽으면 그 방문의 광고 밀도는 25%가 됩니다. 광고가 1픽셀이라도 화면에 걸쳐 있으면 개수에는 1개로 잡힙니다.
이렇게 모은 방문을 줄 세워서 75번째 값, 즉 p75를 공개합니다. 광고 밀도가 23으로 나오면 방문 네 번 중 세 번은 23% 이하였다는 뜻입니다.
개발자도구에서 애플리케이션 패널로 들어가면 광고 탭이 생겨 있습니다. 여기서 Highlight ads를 켜면 크롬이 광고로 판단한 영역에 빨간 상자가 씌워집니다. 같은 탭에서 방금 본 페이지의 광고 지표도 바로 보여줍니다.

첫 시도는 완전히 헛손질이었습니다. 광고 개수 0, 밀도 0이 떴습니다. 잠깐 좋아했는데 제 크롬에 광고 차단 확장 프로그램이 켜져 있었습니다. 게스트 창을 새로 열고 다시 쟀습니다.
두 번째는 모바일 화면으로 바꿔서 가장 많이 읽히는 글 하나를 처음부터 끝까지 천천히 내려 봤습니다. 광고 밀도 31%, 동시 노출 광고 평균 2.4개. 하단에 붙어 따라다니는 앵커 광고가 있는데 이게 화면 아래를 계속 차지하고 있었습니다. 본문 광고가 지나가는 순간엔 둘이 겹쳐서 화면의 절반 가까이가 광고였습니다.
앵커 광고만 끄고 같은 글을 같은 속도로 다시 내렸습니다. 밀도가 19%로 떨어졌습니다. 개수는 1.3개였습니다.
숫자 두 개 차이인데 체감이 컸습니다. 제가 독자였다면 31% 쪽 화면에서 뒤로 가기를 눌렀을 것 같습니다.
여기서 하나 헷갈렸던 게 있습니다. 개발자도구에 뜨는 숫자는 제 브라우저 한 대에서 잰 값이라 CrUX에 공개되는 값과 다릅니다.

CrUX에 광고 지표가 잡히려면 조건이 있습니다. 사이트 루트에 ads.txt 파일이 있고 그 안에 승인된 판매자가 한 줄 이상 적혀 있어야 합니다. 파일이 없거나 빈 자리표시 줄만 있으면 아예 집계 대상에서 빠진다고 문서에 나와 있습니다. (CrUX 광고 측정 방법론)
기존 웹 바이탈처럼 방문자 수가 어느 정도 쌓여야 한다는 조건도 그대로 적용됩니다. 하루 방문자가 몇십 명인 블로그라면 CrUX에는 한동안 아무것도 안 나올 수 있습니다.
그래서 제 경우엔 개발자도구로 직접 재는 쪽이 당분간 더 쓸모 있습니다. 크롬 팀도 앞으로 한 달 동안 데이터가 점점 늘어날 거라고 했으니 CrUX Vis 대시보드는 10월 중순쯤 다시 열어 볼 생각입니다.
발표문 어디에도 검색 순위에 반영한다는 말은 없습니다. 구글 검색 순위가 흔들린 건 다른 이유였다는 이야기는 6월 스팸 업데이트 글에서 따로 적었으니 여기선 넘어가겠습니다.
제가 걸리는 건 광고를 사는 쪽입니다. 발표문을 보면 이 숫자를 반기는 쪽이 대부분 광고 대행 지주사나 광고 거래소 같은 곳입니다. 광고 자리의 값을 매길 때 이 지표를 쓰겠다는 뜻으로 읽힙니다.
광고가 빽빽한 페이지의 자리는 덜 쳐주고 여유 있는 페이지는 더 쳐줄 수 있다는 겁니다. 솔직히 아직은 가능성 단계입니다. 그래도 애드센스 수익이 방문자 수 곱하기 단가라는 걸 생각하면 단가 쪽 변수가 하나 더 생긴 셈입니다.
방문자 수 쪽은 결국 검색에서 얼마나 불려 나오느냐인데, 요즘은 그것도 AI 답변에 몇 번 인용됐는지까지 봐야 하는 상황이라 한쪽만 붙잡고 있을 수가 없습니다.
바꾼 건 모바일 앵커 광고입니다. 애드센스 자동 광고 설정에서 앵커 광고만 껐습니다. 일주일쯤 수익과 체류 시간을 보고 다시 판단할 생각입니다.
본문 중간 광고 개수는 그대로 뒀습니다. 문단 사이에 들어가는 광고는 스크롤하면 금방 화면 밖으로 빠져서 밀도 계산에서 차지하는 비중이 생각보다 작았습니다. 오히려 문단을 짧게 끊어 쓴 글은 광고 사이 간격이 넓어져 밀도가 낮게 나왔습니다.
광고 네트워크를 추가로 붙이는 것도 보류했습니다. 광고 무게 CPU 지표가 어떻게 나오는지 보고 나서 정해도 늦지 않다고 봤습니다. 광고 스크립트가 무거우면 페이지 자체가 느려지는데 그러면 꾸준히 써도 검색이 안 되는 블로그 쪽 문제로 번질 수 있으니까요.
정답이라고 말할 수 있는 건 아직 없습니다. 기준선이 없는 지표라 몇 퍼센트가 적당한지 아무도 모릅니다. 그래서 저는 제 글끼리 비교하는 데만 씁니다.
현재 크롬과 구글 발표에는 순위에 쓴다는 내용이 없습니다. 코어 웹 바이탈에도 들어가지 않았고 네 지표 모두 실험용이라고 명시돼 있습니다.
ads.txt에 구글 판매자 줄이 제대로 들어가 있고 방문자 수가 CrUX 기준을 넘으면 잡힙니다. 방문자가 적으면 데이터가 비어 있을 수 있으니 그땐 개발자도구 광고 탭으로 직접 재 보는 게 빠릅니다.
개발자도구는 내가 지금 본 한 번의 방문만 잽니다. CrUX는 실제 방문자 28일치를 모아 75번째 값을 냅니다. 내가 천천히 읽었는지, 빨리 내렸는지에 따라서도 로컬 값은 크게 흔들립니다.
아직은 CrUX API, CrUX History API, CrUX Vis에서만 볼 수 있습니다. BigQuery 데이터셋에는 추가하는 중이라고 크롬 문서에 적혀 있습니다.