두 데이터는 각각 무엇을 기록하나

GA4는 브라우저에서 실행된 태그가 보내는 이벤트를 기록합니다. 사람이 무엇을 봤고 어디를 눌렀는지에 가깝습니다. 서버로그는 서버에 도착한 요청과 서버가 돌려준 응답을 기록합니다. 어떤 URL이 몇 번 호출됐고 응답 코드가 무엇이며 처리에 몇 밀리초가 걸렸는지가 남습니다.

이 차이 때문에 두 데이터의 숫자는 원래 다릅니다. 광고 차단 확장이나 스크립트 오류로 태그가 실행되지 않으면 GA4에는 안 잡히지만 서버로그에는 남습니다. 반대로 캐시에서 바로 그려진 페이지는 서버로그에 요청이 안 남을 수 있습니다. 어느 쪽이 맞느냐를 다투는 대신, 각자 잘 잡는 것을 맡기는 편이 실무적으로 유용합니다.

진단은 어떤 순서로 하나

큰 것부터 작은 것으로 갑니다. 첫 단계는 GA4 탐색 분석의 퍼널 탐색입니다. 상세페이지, 장바구니, 주문서, 결제완료 순으로 단계를 지정하면 각 단계에서 이탈한 사용자 비율이 시각화되므로 가장 크게 새는 구간이 바로 보입니다.

두 번째 단계는 좁히기입니다. 상세페이지 구간이 문제라면 스크롤 구간별 도달률로 어느 지점에서 멈추는지 봅니다. 세 번째 단계는 경로 탐색입니다. 특정 이벤트 전후에 사용자가 실제로 거친 흐름을 트리로 보여 주므로, 그 구간에서 나간 사람들이 다른 상품으로 갔는지 그대로 세션을 끝냈는지 확인할 수 있습니다.

GA4 숫자를 믿기 전에 무엇을 점검하나

네 가지를 먼저 봅니다. 첫째, 결제 도메인 참조 제외입니다. 결제 완료 후 PG사 도메인을 거쳐 돌아올 때 GA4가 이를 새 유입으로 잘못 잡으면 퍼널이 중간에서 끊겨 보이고 전환이 엉뚱한 매체에 붙습니다. 태그 설정 구성의 원치 않는 추천 나열에 결제 도메인을 등록해 두어야 합니다.

둘째, 샘플링과 임계값 처리입니다. GA4는 보고서와 탐색 분석 제목 옆 아이콘으로 데이터 품질을 표시하는데, 녹색 방패는 샘플링 없음, 노란색과 빨간색은 샘플링 적용, 주황색 방패는 개인정보 보호를 위한 임계값 처리 적용을 뜻합니다. 셋째, 데이터 보관 기간입니다. 이벤트 데이터 보관 기간은 2개월 또는 14개월 중 하나만 선택 가능하며 탐색 분석에 영향을 줍니다. 넷째, 처리 지연입니다. 실시간 보고서는 최근 약 30분 내 활동을 보여 주지만 표준 보고서는 당일 데이터가 완전히 반영되기까지 24에서 48시간이 걸릴 수 있습니다.

서버로그에서 무엇을 뽑아야 하나

세 가지를 뽑으면 대부분의 질문에 답할 수 있습니다. 첫째, URL별 응답 코드 분포입니다. 상세페이지 경로에서 4xx나 5xx가 일정 비율로 나오고 있다면 그 페이지의 이탈은 UX 문제가 아니라 장애입니다. 품절 상품 페이지가 오류로 응답하고 있는 경우가 흔히 발견됩니다.

둘째, 응답 시간 분포입니다. 평균이 아니라 상위 구간을 봐야 합니다. 평균은 괜찮은데 상위 10퍼센트가 몇 초씩 걸린다면 일부 사용자가 매우 느린 경험을 하고 있다는 뜻입니다. 셋째, 정적 자원의 용량과 호출 수입니다. 상세페이지 하나를 여는 데 이미지가 몇 개 호출되고 총 몇 메가바이트가 오가는지 보면 성능 개선의 대상이 바로 나옵니다.

두 데이터를 어떻게 대조하나

같은 기간, 같은 URL을 기준으로 GA4 페이지뷰와 서버로그의 해당 경로 요청 수를 나란히 놓습니다. 차이가 일정 비율로 유지된다면 정상 범위로 보고, 특정 페이지에서만 차이가 크게 벌어진다면 그 페이지에 태그가 누락됐거나 스크립트 오류로 태그 실행이 중단되고 있을 가능성이 큽니다.

결제 구간에서는 대조 대상이 하나 더 있습니다. PG사 관리자에서 뽑은 결제 승인 시도와 승인 성공 건수입니다. GA4의 결제 완료 이벤트 수, 자사몰 주문 테이블의 주문 건수, PG사 승인 건수 셋을 매주 맞춰 보면 어느 지점에서 숫자가 새는지 드러납니다. 세 값이 벌어지는 지점이 바로 다음 개선 대상입니다.

진단 결과를 어떻게 개선으로 연결하나

찾아낸 후보가 여러 개라면 순서를 정합니다. 기준은 두 가지 곱입니다. 트래픽이 큰 페이지와 유실이 큰 구간의 교집합부터 손댑니다. 트래픽이 적은 페이지를 완벽하게 고쳐도 전체 지표는 거의 움직이지 않습니다.

개선 후에는 한 번에 한 항목만 바꾸고 같은 요일끼리 비교합니다. 그리고 진단을 일회성 작업으로 두지 않는 편이 좋습니다. 상품이 추가되고 배포가 반복되면 태그는 언제든 다시 깨집니다. 주 단위로 퍼널 단계별 유실률과 결제 건수 대조를 확인하는 루틴을 만들어 두면, 사고가 나도 며칠 안에 잡힙니다.