GA4는 자동 수집, 향상된 측정, 추천 이벤트와 맞춤 이벤트를 구분합니다. 구현 방식이 다르며 이벤트 이름만으로 업무 행동의 성공이 증명되지 않습니다.
관측 가능한 행동 정의하기
새로 만들기 전에 기존 또는 추천 이벤트를 찾습니다. 트리거, 매개변수, 집계 단위와 한계를 기록합니다. 양식 클릭은 요청 수신과 다릅니다. 이름, URL과 전송 매개변수에 개인정보를 넣지 않습니다.
수집과 업무 중요성 구분하기
GA4 이벤트를 주요 이벤트로 표시할 수 있습니다. 이는 선택한 분석 중요성이며 판매나 수익성의 증거는 아닙니다. 보고서 전에 중복, 값과 수집 범위를 확인합니다. 향상된 측정과 자동 수집은 별도 범주입니다.
| 범주 | 예시 | 조건 |
|---|---|---|
| 자동 수집 | first_visit, session_start | 기본 구성에서 제공하는 수집 |
| 향상된 측정 | scroll, file_download | 기능 활성화 및 지원되는 상호작용 |
| 추천 | add_to_cart, purchase | 문서화된 이름과 매개변수 구현 |
| 맞춤 | 제품별 행동 | 다른 범주가 맞지 않을 때 정의 |
출처와 검증
- Google Analytics — Set up events
- Google Analytics — About key events
- Google Analytics — Avoid sending personally identifiable information
사용자 지정 이벤트는 비즈니스 사실을 설명해야 합니다.
사용자 지정 GA4 이벤트는 관찰 가능한 작업을 나타내고 의사 결정을 지원해야 합니다. 명확한 이름만으로는 부정확한 트리거를 보완할 수 없습니다. 예를 들어, 양식을 제출했다고 해서 서버가 요청을 수락했다는 증거는 아닙니다.
- 이벤트 사전에서 트리거, 매개변수, 유형 및 제외된 사례에 대한 버전을 관리합니다.
- DebugView 또는 이와 유사한 도구를 사용하여 성공, 오류, 뒤로 가기 및 새로 고침을 테스트합니다.
- 수신된 이벤트를 알려진 작업과 대조하고 불일치를 할당합니다.
1차 자료: Google Analytics — Set up events. 관련 방법: 실무 가이드 읽기.
데이터 조인 무결성
조인은 행을 늘려 합계를 왜곡할 수 있습니다.
- 주문 테이블의 한 행은 주문을, 항목 테이블의 한 행은 주문 내 상품을 나타냅니다. 결합 전에 반복 키와 NULL 키를 확인합니다.
- 주문 키별로 항목을 집계합니다. 그 결과를 주문과 결합하면 상품마다 주문 금액이 반복되지 않습니다. 원래 주문 테이블의 합계와 비교합니다.
- LEFT JOIN은 항목이 없는 주문도 남기지만, 오른쪽 테이블에 적용한 WHERE 조건이 이를 제거할 수 있습니다. 대응 없음과 금액 0은 다릅니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"orders": [
{
"id": 1,
"total": 100
},
{
"id": 2,
"total": 200
}
],
"line_order_ids": [
1,
1,
2
],
"sum_before": 300,
"sum_after_raw_join": 400
}예상 판단
400은 주문 하나를 중복 계산합니다. 주문별로 항목을 집계하여 300을 복원합니다. 각각 100인 가상 주문 두 건도 시험합니다. 합계는 200입니다. SUM(DISTINCT total)은 100을 반환하여 유효한 값을 제거합니다. 금액 중복 제거 대신 식별자와 조인 관계의 수를 확인합니다.
재현 가능한 SQL 쿼리
가상 예: 주문 금액 100과 200, 주문 1, 1, 2에 연결된 항목 세 개입니다. 쿼리는 VALUES만 사용하며 테스트 환경에서 실행하세요.
WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
SELECT order_id, COUNT(*) AS line_count
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;직접 결합하면 세 행과 합계 400이 나옵니다. 먼저 집계하면 주문 두 건과 합계 300을 얻습니다.
WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
SUM(DISTINCT total) AS distinct_total
FROM orders;금액이 100과 100이면 올바른 합계는 200이지만 SUM(DISTINCT total)은 100입니다.
검증 절차
- 주문과 항목의 세분성을 정의합니다.
- 두 항목을 가진 주문을 결합합니다.
- 키, 행 수 및 대조한 합계를 보존합니다.
SUM(DISTINCT total)이면 충분한가요?
아닙니다. 금액 100인 주문 두 건의 합계는 200이지만 SUM(DISTINCT total)은 100을 반환합니다. 금액 중복 제거 대신 키 관계를 수정하세요.
1차 자료: PostgreSQL — Table expressions and joins. 관련 방법: 실무 가이드 읽기.
조인 카디널리티, NULL 및 집계
이 언어판의 상세 참고 설명은 영어로 제공됩니다.
Read the cardinality behind a published number
When a result combines sources, ask what one row represents and how keys were matched. An apparently correct sum can conceal two offsetting errors. Pair counts and identifier coverage provide additional evidence.
- Document population before and after joining.
- Do not infer causation from the total alone.
- Connect the metric definition to actual retained rows.
Inspect pairs and aggregates in the workshop →
PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23
PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23
PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23