GA 입문 2편 — 데이터 모델 깊이 · User ID · Session · Custom Dimension

이 글은 Google Analytics 입문에서 운영까지 시리즈 2편이에요. 1편 의 큰 그림 다음 — 데이터 단위까지의 깊이. 1편에서 event 기반 모델 · 4 측정 방법 봤다면, 2편은 어떻게 사용자를 식별하고 · 세션을 정의하고 · custom 데이터를 박는지.

이번 글의 범위

1편에서 "같은 사용자가 web + iOS + Android 통합 추적" 이 GA4 의 큰 강점이라 했어요. 어떻게 그게 되는지의 깊이가 2편. 한 마디로 — 식별 + 한도 + privacy 의 3 축.

GA4 데이터 모델 — 큰 그림

[사용자] (정체 식별)
   ↓
   Client ID + User ID + Google Signal
   ↓
[Session] (활동 시간 단위)
   ↓
   30분 timeout · engaged session
   ↓
[Event] (각 행동)
   ↓
   event_name + event_params
   ↓
[Parameters · User Properties]
   ↓
   한도 + cardinality 통제
   ↓
[Custom Dimension / Metric] (보고서·분석 단위)

각 layer 의 함정 이 다음 layer 에 영향. 처음부터 잘 잡는 게 6개월 후의 모든 분석 품질을 결정. 여기서 cardinality (한 dimension 의 unique 값 개수) 라는 단어가 계속 나오는데, 뒤에서 다시 풀어요.

User 식별 — 3 Layer

GA4 의 사용자 식별 이 3 layer 의 결합. 각 layer 가 다른 신뢰도 · 다른 cross-device 범위.

Layer 1: Client ID — 자동 부여

Client ID = 브라우저 · 디바이스 별 unique ID. cookie 또는 localStorage 에 저장.

사용자 첫 방문 → Client ID 자동 생성 (UUID 형식)
  → cookie `_ga=GA1.1.xxx.xxx` 에 저장
  → 같은 브라우저 다음 방문 = 같은 Client ID

UUID (Universally Unique Identifier, 충돌 거의 없는 ID 표준) 형식으로 발급되는 게 포인트.

한계 — cookie 삭제 하면 새 Client ID 가 발급돼 다른 사용자로 인식되고, Incognito · Private 모드 도 매번 새로 발급돼요. 다른 디바이스 (PC ↔ 모바일) 끼리는 당연히 다른 ID 고, 같은 디바이스라도 다른 브라우저 면 역시 다른 ID. → Client ID 만으로는 cross-device 추적 어려움.

Layer 2: User ID — 로그인 사용자

User ID 를 GA 로 전송 = 여러 세션 · 기기 · 플랫폼에서 사용자 행동 연결. — 공식 docs

User ID = 우리 시스템의 로그인 사용자 ID. 우리가 명시 박음.

// 사용자 로그인 시점
gtag('config', 'G-XXXXXXXX', {
  user_id: 'user-12345'    // 우리 DB user.id
});

// 또는 이미 초기화 된 후
gtag('set', { user_id: 'user-12345' });

효과 — 같은 user_id 가 여러 디바이스 에서 로그인 시 → cross-device 통합 추적.

사용자 김철수:
  - 노트북 (Client ID A) + 로그인 → user_id="user-123"
  - 회사 PC (Client ID B) + 로그인 → user_id="user-123"
  - iPhone 앱 (App Instance ID C) + 로그인 → user_id="user-123"
  → GA4 가 *한 사용자* 로 통합

User ID 의 함정 — 4가지

함정 1: User ID 를 Custom Dimension 으로 박지 X

User ID 기반으로 Custom Dimension 설정 X. 고유 값 너무 많아져 데이터 정확성 손상. — 공식 docs

왜 — Custom Dimension 은 cardinality 통제 가 필수. user_id 박으면 값이 사용자 수만큼 → 폭증.

해결 — User ID 는 GA 표준 식별자. 별도 dimension X.

함정 2: 로그아웃 시 null 정확히

// ✓ 로그아웃 시 정확
gtag('set', { user_id: null });

// ✗ 잘못된 값
gtag('set', { user_id: '' });          // 빈 문자열
gtag('set', { user_id: 'null' });      // 문자열 "null"
gtag('set', { user_id: undefined });   // undefined

null 만 명시 권장. 다른 값 = User ID 가 그 값 으로 박힘 (모든 익명 사용자가 같은 ID = 한 사용자로 인식).

함정 3: PII 박지 X

✗ user_id: "user@example.com"       (이메일 = PII)
✗ user_id: "010-1234-5678"          (전화 = PII)
✗ user_id: "주민번호..."              (절대 금지)

✓ user_id: "user-12345"              (DB 의 unique ID)
✓ user_id: "550e8400-e29b-41d4..."   (UUID)
✓ user_id: sha256("user@email.com") (hash)

여기서 PII (Personally Identifiable Information, 개인식별정보) 가 처음 나오는데, 뒤 PII 정책 절에서 깊이 봐요.

Braze 3편 External ID 보안 · Statsig 의 user identifier 와 같은 원칙.

함정 4: 일관성 — 모든 환경 같은 ID

Web 에서:    user_id = "user-12345"
iOS 에서:    user_id = "user_12345"   (언더바)
Android:    user_id = "12345"        (prefix 없음)
→ 3 명의 다른 사용자로 인식

Braze 3편 user factory 함수 와 같은 패턴 — user ID normalization 통일.

Layer 3: Google Signal — Google 로그인 활용

Google Signal = Google 계정 로그인 + 광고 개인 맞춤 활성화 사용자의 cross-device 자동 추적.

사용자가 Chrome · Google 검색 · YouTube · Gmail 등에서
  Google 계정 로그인 상태
  + "광고 개인 맞춤" 동의함
  → Google 이 이 사용자 cross-device 통합 인식
  → GA4 에 통합 데이터 제공

효과 — User ID 없이도 (anonymous user) cross-device 통합이 가능하고, 광고 ROI 정확도가 올라가요. 거기에 demographic 데이터 (연령 · 성별 · 관심사) 까지 같이 들어옵니다.

활성 방법:

GA4 console → Admin → Property settings → Data settings → Data collection
→ "Google signals data collection" 활성화

3 Layer 의 결합

가장 강력한 cross-device 추적:
  Client ID (브라우저 단위) +
  User ID (로그인 사용자) +
  Google Signal (Google 로그인) +
  Device ID (Firebase, 앱)
  ↓
  GA4 의 통합 user identity

대부분 큰 회사 = 3 layer 모두 활성. 적절한 cross-device 추적 + 사용자 분석.

Session — UA 와 큰 차이

여기서 UA (Universal Analytics, GA4 이전 세대 GA) 가 처음 나와요. 이후로는 UA 로만 표기.

Session 정의

Session = 사용자가 사이트 · 앱에 active 한 시간 단위. 연속 활동 의 묶음.

기본 규칙

1. session_start event 가 새 session 시작
2. 30분 동안 활동 없으면 session 자동 종료
3. 자정 (timezone 기준) 에 강제 종료
4. UTM 파라미터 변경 = 새 session (옵션)

UA 와 다른 자리 — 함정

UA 시대의 session 정의 와 GA4 가 조금씩 다름:

→ UA 시대 보고서 와 GA4 보고서의 session 수가 다를 수밖에. 추세만 비교, 절대 수 비교 X.

Engaged Session — GA4 신규

Engaged Session = 진짜 의미 있는 session 만 카운트:

조건 (다음 중 하나 이상):
  - 세션이 10초 이상 지속
  - conversion event 발생
  - 2개+ 페이지뷰

이유 — UA 시대 bounce rate 가 "1 페이지만 보고 떠난 사용자" 정의가 단순했어요. GA4 의 engaged session = 진짜 engagement 측정 위한 더 엄격한 정의.

Bounce Rate 정의 변화

UA 의 bounce rate:
  = 1 페이지만 본 세션 비율

GA4 의 bounce rate:
  = (전체 session - engaged session) / 전체 session
  = engaged session 의 반대 비율

UA 의 bounce rate 30% 가 GA4 에서 보면 다를 수 있음. 정의 자체가 다름.

Cross-domain Session

사용자가 site-a.com 에서 site-b.com 로 이동
  → UA: 별도 session (다른 사이트 인식)
  → GA4 + cross-domain 설정: 같은 session 유지

설정 = console → Data Streams → web stream → Configure cross-domain measurement 에 도메인 list 추가.

대표 사용은 마케팅 사이트 + 본 서비스 (다른 도메인) 조합, 결제 partner 의 redirect 사이트, 그리고 subdomain (보통 자동, 다른 도메인은 명시 필요) 정도예요.

Event Parameter 한도

각 event 의 parameter (속성) 한도가 있어요. 운영 환경에서 모르면 사고.

한도 정리

이벤트 1개당:
  - parameter 최대: 25개
  - parameter name 길이: 40 자 (영문)
  - parameter value 길이: 100 자 (영문)

User Property:
  - property 최대: 25개
  - property name 길이: 24 자
  - property value 길이: 36 자

Event Name:
  - 최대 길이: 40 자
  - 영문 + 숫자 + 언더바 (snake_case)

여기서 시험 함정이 하나 있어요 — 값 길이 초과 시 자동 절단. 100자 초과 = 처음 100자만 박힘. 긴 URL · 메시지 박으면 예상 못한 잘림.

자동 수집 Parameter

GA4 가 모든 event 에 자동 부여:

모든 event 자동:
  - language       (브라우저 언어)
  - page_location  (URL)
  - page_referrer  (referrer URL)
  - page_title     (페이지 타이틀)
  - screen_resolution

수동 박을 필요 없음. 우리 custom parameter 만 박기.

Recommended Event 의 표준 Parameter

// purchase event 의 표준 parameter
gtag('event', 'purchase', {
  transaction_id: 'T-12345',
  value: 50000,
  currency: 'KRW',
  tax: 5000,
  shipping: 3000,
  items: [
    {
      item_id: 'P-1',
      item_name: '여름 원피스',
      category: 'dress',
      price: 50000,
      quantity: 1
    }
  ]
});

업종별 권장 parameter 사용 = 자동 보고서 풍부. 표준 e-commerce funnel 자동 생성.

Custom Dimension / Metric — 깊이

정의

• Custom Dimension = 문자 분류 (값이 카테고리)
• Custom Metric = 숫자 측정 (값이 정량)

Custom Dimension 예:
  - user_tier ("free" / "premium" / "enterprise")
  - article_category ("tech" / "lifestyle" / "news")
  - login_method ("email" / "kakao" / "google")

Custom Metric 예:
  - cart_value (결제 금액)
  - page_load_time (성능)
  - article_word_count

Scope 3 종 — 가장 중요한 자리

여기가 시험 함정 자리. Custom Dimension/Metric 은 3 scope 중 하나 선택. 잘못 선택 = 회복 어려움:

Event scope — 한 사용자가 여러 article 조회 하면 각 event 의 article_category 다름. 보고서 = article 별 group by.

User scope — 사용자 tier 는 해당 사용자의 모든 event 에 적용. tier 가 바뀌면 future event 만 새 tier (과거 event 의 tier 변경 X).

Item scope — e-commerce 의 상품 array 안 dimension. 한 결제에 여러 상품 의 각자 다른 brand.

Scope 결정 가이드

"한 사용자가 시간에 따라 값이 바뀌는 attribute?"
  Yes → User scope (tier · subscription_state)

"같은 사용자도 event 마다 값이 다른 attribute?"
  Yes → Event scope (article_id · search_query)

"상품 array 안의 attribute?"
  Yes → Item scope

Cardinality 함정 — 가장 큰 위험

Cardinality = 한 dimension 의 unique 값 개수. GA4 의 한도:

한 property 안:
  - Custom Dimension 최대: 50개 (Event scope) + 25개 (User scope) + 10개 (Item scope)
  - 각 dimension 의 unique 값: 권장 50,000 미만

고 cardinality 의 위험:

✗ user_id 를 dimension 으로            (값 = 사용자 수, 수백만+)
✗ session_id 를 dimension 으로         (값 = 세션 수, 무한)
✗ product_id 를 user-scope dimension (값 = 상품 × 사용자)
✗ search_query 를 dimension          (자유 입력, 무한)

Cardinality 초과 시 GA4 동작:

값이 50K 초과:
  → 상위 N 만 명시 표시
  → 나머지 = "(other)" 로 통합
  → 분석 정확도 ↓

→ 분류 가능한 카테고리만 dimension. 고유 값은 Event parameter 로만 (BigQuery 에서 raw 조회).

Statsig · Braze 의 cardinality 통제 원칙 과 같음. 모든 analytics 도구의 공통 원칙.

활용 예제

// User scope — 로그인 시
gtag('set', 'user_properties', {
  user_tier: 'premium',
  signup_year: 2025,
  country: 'KR'
});

// Event scope — 페이지뷰 시
gtag('event', 'page_view', {
  article_category: 'tech',
  article_author: 'Kim'
});

// Item scope — 결제 시
gtag('event', 'purchase', {
  transaction_id: 'T-1',
  value: 50000,
  items: [
    {
      item_id: 'P-1',
      item_name: '...',
      // Item scope dimension
      brand: 'Nike',
      color: 'red',
      size: 'L'
    }
  ]
});

PII 정책 — 절대 박으면 안 되는 것

GA4 의 PII (개인식별정보) 금지 정책. 위반 = property 정지 위험.

절대 X

- 이메일 (full email)
- 전화번호
- 주민등록번호 · SSN
- 실명 · 주소 · 신용카드번호
- 정확한 위도/경도
- IP 주소 (anonymize_ip 자동 처리 — 단 수동 박지 X)

박는다면 — Hash 필수

// 이메일 hash
const hashedEmail = sha256(user.email);
gtag('set', { user_id: hashedEmail });

PII 의 raw 박지 말고 hash. 단 진짜 hash 가 unique 식별 가능 하면 PII 여전 → PII 의 한계는 회피 어려움.

Anonymize IP

GA4 = IP anonymization 자동 (UA 시대 명시 옵션이었던 게 기본 활성).

실제 IP: 1.2.3.4
GA4 처리: 1.2.3.0 (마지막 옥텟 0)

위반 시 처벌

GA 가 PII 추적을 잡아내면 경고 또는 정지가 떨어지고, 사용자가 GDPR (EU 개인정보보호 규정) 위반으로 신고하면 큰 벌금 (EU 매출 4%) 까지 갈 수 있어요. 거기에 신뢰 손실까지. → PII 추적 안 하는 게 기본 원칙. 의도하지 않은 누설도 검토.

Consent Mode — Cookieless 미래

Cookie 의 종말

Safari · Firefox: 이미 third-party cookie 차단
Chrome: 2024 ~ 진행 중 (Privacy Sandbox)
EU/UK: GDPR · ePrivacy 강화

여기 Privacy Sandbox (Chrome 의 cookie 대체 광고 측정 프레임워크) 와 ePrivacy (EU 의 전자통신 사생활 지침) 가 함께 나와요. Cookie 의존 의 GA4 가 어떻게 대응 하는가의 자리.

Consent Mode 의 의미

Consent Mode = 사용자 동의 상태를 GA4 에 명시 전달. 동의 거부 시도 cookieless 측정 활성.

// 기본 — 동의 안 받은 상태 (default)
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied'
});

// 사용자가 동의 후
gtag('consent', 'update', {
  'analytics_storage': 'granted',
  'ad_storage': 'denied'   // analytics 만 동의
});

Consent Mode 의 효과

[동의 받음]: 일반 GA4 추적 (cookie 기반)
[동의 거부]: cookieless ping
  → User ID 없는 hit
  → Google 의 *modeling* 으로 일부 데이터 추정
  → Conversion 보고서는 어느 정도 정확도 유지

modeling 의 의미 — 동의 거부 사용자의 행동 을 동의 받은 사용자의 패턴 기반 으로 통계적 추정. 100% 정확 X but 보고서가 비어 보이지 않음.

통합 — Cookie Banner

[사용자 진입]
   ↓
[Consent Mode default 설정] (모든 거부)
   ↓
[Cookie Banner 표시] (Cookiebot · OneTrust 등)
   ↓
[사용자 선택]:
   동의 → consent update (granted)
   거부 → consent 유지 (denied · cookieless)

대부분 큰 회사 = Cookie Banner + Consent Mode 결합. GDPR 준수 + 가능한 데이터 수집 최대화.

자주 만나는 사고 — 데이터 모델

사고 1: User ID 부정확

원인 — Web 에서는 user.id, iOS 에서는 user.email 박음.

해결 — 모든 환경 같은 normalization. 우리 DB 의 표준 ID 통일.

사고 2: User ID 를 Custom Dimension 으로

원인 — "사용자별 분석 하고 싶어서" User ID 를 Dimension 으로 설정.

해결 — 공식 user_id 만. 별도 Custom Dimension 절대 X (cardinality 폭증).

사고 3: Logout 시 user_id 빈 문자열

원인 — gtag('set', { user_id: '' }).

해결 — null 정확히 명시. 빈 문자열 = "" 사용자로 인식.

사고 4: Custom Dimension scope 잘못

원인 — user_tier 를 Event scope 로 설정. 사용자 tier 가 event 마다 박혀야 보고서 정확.

해결 — User scope 사용. tier 변경 시 future event 만 영향.

사고 5: Cardinality 폭증

원인 — search_query 를 dimension 으로 → 자유 입력 = 무한 unique.

해결 — 카테고리 dimension 만. 자유 입력 = parameter 로만 (BigQuery query 용).

사고 6: PII 누설

원인 — user_email 을 user property 로.

해결 — 절대 X. 이메일은 hash 또는 별도 시스템.

사고 7: Consent Mode 빠뜨림

원인 — GDPR/KISA (한국 인터넷진흥원) 환경 + Consent Mode 미설정 → 동의 안 받은 사용자도 raw cookie 추적.

해결 — default = denied 설정 + cookie banner 통합.

사고 8: Cross-domain 미설정

원인 — site-a.com → site-b.com 이동 = 다른 session 인식.

해결 — Data Stream → cross-domain 에 도메인 list 추가.

사고 9: Session timeout 부적절

원인 — 30분 default 가 우리 비즈니스 와 안 맞음 (예: 긴 video 사이트).

해결 — Data Stream 설정 에서 timeout 변경 (1~480분).

운영 권장 패턴

Pattern 1: User Identity 표준 설정

// utils/ga.js
export function syncUserToGA(user) {
  // User ID 박기 (PII 아닌 ID)
  gtag('set', { user_id: user.id });

  // User Property 일관
  gtag('set', 'user_properties', {
    user_tier: user.tier,           // 분류 가능 (cardinality 낮음)
    signup_year: user.signupYear,    // 분류 가능
    country: user.country,           // 분류 가능
    language: user.language          // 분류 가능
  });

  // PII 절대 X
  // ✗ gtag('set', 'user_properties', { user_email: user.email });
}

export function clearUserFromGA() {
  gtag('set', { user_id: null });
}

Braze user factory · Statsig user object 와 같은 일관성 패턴.

Pattern 2: Custom Dimension 설계 표준

custom_dimensions:
  user_scope:
    - user_tier         # free / premium / enterprise
    - signup_year       # 2024 / 2025 / 2026
    - country           # KR / JP / US / ...
    - language          # ko / en / ja

  event_scope:
    - article_category  # tech / lifestyle / news
    - article_author    # author name (limited)
    - source_campaign   # marketing campaign ID (controlled)

  item_scope:
    - brand
    - color
    - size

cardinality_rules:
  - 각 dimension 의 unique 값 < 1,000 권장 (50K 한도이지만 안전 마진)
  - 자유 입력 (search query 등) = parameter 로만, dimension X
  - User ID · Session ID · Product ID 절대 dimension X

Pattern 3: Consent Mode 통합

<!-- 1. 페이지 로드 시 default = denied -->
<script>
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied'
  });
</script>

<!-- 2. Cookie banner 표시 (Cookiebot 등) -->
<script
  src="https://consent.cookiebot.com/uc.js"
  data-cbid="YOUR-ID"
  type="text/javascript"
  async>
</script>

<!-- 3. 사용자 동의 시 update -->
<script>
  window.addEventListener('CookiebotOnAccept', function() {
    gtag('consent', 'update', {
      analytics_storage: Cookiebot.consent.statistics ? 'granted' : 'denied',
      ad_storage: Cookiebot.consent.marketing ? 'granted' : 'denied'
    });
  });
</script>

GDPR · KISA 준수 + 데이터 수집 최대화.

Pattern 4: 환경별 Property 분리

const PROPERTY_ID = process.env.NODE_ENV === 'production'
  ? 'G-PROD-XXXXX'
  : 'G-DEV-YYYYY';

gtag('config', PROPERTY_ID);

dev/staging/prod 별 별도 GA4 property. production 데이터 오염 방지.

Pattern 5: BigQuery → 깊은 분석

-- High cardinality 데이터 분석 (search query · product_id)
SELECT
    event_name,
    -- raw parameter 직접 조회 (dimension cardinality 제한 회피)
    (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'search_query') AS query,
    COUNT(*) AS searches
FROM `project.analytics_XXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260501' AND '20260517'
  AND event_name = 'search'
GROUP BY 1, 2
ORDER BY searches DESC
LIMIT 100

GA4 dashboard 의 50K cardinality 한도 회피. raw event 직접 query.

시험 직전 한 번 더 — GA4 데이터 모델 함정 압축 노트

User 식별 3 Layer

• Client ID — cookie 기반 (브라우저 단위, 자동)
• User ID — 우리 시스템 로그인 ID (cross-device)
• Google Signal — Google 계정 로그인 + 광고 동의 (자동 cross-device)
• 3 layer 결합 = 가장 강력한 통합 추적

User ID 함정 4종

• Custom Dimension 으로 박지 X (cardinality 폭증)
• 로그아웃 시 null 정확히 (빈 문자열·"null" 문자열 X)
• PII 박지 X (이메일·전화 X, hash 만)
• 모든 환경 같은 normalization (Web · iOS · Android 통일)

Google Signal

• console → Property settings → Data settings 에서 활성
• 광고 ROI 정확도 ↑ · demographic 데이터

Session 정의

• 30분 timeout (변경 가능 1~480분)
• 자정 reset (timezone 기준)
• UTM 변경 = 새 session (옵션)
• Cross-domain = 명시 설정
• UA 시대 보고서와 직접 비교 X (정의 다름)

Engaged Session

• 10초+ 지속 OR 2 page+ OR conversion
• GA4 의 진짜 engagement 측정
• Bounce rate = (전체 - engaged) / 전체

Event Parameter 한도

• event 1개 = parameter 최대 25개
• parameter name 40자 · value 100자
• User Property = 25개 · name 24자 · value 36자
• Event Name = 40자
• 초과 시 자동 절단

Custom Dimension / Metric — 3 Scope

• Event scope = event 별 (article_category · search_query)
• User scope = 사용자 전체 (tier · signup_year)
• Item scope = 상품 array (brand · color · size)
• 한도 = Event 50 · User 25 · Item 10
• Scope 잘못 = 회복 어려움 (User → Event 불가)

Cardinality 함정

• dimension unique 값 < 50K 권장
• 초과 = "(other)" 통합 · 분석 정확도 ↓
• user_id · session_id · product_id 절대 dimension X
• 자유 입력 (search · URL) = parameter 로만
• BigQuery 에서 raw query 가능

Recommended Event 표준 Parameter

• e-commerce: transaction_id · value · currency · items[] (brand · color · size)
• 표준 사용 = 자동 보고서 풍부

PII 정책

• 절대 X = email · phone · 주민번호 · 신용카드 · 정확 위치 · IP
• Hash 도 unique 식별 가능 = PII 여전
• 위반 = property 정지 · GDPR 벌금
• IP anonymization = GA4 자동 (UA 시대 옵션이었음)

Consent Mode (cookieless 미래)

• Cookie 의 종말 (Safari · Firefox · Chrome Privacy Sandbox · GDPR)
• default = denied (page load 즉시)
• update = granted (cookie banner 동의 후)
• denied 사용자도 cookieless ping + modeling 추정
• ad_storage · analytics_storage · ad_user_data · ad_personalization 4 동의

사고

• User ID 부정확 (normalization 불일치)
• User ID 를 Custom Dimension 으로 (cardinality 폭증)
• Logout 시 빈 문자열 (null 정확히)
• Custom Dimension scope 잘못 (Event vs User vs Item)
• Cardinality 폭증 (자유 입력 dimension)
• PII 누설 (이메일 박기)
• Consent Mode 빠뜨림 (GDPR 위반)
• Cross-domain 미설정
• Session timeout 부적절

운영 패턴

• User Identity 표준 함수 (PII 회피 + 일관)
• Custom Dimension 설계 표준 (scope · cardinality 룰)
• Consent Mode 통합 (default denied → 동의 후 update)
• 환경별 Property 분리 (dev/staging/prod)
• BigQuery 로 high cardinality raw query

공식 문서: GA4 User ID · Event Parameters 에서 원문을 확인할 수 있어요.

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

이전 글:

• 1편 — GA4 종합 · Event 기반 · 4 측정 방법

다음 글:

• 3편 — 측정 통합 4 방법 깊이 (gtag · GTM · Firebase · MP)
• 4편 — Event · Conversion · Audience 설계 깊이
• 5편 — Data API · Admin API · 외부 통합 깊이
• 6편 — BigQuery Export 깊이 (schema · UNNEST · 비용)
• 7편 — Reports · Explorations · Attribution 깊이