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

보고서의 숫자를 믿기 전에 설치부터 attribution까지 같은 순서로 확인하면, GA4 계정의 위험을 감이 아니라 증거로 인수인계할 수 있습니다.

처음 보는 GA4 계정의 보고서에는 숫자가 차 있지만, 그 숫자를 믿어도 되는지는 별개의 문제입니다. 전환이 중복으로 잡혔는지, 내부 트래픽이 섞였는지, 이벤트 이름이 제멋대로인지를 화면만 봐서는 모릅니다. 컨설팅이든 인수인계든, GA4를 마주할 때 필요한 건 영감이 아니라 순서입니다. 무엇부터 열어보고 무엇을 확인할지가 정해져 있으면 짧은 1차 진단만으로도 더 깊게 조사할 영역이 드러납니다.

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

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

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

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

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

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

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

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

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

계정 소유 권한이 회사 자산인가, 특정 개인 계정에 묶여 있는가. 개인 계정만 관리자라면 담당자 변경 때 접근이 끊길 수 있습니다.
권한이 역할에 맞게 최소로 부여됐는가. 모두가 관리자면 누구도 책임지지 않습니다.
Google Ads, BigQuery, Search Console 연동이 각각 살아 있는가. Google Ads 연동은 광고 차원과 전환 활용, BigQuery 연동은 event export, Search Console 연동은 검색어·랜딩 보고에 영향을 주므로 한 문장으로 같은 장애처럼 묶지 않습니다.
데이터 보관 기간(Data Retention)이 의도대로 설정됐는가. 이 설정은 주로 탐색의 사용자·이벤트 수준 데이터에 영향을 주며, 모든 표준 집계 보고서가 같은 날 사라진다는 뜻은 아닙니다.
변경 이력을 남기는 합의가 있는가. 누가 언제 전환을 바꿨는지 기록이 없으면, 숫자가 튀었을 때 원인을 찾을 수 없습니다.

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

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

내부 트래픽이 제외됐는가. 직원과 개발자의 방문이 섞이면 전환율과 체류 시간이 왜곡됩니다.
비정상 트래픽을 탐지하는 모니터가 있는가. GA4에는 Universal Analytics와 같은 사용자 정의 bot filter 설정이 없으므로, 지역·hostname·source·이벤트 빈도의 급변을 보고 원인을 조사합니다.
referral 제외 목록이 정리됐는가. 결제 도메인(PG사)이 referral로 잡히면 세션이 끊겨 전환 경로가 망가집니다.
UTM 규칙이 일관된가. utm_source에 facebook, Facebook, fb가 섞여 있으면 채널 집계가 산산조각 납니다.
채널 그룹(Channel Grouping)이 우리 채널 현실과 맞는가. 네이버·카카오도 source category와 medium이 기본 규칙에 맞지 않거나 UTM이 흔들리면 organic·referral·unassigned 등 의도하지 않은 채널로 분류될 수 있습니다.

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

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

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

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

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

전환으로 표시된 이벤트가 정말 비즈니스 전환인가. page_view나 scroll처럼 매출과 직접 연결되지 않는 이벤트가 주요 이벤트로 지정돼 있지 않은지 확인합니다.
전환이 중복 정의되지 않았는가. purchase와 별도 커스텀 구매 이벤트가 둘 다 전환이면 한 건이 두 번 셉니다. ecommerce의 transaction_id는 비어 있지 않은 주문별 고유값이어야 합니다. 웹 스트림은 같은 ID의 purchase를 중복 제거하지만 앱 스트림에는 이 동작이 적용되지 않고, 서로 다른 주문에 같은 ID를 재사용하면 오히려 과소 집계될 수 있습니다.
전환 매출(value)이 실제 금액과 단위가 맞는가. 통화 단위가 어긋나거나 부가세 포함 여부가 뒤섞이면 ROAS가 통째로 틀립니다.
Google Ads로 가져오는 전환과 GA4 전환의 정의가 같은가. 두 시스템의 전환 정의가 다르면 매체 최적화가 엉뚱한 신호를 따라갑니다.
테스트 전환이 운영 데이터에 섞이지 않았는가. 개발 중 발생한 가짜 구매가 전환 수를 부풀리는 경우입니다.

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

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

주요 이벤트 범위(event-scoped)의 attribution 모델이 무엇으로 설정됐는가. data-driven과 paid-and-organic last click은 귀속 결과가 다르며, 사용자·세션 유입 차원은 별도의 scope 규칙을 따릅니다.
lookback window가 채널 구매 주기와 맞는가. 고가 상품의 긴 고려 기간을 짧은 윈도로 보면 전환이 누락됩니다. 같은 전환도 창 길이에 따라 ROAS가 달라지는 과정은 lookback window 비교에서 숫자로 이어집니다.
보고서 기준(reporting identity)이 의도와 맞는가. User-ID·device ID·모델링 신호를 어떤 순서로 합치는지에 따라 사용자 수와 경로가 달라질 수 있습니다.
Google signals와 작은 사용자 수 조합에서 데이터 임계값(thresholding)이 적용됐는지 보고서 품질 아이콘으로 확인했는가. 가려진 행을 수집 실패로 단정하지 않습니다.
같은 지표를 두 보고서에서 봤을 때 일치하는가. 표준 보고서와 탐색(Exploration)의 숫자가 다르면, 디멘션 조합이나 기간 처리 차이를 의심합니다.

이 API로 실제 무엇을 만들 수 있는지

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

통과 개수보다 의사결정 영향을 먼저 본다

30개 중 몇 개를 통과했는지만 세면 위험이 평평해집니다. 구매 이벤트가 두 번 들어오는 한 건은 변경 이력이 없는 한 건보다 훨씬 비쌉니다. 감사 결과는 실패 개수가 아니라, 그 문제가 예산 결정을 얼마나 흔드는지에 따라 아래 세 상태로 접는 편이 낫습니다.

판정	이 상태로 보는 조건	다음 행동
중단	측정 ID·중복 태그·주요 이벤트·금액·통화 오류처럼 전환 수나 매출을 직접 바꿈	ROAS 기반 증액과 성과 보고를 멈추고 수정 후 같은 합성 동선을 재실행
조건부 사용	수집은 되지만 UTM·채널 그룹·lookback window·reporting identity의 정의가 비교 대상과 다름	숫자 옆에 적용 범위와 예외를 적고, 같은 정의끼리만 비교
운영 백로그	현재 수치보다 권한·명명 규칙·변경 기록의 재발 가능성을 키움	담당자와 기한을 정해 다음 배포 또는 분기 감사 전에 닫기

가령 합성 점검에서 30개 중 26개를 통과했다고 해봅시다. purchase가 두 번 들어온 항목 22는 중단, facebook과 Facebook이 섞인 항목 14와 구매 주기보다 짧은 항목 27은 조건부 사용, 변경 기록이 없는 항목 10은 운영 백로그입니다. 통과율은 87%지만 최종 판정은 중단입니다. 평균 점수가 치명적인 한 건을 가리지 못하게 하는 방식입니다.

합성 재검증은 같은 입력을 다시 보내는 계약이다

수정 확인에는 실제 구매나 고객 데이터가 필요하지 않습니다. 테스트 속성 또는 스테이징 스트림에서 transaction_id=qa_20260809_001, value=78000, currency=KRW처럼 존재하지 않는 주문을 보내고, 기대 결과를 먼저 고정합니다. DebugView와 Realtime 보고서는 이벤트가 들어왔다는 빠른 증거로 쓰고, 최종 통과는 export가 안정된 뒤 같은 transaction_id의 건수·금액이 기대값과 일치하는지로 판단합니다.

합성 거래 정합률 = 일치한 transaction_id 수 ÷ 전송한 transaction_id 수

이 격리된 테스트 묶음에서는 정합률 100%와 중복 0건을 요구합니다. GA4 화면과 BigQuery 전체 집계는 reporting identity, 시간대, 제외 이벤트처럼 비교 조건이 달라 숫자가 어긋날 수 있으므로, 먼저 조건을 맞춘 뒤 차이를 결함으로 판정합니다. 비교 쿼리의 grain과 조인 위험은 광고 SQL·BI 안티패턴 7가지, event export에서 ROAS까지 잇는 순서는 GA4 + BigQuery 파이프라인에서 이어서 확인할 수 있습니다.

자동화는 판정을 대신하지 않고 증거를 모은다

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

설정 스냅샷: Google Analytics Admin API로 속성·데이터 스트림·주요 이벤트·커스텀 정의 목록을 정기 저장하고, 지난 스냅샷과 달라진 항목을 변경 로그로 보냅니다.
배포 직후 스모크 테스트: Realtime Data API의 실시간 보고서와 DebugView를 함께 사용해 핵심 이벤트 이름과 파라미터가 들어오는지 확인합니다. 실시간 보고서는 수집 여부를 빠르게 확인하는 도구이지 최종 집계의 대체품은 아닙니다.
일별 이상 탐지: Data API 또는 BigQuery export에서 주요 이벤트 수·매출·미매핑 UTM 비율을 뽑고, 직전 4주 같은 요일 범위를 크게 벗어나면 알림을 보냅니다.
분기 감사 팩: 자동 검사 결과에 사람이 확인할 DebugView·권한·보고서 임계값 항목을 합쳐, 미해결 위험·담당자·기한이 있는 한 장짜리 점검표를 만듭니다.

권장 주기는 배포 직후 스모크 테스트, 매일 자동 이상 탐지, 매주 미매핑 UTM 검토, 분기 전체 점검입니다. 이는 모든 조직에 맞는 절대값이 아니라 시작점입니다. 트래픽 규모와 배포 빈도에 맞춰 경보 임계값과 주기를 조정해야 합니다.

마치며

GA4 점검의 핵심은 똑똑한 분석이 아니라 정직한 순서입니다. 설치가 맞는지부터 보고, 토대가 단단할 때만 윗단으로 올라갑니다. 이 30개를 위에서부터 내려가며 확인하면, 처음 보는 계정에서도 추가 조사가 필요한 영역과 그 근거를 같은 형식으로 남길 수 있습니다.

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