분석 스크립트 중복 실행 확인 흐름

방문자 수 오류 | 분석 스크립트 중복 실행

웹개발·SEO 댓글쓰기

사이트 방문자 수가 평소보다 이상하게 높게 잡혔습니다. 처음에는 콘텐츠가 잘 노출된 줄 알았습니다. 그런데 페이지뷰는 늘었는데 체류시간은 짧고, 이탈률은 비정상적으로 낮게 보였습니다.

나중에 확인해보니 실제 방문자가 늘어난 것이 아니었습니다. 사이트 공통 헤더에 분석 스크립트가 두 번 들어가 있었고, 한 번의 방문이 두 번 수집되고 있었습니다.

이 글은 분석 도구 설정법을 설명하는 글이 아닙니다. 오래된 사이트 헤더를 정리하다가 구버전 분석 코드와 새 태그가 동시에 실행되고 있던 문제를 찾았고, 어떤 순서로 확인하고 안전하게 제거했는지 정리한 글입니다.

분석 스크립트 중복 실행 확인 흐름

이상하게 좋아 보였던 방문자 지표

처음 이상하다고 느낀 것은 방문자 수가 아니라 지표의 조합이었습니다.

  • 페이지뷰 수가 실제 체감보다 많음
  • 이탈률이 비정상적으로 낮음
  • 평균 세션 시간이 말도 안 되게 짧음
  • 실시간 방문자 수가 새로고침할 때마다 과하게 튐

방문자가 늘었다면 좋은 신호일 수 있습니다. 하지만 페이지뷰만 늘고 체류시간이나 이벤트 흐름이 어색하다면 먼저 수집 방식부터 의심해야 합니다.

한 번의 페이지 로드에서 분석 요청이 두 번 나가면 방문 기록도 두 번 쌓일 수 있습니다. 그러면 실제보다 페이지뷰가 많아지고, 사용자가 정상적으로 움직인 것처럼 보이지 않는 이상한 데이터가 만들어집니다.

오래된 헤더에 남아 있던 구버전 코드

공통 헤더 파일을 열어보니 원인은 바로 보였습니다.

<head>
  <!-- 몇 년 전 넣어둔 구버전 분석 코드 -->
  <script>
    var _trackAccount = "UA-XXXXXXX-1";
    var _trackDomain  = "example.com";
  </script>
  <script src="/js/legacy-tracker.js"></script>

  <!-- 최근에 새로 붙인 분석 태그 -->
  <script async src="https://www.example-analytics.com/tag.js?id=G-XXXXXXX"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){ dataLayer.push(arguments); }
    gtag('js', new Date());
    gtag('config', 'G-XXXXXXX');
  </script>
</head>

새 태그를 붙이면서 예전 코드를 지우지 않은 상태였습니다. 예전 코드가 완전히 죽어 있으면 괜찮았겠지만, 실제로는 페이지가 열릴 때마다 같이 실행되고 있었습니다.

오래된 사이트에서는 이런 일이 자주 생깁니다. 담당자가 바뀌거나, 분석 도구를 교체하거나, 급하게 태그를 추가하면서 기존 코드를 남겨두는 경우가 많기 때문입니다.

네트워크 탭으로 중복 요청 확인

가장 먼저 확인한 곳은 브라우저 개발자 도구의 네트워크 탭이었습니다.

  1. 개발자 도구 열기
  2. Network 탭 선택
  3. analytics, collect, gtag, tracker 같은 단어로 필터
  4. 페이지 새로고침
  5. 페이지뷰 요청이 몇 번 나가는지 확인

정상이라면 기본 페이지뷰 요청은 보통 한 번만 나가야 합니다. 그런데 같은 페이지를 한 번 열었을 뿐인데 분석 요청이 두 번 보였습니다.

GET /collect?...page=/sample
GET /collect?...page=/sample

이렇게 같은 성격의 요청이 반복되면 중복 설치 가능성이 높습니다. 특히 하나는 구버전 스크립트에서, 다른 하나는 새 태그에서 나가고 있다면 거의 확정입니다.

페이지 소스에서 스크립트 개수 확인

브라우저에서만 보면 헷갈릴 수 있어서 소스에서도 다시 확인했습니다.

curl -s https://example.com | grep -c "analytics"

또는 태그 ID와 구버전 파일명을 같이 검색했습니다.

curl -s https://example.com | grep -E "legacy-tracker|G-XXXXXXX|UA-XXXXXXX"

사이트 파일 전체에서도 검색했습니다.

grep -rn "legacy-tracker\|_trackAccount\|G-XXXXXXX" ./ --include="*.php" --include="*.html"

이 과정을 거친 이유는 공통 헤더 하나만 보고 지우면 안 되기 때문입니다. 오래된 사이트는 페이지마다 다른 헤더를 쓰거나, 특정 게시판만 별도 스킨을 쓰는 경우가 있습니다. 한 곳에서 지워도 다른 파일에 같은 코드가 남아 있을 수 있습니다.

구버전 코드 삭제 전 확인한 항목

구버전 분석 코드를 바로 지우지는 않았습니다. 단순 페이지뷰 코드처럼 보여도 다른 기능이 묶여 있을 수 있기 때문입니다.

확인한 것은 세 가지였습니다.

  • 문의 완료, 회원가입 완료 같은 전환 추적이 구버전 코드에 묶여 있는지
  • 쿠키 동의나 추적 거부 같은 옵트아웃 코드가 연결되어 있는지
  • 다른 자바스크립트가 _trackAccount 같은 전역 변수를 참조하고 있는지

특히 전역 변수는 조심해야 합니다. 분석 코드라고 생각하고 지웠는데 다른 스크립트가 해당 변수를 읽고 있다면 콘솔 오류가 생길 수 있습니다.

그래서 먼저 전체 검색을 돌렸습니다.

grep -rn "_trackAccount\|legacy-tracker" ./ --include="*.php" --include="*.js" --include="*.html"

검색 결과에서 다른 의존 코드가 없다는 것을 확인한 뒤 구버전 스크립트를 제거했습니다.

정리 후 남긴 분석 태그

최종적으로는 최신 분석 태그 하나만 남겼습니다.

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>페이지 제목</title>
  <link rel="canonical" href="https://example.com/sample">
  <meta name="description" content="페이지 설명">

  <!-- CSS -->
  <link rel="stylesheet" href="/css/style.css">

  <!-- 분석 태그는 하나만 유지 -->
  <script async src="https://www.example-analytics.com/tag.js?id=G-XXXXXXX"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){ dataLayer.push(arguments); }
    gtag('js', new Date());
    gtag('config', 'G-XXXXXXX');
  </script>
</head>

분석 태그는 하나만 남기고, title, canonical, description 같은 기본 SEO 태그는 위쪽에 두었습니다. 분석 스크립트에 async가 붙어 있더라도 굳이 head 맨 위에 둘 필요는 없었습니다.

함께 정리한 head 태그

분석 스크립트를 확인하다 보니 다른 찌꺼기도 같이 발견됐습니다.

  • 사용하지 않는 CSS 파일
  • 예전 검색엔진 소유확인 메타태그
  • 중복된 <meta name="keywords">
  • 모든 페이지에 똑같이 들어가던 description
  • 오래전에 쓰던 외부 위젯 스크립트

오래된 사이트의 <head>는 지층처럼 쌓입니다. 누군가 새 코드를 추가할 때는 많지만, 예전 코드를 지우는 일은 잘 하지 않기 때문입니다.

그래서 분석 코드만 보지 않고 head 전체를 한 번에 정리했습니다. 단, 한꺼번에 삭제하지는 않았습니다. 주석 처리 → 확인 → 삭제 순서로 진행했습니다.

수정 후 다시 확인한 요청 수

삭제 후에는 같은 방법으로 다시 확인했습니다.

curl -s https://example.com | grep -E "legacy-tracker|G-XXXXXXX|UA-XXXXXXX"

브라우저 네트워크 탭에서도 페이지뷰 요청이 한 번만 나가는지 확인했습니다.

GET /collect?...page=/sample

그리고 며칠 동안 분석 도구의 지표를 지켜봤습니다. 바로 모든 값이 정상처럼 보이지는 않았지만, 시간이 지나면서 페이지뷰와 체류시간이 현실적인 범위로 돌아왔습니다.

적용 후 달라진 지표

수정 후 확인한 변화는 아래와 같았습니다.

  • 페이지뷰 수집이 1회로 정상화
  • 이탈률과 평균 체류시간이 현실적인 값으로 복원
  • 구버전 스크립트 요청 제거로 불필요한 로딩 감소
  • head 영역이 짧아져 이후 수정이 쉬워짐
  • 분석 데이터를 다시 믿고 볼 수 있게 됨

이번 작업에서 중요한 것은 숫자가 낮아졌다는 점이 아닙니다. 실제보다 부풀려진 숫자를 걷어내고, 판단 가능한 데이터로 되돌렸다는 점입니다.

분석 스크립트 점검 체크리스트

숫자보다 먼저 수집 방식 확인

분석 데이터가 이상하게 보이면 먼저 지표 해석부터 하고 싶어집니다. 하지만 수집 코드가 잘못되어 있으면 해석은 의미가 없습니다.

제가 겪은 문제도 방문자가 갑자기 늘어난 것이 아니었습니다. 같은 방문이 두 번 기록되면서 숫자가 좋아 보였을 뿐입니다.

새 분석 도구를 붙일 때는 추가만 하면 끝이 아닙니다. 예전 코드를 지우는 것까지가 작업입니다. “일단 둘 다 두고 나중에 정리하자”는 생각이 방문자 수, 이탈률, 체류시간을 전부 흐리게 만들 수 있습니다.

조회수 1

댓글 남기기