Google Analytics 입문 1편 — GA4 종합 · Event 기반 · 4 측정 방법

오늘부터 Google Analytics 입문에서 운영까지 시리즈를 시작해요. 1편은 GA4 가 도대체 뭘 해주는 도구인가 — 큰 그림.

처음 들으면 어렵게 느껴지는 이유

GA 가 처음 헷갈리는 건 비슷한 도구 들과 지나치게 큰 변화 때문이에요.

첫째, 카테고리 경계 흐림 — Mixpanel(제품 사용 분석 SaaS) · Amplitude(제품 사용 분석 SaaS) · Adobe(엔터프라이즈 분석 스위트) · Statsig(실험·분석 통합 도구) 의 Product Analytics, Looker(BI 대시보드 플랫폼) · Tableau(시각화 BI 도구) 의 BI (Business Intelligence, 비즈니스 분석), Segment(이벤트 라우팅 허브) 의 CDP (Customer Data Platform, 고객 데이터 통합 플랫폼) 사이에서 GA 가 어디 속하나 헷갈려요.

둘째, GA4 의 큰 변화 — 2023년 7월 Universal Analytics (UA) 가 sunset 됐고 GA4 로 강제 전환. 인터넷의 옛 자료가 UA 기준 이라 지금도 혼란. 데이터 모델 자체가 달라져서 예전 지식이 안 통함.

해결법은 비유 하나. GA = 모든 회사의 "기본 무료 web analytics 표준". 일반 분석 은 GA · 깊은 product analytics 는 Mixpanel/Amplitude · 실험은 Statsig · CRM (Customer Relationship Management, 고객 관계 관리) 통합은 HubSpot(마케팅·세일즈 자동화 SaaS) — 역할이 다른 도구들. GA 는 "우선 깔아두는 도구" 의 자리.

GA 한 줄 정의

GA4 = 웹사이트와 앱에서 트래픽 + 참여도를 측정 하는 분석 서비스. — 공식 docs

쉽게 풀면 — 누가 우리 사이트 왔는지 + 무엇 했는지 + 어디서 왔는지 를 자동 추적. Google 이 무료 제공 하는 web analytics 표준 도구.

대표 사용을 늘어놓으면 일일 방문자·세션 수, traffic source (검색·소셜·광고·direct), 인기 페이지·이탈률, 전환 funnel (가입·결제·구독), 사용자 segment 의 행동 차이, 캠페인 ROI (UTM, 광고 추적용 URL 파라미터 기반) — 이 정도가 매일 보는 그림이에요.

3 학습 Path — 누가 무엇 배우나

GA Developers 가 제시하는 3 길:

→ 우리 시리즈는 Developer + Analyst 관점 중심으로 풀이.

GA4 vs Universal Analytics — 큰 변화

2023.7 sunset 됐지만 예전 지식이 머리에 박혀 있을 수도. 정리:

여기서 시험 함정이 하나 있어요 — GA4 = 완전히 새 도구. UA 의 세션 · 이탈률 · 페이지뷰 같은 metric 정의가 조금씩 달라요. 옛 보고서 와 직접 비교 X. 추세만 비교.

핵심 계층 — Account · Property · Data Stream

GA 의 조직 구조 3 단:

[Account] (회사 단위)
   ├─ [Property] (브랜드 · 서비스)
   │   ├─ [Data Stream] iOS 앱
   │   ├─ [Data Stream] Android 앱
   │   └─ [Data Stream] Web (예: example.com)
   │
   └─ [Property] (다른 브랜드)
       └─ ...

Account

회사 · 조직 단위. 권한 관리. 일반적으로 회사당 1 account.

Property

분석 단위. 하나의 서비스 · 브랜드 · 도메인 그룹 = 하나의 property.

예시로 카카오를 놓고 보면, 회사가 카카오, Account 가 "카카오", Property 1 이 "카카오톡" (모바일 + 웹 통합), Property 2 가 "카카오뱅크" (모바일 + 웹), Property 3 이 "카카오엔터프라이즈" 식으로 갈라져요.

Data Stream

데이터 수집의 entry point. iOS · Android · Web 별 stream.

핵심 차이 vs UA — UA 는 iOS 앱 · Android 앱 · Web 이 별도 property 였음. GA4 는 한 property 안에 여러 stream = cross-platform 사용자 통합 view.

Stream ID = Measurement ID

각 stream 의 unique ID. Web 의 경우 Measurement ID (G-XXXXXXXX 형식). gtag(Google 통합 태깅 스크립트) · GTM (Google Tag Manager, 태그 통합 관리 도구) 설치 시 이 ID 사용.

Event 기반 데이터 모델

GA4 의 가장 큰 변화. UA 의 hit 모델 과 다른 event-everything 모델.

모든 게 Event

UA 시대:

- pageview (페이지 조회) → 별도 hit type
- event (사용자 행동) → 별도 hit type
- transaction (결제) → 별도 hit type
- screenview (앱 화면) → 별도 hit type

GA4 시대:

- page_view  → event
- click       → event
- purchase    → event
- screen_view → event
- 모든 게 event

각 event 가 공통 schema: event_name + event_params (key-value).

자동 수집 Event

gtag 또는 GTM 설치만 해도 자동:
  - page_view
  - first_visit
  - session_start
  - user_engagement
  - scroll (90% 도달)
  - click (outbound link)
  - file_download
  - video_start · video_progress · video_complete
  - form_start · form_submit

설치 몇 줄 로 수십 가지 표준 event 자동 수집. UA 시대 모두 수동 박아야 한 것과 큰 차이.

Recommended Event

업종별 권장 event 이름. 표준화 가치:

E-commerce:
  - view_item · add_to_cart · begin_checkout · purchase

Travel:
  - view_search_results · select_promotion · select_item

Gaming:
  - level_start · level_end · earn_virtual_currency

일관 이름 박으면 자동 보고서가 richer. e-commerce 표준 funnel 자동 생성.

Custom Event

gtag('event', 'my_custom_event', {
  category: 'shoes',
  action: 'detail_view',
  value: 50000
});

표준 외 우리 비즈니스 특화 event. naming convention (snake_case · 동사_명사) 권장.

Event Parameter

각 event 의 속성. 표준 + custom 가능.

event: purchase
params:
  - value: 50000           (표준 — 금액)
  - currency: "KRW"        (표준 — 통화)
  - items: [...]           (표준 — 상품 list)
  - payment_method: "card" (custom)

Statsig 5편 Event 설계 · Braze 3편 Custom Event 와 같은 event-everything 패턴.

User Property

사용자 상태 정보 (event 가 아닌). 비교적 안정.

gtag('set', 'user_properties', {
  tier: 'premium',
  signup_year: 2025,
  country: 'KR'
});

Braze 의 User Attribute 와 같은 상태 단위. event 마다 박는 게 아니라 변경 시 sync.

4 측정 방법

GA4 에 데이터 보내는 4 가지 길. 어디서 데이터 보내는가에 따라 선택.

1. gtag.js — 직접 통합

<!-- HTML head -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXX');
</script>

가장 단순하고 코드를 직접 박는 방식이라 자동 event 수집이 곧장 도는 게 장점. 추가 event 는 gtag('event', ...) 한 줄로 끝나서, 작은 사이트 나 단순 통합 에서 주로 골라요.

2. Google Tag Manager (GTM)

<!-- GTM container script (head) -->
<script>(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXXX');</script>

Tag · Trigger · Variable 을 대시보드 에서 굴리는 방식이라, GA4 외에 다른 도구 (Facebook Pixel · Hotjar) 도 한 곳에 모아 운영해요. 마케터가 코드 없이 추가 event 를 박을 수 있다는 게 결정적이고, 복잡한 marketing stack · 여러 분석 도구 를 동시에 굴릴 때 거의 기본 선택.

여기서 정말 중요한 시험 함정 — gtag.js vs GTM 의 결정. 대부분 운영 환경 = GTM 권장. 유연성 + 마케터 자율성 + 여러 도구 가 gtag 직접 보다 우월.

3. Firebase SDK — 모바일

// iOS
import FirebaseCore
import FirebaseAnalytics

FirebaseApp.configure()

Analytics.logEvent("product_viewed", parameters: [
    "product_id": "P-123",
    "category": "shoes"
])

// Android
val analytics = Firebase.analytics
analytics.logEvent("product_viewed") {
    param("product_id", "P-123")
    param("category", "shoes")
}

iOS · Android 앱 의 표준 통합 경로이고, Firebase(Google 모바일 앱 백엔드 플랫폼) 의 SDK (Software Development Kit, 개발 도구 모음) 가 Crashlytics(앱 크래시 리포트) · Remote Config 같은 Firebase ecosystem 과 자연스럽게 묶여요. 자동 SDK 통합과 custom event 가 모두 깔리니까 네이티브 앱 에서는 사실상 모바일 표준.

4. Measurement Protocol — Server-side

curl -X POST 'https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET' \
  -H 'Content-Type: application/json' \
  -d '{
    "client_id": "555",
    "events": [{
      "name": "purchase",
      "params": {
        "transaction_id": "T-12345",
        "value": 50000,
        "currency": "KRW",
        "items": [{"item_id": "P-1", "item_name": "Shoes"}]
      }
    }]
  }'

서버에서 직접 GA 로 쏘는 방식. Client SDK 없이 가능해서, CRM 시스템의 결제 알림처럼 클라이언트가 닿지 않는 경로에서도 이벤트를 보낼 수 있고 민감 데이터 를 server-side 에서 통제할 수 있어요. 그래서 결제 webhook 에서 서버가 직접 전환을 쏘거나, refund · subscription cancellation 같은 server-side event, 또는 cookieless 환경 에서 자주 등장.

4 방법의 선택 가이드

간단한 웹사이트 (블로그 등): gtag.js
복잡한 marketing stack 가진 웹: GTM
모바일 앱: Firebase SDK
백엔드 이벤트 (결제 webhook 등): Measurement Protocol

대부분 큰 회사 = GTM (web) + Firebase (app) + Measurement Protocol (server) 의 조합.

Conversion · Audience — 분석의 두 축

Conversion — 비즈니스 가치

Conversion = 비즈니스적으로 중요한 사용자 행동. 흔히 박는 예가 signup_completed · first_purchase · subscription_started · free_trial_signup · phone_consultation_requested 정도.

UA = Goal 설정 (어렵고 제한적) GA4 = Event 자체를 conversion 으로 toggle (한 클릭)

Audience — 사용자 segment

Audience = 조건 만족 사용자 그룹.

"VIP 사용자 segment":
  - 30일 안 3+ 구매
  - 총 결제액 100,000원+
  - 지난 7일 active

이 segment 를 만들어 두면 광고 retargeting (Google Ads 로 동기화) 에 그대로 쓰거나, 마케팅 자동화 도구 (Braze · Iterable) 로 export 하거나, 사용자 group 별 분석 의 단위로 활용해요.

Statsig segment · Braze segment 와 같은 개념. 세 도구가 비슷한 segment 메커니즘.

Reports vs Explorations

GA4 의 분석 두 도구:

Reports — 표준 보고서

Realtime · Acquisition · Engagement · Monetization · Retention · ...

미리 정의된 보고서. 빠른 overview.

Explorations — 커스텀 분석

종류는 Free-form (피벗 테이블) · Funnel (단계별 전환) · Path (사용자 경로) · Segment overlap · User explorer · Cohort 로, 자유롭게 차원·지표를 조합 해 깊게 들여다보는 도구예요.

Statsig Product Analytics 6 차트 와 비슷. GA4 도 funnel · path · cohort 표준 지원.

Developer 도구 — 3 API + BigQuery

Data API

GET https://analyticsdata.googleapis.com/v1beta/properties/{property_id}:runReport

보고서 데이터 프로그래밍 조회. 우리 dashboard · BI · 알림 시스템에 GA 데이터 통합.

Admin API

PUT https://analyticsadmin.googleapis.com/v1beta/properties/{property_id}

property · stream · custom dimension · audience 같은 설정 관리 API.

대량 운영 = programmatic 설정 (예: 100개 property 자동 생성).

Measurement Protocol

위 4 측정 방법의 1. server-side event 전송.

BigQuery Export

GA4 의 가장 큰 변화 — 모든 raw event 를 BigQuery 로 자동 export (무료, GA4 표준).

-- BigQuery 에서 GA4 데이터 직접 query
SELECT
    event_name,
    COUNT(DISTINCT user_pseudo_id) as users
FROM `project.analytics_XXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260501' AND '20260517'
GROUP BY event_name
ORDER BY users DESC

UA 시대 = GA 360 (유료) 만 BQ (BigQuery, Google Cloud 의 데이터 웨어하우스) export 됐는데 GA4 = 무료 표준.

→ 모든 회사가 raw data 통제 가능. 우리 BI · ML · 외부 도구 자유 결합.

경쟁 도구 — 객관 비교

GA4 의 자리

GA4 가 가장 강한 자리 — 모든 회사 기본 분석 (무료 + 표준), 광고 attribution (Google Ads · Search Console · YouTube 통합), BigQuery export 무료 (raw data 통제), cross-platform (Web + iOS + Android 통합) 네 가지가 결정적이에요.

반대로 GA4 가 약한 자리 는 Product analytics 깊이 (Mixpanel · Amplitude 우세), 실험 도구 (Statsig 우세), real-time 분석 (Mixpanel 우세), Custom dashboard UI 한계 — 이 네 군데.

→ GA4 + 다른 도구 가 가장 흔한 운영. 광고 + 기본 분석은 GA, product analytics 는 Mixpanel/Amplitude, 실험은 Statsig.

도입 결정 — 누가 가야 하나

도입 시그널

3 이상 해당 = GA 도입 권장 인데, 체크 항목을 죽 풀면 웹사이트 있음 + 방문자 추적 필요, Google Ads · SEO 운영, 어디서 사용자 오는지 모르겠음, 전환 funnel 측정 필요, 광고 ROI 측정 필요, 예산 제약 (GA 는 무료), 마이그레이션 부담 회피 — 이 정도가 신호.

거의 모든 회사 = GA 도입 권장. 무료 + 표준 이라 진입 장벽 거의 0.

도입 아님

반대로 도입을 미루는 자리는 완전 internal tool (사용자 없음), Privacy 매우 엄격 — GA 자체가 cookie 기반 (cookieless 대응은 보강 중), Adobe 같은 enterprise 가 이미 깔린 환경 정도예요.

자주 만나는 사고 — 도입 단계

사고 1: Universal Analytics 사고

원인 — 옛 UA tracking code 가 여전히 사이트에 박혀 있음. no-op 이지만 코드 무게.

해결 — 사이트의 모든 페이지에서 UA 코드 제거 + GA4 만 운영.

사고 2: Property 너무 많이 만듦

원인 — page · feature 별 별도 property → 분석 분산.

해결 — 서비스 단위 1 property. 페이지/기능은 event 의 dimension 으로.

사고 3: Cookie consent 누락

원인 — GDPR (EU 개인정보보호 규정) · KISA (한국인터넷진흥원) 의 cookie 동의 없이 추적.

해결 — cookie banner 통합 (Cookiebot · OneTrust 등) + 동의 전 X · 동의 후 ON.

사고 4: Data retention 만료 충격

원인 — 14개월 default retention 도달 후 옛 데이터 사라짐.

해결 — BigQuery export 활성화 (raw data 영구 보존) + retention 14→ 원하는 최대 로 변경.

사고 5: PII 데이터 박기

원인 — user_email · phone 같은 PII (Personally Identifiable Information, 개인 식별 정보) 를 user property 에.

해결 — GA4 의 PII 정책 위반. PII 절대 안 박기. hash 또는 ID 만.

사고 6: Sampling 의 함정

원인 — 데이터 많은 property 의 보고서가 sampling 으로 정확도 ↓.

해결 — BigQuery query = sampling 없음 (raw data). 중요 분석은 BQ.

운영 권장 패턴

Pattern 1: 표준 셋업 — 신규 회사

1. GA4 Account · Property 생성
2. Data Stream (Web + iOS + Android 통합)
3. GTM 컨테이너 통합 (한 곳에서 모든 tag)
4. BigQuery export 활성화 (무료 + raw data)
5. 핵심 conversion event 정의 (signup · purchase · ...)
6. Audience 정의 (VIP · 광고 retargeting · 마케팅 export)

Pattern 2: Event Naming 표준

event_naming:
  format: snake_case
  pattern: verb_noun (예: product_viewed, checkout_completed)
  recommended_events:
    e_commerce:
      - view_item · add_to_cart · begin_checkout · purchase · refund
    engagement:
      - signup_completed · login · subscription_started

custom_event:
  - 명확한 비즈니스 의미만
  - 표준 event 와 중복 X
  - 일관 property 구조

Pattern 3: Privacy-first 통합

사용자 진입 → Cookie consent (Cookiebot 등)
   ↓ 동의 거부:
   GA 추적 OFF · gtag 호출 X

   ↓ 동의:
   GA4 초기화 + tracking 시작
   anonymize_ip 활성
   ad_storage · analytics_storage consent 명시

Pattern 4: BigQuery export + 우리 BI

GA4 → BigQuery (raw event)
   ↓
[우리 BI]
  - Looker · Looker Studio
  - Tableau · Power BI
  - Custom dashboard
  - ML 학습 데이터

Statsig 6편 WHN · Braze 5편 Currents 와 같은 데이터 통제 패턴. GA4 는 무료 라 더 매력적.

Pattern 5: 광고 통합

GA4 audience → Google Ads (retargeting · lookalike)
GA4 conversion → Google Ads (입찰 최적화)
GA4 + Search Console (SEO 분석)
GA4 + YouTube (영상 광고 효과)

GA4 의 가장 큰 차별 — Google 광고 ecosystem 깊은 통합.

시험 직전 한 번 더 — GA4 입문 함정 압축 노트

• GA = web/app 분석의 무료 표준
• Google 무료 제공 + 광고 ecosystem 깊은 통합
• 3 학습 path = Beginners · Marketing/Analyst · Developers
• GA4 vs UA 큰 변화 — Session → Event 기반
• UA = 2023.7.1 sunset
• GA4 차이 — 앱+웹 통합 · Conversion event toggle · 50+ Custom Dimension · BigQuery 무료 · 14개월 retention
• 계층 3 단 = Account · Property · Data Stream
• Property = 분석 단위 (서비스/브랜드)
• Data Stream = Web · iOS · Android 의 entry point
• Measurement ID = Stream 의 ID (G-XXXXXXXX, Web)
• Event 기반 모델 — 모든 게 event (page_view · click · purchase · screen_view)
• 자동 수집 event = page_view · session_start · scroll · click · file_download · video · form
• Recommended Event = 업종별 (e-commerce · travel · gaming)
• Custom Event = 자유 정의
• Event Parameter = 표준 + custom
• User Property = 사용자 상태 (event 아님)
• 4 측정 방법:
• gtag.js — 직접 (단순)
• GTM — Tag Manager (마케터 자율 · 권장)
• Firebase SDK — 모바일 (iOS · Android)
• Measurement Protocol — Server-side
• 대부분 운영 = GTM (web) + Firebase (app) + MP (server) 조합
• Conversion — 비즈니스 가치 event (toggle)
• Audience — 사용자 segment (광고 retargeting · 마케팅 export)
• Reports = 표준 보고서 · Explorations = 커스텀 분석
• Explorations 종류 — Free-form · Funnel · Path · Segment overlap · User explorer · Cohort
• 개발자 도구 = Data API (조회) · Admin API (관리) · Measurement Protocol · BigQuery
• BigQuery export = GA4 무료 표준 (UA 시대 GA 360 유료)
• 경쟁 도구 위치:
• GA4 = 기본 분석 + 광고 통합
• Mixpanel/Amplitude = product analytics 깊이
• Adobe = enterprise
• Statsig = 실험 + 분석 + Flag 통합
• PostHog = open-source
• Heap = auto-capture
• 대부분 운영 = GA4 + 다른 도구 결합
• 도입 시그널 — 거의 모든 회사 (무료 + 표준)
• 사고 — UA 코드 잔존 · Property 너무 많음 · cookie consent 누락 · retention 만료 · PII 박기 · sampling
• 패턴 — 표준 셋업 (Account → Property → Stream → GTM → BQ → conversion)
• 패턴 — Event Naming 표준 (snake_case · verb_noun)
• 패턴 — Privacy-first (cookie consent · anonymize_ip · consent mode)
• 패턴 — BigQuery + 우리 BI 통합
• 패턴 — 광고 통합 (Google Ads · Search Console · YouTube)

공식 문서: Google Analytics Developers 에서 원문을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

다음 글:

• 2편 — 데이터 모델 깊이 · User ID · Session · Custom Dimension
• 3편 — 측정 통합 4 방법 깊이 (gtag · GTM · Firebase · MP)
• 4편 — Event · Conversion · Audience 설계 깊이
• 5편 — Data API · Admin API · 외부 통합 깊이
• 6편 — BigQuery Export 깊이 (schema · UNNEST · 비용)