huny.log

GA4 컨설팅 체크리스트 30 — 설치·권한·이벤트·전환·attribution을 한 번에 점검하기

새 GA4 계정을 넘겨받았거나 컨설팅을 시작할 때, 무엇부터 확인해야 하나. 설치 정합성부터 권한, 이벤트 택소노미, 전환, attribution 설정까지 30개 점검 항목을 영역별로 정리했습니다. 나가서 바로 쓰는 체크리스트.

· 10분 읽기 · ga4analyticstracking-auditevent-taxonomyattribution

처음 보는 GA4 계정을 넘겨받는 순간은 늘 비슷합니다. 보고서에 숫자는 차 있는데, 그 숫자를 믿어도 되는지 알 수가 없습니다. 전환이 중복으로 잡혔는지, 내부 트래픽이 섞였는지, 이벤트 이름이 제멋대로인지를 화면만 봐서는 모릅니다. 컨설팅이든 인수인계든, GA4를 마주할 때 필요한 건 영감이 아니라 순서입니다. 무엇부터 열어보고 무엇을 확인할지가 정해져 있으면 반나절이면 계정의 건강 상태가 드러납니다.

이 글은 그 순서를 30개 항목으로 정리한 체크리스트입니다. 설치 정합성에서 시작해 권한, 데이터 위생, 이벤트 택소노미, 전환, attribution, 보고서 신뢰도까지 영역별로 묶었습니다. 위에서부터 내려가며 점검하면 됩니다.

먼저, 점검에는 순서가 있다

체크리스트를 영역별로 나눈 데는 이유가 있습니다. 아래 항목일수록 위 항목의 정합성에 의존하기 때문입니다. 설치가 잘못돼 있으면 전환 설정이 아무리 깔끔해도 숫자가 틀립니다. 그래서 전환부터 보지 말고 설치부터 봅니다.

여섯 개 영역을 이 순서로 봅니다. 설치, 권한과 거버넌스, 데이터 위생, 이벤트 택소노미, 전환, attribution과 보고서. 앞 단계에서 문제가 나오면 거기서 멈추고 고친 뒤 내려갑니다. 깨진 토대 위에서 윗단을 점검하는 건 시간 낭비입니다.

설치, 권한, 데이터 위생, 이벤트, 전환, attribution 6개 영역으로 GA4 점검 순서를 보여주는 다이어그램
아래 영역은 위 영역의 정합성에 기댄다. 설치가 틀리면 전환 숫자도 틀린다. 그래서 위에서부터 내려간다.

영역 1. 설치 정합성 (5)

가장 흔한 사고가 여기서 납니다. 코드가 두 번 들어가 페이지뷰가 두 배로 잡히거나, 측정 ID가 환경마다 섞여 들어간 경우입니다.

  1. 측정 ID가 하나만, 그리고 맞는 것이 들어갔는가. 운영과 스테이징의 ID가 섞이면 테스트 트래픽이 운영 데이터를 오염시킵니다.
  2. GA4 태그가 중복 실행되지 않는가. GTM과 하드코딩 gtag가 동시에 있으면 페이지뷰가 두 배가 됩니다. 실시간 보고서에서 한 번의 방문이 몇 건으로 잡히는지 보면 바로 드러납니다.
  3. 모든 주요 페이지에서 page_view가 발화하는가. SPA라면 라우팅 전환 시 수동으로 page_view를 쏘고 있는지 확인합니다.
  4. 향상된 측정(Enhanced Measurement)의 자동 이벤트가 의도와 맞는가. 스크롤, 이탈 클릭, 사이트 검색이 자동으로 켜져 있는데, 이게 커스텀 이벤트와 겹쳐 같은 행동을 두 번 세는 경우가 있습니다.
  5. 디버그 모드로 실제 발화를 눈으로 봤는가. DebugView에서 핵심 동선을 한 번 클릭해보는 것이, 설정 화면을 백 번 보는 것보다 정확합니다.

영역 2. 권한과 거버넌스 (5)

데이터가 맞아도 사람 구조가 엉키면 사고는 시간문제입니다.

  1. 계정 소유 권한이 회사 자산인가, 특정 개인 계정에 묶여 있는가. 퇴사 한 번에 GA4 접근이 끊기는 조직을 자주 봅니다.
  2. 권한이 역할에 맞게 최소로 부여됐는가. 모두가 관리자면 누구도 책임지지 않습니다.
  3. Google Ads, BigQuery, Search Console 연동이 살아 있는가. 연동이 끊기면 attribution과 raw export가 조용히 멈춥니다.
  4. 데이터 보관 기간(Data Retention)이 의도대로 설정됐는가. 기본값이 짧으면 탐색 분석에서 과거 데이터가 비어버립니다.
  5. 변경 이력을 남기는 합의가 있는가. 누가 언제 전환을 바꿨는지 기록이 없으면, 숫자가 튀었을 때 원인을 찾을 수 없습니다.

영역 3. 데이터 위생 (5)

여기까지 통과하면 이제 들어오는 데이터가 깨끗한지를 봅니다.

  1. 내부 트래픽이 제외됐는가. 직원과 개발자의 방문이 섞이면 전환율과 체류 시간이 왜곡됩니다.
  2. 봇·스팸 트래픽 필터가 작동하는가. 갑자기 특정 지역에서 트래픽이 솟구치면 referral 스팸을 의심합니다.
  3. referral 제외 목록이 정리됐는가. 결제 도메인(PG사)이 referral로 잡히면 세션이 끊겨 전환 경로가 망가집니다.
  4. UTM 규칙이 일관된가. utm_source에 facebook, Facebook, fb가 섞여 있으면 채널 집계가 산산조각 납니다.
  5. 채널 그룹(Channel Grouping)이 우리 채널 현실과 맞는가. 기본 그룹은 국내 매체(네이버, 카카오)를 organic이나 referral로 잘못 분류하곤 합니다.

영역 4. 이벤트 택소노미 (5)

GA4는 모든 게 이벤트입니다. 그래서 이벤트 이름 체계가 무너지면 보고서 전체가 무너집니다.

  1. 이벤트 이름이 규칙을 따르는가. snake_case 통일, 동사_명사 같은 패턴이 있으면 나중에 분석이 수월합니다.
  2. 같은 행동이 다른 이름으로 흩어져 있지 않은가. add_to_cart와 cart_add가 공존하면 둘을 매번 합쳐야 합니다.
  3. 추천 이벤트(Recommended Events) 규격을 따랐는가. GA4가 기대하는 이름(purchase, begin_checkout 등)을 써야 기본 보고서와 머신러닝 기능이 제대로 작동합니다.
  4. 이벤트 파라미터가 커스텀 디멘션·매트릭으로 등록됐는가. 파라미터를 쏘기만 하고 등록하지 않으면 보고서에서 쪼개 볼 수 없습니다.
  5. ecommerce 이벤트의 items 배열이 규격대로인가. item_id, item_name, price, quantity 구조가 어긋나면 매출 보고서가 비거나 틀립니다.

영역 5. 전환(주요 이벤트) (5)

이제 돈과 직결되는 부분입니다. GA4에서 전환은 주요 이벤트(Key Events)로 이름이 바뀌었지만, 점검 관점은 같습니다.

  1. 전환으로 표시된 이벤트가 정말 비즈니스 전환인가. page_view나 scroll이 전환으로 켜져 있는 계정을 의외로 자주 봅니다.
  2. 전환이 중복 정의되지 않았는가. purchase와 별도 커스텀 구매 이벤트가 둘 다 전환이면 한 건이 두 번 셉니다.
  3. 전환 매출(value)이 실제 금액과 단위가 맞는가. 통화 단위가 어긋나거나 부가세 포함 여부가 뒤섞이면 ROAS가 통째로 틀립니다.
  4. Google Ads로 가져오는 전환과 GA4 전환의 정의가 같은가. 두 시스템의 전환 정의가 다르면 매체 최적화가 엉뚱한 신호를 따라갑니다.
  5. 테스트 전환이 운영 데이터에 섞이지 않았는가. 개발 중 발생한 가짜 구매가 전환 수를 부풀리는 경우입니다.

영역 6. attribution과 보고서 신뢰도 (5)

마지막으로, 이 데이터로 만든 보고서를 믿어도 되는지를 봅니다.

  1. attribution 모델이 무엇으로 설정됐는가. GA4 기본은 data-driven인데, 이 모델은 last-click과 다른 숫자를 냅니다. 광고 매니저와 GA4가 안 맞는 단골 원인입니다.
  2. lookback window가 채널 구매 주기와 맞는가. 고가 상품의 긴 고려 기간을 짧은 윈도로 보면 전환이 누락됩니다.
  3. 보고서 기준(reporting identity)이 의도와 맞는가. 기기 기반과 사용자 기반 중 무엇으로 합치느냐에 따라 사용자 수가 달라집니다.
  4. 데이터 임계값(thresholding)으로 보고서가 비어 보이지 않는가. 표본이 적으면 GA4가 일부 행을 가리는데, 이걸 데이터 없음으로 오해하기 쉽습니다.
  5. 같은 지표를 두 보고서에서 봤을 때 일치하는가. 표준 보고서와 탐색(Exploration)의 숫자가 다르면, 디멘션 조합이나 기간 처리 차이를 의심합니다.

체크리스트를 운영에 녹이는 법

이 30개는 한 번 보고 끝낼 점검이 아닙니다. 새 계정을 받을 때만이 아니라 분기마다 한 번씩 위에서부터 훑으면, 트래킹이 조용히 망가지는 일을 막습니다. 사이트를 개편하거나 새 매체를 붙일 때 트래킹이 깨지는 일은 흔하고, 그 사실을 보고서 숫자가 이상해진 한참 뒤에야 알아차리니까요.

가장 좋은 운영은 이 점검을 자동화 쪽으로 미는 것입니다. DebugView를 눈으로 보는 일은 사람이 하더라도, 전환 중복이나 UTM 표기 흔들림 같은 항목은 BigQuery export 위에서 쿼리로 정기 점검할 수 있습니다. 사람의 시간은 판단이 필요한 곳에 쓰고, 규칙으로 잡히는 건 기계에게 맡깁니다.

마치며

GA4 점검의 핵심은 똑똑한 분석이 아니라 정직한 순서입니다. 설치가 맞는지부터 보고, 토대가 단단할 때만 윗단으로 올라갑니다. 이 30개를 위에서부터 내려가며 확인하면, 처음 보는 계정도 반나절이면 어디가 성한지 어디가 곪았는지가 보입니다.

그리고 이 점검은 결국 한 질문으로 수렴합니다. 이 숫자를 믿고 예산을 움직여도 되는가. 트래킹이 깨진 채로 만든 ROAS는 그 위에 쌓는 모든 의사결정을 같이 무너뜨립니다.

참고

Analytics Ops (GA4·GTM) 카테고리의 다른 글

전체 보기 →