티스토리 방문통계를 칸별로 대조해봤습니다 — 되는 칸, 오히려 나아지는 칸, 영원히 안 되는 칸

블로그를 세 곳 굴리고 있습니다. 하나는 직접 만든 정적 사이트고 둘은 티스토리입니다. 티스토리 관리자에는 방문통계 화면이 있고 제가 실제로 열어보던 값은 결국 어떤 글에 몇 명이 들어왔나 하나였습니다. 이걸 서버 없이, 쿠키 없이, 돈 안 들이고 가져갈 수 있는지 재봤습니다.

처음 세운 질문은 「티스토리 통계를 대체할 수 있나」였습니다. 이 질문으로는 답이 안 나옵니다. 「대체로 됩니다」 같은 말밖에 안 나오는데, 그 말은 정작 안 되는 칸을 만났을 때 아무 도움이 안 됩니다.

그래서 화면을 항목 단위 12칸으로 쪼개고 칸마다 따로 판정했습니다. 쪼개고 나니 답이 되는 칸, 오히려 나아지는 칸, 도구를 바꿔도 영원히 안 되는 칸 세 종류로 갈렸습니다.

12칸 판정표

표에서 「차원」은 대시보드가 숫자를 쪼개 보여주는 기준 축을 말합니다.

여섯 칸이 완전대체 또는 얻는 것이고 네 칸이 부분이고 한 칸이 못 넘어옵니다. 남은 한 칸은 애초에 대체 대상이 아닙니다. 「대체로 된다」와 이 표는 정보량이 다릅니다.

두 칸은 대체가 아니라 오히려 얻는 것이었습니다

티스토리는 블로그마다 관리자에 따로 들어가야 했습니다. 세 곳이면 세 번, 다섯 곳이면 다섯 번입니다. 계측 토큰(어느 사이트의 기록인지 구분하는 열쇠 문자열) 하나를 여러 사이트가 공유하면 대시보드를 여는 순간 합산이 뜨고 거기서 블로그별로 쪼개니 없던 기능이 생기는 쪽입니다.

두 번째는 백업입니다. 티스토리 백업 파일을 받아보면 글과 첨부는 들어 있는데 통계는 안 들어옵니다. 플랫폼을 떠나는 순간 지난 방문 기록은 같이 못 나옵니다. 바깥 계측으로 옮기면 그 값이 API(프로그램끼리 데이터를 주고받는 통로)로 빠집니다.

티스토리 고객센터가 백업 대상을 「작성한 글」과 「글에 첨부한 파일과 이미지」로 한정하고, "‘통계’, ‘댓글’, ‘방명록’ … 등은 백업되지 않습니다" 라고 따로 못박아 둡니다 — 백업되는 데이터 · 백업되지 않는 데이터. 2026-09-21에 두 주소가 모두 열리는 것까지 확인했습니다.

앞선 글에서 티스토리 쪽 기록 전송이 POST 404(그런 주소가 없다는 응답)를 돌려주는 데서 막혔고 남은 가설 하나를 미확인으로 남겨뒀습니다. 사이트가 자동 설치 모드라 수동 수집 경로가 안 열려 있다는 가설이었습니다. 관리 화면에서 코드 조각을 직접 붙여 넣는 설치 방식으로 바꾸니 세 호스트 전부 204, 즉 정상 접수로 바뀌었습니다. 그 가설이 맞았습니다. 다만 curl 재현은 전환 뒤에도 404였습니다. 손으로 만든 요청이 브라우저와 어딘가 다르다는 뜻이라 최종 확인은 개발자 도구로 했습니다.

그리고 여기서 축을 잘못 적어뒀던 게 드러났습니다

「블로그별로 나눠 본다」 칸은 Site 차원이 맡는 줄 알았습니다. 이름부터 사이트를 구분하는 차원이니 당연히 그걸로 나뉠 거라고 생각했습니다.

아닙니다. 토큰 하나를 여러 호스트가 공유하면 그 전부가 같은 Site 값 하나로 들어옵니다. 실제 분리축은 Host 입니다. 이건 이름을 헷갈린 정도가 아니라 택일 구조였습니다.

둘 다 「블로그별로 보인다」까지는 같아서 차원 이름만 보고는 차이가 안 드러납니다. 차이는 통합 뷰를 잃느냐에서 나는데 제가 원래 원했던 게 정확히 그 통합 뷰였습니다. Site 가 분리축이라고 믿은 채 진행했으면 토큰을 사이트마다 새로 발급했을 것이고 얻으려던 칸을 스스로 버린 상태로 「대체 완료」라고 적었을 겁니다.

유입 검색어는 도구를 바꿔도 안 풀립니다

이 칸만 다른 칸과 성질이 다릅니다. 세 겹으로 막혀 있어서 도구 선택 문제가 아니라 구조입니다.

계측 쪽이 쿼리스트링을 아예 안 받습니다. 쿼리스트링은 주소 뒤 ? 다음에 붙는 부분입니다. 제공되는 차원은 열 종입니다 — Country · Host · Path · Referer · Device type · Browser · OS · Site · Exclude Bots · Navigation type. 이 목록에는 쿼리스트링도, 링크에 붙이는 유입 표시용 꼬리표인 UTM도 없습니다. 민감정보 회피가 이유라 API로 내려받아도 나오지 않습니다. (Navigation type 은 2026-04-30에 추가된 차원인데 문서 로드 방식 진단용이라 유입 분석에는 기여가 없습니다.)

차원 열 종은 Cloudflare Web Analytics · Dimensions 목록 그대로이고, Navigation type 이 붙은 날짜는 2026-04-30 changelog 입니다. 쿼리스트링을 안 받는 이유는 FAQ 가 “Cloudflare Web Analytics do not log query strings to avoid collecting potentially sensitive data” 라고 직접 적어둡니다 — FAQ. 세 주소 모두 2026-09-21에 열립니다.

다른 도구로 갈아타도 그 칸이 없습니다. GA4에는 「구글 오가닉 검색어」 차원이 없습니다. GA4의 Search term 은 사이트 내부 검색어고 Manual term 은 utm_term 입니다. 이름이 비슷해서 있는 줄 알기 딱 좋게 생겼습니다.

2026-09-21에 GA4 측정기준·측정항목 목록 전문을 받아 대조했습니다 — Search term 은 “The term used to search your website or application”, Manual term 은 “manually tagging the destination URLs in your ads with the utm_term parameter” 이고, 「구글 오가닉 검색어」에 해당하는 차원은 그 목록에 없습니다. 그 값은 서치 콘솔을 연동했을 때 별도 보고서로만 나옵니다 — Search Console 연동 보고서.

애초에 브라우저가 안 보냅니다. 구글 쪽 페이지가 리퍼러 정책을 origin 으로 선언하고, 선언이 없어도 요즘 브라우저의 기본 정책이 strict-origin-when-cross-origin 입니다. 어느 쪽이든 리퍼러에는 어느 사이트에서 왔는지, 즉 도메인 주소까지만 실립니다. 검색어는 거기에 실려 있질 않습니다.

2026-09-21 실측 — https://www.google.com/ 응답에는 referrer-policy 헤더가 없고 HTML 쪽에 <meta content="origin" name="referrer"> 가 들어 있었습니다(curl -sI 와 curl -s 각 1회). 헤더가 없을 때 적용되는 기본값은 Referrer Policy 명세 3절이 “The default referrer policy is strict-origin-when-cross-origin” 이라고 정한 값입니다 (그 값 자체를 정의하는 절은 3.7절입니다). 참고로 같은 날 https://search.naver.com/ 은 referrer-policy: unsafe-url 을 내려보냈습니다 — 네이버 쪽은 정책상 전체 주소를 넘긴다는 뜻이지만, 받는 계측이 쿼리스트링을 버리므로 검색어가 보이지는 않습니다.

그러니 검색어는 검색엔진이 자기 콘솔로 되돌려주는 경로로만 옵니다. 구글은 서치 콘솔, 네이버는 서치어드바이저, 빙은 웹마스터 도구입니다. 다음은 어디에서도 못 봅니다. 티스토리는 전 검색엔진 키워드를 한 화면에 섞어서 보여줬으므로, 이 칸은 무엇을 붙여도 완전히는 복구되지 않습니다.

콘솔로 오는 값도 같은 값이 아닙니다. 클릭·노출·순위지 방문자가 아니고, 글별 검색어 교차는 구글과 빙에서만 됩니다.

빙 쪽은 2026-09-22에 Bing Webmaster API 레퍼런스 를 받아 확인했습니다 — GetQueryStats “Get detailed traffic statistics for top queries” · GetQueryPageDetailStats “Get detailed statistics for specific query and page” 가 문서에 있습니다. 뒤쪽이 글×검색어 교차입니다. 처음 이 글을 쓸 때는 「다음과 빙 둘 다 못 본다」고 적었는데 빙 쪽은 틀렸습니다.

「방문자 수」로 읽던 지표가 사람 수가 아니었습니다

여기가 조용히 틀리기 쉬운 칸입니다. 이 계측의 Visits 는 방문자 수라는 이름이 붙어 있지만 쿠키를 쓰지 않고 리퍼러가 자기 호스트와 다른 페이지뷰를 셉니다. 페이지뷰는 사람 수가 아니라 페이지가 열린 횟수입니다. 사람 수에 가까운 값은 GA4의 Total users 인데 그건 2년짜리 쿠키를 씁니다.

⇒ 「쿠키 없이 방문자 수」는 이 조합 어디에서도 얻을 수 없습니다.

Visits 의 정의는 “A page view that originated from a different website or direct link. Cloudflare checks where the HTTP referer does not match the hostname” 입니다 — High-level metrics. GA4 의 Total users 는 “The number of unique user IDs that triggered any events” 이고(2026-09-21에 측정기준·측정항목 목록 에서 확인), 사용자를 구분하는 퍼스트파티 쿠키 _ga 의 기본 만료가 2년입니다 — GA4 쿠키 사용.

이 칸을 티스토리 「방문자」 옆에 나란히 놓고 늘었다·줄었다를 말하면 그 문장은 그냥 틀린 문장입니다.

대체하는 쪽의 한계도 먼저 적어둡니다

보관·샘플링·쿼리스트링·커스텀 이벤트는 Cloudflare Web Analytics FAQ, 사이트 상한은 Limits 문서에 적힌 값입니다(2026-09-21 기준 두 주소 모두 열립니다). 원문은 차례로 “Currently, you can access data for the previous six months” · “We retain unsampled beacon data for the past 7 days, after this point data is aggregated down to around 10%” · “Does Web Analytics support custom events? Not yet” · “Not proxied through Cloudflare: 10 / Proxied through Cloudflare: No limit” 이고, 그 10개를 FAQ 가 “a soft limit of ten sites per account, but that can be adjusted by contacting Cloudflare support” 라고 덧붙여서 「느슨한」이라고 적었습니다. 샘플링은 한 겹 더 있습니다 — 조회 시점에 0.0001%~100% 범위의 동적 샘플링이 따로 걸리는데, 트래픽이 적은 사이트일수록 오히려 더 높은 비율로 집계한다고 같은 문서가 적어둡니다. 광고 차단률만은 공개된 1차 자료를 찾지 못해 「없음」으로 적었습니다.

보관 6개월은 「작년 이맘때」를 영영 못 본다는 뜻입니다. 백업 칸을 얻는 것으로 판정해놓고 백업을 안 돌리면 그 이득은 없는 것과 같습니다.

지금 아니면 영영 못 재는 값이 하나 있습니다

광고 차단으로 얼마나 잃는지입니다. 차단된다는 것 자체는 확정입니다. 공개 차단 목록인 EasyPrivacy 에 기록을 받는 호스트를 통째로 막는 규칙 ||cloudflareinsights.com^$third-party 이 있고, 도메인과 무관하게 걸리는 경로 규칙 /cdn-cgi/beacon/* · /cdn-cgi/rum? · /cdn-cgi/rum| 도 따로 있습니다.

2026-09-21에 easyprivacy.txt(목록 버전 202609210628, 56,911행) 전문을 받아 grep -n 으로 찾은 결과입니다. 이날 행번호는 6579·569·571·572 였는데 2026-09-02에 같은 규칙을 찾았을 때는 6579·566·568·569 였습니다 — 목록이 갱신되면 행번호는 밀리므로 기준으로 삼을 것은 규칙 문자열 쪽입니다. uBlock Origin 은 이 목록을 기본 활성으로 배포합니다.

여기서 또 하나 틀렸습니다. 저는 자동 설치가 내 도메인 주소로 나가니 차단을 덜 탈 거라고 생각했습니다. 위의 경로 규칙들이 도메인과 무관하게 걸려서 자동 설치도 똑같이 막힙니다. 이 축에서 자동과 수동은 우열이 없습니다.

비율은 1차 자료가 존재하지 않습니다. 만든 쪽도 「차단된다」까지만 인정하고 숫자를 낸 적이 없습니다. 그런데 지금 제 손에 대조군이 있습니다. 두 계측이 같은 블로그에 동시에 붙어 있는 지금, 같은 기간 수치를 대조하면 두 값의 차이까지는 나옵니다.

여기도 처음엔 틀리게 적었습니다. 「티스토리 자체 통계는 플랫폼이 자기 쪽에서 세므로 차단을 안 탄다」를 전제로 깔았는데, 티스토리 페이지 원본에도 방문자 브라우저에서 도는 추적 스크립트가 실려 있고 위에 인용한 같은 차단 목록에 그 수집 호스트를 겨냥한 규칙이 여러 줄 있습니다. 한쪽만 손실이 0인 게 아니므로 그 차이를 그대로 「제 블로그의 차단 손실률」로 읽을 수는 없습니다. 어느 쪽이 얼마나 덜 세는지를 따로 재야 하는데 아직 안 했습니다.

2026-09-22에 misiq.birchholt.com 라이브 HTML 과 EasyPrivacy 원본(목록 버전 202609220530)을 각각 받아 확인했습니다 — 페이지에 tiara-1.2.0.min.js 와 tistory_admin/frontend/tiara/v1.0.7/index.js 가 실리고, 목록에는 ||stat.tiara.kakao.com^ · ||stat.tiara.tistory.com^ · ||track.tiara.daum.net^ 줄이 있습니다.

티스토리를 접으면 대조군은 사라집니다. 그리고 안 재두면, 나중에 숫자가 낮게 나올 때 「트래픽이 줄었다」로 오독하게 됩니다.

확인하지 못한 것

• 비교 대상의 절반을 문서로만 봤습니다. 티스토리 통계 화면을 항목별로 열어 전수 대조하는 데까지는 가지 못했습니다. 그래서 위 표 왼쪽 열에서 1차로 확인한 범위는 티스토리 고객센터의 통계 도움말에 적힌 다섯 항목 — 조회수/방문자 · 유입 경로 · 유입 키워드 · 개별 글 통계 · 인기글 — 까지입니다. 실시간 로그나 누적 합계 같은 세부는 그 목록 밖이라 확인 강도가 다릅니다. 비교표를 그리면서 비교 대상을 눈으로 안 본 셈이고 이건 이 글의 약한 지점입니다.
• GA4 보관 기간을 잘못 알고 있었습니다. 「무료는 14개월밖에 못 본다」가 그것인데, 2/14개월 설정은 탐색 분석 쪽에 걸리고 표준 집계 보고서에는 영향이 없습니다. 글별 조회수를 표준 보고서로 보는 한 그 컷에 안 걸립니다. 다만 API·대시보드 도구 경로까지 같은지는 확인하지 못했습니다. 같은 자리에서 한국어 화면 이름도 헷갈렸습니다 — 「유입경로 보고서」는 방문자가 사이트 안에서 거쳐 간 단계를 보는 화면이고, 어디서 들어왔는지는 「트래픽 획득」입니다. 번역된 메뉴 이름으로 판단하면 정반대로 갑니다.
• API의 리퍼러 경로에 쿼리스트링이 포함되는지. 포함되면 검색어 일부가 나올 여지가 있는데, 「쿼리스트링 미수집」 원칙이 리퍼러 경로에도 적용되는지 명시를 못 찾았습니다.
• 네이버 유입에서 리퍼러가 실제로 전달되는지. 안 오면 네이버 유입이 전부 「어디서 왔는지 모름」으로 뭉쳐서 「국내 검색이 얼마나 오나」를 못 봅니다. 응답 헤더만 보면 넘어올 것처럼 보이는데(위 각주) 대시보드에 실제로 잡히는지는 아직 대조하지 못했습니다.
• 광고 차단 실제 비율. 위에 적은 대로 아직 안 쟀습니다.

위 첫 항목의 「통계 도움말」은 방문 수와 유입 경로 수의 차이 · 유입 경로와 키워드 두 건입니다 (2026-09-21 기준 둘 다 열립니다). 백업에 통계가 담기는지는 예외로, 위 백업 각주의 별도 문서에서 직접 확인했습니다. GA4 보관 항목은 데이터 보관 도움말 이 설정의 적용 범위를 탐색 분석과 유입경로 보고서로 한정하고 표준 집계 보고서는 영향을 받지 않는다고 적어둔 것이 근거이며, 무료 속성의 선택지가 2개월·14개월뿐이라는 것은 구성 한도 문서 쪽에 있습니다.

정리

• 「대체할 수 있나」를 통째로 묻지 말고 칸으로 쪼개서 물으면 답이 갈립니다. 네 칸은 그대로 되고 두 칸은 오히려 나아지고 네 칸은 반만 되고 한 칸은 안 됩니다
• 유입 검색어는 구조 문제입니다. 계측·GA4·브라우저 세 겹이라 도구를 갈아타도 안 풀립니다
• 분리축은 Site 가 아니라 Host 였습니다. 토큰을 사이트마다 새로 발급하면 얻으려던 통합 뷰를 스스로 버립니다
• Visits 는 리퍼러가 자기 호스트와 다른 페이지뷰를 셉니다. 사람 수로 보고 플랫폼 「방문자」와 나란히 놓지 마십시오
• 대조군은 없어지기 전에 써야 합니다. 두 계측이 같이 붙어 있는 기간은 다시 안 옵니다