Яндекс Метрика가 사이트 트래픽을 표시하지 않는 이유

데이터가 없다고 해서 트래픽이 없는 것은 아닙니다

Яндекс Метрика의 빈 그래프는 사이트에 아무도 방문하지 않는다는 것을 증명하지 않습니다. Метрика는 방문자의 브라우저가 카운터 코드를 로드하고 실행한 뒤 분석 서버로 요청을 보냈을 때만 방문을 기록합니다. 사용자가 페이지를 열고 신청서를 남기거나 광고를 통해 유입되더라도, 스크립트 차단, 브라우저 오류 또는 설정의 필터로 인해 보고서에 포함되지 않을 수 있습니다.

먼저 실제 유입이 없는 것과 데이터 수집 장애를 구분하세요. 전체 그래프가 아니라 동일한 기간, 특정 URL, 특정 소스를 비교해야 합니다. 예를 들어 광고 소재, 스트리밍 설명, 뉴스레터 또는 소셜 미디어 게시물의 링크를 말합니다.

트래픽 부재와 데이터 부재를 구분하는 방법

광고 관리 도구는 보통 광고 클릭을 보여주고, 서버 로그는 사이트 요청을 보여줍니다. 확인하려면 서버 액세스 로그를 열고 해당 기간 동안의 랜딩 페이지를 찾으세요. Nginx 로그에서는 다음과 같은 요청일 수 있습니다: grep "GET /promo" /var/log/nginx/access.log. UTM 태그로 인해 경로가 바뀌는 경우, 파라미터를 제외한 URL 자체를 찾거나 랜딩 주소의 일부를 사용하세요.

광고 관리 도구의 클릭은 페이지 로드와 같지 않습니다. 사용자가 탭을 닫았을 수 있고, 연결이 끊겼을 수 있으며, 링크가 접근 불가능한 URL로 연결될 수도 있습니다. 서버 로그 역시 실제 방문과 같지 않은데, 봇, 링크 미리보기, 기술적 점검이 여기에 포함되기 때문입니다. 하지만 로그에는 유입이 있는데 Метрика에는 없다면, 문제는 대개 카운터나 그 설정에 있습니다.

광고, 로그, Метрика 간의 차이가 의미하는 것

광고 관리 도구에는 클릭이 있지만 로그에 랜딩 페이지 요청이 없다면, 최종 URL, 리디렉트, 도메인 접근성, 트래커 설정을 확인하세요. access.log에 기록은 있지만 브라우저가 mc.yandex.ru로 요청을 보내지 않는다면, 카운터가 실행되지 않거나 차단된 것입니다. mc.yandex.ru로 요청은 가는데 보고서가 비어 있다면, 카운터 번호, 필터, 기간, 도메인 설정을 확인하세요.

정확한 대조를 위해서는 짧은 구간과 하나의 소스를 선택하세요. 프로젝트에서 채택한 데이터 처리 규칙 범위 내에서만 시간, 페이지 경로, 응답 상태, IP 주소, User-Agent를 비교하세요. 수동 대조는 대규모 트래픽에서는 불편합니다. 장애를 찾는 데는 도움이 되지만 지속적인 모니터링을 대체하지는 못합니다.

일부 페이지에 카운터 코드가 없음

카운터가 메인 페이지에는 있지만 랜딩 페이지, 블로그, 카탈로그, 개인 계정, 모바일 템플릿 또는 서브도메인에는 없을 수 있습니다. 이런 오류는 사이트 이전, 별도 프로모션 페이지 생성 또는 CMS 테마 업데이트 후에 자주 발생합니다. 방문자가 사이트를 열어도 특정 URL에서는 Метрика가 실행할 것이 없습니다.

브라우저 코드 보기를 통해 페이지 소스 코드를 열고 mc.yandex.ru 조각이나 카운터 번호를 찾으세요. 메인 페이지만이 아니라 광고와 소셜 미디어에서 실제로 링크가 연결되는 주소를 확인하세요. 이러한 점검의 단점은 드문 페이지와 시나리오, 예를 들어 결제 후 화면이나 모바일 버전의 양식을 수동으로 놓치기 쉽다는 것입니다.

사이트에 다른 카운터 번호가 설치됨

코드가 정상적으로 작동하지만 이전, 테스트 또는 다른 사람의 카운터로 데이터를 보낼 수 있습니다. 이는 템플릿 복사, 대행사 변경, 새 도메인으로 이전 또는 여러 버전의 사이트가 동시에 운영될 때 발생합니다. 브라우저에서는 요청이 보이지만 채널 또는 사이트 소유자는 다른 카운터의 보고서를 보고 있는 것입니다.

페이지 코드에서 식별자를 찾아 Метрика 계정의 번호와 비교하세요. 브라우저 콘솔에서 다음 요청을 실행할 수 있습니다: document.documentElement.innerHTML.includes("mc.yandex.ru"). 이는 HTML에 Метрика 주소가 포함되어 있는지 보여주지만 스크립트가 실행되었는지는 확인하지 못합니다. 이를 위해서는 네트워크 요청 점검이 필요합니다.

브라우저에서 Метрика 로드 확인 방법

차단 프로그램 없이 브라우저에서 페이지를 열고 F12를 누른 뒤 Network 탭으로 이동하여 페이지를 새로고침하세요. 필터 줄에 mc.yandex.ru를 입력하세요. 정상 작동 시 스크립트 로드 주소로의 요청과 데이터 수집 요청이 나타나야 하며, 보통 metrika/tag.js 경로 또는 카운터 번호가 포함된 watch가 있습니다.

그런 다음 Console 탭을 열고 오류를 확인하세요. 문제의 유용한 징후: «Refused to load the script», «blocked by client», «Content Security Policy» 메시지 또는 카운터 실행 전에 발생하는 JavaScript 오류입니다. 한 브라우저에서의 점검은 단점이 있습니다. 특정 사용자의 확장 프로그램, 브라우저 버전 또는 네트워크 설정이 다른 결과를 줄 수 있습니다.

광고 차단기가 일부 방문을 숨김

광고 차단 확장 프로그램, 프라이빗 DNS 서비스, 브라우저 내장 보호 기능, 백신이 분석 요청을 중단시킬 수 있습니다. Network에서는 흔히 blocked by client로 표시됩니다. 페이지는 정상적으로 열리고 서버는 요청을 기록하지만 Метрика는 방문 정보를 받지 못합니다.

확장 프로그램 없는 일반 브라우저 창과 차단 프로그램이 있는 프로필에서 페이지를 비교하세요. 이러한 테스트는 차단 사실 자체는 보여주지만 손실된 방문 비율을 정확히 평가할 수는 없습니다. 사용자층의 보호 설정이 다르기 때문입니다. 분석 요청을 위장하려는 시도는 유지보수를 복잡하게 하고 사이트 보안 정책과 충돌할 수 있습니다.

Content Security Policy가 Метрика 요청을 차단함

Content Security Policy 헤더는 페이지가 스크립트, 이미지를 로드하고 네트워크 요청을 실행할 수 있는 소스를 제한합니다. CDN, 프록시 연결 또는 보안 강화 후 사이트가 Метрика로의 요청을 금지하기 시작할 수 있습니다. 브라우저 콘솔에 차단된 mc.yandex.ru 주소를 명시한 CSP 위반 메시지가 나타납니다.

규칙은 CSP를 완전히 비활성화하는 것이 아니라 정밀하게 보완해야 합니다. 한 줄로 된 지시문 예시: script-src 'self' https://mc.yandex.ru; connect-src 'self' https://mc.yandex.ru; img-src 'self' data: https://mc.yandex.ru;

이 줄을 기존 헤더에 무분별하게 교체해서는 안 됩니다. 이미 필요한 사이트 소스와 병합되어야 합니다. 카운터 코드가 HTML에 직접 삽입된 경우 nonce 또는 hash를 통한 인라인 스크립트에도 별도 허가가 필요할 수 있습니다. unsafe-inline 추가가 더 간단하지만, 단점은 외부 JavaScript 삽입에 대한 보호가 약해진다는 것입니다.

쿠키 동의가 카운터 실행을 허용하지 않음

동의 배너가 있는 사이트에서는 Метрика가 버튼 클릭 후에만 실행되는 경우가 있습니다. 배너 로직의 오류로 인해 동의 후에도 카운터가 꺼진 채로 남거나, 첫 페이지에서만 켜지거나, 사용자의 선택이 저장되지 않을 수 있습니다. 이로 인해 일부 방문, 특히 랜딩 페이지에서의 짧은 방문이 누락됩니다.

첫 방문, 동의, 거부, 재방문, 모바일 브라우저, 시크릿 모드 시나리오를 확인하세요. 사용자 선택 전에 분석을 실행하면 데이터 양이 늘어날 수 있지만, 이러한 방식에는 법적·평판적 단점이 있습니다. 데이터 처리 절차는 프로젝트에 적용되는 요구사항을 준수해야 합니다.

카운터 필터가 필요한 방문을 제외함

Метрика 설정에서 IP 주소, 도메인, URL, 파라미터 또는 기술적 트래픽별 필터가 작동할 수 있습니다. 보통 팀 방문과 테스트 유입을 제거하기 위해 추가합니다. 사무실, VPN, 기업 네트워크 또는 URL 구조가 변경된 후에는 이러한 필터가 더 이상 내부 방문만 제외하지 않을 수 있습니다.

활성 필터를 검토하고 각 규칙의 목적을 확인하세요. 진단을 위해 하나의 필터를 일시적으로 변경하고 테스트 유입을 반복할 수 있습니다. 필터를 비활성화하는 것의 단점은 직원, 개발자, 자동 테스트의 방문이 통계에 포함된다는 것이므로, 변경 사항은 별도로 기록하는 것이 좋습니다.

잘못된 기간, 보고서 또는 시간대가 열려 있음

때로는 데이터가 이미 있지만 계정에서 다른 카운터, 너무 좁은 기간, 날짜 비교 모드 또는 부적합한 시간대가 선택되어 있을 수 있습니다. 방문 수가 적을 때 몇 시간의 차이는 특정 날짜의 전체 그림을 완전히 바꿀 수 있습니다. 유입 후 몇 분만으로 카운터 작동을 평가해서는 안 됩니다.

기간 비교를 해제하고 범위를 더 넓게 열고 테스트 방문 날짜를 확인하세요. 그런 다음 페이지 보고서로 이동하여 랜딩 페이지의 정확한 경로를 찾으세요. 넓은 기간은 데이터를 찾기에 편리하지만, 단점은 전체 그래프에서 사이트 업데이트 후 카운터가 작동을 멈춘 시점을 알아채기 어렵다는 것입니다.

리디렉트와 도메인이 방문자의 경로를 바꿈

유입은 링크 단축기, 트래커, 사이트의 HTTP 버전, www 도메인, 모바일 서브도메인을 거쳐 최종 랜딩 페이지에 도달할 수 있습니다. 리디렉트가 오류로 설정되었거나, 페이지 응답이 느리거나, 방문자가 다른 도메인으로 리디렉트되면 해당 사이트의 카운터가 로드되지 않을 수 있습니다. 이는 특히 방송 설명과 광고 캠페인의 링크에서 중요합니다.

curl -I -L "https://example.com/promo" 명령으로 체인을 확인하고 리디렉트 주소가 포함된 상태를 확인하세요. 이 명령은 서버 리디렉트를 보여주지만 브라우저 테스트를 대체하지는 못합니다. JavaScript 리디렉트와 확장 프로그램 차단은 curl이 볼 수 없습니다. 단축 링크는 게시물에서 편리하지만, 추가 리디렉트가 진단을 복잡하게 만듭니다.

SPA가 내부 이동 시 조회를 전송하지 않음

단일 페이지 사이트에서는 섹션 간 이동이 전체 새로고침 없이 이루어지는 경우가 많습니다. 사용자가 요금제, 상품 카드, 양식 또는 감사 페이지를 열어도 Метрика는 첫 화면만 기록합니다. 방문은 보고서에 있을 수 있지만 진입 페이지, 조회 깊이, 전환은 불완전해 보입니다.

애플리케이션 내에서 경로 변경 후 Network에 Метрика로의 새 요청이 나타나는지 확인하세요. 브라우저 버튼으로의 이동, 모달 창, 언어 변경, 동적 URL을 테스트하세요. 라우터를 통한 자동 조회 전송은 편리하지만, 단점은 로직 오류 시 조회 중복과 부풀려진 방문 깊이를 쉽게 얻을 수 있다는 것입니다.

방문이 있어도 목표가 작동하지 않음

목표에 대한 빈 보고서는 사이트에 트래픽이 없다는 것을 의미하지 않습니다. 방문은 정상적으로 수집되지만 양식 제출, 버튼 클릭, 구매 또는 감사 페이지 이동이 기록되지 않을 수 있습니다. 원인으로는 변경된 CSS 선택자, 카운터 초기화 전 이벤트, 결과 처리가 없는 AJAX 양식 또는 페이지의 다른 Метрика 번호가 있습니다.

수동으로 작업을 수행하고 동시에 Network를 확인하세요. 작업 후 이벤트 전송과 관련된 요청이 나타나야 합니다. 버튼 클릭 목표는 빠르게 설정되지만, 단점은 양식의 성공적 제출이 아니라 클릭만 기록한다는 것입니다. 신청서의 경우 작성 시작, 오류, 확인된 결과를 별도로 추적하는 것이 더 유용합니다.

5분 진단 체크리스트

1. 트래픽이 유입되어야 하는 링크를 차단 프로그램 없는 일반 브라우저에서 여세요.
2. DevTools에서 Network를 열고 페이지를 새로고침한 뒤 mc.yandex.ru로 요청을 필터링하세요.
3. Console 탭에서 JavaScript 오류, CSP, blocked by client 메시지를 확인하세요.
4. 페이지 코드의 카운터 번호를 Метрика 계정의 보고서 번호와 대조하세요.
5. access.log에서 테스트 시간 동안 필요한 URL로의 요청을 확인하세요. 예: grep "GET /promo" /var/log/nginx/access.log.
6. 하나의 링크와 하나의 기간을 기준으로 서버 로그를 광고 관리 도구의 클릭과 비교하세요.
7. 필터, 선택된 날짜, 시간대, 서브도메인, 쿠키 동의 시나리오를 검토하세요.
8. SPA의 경우 내부 이동을 수행하고 경로 변경 후 새 요청이 전송되는지 확인하세요.