GA4 데이터 수집이 안 될 때 확인 순서

GA4(Google Analytics 4) 태그를 붙였는데 보고서가 계속 0이면 태그가 빠진 것이 아니라 수집 요청이 안 나가고 있을 수 있습니다. 원인은 대개 셋 중 하나입니다. 화면의 측정ID가 다른 속성을 가리키거나, 지금 열어 본 주소가 태그를 일부러 빼는 환경이거나, 브라우저가 수집 요청 자체를 막은 경우입니다. 마지막 경우는 화면에도 콘솔에도 태그가 멀쩡히 보여서 눈으로 대조하면 그대로 통과합니다.

측정ID, 환경, 요청 수 순서로 좁힌다

1. 페이지 소스에서 G- 로 시작하는 측정ID를 찾아 지금 보고 있는 속성의 것과 맞춰 봅니다. 다르면 데이터는 남의 속성에 쌓이고 있습니다.
2. 소스에 gtag 스크립트가 아예 없다면 이 주소가 태그를 내보내지 않는 환경입니다. 로컬과 미리보기 주소에서만 0이라면 대개 여기입니다.
3. 브라우저에서 F12 를 눌러 여는 개발자도구의 네트워크 탭에서 g/collect 요청이 나가는지 셉니다. 네트워크 탭은 그 페이지가 밖으로 보낸 요청을 전부 줄줄이 보여주는 화면입니다. 태그는 보이는데 실시간 보고서가 0이면 이 단계에서 갈립니다.

1과 2에서 안 걸리면 3으로 갑니다. 여기부터가 화면으로는 안 보이는 구간입니다.

로컬과 미리보기에서 GA4가 안 잡히는 것은 정상이다

개발 중인 화면과 자동 테스트가 운영 보고서에 섞이면 방문 수와 문의 수가 같이 부풉니다. 그래서 운영 도메인이 아닌 곳에서는 태그를 아예 내보내지 않는 편이 낫고, 저희는 모든 사이트에 그 차단을 넣어 둡니다.

넣기 전에 어떻게 되는지는 저희 데이터에 남아 있습니다. 한 속성을 방문 주소별로 쪼개 보니 이렇게 나왔습니다.

운영 도메인

6,843건

localhost

914건

127.0.0.1

582건

임시 미리보기 주소

37건

전체 8,376건 중 1,533건, 18.3%가 사람이 방문한 기록이 아니었습니다. 그중에는 문의 완료로 집계된 이벤트도 섞여 있어서, 8월 1일부터 18일까지 실제 접수가 1건이던 구간이 보고서에서는 8건으로 보였습니다.

GA4에는 내부 트래픽 제외 기능이 있지만 기준이 IP입니다. 사무실 IP가 고정이면 맞고, 개발 중 로컬 화면이나 자동 테스트처럼 IP가 그때그때 달라지는 것은 이 방식으로 잘 안 걸립니다. 그래서 저희는 태그를 아예 안 내보내는 쪽을 먼저 두고, 이미 섞인 구간은 조회할 때 접속 주소로 가릅니다.

GA4는 이미 들어온 기록을 소급해서 지우지 못합니다. 오염된 구간은 조회할 때 운영 도메인만 남기고 빼는 수밖에 없습니다.

GA4 태그는 살아 있는데 수집 요청만 막히는 경우

저희 사이트의 GA4가 2026년 5월 22일부터 8월 28일까지 그 상태였습니다. 세 달 동안 한 건도 들어오지 않았고, 그동안 확인할 때마다 배관은 정상으로 보였습니다.

정상이던 것과 0이던 것을 나눠 보면 이렇습니다.

측정ID가 맞는지, 태그가 렌더되는지, 보안 정책에 GA 도메인이 적혀 있는지를 대조하면 셋 다 통과합니다. 실제로 그 셋을 확인하고 정상으로 판정한 뒤에야, 브라우저로 직접 열어 수집 요청을 세어 보고 0건인 것을 봤습니다.

원인은 사이트가 내려보내는 콘텐츠 보안 정책(CSP, Content-Security-Policy 헤더)이었습니다. 그중 connect-src 는 페이지가 어떤 주소로 연결해도 되는지를 브라우저에 미리 알려주는 목록입니다. 목록에 없는 주소로는 요청이 나가지 않고, 막혀도 화면에는 아무 일도 일어나지 않습니다.

*.google-analytics.com 은 analytics.google.com 을 포함하지 않는다

저희 connect-src 목록에는 https://*.google-analytics.com 이 적혀 있었습니다. 그런데 gtag가 실제로 보낸 곳은 셋이었습니다.

analytics.google.com/g/collect
www.google.com/g/collect
stats.g.doubleclick.net/g/collect

셋 다 목록에 없어서 전부 막혔습니다. 특히 첫 줄이 함정입니다. 이름이 비슷해 보이지만 analytics.google.com 은 google-analytics.com 의 하위 도메인이 아니라 google.com 쪽 주소이고, 앞에 붙은 별표는 하위 도메인 자리만 대신합니다. 사람 눈에는 같은 계열로 읽히는데 브라우저는 다른 도메인으로 봅니다.

지금 GA4 데이터가 들어온다고 안전한 것은 아니다

같은 시점에 저희가 운영하는 다른 사이트 세 곳은 데이터가 정상으로 들어오고 있었습니다. 목록이 더 넓어서가 아니라, 그 사이트들의 gtag가 region1.google-analytics.com 으로 보내고 있어서 와일드카드(앞에 붙은 별표)에 우연히 걸린 것뿐이었습니다.

어느 수집 주소를 쓸지는 구글 쪽에서 정합니다. 광고 계정 연동 여부와 지역에 따라 갈리고, 사이트 코드를 한 줄도 건드리지 않아도 바뀔 수 있습니다.

그래서 넷 중 하나만 열어 둔 사이트는 지금 멀쩡해도 어느 날 조용히 0이 됩니다.

네트워크 탭에서 g/collect 요청 수를 센다

브라우저에서 운영 주소를 열고 개발자도구를 켭니다.

1. 네트워크 탭에서 collect 로 필터를 겁니다. 페이지를 새로고침했을 때 요청이 한 건도 없으면 태그가 아니라 연결을 의심합니다.
2. 콘솔 탭을 봅니다. 보안 정책에 막힌 경우 Refused to connect to ... 로 시작하는 줄이 뜨고, 그 줄이 막힌 주소를 그대로 알려줍니다.

요청이 나가는데 보고서만 비어 있다면 그때는 측정ID와 속성을 다시 맞춰 봅니다. 두 증상은 원인이 다릅니다.

메타 픽셀도 같은 자리에서 같은 방식으로 셉니다. 확인할 화면이 셋으로 갈리는 이유는 메타 픽셀이 제대로 작동하는지 확인하는 세 가지 방법에 적어 뒀습니다.

보안 헤더를 지우지 말고 연결 허용 목록을 넓힌다

콘텐츠 보안 정책은 페이지에 코드가 주입됐을 때 피해를 줄이려고 두는 장치입니다. 계측 문제 하나 때문에 걷어내면 훨씬 큰 것을 내주게 됩니다.

넓히면 됩니다. 저희는 전 사이트 공통으로 연결 허용 목록을 이렇게 두고 있습니다.

connect-src 'self'
  https://*.google-analytics.com
  https://analytics.google.com https://*.analytics.google.com
  https://*.g.doubleclick.net
  https://www.google.com https://www.google.co.kr
  https://*.googletagmanager.com

지금 데이터가 들어오는 사이트까지 같이 넓힌 것은 수집 주소를 구글 쪽에서 정하기 때문입니다. 어느 날 바뀌어도 사이트에는 알림이 오지 않습니다.

직접 열어보기 어렵다면 이렇게 물어보세요

위 절차는 브라우저 개발자도구를 여는 일이라 직접 하기 번거로울 수 있습니다. 사이트를 만든 쪽에 두 가지를 물어보면 같은 답이 나옵니다.

• 「우리 사이트에서 GA4 수집 요청이 실제로 나가고 있는지, g/collect 요청 수로 확인해 주세요.」
• 「보안 정책의 connect-src 목록에 GA4 수집 주소가 다 들어 있는지 봐 주세요.」

둘 다 답이 「나갑니다」 또는 「안 나갑니다」로 떨어지는 질문입니다. 확인에 오래 걸리는 일도 아닙니다. 답이 「안 나갑니다」로 오면 이 글의 목록을 그대로 건네면 됩니다.