QA·Debugging·Governance
Realtime, DebugView, Tag Assistant, BigQuery를 이용한 GA4 이벤트 품질 관리
핵심 요약
- 이벤트 설계는 UI·GTM·route·checkout provider·consent banner가 바뀌면 배포 후 깨지므로 QA를 계속 돌려야 합니다.
- QA 표면은 Realtime, DebugView, Tag Assistant/GTM Preview, Events report, BigQuery Export로 나뉘고, 각각 다른 단계를 확인합니다.
- reports와 explorations는 처리에 24~48시간이 걸리기도 하니 수집 확인은 Realtime과 DebugView로 합니다.
- 배포 전 checklist에서는 Measurement ID 혼동, 중복 발화, 필수 파라미터, 값 형식, PII, consent, cross-domain, internal traffic, BigQuery row를 점검합니다.
- governance 원칙은 event owner 지정, registry first(구현 전 사전 수정), backward compatible 변경, low cardinality UI, raw data audit입니다.
2026년 하반기 수집 검증 변경
9월 21일 추가된 Hostname Include filter는 허용한 hostname의 웹 이벤트를 수집하도록 구성합니다. 적용 전 preview·결제·auth domain을 목록으로 만들고 테스트합니다. Measurement Protocol 이벤트에는 이 filter가 적용되지 않으므로 서버 이벤트의 유효성·출처 통제는 별도입니다. hostname이 비어 있는 이벤트는 차단될 수 있어 정상 웹 경로도 확인합니다.
Measurement Protocol은 잘못된 payload에도 HTTP 성공을 반환할 수 있습니다. 개발 시 /debug/mp/collect와 validation_behavior: "ENFORCE_RECOMMENDATIONS"로 validationMessages를 확인합니다. debug 요청은 실제 보고서에 적재되지 않으며 api_secret·firebase_app_id의 정확성도 검증하지 않으므로 정상 수집 endpoint의 별도 smoke 확인이 필요합니다.
| 검증 단계 | 확인할 것 |
|---|---|
| payload validation | 필드·형식·제약 오류; debug 응답 내용 |
| 실제 수집 | 올바른 property·credential과 정상 endpoint |
| 처리 후 확인 | DebugView·Realtime·daily export를 목적별로 사용 |
| hostname filter | 허용 domain·빈 hostname·MP 예외의 실제 영향 |
Google Analytics 변경내역 · Measurement Protocol 검증.
이벤트 설계는 배포하고 나면 깨집니다. UI나 GTM 버전, route, checkout provider, consent banner가 바뀌면 이벤트 발화도 따라 바뀌기 때문입니다.
QA 표면
| 도구 | 확인할 것 |
|---|---|
| Realtime report | 이벤트가 실제 property에 들어오는지 |
| DebugView | 특정 device/browser에서 이벤트와 parameter가 의도대로 발화하는지 |
| Tag Assistant / GTM Preview | tag trigger, dataLayer, consent state |
| Events report | 처리 후 이벤트 수와 추세 |
| BigQuery Export | 원시 row, params, 중복 여부 |
Google 공식 문서는 reports와 explorations가 처리에 24~48시간까지 걸리기도 하니, 수집 여부는 Realtime과 DebugView로 확인하라고 안내합니다.
배포 전 QA checklist
| 항목 | 통과 기준 |
|---|---|
| Measurement ID | prod/staging ID 혼동 없음 |
| 중복 발화 | 같은 사용자 행동에 이벤트 1회 |
| 필수 파라미터 | required parameters가 모두 존재 |
| 값 형식 | snake_case, enum 값, numeric type 일치 |
| PII | URL, title, search term, form field, parameter에 PII 없음 |
| Consent | 동의 상태별 수집 동작 확인 |
| Cross-domain | checkout/auth 이동 후 session 단절 없음 |
| Internal traffic | 사내/QA 트래픽 처리 기준 확인 |
| BigQuery | 다음 export에서 raw row 확인 가능 |
DebugView 사용 기준
| 상황 | 확인 |
|---|---|
| 새 이벤트 추가 | event name, timestamp, required parameters |
| key event 후보 | 중복 발화와 trigger 조건 |
| GTM 변경 | trigger firing condition과 tag sequence |
| SPA routing | route change마다 page_view 중복/누락 |
| form tracking | PII가 parameter로 들어가지 않는지 |
이벤트 변경 프로세스
- 이벤트 스펙 PR이나 문서 변경부터 만듭니다.
- owner, trigger, required parameters, custom definitions, key event 여부를 기록합니다.
- 스테이징 또는 debug 환경에서 DebugView로 검증합니다.
- GTM container 또는 앱 배포 버전을 기록합니다.
- 배포 후 Realtime과 BigQuery로 24~48시간 확인합니다.
- 변경 내역은
updates.mdx또는 별도 analytics changelog에 남깁니다.
실패 모드
| 증상 | 원인 후보 | 대응 |
|---|---|---|
| 이벤트가 안 보임 | tag 미설치, consent denied, trigger 조건 오류 | Tag Assistant, DebugView |
| 파라미터가 비어 있음 | dataLayer key 불일치 | GTM 변수와 spec 비교 |
| key event가 과다 | 중복 발화, page reload, retry | idempotency 또는 trigger 조건 보정 |
| 보고서에 dimension 없음 | custom definition 미등록 또는 처리 지연 | 등록 후 24~48시간 관찰 |
| BigQuery row 없음 | export 지연, event exclusion, table suffix 오류 | export 설정과 raw table 확인 |
Governance 원칙
| 원칙 | 설명 |
|---|---|
| Event owner | 이벤트마다 제품/데이터 owner를 둠 |
| Registry first | 구현 전에 이벤트 사전을 수정 |
| Backward compatible | 기존 보고서를 깨는 변경은 새 event/parameter로 migration |
| Low cardinality UI | GA4 UI용 dimension은 값 집합을 관리 |
| Raw data audit | BigQuery로 원시 이벤트 표본을 정기 검수 |