집계가 섞이는 이유
AI가 글을 등록한 뒤 실제 화면을 확인하면 일반 방문자와 같은 브라우저 요청이 발생한다. Jetpack은 로그인한 사이트 관리자 방문을 기본적으로 제외하지만, GA4는 WordPress 로그인 여부를 자동으로 알지 못한다. GA4에서는 내부 IP를 먼저 ‘테스트’ 상태로 표시한 뒤 이상이 없는지 확인하고 제외 필터를 활성화해야 한다.
블로그를 막 운영하기 시작했을 때 조회수가 조금씩 올라가면 반갑다. 그런데 글을 발행하고 모바일과 PC에서 여러 번 확인한 날에만 조회수가 늘었다면 실제 유입과 내 점검 방문이 섞였을 가능성이 있다. AI 브라우저로 레이아웃을 확인할 때도 마찬가지다.
이 문제를 해결하려면 Jetpack과 GA4를 같은 방식으로 설정하면 안 된다. 두 도구는 방문자를 구분하는 기준이 다르기 때문이다.
먼저 AI가 어떤 방식으로 사이트를 열었는지 구분한다
| 접근 방식 | 자바스크립트 실행 | 조회수에 잡힐 가능성 |
|---|---|---|
| 로그인된 브라우저로 공개 글 확인 | 실행 | Jetpack은 기본 제외, GA4는 내부 트래픽 설정에 따라 달라짐 |
| 로그아웃 브라우저로 공개 글 확인 | 실행 | 일반 방문처럼 잡힐 수 있음 |
| 서버가 HTML만 가져옴 | 대개 실행하지 않음 | 브라우저 추적 코드는 보통 동작하지 않음 |
| 검색엔진 크롤러 | 도구마다 다름 | Jetpack은 알려진 검색 로봇을 제외한다고 안내 |
“AI가 접속했다”는 사실만으로 포함 여부가 정해지지는 않는다. 로그인 상태, 자바스크립트 실행 여부, 접속한 네트워크가 기준이 된다. 따라서 자동화 도구의 이름보다 실제 접속 환경을 확인해야 한다.
Jetpack은 로그인한 관리자 방문이 빠지는지 먼저 확인한다
Jetpack 공식 안내에 따르면 공개 사이트를 보는 로그인된 관리자와 사이트 구성원의 방문은 기본적으로 통계에 포함되지 않는다. 설정에서 로그인 사용자 방문을 집계하도록 바꿨거나, 자동화 브라우저가 로그아웃 상태라면 예외가 생길 수 있다.
- 워드프레스 관리자 화면에 로그인한 상태로 글을 연다.
- 같은 시간대 Jetpack 조회수가 올라가는지 확인한다.
- Jetpack 통계 설정에서 로그인 사용자 조회 집계 범위를 확인한다.
- 자동화에 쓰는 브라우저도 같은 WordPress 세션을 쓰는지 확인한다.
통계는 실시간으로 바로 반영되지 않을 수 있으므로 한 번 새로고침한 직후 숫자만 보고 판단하지 않는 것이 좋다. 테스트 시각과 연 페이지를 적어두고 나중에 비교하면 편하다.
GA4는 내부 IP를 표시하고 바로 제외하지 않는다
GA4의 내부 트래픽 설정은 두 단계다. 먼저 특정 IP에서 들어온 이벤트에 traffic_type 값을 붙이고, 그다음 데이터 필터에서 이 값을 제외한다. Google은 필터를 바로 활성화하기 전에 ‘테스트’ 상태로 검증하도록 안내한다.
- GA4 관리에서 웹 데이터 스트림을 연다.
- 태그 설정의 ‘내부 트래픽 정의’에서 현재 공인 IP를 규칙으로 만든다.
- 데이터 필터에서 내부 트래픽 ‘제외’ 필터를 만들고 상태를 ‘테스트’로 둔다.
- 사이트를 몇 번 열고 테스트 데이터 필터 이름이 붙은 이벤트가 들어오는지 확인한다.
- 업무 트래픽만 정확히 표시되는 것이 확인되면 필터를 ‘활성’으로 바꾼다.
활성화된 제외 필터의 영향은 되돌려 과거 데이터에 복원할 수 없다. Google 도움말에도 제외된 데이터는 Analytics나 BigQuery에서 사용할 수 없다고 적혀 있다. 테스트 상태를 건너뛰지 말아야 하는 이유다.
집과 휴대폰의 IP가 자주 바뀌면 IP 필터만으로 부족하다
회사 고정 IP에서는 규칙을 한 번 만들면 관리하기 쉽다. 집 인터넷의 공인 IP가 바뀌거나 휴대폰 LTE·5G로 접속하면 같은 사람이더라도 다른 주소로 보인다. VPN을 켜도 주소가 달라진다.
이럴 때는 운영 방식을 함께 정하는 편이 현실적이다. 발행 확인은 항상 로그인된 전용 브라우저와 정해진 네트워크에서 하고, 휴대폰 외부망 확인은 꼭 필요한 경우에만 한다. 더 정확한 구분이 필요하면 WordPress 로그인 상태를 기준으로 GA 태그를 보내지 않거나 별도 내부 사용자 값을 붙이는 구현을 검토할 수 있다. 다만 이 방식은 테마·태그 설정을 바꾸므로 적용 전 별도 테스트가 필요하다.
필터를 켠 뒤에는 실제 유입이 사라지지 않았는지 확인한다
| 확인할 상황 | 예상 결과 |
|---|---|
| 내부 네트워크·로그인 브라우저 | Jetpack 제외, GA4 내부 트래픽으로 식별 |
| 외부 네트워크·로그아웃 브라우저 | 일반 방문으로 수집 |
| 검색 결과에서 들어온 실제 사용자 | 유입 경로와 페이지뷰 수집 |
| 자동화 서버의 단순 HTML 확인 | 추적 코드가 실행되지 않으면 페이지뷰 없음 |
Google은 데이터 필터 적용에 24~36시간이 걸릴 수 있다고 안내한다. 설정 직후 모든 수치가 달라질 것으로 기대하기보다 하루 이상 두고 테스트 이벤트와 실제 유입을 같이 확인하는 편이 낫다.
Jetpack은 빠른 확인, GA4는 행동 분석에 나눠 쓴다
두 통계가 완전히 같아질 필요는 없다. Jetpack은 로그인 사용자와 일부 봇을 기본적으로 제외하고 실시간 반영에도 차이가 있다. GA4는 내부 트래픽 규칙, 동의 배너, 광고 차단기 영향을 받는다.
Jetpack에서는 당일 인기 글을 빠르게 보고, GA4에서는 검색·내부 링크 클릭·스크롤처럼 독자의 행동을 보는 식으로 역할을 나누면 숫자 차이에 덜 흔들린다. 중요한 것은 한 도구의 숫자를 절대값으로 믿는 것이 아니라, 같은 기준을 유지해 변화 추이를 보는 것이다.
설정 방법과 주의사항은 Google Analytics 내부 트래픽 필터링 안내와 Jetpack Stats 문제 해결 안내에서 확인할 수 있다.
확인 범위: 2026-09-21 기준 공식 문서와 요즘노트 운영 중 발생한 내부 조회 문제를 바탕으로 작성했다. 현재 GA4 필터의 실제 활성 상태를 재검증한 결과는 아니다. 작성: 노트지기.

답글 남기기