GA4 클릭 이벤트 0건, 계측 고장이 아니라 링크 위치였다

증상: 판매 서비스로 가는 클릭이 28일 동안 0건

GA4 클릭 이벤트가 0건으로 나왔을 때 원인은 계측이 아니라 링크가 놓인 자리였고, 이걸 가르는 데 라이브 페이지 클릭 한 번이면 충분했습니다. 2026년 8월 25일, 리포트 글에서 판매 서비스 페이지로 넘어가는 클릭 이벤트(`content_to_offer_click`)를 28일 범위로 조회하니 0건이었습니다.

다른 숫자는 글이 읽히고 있다고 말했습니다. 같은 28일 동안 글 끝까지 스크롤한 기록(`scroll_100`)은 96건이었고, 페이지 안의 일반 클릭은 5건이었습니다. 끝까지 내려간 사람이 96번 있었는데 판매 서비스로 넘어간 사람은 한 명도 없었다는 뜻이고, 방문 한 번에 본 페이지 수는 1.1이었습니다. 들어온 사람 대부분이 글 하나만 읽고 나갔습니다.

이 조합은 해석이 두 갈래로 갈립니다. 사람들이 정말 안 눌렀을 수도 있고, 눌렀는데 기록이 GA4까지 가지 않았을 수도 있습니다. 대시보드의 0은 두 경우에 똑같이 0으로 보입니다.

처음에는 왜 계측 고장을 의심했나?

처음 세운 가설은 계측 고장이었습니다. 근거는 감이 아니라 전례였습니다. 바로 엿새 전인 8월 19일, 같은 링크의 클릭이 GA4에서 조회 자체가 안 되던 문제를 고친 적이 있었습니다.

당시 링크는 클릭할 때 `data-ga-category`·`data-ga-label` 속성을 함께 보냈는데, 이 둘은 GA4에 커스텀 디멘션으로 등록한 적이 없었습니다. 이벤트 이름도 범용 `click`이라, 28일 동안 쌓인 95건을 “리포트에서 판매 서비스로 간 클릭”만 골라 볼 방법이 없었습니다. 조회가 안 되니 0건과 95건 미분류가 화면에서 구분되지 않았고, 그 사실을 아무도 몰랐습니다.

그때는 커스텀 디멘션을 새로 등록하는 대신 이벤트 이름을 `content_to_offer_click`으로 바꿨습니다. GA4의 기본 이벤트 이름 필터는 등록 없이 바로 쓸 수 있고, 등록은 반영까지 하루 이틀이 걸리는 데다 과거 95건을 소급해 분류해 주지도 않기 때문입니다. 이렇게 한 번 “0처럼 보였지만 실은 기록 문제”였던 일을 겪은 직후라, 다시 0을 보자 같은 고장을 먼저 떠올렸습니다.

다른 작업에서도 비슷한 일이 있었습니다. 실측 0을 “아직 집행하지 않은 상태”로 잘못 읽었던 판정이 있었고, 그 뒤로 0이 나오면 먼저 계기가 실제로 발화하는지부터 가르기로 정했습니다.

확인 수단: 라이브 페이지에서 직접 눌러 전송 요청을 봤다

대시보드를 더 들여다보는 대신 계기 자체를 확인했습니다. 배포된 실제 리포트 페이지를 브라우저로 열고, 개발자 도구의 네트워크 탭을 켠 채 판매 서비스 링크를 직접 눌렀습니다. 확인할 것은 세 가지였습니다.

• 클릭 순간 GA4 수집 주소(`analytics.google.com/g/collect`)로 요청이 나가는가
• 요청 안의 이벤트 이름이 조회에 쓰는 이름(`content_to_offer_click`)과 정확히 같은가
• 서버가 그 요청을 받았는가 (응답 코드)

스테이징이나 로컬이 아니라 라이브 페이지에서 눌러야 했던 이유가 있습니다. 계측 문제는 배포 설정, 광고 차단, 링크를 감싸는 컴포넌트 차이처럼 실제 환경에서만 드러나는 경우가 많습니다. 로컬에서 잘 나가는 요청은 라이브에서 나간다는 증거가 되지 못합니다.

알리바이: 응답 204, 계측은 끝까지 살아 있었다

요청은 정상으로 나갔습니다. 이벤트 이름은 `en=content_to_offer_click`, 라벨은 어느 글 묶음에서 어느 서비스로 갔는지까지 담겨 있었고(`ep.event_label=nomu→AI자동화:primary`), 수집 서버는 204로 응답했습니다. 클릭부터 GA4 수신까지 끊긴 곳이 없었습니다.

그래서 계측 고장 가설은 여기서 버렸습니다. 0은 “기록이 안 남았다”가 아니라 “아무도 안 눌렀다”였습니다.

한 가지 한계는 적어 둡니다. 이벤트 이름을 바꾼 날이 8월 19일이라, 28일 범위 가운데 이 이름으로 셀 수 있던 기간은 그 뒤 며칠뿐이었습니다. 그래서 28일 0건은 정확히는 “새 이름으로 센 며칠 동안 0건”이고, 그 앞 기간의 클릭은 옛 이름 아래 미분류로 남아 있습니다. 그래도 계기가 살아 있다는 판정은 이 한계와 상관없이 성립합니다.

진짜 원인: 링크는 왜 아무도 누르지 않았나?

계측이 멀쩡하다면 남은 질문은 링크가 보였느냐였습니다. 라이브 페이지에서 링크 위치를 재 보니 답이 바로 나왔습니다. 판매 서비스로 가는 링크는 글 하나에 2개뿐이었고, 둘 다 같은 카드 안에 있었습니다.

그 카드는 문서 높이 3,936px 가운데 2,176px 지점, 비율로 55.3%에 있었습니다. 화면 높이 661px 기준으로는 세 화면을 내려가야 처음 보이는 자리입니다. 끝까지 스크롤한 96건이 있었으니 카드를 지나간 사람은 있었겠지만, 정보를 찾으러 온 사람이 글 중간을 넘어 카드까지 내려와 눌러야 할 이유는 없었습니다.

2주 뒤인 9월 7일 90일 범위로 층별로 다시 재 보니 그림이 더 분명해졌습니다. 노출, 유입, 읽힘, 체류는 모두 살아 있었고, 끊긴 곳은 “읽은 다음 갈 곳” 한 층뿐이었습니다.

라이브에서 확인한 링크 문구도 독자와 어긋나 있었습니다. 권고사직 위로금 글 끝에 “이 계산을 매달 손으로 다시 하고 있다면, 어떤 업무가 자동화되는지부터 가려 드립니다”라는 문구가 붙어 있었습니다. 위로금을 협상 중인 사람에게 매달 반복하는 업무를 묻는 셈입니다.

고친 방법: 문구가 아니라 위치를 옮겼다

대안은 세 가지였습니다. 먼저 링크 문구를 다시 쓰는 안은 기각했습니다. 안 보이는 문구를 고쳐도 여전히 안 보이기 때문입니다. 반응 좋은 상위 10편에만 손으로 링크를 붙이는 안도 기각했습니다. 글이 137편이었고 매주 늘어나서, 글별 작업은 끝나지 않습니다.

채택한 안은 컴포넌트 하나로 모든 글에 본문 중간 링크 블록을 넣는 방식입니다. 블록은 두 번째 섹션 바로 뒤에 들어가고, 문구는 판매 서비스별로 4종으로 고정해 글마다 달라지지 않게 했습니다. 배경과 테두리는 본문의 기존 강조 블록과 같은 색을 써서 광고처럼 튀지 않게 맞췄습니다.

그 결과 첫 판매 서비스 링크의 위치가 문서 높이 56.7%에서 28.2%로 올라왔습니다. 세 화면 아래에 있던 링크가 한 화면 남짓 내려가면 보이는 자리로 옮겨 왔습니다.

위치만큼 중요하게 챙긴 것은 링크 자리별 구분입니다. 링크마다 `inline`(본문 중간), `primary`(카드 첫 링크), `secondary`(카드 둘째 링크)라는 자리 이름을 붙여, GA4에서 어느 자리가 눌렸는지 따로 볼 수 있게 했습니다. 이게 없으면 링크를 더 놓아도 효과가 위치 덕인지 판정할 수 없습니다.

9월 7일에는 세무·노무 글의 링크 행선지도 바꿨습니다. 두 묶음은 AI 업무 자동화 페이지로 보내고 있었는데, 그 무렵 세무·노무 서비스가 로그인 없이 쓰는 무료 도구로 바뀌어 있었습니다. 상품이 없던 게 아니라 글에서 그쪽으로 가는 길이 한 줄도 없었던 겁니다.

반전: 계측 고장 가설은 다른 페이지에서 맞았다

리포트 글에서 버린 가설이 9월 7일 다른 표면에서 맞았습니다. 세무·노무 링크를 고친 직후 “다른 글 묶음은 괜찮은가”를 묻는 질문이 나왔고, 전 콘텐츠 표면을 훑자 가이드 페이지(`/guides`)가 더 나쁜 상태였습니다. 판매 서비스로 가는 링크가 4개 있었는데 계측 속성이 하나도 달려 있지 않았습니다.

사이트의 클릭 추적기는 우리 서브도메인으로 나가는 링크를 외부 링크로 치지 않습니다. 그래서 명시 속성이 없는 링크는 눌려도 어디에도 기록이 남지 않습니다. 가이드 페이지는 90일 동안 37세션, 평균 21.7초 체류가 있었지만, 앞서 인용한 판매 서비스 클릭 6건에 이 페이지는 애초에 들어갈 수 없었습니다. 그 0은 0이 아니라 미측정이었습니다.

9월 10일에는 기술블로그에서 같은 일이 한 번 더 나왔습니다. 계측 자체는 정상이었습니다(라이브 `page_view` 응답 204, 사이트 8곳 점검 결과 누락 0). 그런데 기술블로그 41편의 상담 링크만 계측 속성이 없었습니다. 같은 유형의 누락이 사흘 사이 두 번 나온 셈입니다.

정리하면 처음 가설은 리포트 글에서는 틀렸고, 가이드와 기술블로그에서는 맞았습니다. 한 표면에서 확인한 결론을 다른 표면으로 넓히지 않고 표면마다 계기를 따로 확인해야 했던 이유가 여기 있습니다.

같은 실수를 막는 장치는 어떻게 짰나?

9월 7일 가이드 페이지를 고치면서 테스트 하나를 함께 만들었습니다. 콘텐츠 표면마다 계측 속성이 있는지, 서브도메인으로 나가는 링크가 전부 속성을 달고 있는지 검사하는 테스트입니다. 다만 검사할 표면을 리포트·인사이트·가이드 3개로 손으로 적은 목록이었고, 주석에 “새 표면을 만들 때 이 목록에 추가한다. 잊으면 그 표면은 조용히 계측 밖에 놓인다”고 적어 두었습니다.

사흘 뒤 기술블로그가 정확히 그 경고대로 빠졌습니다. 목록에 없는 표면은 검사하지 않으니 테스트는 실패하지 않고 초록불로 통과합니다. 등록을 잊으면 실패가 아니라 통과가 나오는 검사는, 주석으로 아무리 경고해도 두 번째 누락을 막지 못했습니다.

그래서 검사 대상을 목록이 아니라 탐색으로 바꿨습니다. 앱 폴더에서 `src/app/**/[slug]/page.tsx` 형태의 페이지를 직접 찾아 전부 검사하고, 같은 주소로 가는 상담 링크(`/contact`)도 판매 서비스 링크로 치게 했습니다. 탐색 자체가 고장 나 아무것도 못 찾으면 다시 무증상 통과가 되므로, 찾은 표면 수의 하한도 함께 검사합니다.

검사가 실제로 잡는지는 거꾸로 확인했습니다. 수리 전 파일로 되돌리면 해당 표면을 지목하며 실패했고, 되돌린 걸 다시 고치면 통과했습니다. 9월 7일 판별 확인에서는 가이드 표면만 정확히 2건 실패하고 나머지는 통과했고, 그날 타입 검사 오류 0건과 테스트 140개 통과를 확인했습니다. 라이브에서도 기술블로그 상담 링크를 눌러 이벤트 요청과 응답 204를 다시 확인했습니다.

GA4 클릭 이벤트가 0건일 때 무엇부터 확인하나?

이번 일로 정한 확인 순서는 네 단계입니다. 앞 단계가 통과해야 다음 단계의 숫자를 믿을 수 있습니다.

• 계기 발화: 라이브 페이지에서 직접 눌러 GA4 수집 요청이 나가고 응답 204가 오는지 본다
• 조회 가능성: 이벤트 이름이 등록 없이 필터되는 전용 이름인지 본다. 범용 `click`에 속성만 붙여 보내면 등록 전까지 골라낼 수 없다
• 표면 전수: 한 페이지에서 확인한 결과를 다른 글 묶음으로 넓히지 않는다. 계측 속성 누락은 표면 단위로 생긴다
• 노출 면적: 계측이 정상이면 링크가 문서 몇 % 지점에 있는지, 화면 몇 장 아래인지 잰다

다리가 놓였다고 끝은 아닙니다. 9월 10일 기준 기술블로그 개별 글의 30일 페이지뷰 0은 계측 결함이 아니라 유입 부재였습니다. 구글 서치 콘솔 60일 동안 41편 중 노출이 잡힌 글은 5편, 노출 합 16회, 클릭 0회였습니다. 0을 만났을 때 계측, 위치, 유입 가운데 어느 층의 0인지부터 가르는 습관이 이번 디버깅의 가장 큰 수확이었습니다.

같은 원문에서 노출 쪽 원인을 따로 다룬 글은 콘텐츠 발행량을 늘렸더니 구글 노출이 줄었다에 있습니다. 사이트 계측이나 콘텐츠에서 문의로 이어지는 길을 점검하고 싶다면 상담으로 남겨 주세요.