Kwangmin Kim - Randomization Unit vs Analysis Unit

1 정의

정의: Randomization Unit ↔︎ Analysis Unit 의 관계

실험 설계 시 두 단위의 관계는 분석 가능성과 통계적 정확성을 동시에 결정한다 (Kohavi, Tang, Xu, 2020, Ch.14.1).

관계	분석	권장
Randomization = Analysis	표준 t-test, i.i.d. 가정 직접 hold	가장 안전, 권장
Randomization coarser than Analysis	Bootstrap, delta method 필요	가능, 추가 작업
Randomization finer than Analysis	User-level metric 의 의미 깨짐	사용 불가

원문 (Ch.14.1): “Generally, we recommend that the randomization unit be the same as (or coarser than) the analysis unit in the metrics you care about.”

핵심 통찰: User-level randomization 은 거의 모든 metric 분석 가능 (bootstrap·delta method 추가 하면 fine metric 도 가능). Page-level randomization 은 user-level metric 분석 불가. 따라서 유연성을 위해 user-level 이 default.

2 개념 및 원리

2.1 Randomization Unit ↔︎ Analysis Unit 매칭

2.1.1 Case 1 — Randomization = Analysis (표준)

저자 명시: “It is easier to correctly compute the variance of the metrics when the analysis unit is the same as the randomization unit, because the independence assumption between units is reasonable in practice.”

2.1.1.1 예시 — Page-level Randomization + Page-level Analysis

실험 설계:
  Randomization unit: page
  Metric: click-through rate (clicks / pageviews) = page-level

분석:
  - 각 page 가 하나의 sample
  - Page 간 i.i.d. 가정 hold (실험 design 자체 보장)
  - Click 의 평균 = 표준 binomial proportion
  - Variance = p(1-p)/N (표준 공식)
  - Two-sample test 직접 적용

장점: 분석 단순, 정확

2.1.1.2 예시 — User-level Randomization + User-level Analysis

실험 설계:
  Randomization unit: user
  Metric: sessions-per-user = user-level

분석:
  - 각 user 가 하나의 sample
  - User 간 i.i.d. 가정 hold
  - User 의 sessions count 분포 → 평균·variance 표준
  - t-test 직접 적용

장점: 분석 단순, 정확, 일관 user experience

2.1.2 Case 2 — Coarser Randomization, Finer Analysis (Bootstrap·Delta Method)

저자 강조: “Having the randomization unit be coarser than the analysis unit, such as randomizing by user and analyzing the click-through rate (by page), will work, but requires more nuanced analyses methods such as bootstrap or the delta method.”

2.1.2.1 예시 — User-level Randomization + Page-level CTR Analysis

실험 설계:
  Randomization unit: user
  Metric: CTR = total clicks / total pageviews (page-level ratio)

분석의 challenge:
  - 같은 user 의 pageviews 가 correlated (i.i.d. 위반 in page-level)
  - 표준 variance 공식 사용 불가
  - User 간 pageview 수 다름 → ratio 의 variance 가 user 간 분포 의존

해결 1 — Delta Method:
  CTR = X / Y (X=clicks, Y=pageviews, both user-level)
  Variance(X/Y) ≈ (1/μY)² × [Var(X) + (μX/μY)² × Var(Y) - 2(μX/μY) × Cov(X,Y)]

해결 2 — Bootstrap:
  - User-level resample (with replacement)
  - 각 resample 에서 CTR 계산
  - 1000 resamples 의 분포 → empirical variance

저자 인용 (Deng et al. 2017, Deng, Knoblich and Lu 2018, Tang et al. 2010, Deng et al. 2011): 이 방법론들이 산업 분석의 표준.

2.1.2.2 Delta Method 의 메커니즘

가정: CTR = X / Y where X=clicks per user, Y=pageviews per user

Standard error of ratio:
SE(X/Y) = (1/Y_mean) × sqrt(Var(X) + (X_mean/Y_mean)² × Var(Y)
                              - 2(X_mean/Y_mean) × Cov(X,Y))

이 공식이 ratio 의 variance 를 정확 추정. 근본적으로 first-order Taylor expansion 의 결과.

2.1.2.3 Bootstrap 의 메커니즘

1. User pool 에서 N users 의 random sample (with replacement)
2. 이 sample 의 CTR 계산
3. 1~2 를 1000 회 반복
4. CTR 의 1000 개 값 의 분포 → empirical 95% CI

장점: 분포 가정 없음
단점: 계산 비용 큼 (1000 × 분석)

2.1.2.4 Bot 의 영향

저자 강조: “the experiment results can be skewed by bots that use a single user ID, e.g., a bot that has 10,000 pageviews all done using the same user ID.”

시나리오:
  10,000 user (정상): 각 100 pageviews
  1 bot user: 10,000 pageviews (정상 user 의 100 배)

CTR 분석 (page-level):
  Bot 이 전체 pageview 의 ~5% 차지
  Bot 의 click 행동이 결과 왜곡

해결 (저자 명시):
1. Bound contribution:
   - 각 user 의 max pageview 를 cap (예: 1000/day)
   - Bot 의 영향 제한

2. User-based metric:
   - "Average CTR per user" (각 user 의 CTR 평균)
   - Bot 의 단일 user 효과 ↓
   - User 간 균등 weight

2.1.2.5 CTR-per-User 의 메커니즘

일반 CTR (page-level):
  CTR = total_clicks / total_pageviews
  Bot 영향: bot 의 click·pageview 가 numerator·denominator 에 다 영향

CTR-per-user:
  Per-user CTR = user_clicks / user_pageviews
  Total CTR = mean(per-user CTR across users)
  Bot 영향: bot 도 1 user 으로 weight (다른 user 와 equal)
  Bot 의 상대적 영향 → 1 / N

이 차이가 robust analysis 의 핵심. Per-user metric 이 outlier 에 더 robust.

2.1.3 Case 3 — Finer Randomization, Coarser Analysis (불가능)

저자 강조: “Conversely, when the metrics are computed at the user-level (e.g., sessions-per-user or revenue-per-user) and the randomization is at a finer granularity (i.e., page-level), the user’s experience likely contains a mix of variants.”

2.1.3.1 예시 — Page-level Randomization + Sessions-per-User Analysis

실험 설계:
  Randomization unit: page
  Metric: sessions-per-user

문제:
  Alice 의 page 1: variant A
  Alice 의 page 2: variant B
  Alice 의 page 3: variant A
  ...
  Alice 가 어느 variant 의 효과인가?
  → Alice 의 session count 가 어느 variant 의 효과인가?
  → 답: 둘 다 (mix)

분석 결과:
  Treatment 의 user 의 session: A·B mix 의 합
  Control 의 user 의 session: A·B mix 의 합
  → 두 그룹의 차이 = 0 (분석 의미 없음)

이 case 가 randomization unit 선택의 hard constraint. User-level metric 사용 시 fine randomization 절대 불가.

가정 — Bot 의 outlier effect 무시 시

가정: Bot 의 영향을 무시하고 page-level CTR 분석.

2.1.3.2 시나리오

정상 user 1000 명: 각 100 pageviews, 5% click rate
1 bot: 100,000 pageviews, 0% click rate (page 만 robotically scrape)

Page-level CTR:
  Total clicks: 1000 × 100 × 0.05 = 5,000
  Total pageviews: 1000 × 100 + 100,000 = 200,000
  CTR = 5,000 / 200,000 = 2.5%

Per-user CTR:
  정상 user CTR: 5%
  Bot CTR: 0%
  Mean CTR: (1000 × 5% + 1 × 0%) / 1001 ≈ 5%

차이:
  Page-level: 2.5%
  Per-user: 5%
  Bot 의 영향이 page-level 에서 50% 의 metric 왜곡

2.1.3.3 결과

Treatment effect estimate 왜곡 — Bot 이 Treatment·Control 에 다른 분포로 들어가면 effect 가 bot 행동의 부산물 가능.
False alarm 또는 missed signal — Real effect 가 bot noise 에 묻힘.
분석 신뢰성 위기 — “왜 이 결과? bot 영향?” 의문 반복.

해결:

Bot detection 시스템 (이미 platform 에 있어야)
User-based metric 우선 사용
Bound per-user contribution

이것이 modern A/B platform 의 표준 hardening. Bot 처리는 platform 의 일부 (Ch.4 의 infrastructure).

2.2 User-level Randomization 의 ID 선택

저자 명시 (Ch.14.2): “User-level randomization is the most common as it avoids inconsistent experience for the user and allows for long-term measurement such as user retention.”

2.2.1 3 가지 ID 옵션

2.2.1.1 옵션 1 — Signed-in User ID

저자 명시: “A signed-in user ID or login that users can use across devices and platforms. Signed-in IDs are typically stable not just across platforms, but also longitudinally across time.”

Signed-in ID 의 특성:
  - 사용자가 명시적으로 sign-in
  - Cross-device: 같은 사용자가 desktop, mobile, web 모두 같은 ID
  - Longitudinal stability: 사용자가 계속 sign-in 시 영구
  - 사용자 변경 의지 (account 삭제, 변경): 가능

장점:
  - 가장 stable identifier
  - Long-term retention 측정 정확
  - Cross-platform interaction 분석 가능
  - Family-friendly (한 family 가 다른 account)

단점:
  - 사용자가 sign-in 안 한 경우 (anonymous browsing) ID 없음
  - Sign-up process 의 실험 시 적용 어려움
  - Privacy concerns (login = identification)

2.2.1.2 옵션 2 — Pseudonymous User ID (Cookie, IDFA, AAID)

저자 명시: “A pseudonymous user ID, such as a cookie. On most websites when a user visits, the website writes a cookie containing an identifier (usually mostly random). On mobile devices for native apps, the OS often provides a cookie, such as Apple’s idFA or idFV or Android’s Advertising ID.”

Pseudonymous ID 의 종류:
  - Web cookie (보통 random UUID)
  - Apple IDFA (Identifier for Advertisers)
  - Apple IDFV (Identifier for Vendor) — vendor-specific
  - Android AAID (Android Advertising ID)

특성:
  - Sign-in 없이 device 단위 식별
  - Cross-device 안 됨 (각 device 다른 ID)
  - Browser/OS 통제 가능
    - 사용자가 cookie 삭제
    - Incognito mode 사용
    - iOS App Tracking Transparency (사용자 권한 요청)
    - Browser privacy mode (Safari ITP, Brave 등)

장점:
  - Sign-in 안 한 사용자도 추적
  - 일반적 anonymous browsing 에 적합

단점:
  - 사용자가 cookie 변경/삭제 → ID 변경
  - Longitudinal stability 약함
  - 같은 사용자의 cross-device 행동 분석 어려움

2.2.1.3 iOS ATT 의 영향 (사전지식)

2021 iOS 14.5 의 App Tracking Transparency:
  - 모든 app 이 사용자에 IDFA 사용 권한 요청
  - 사용자의 ~70% 가 거부
  - IDFA 사용률 30% 로 감소

영향:
  - Mobile attribution 약화
  - Cross-app 추적 거의 불가
  - Pseudonymous ID 의 stability ↓
  - Server-side ID (회사 내부) 비중 ↑

이 변화가 modern mobile 분석의 큰 shift. Pseudonymous 의존 platform 은 적응 필요.

2.2.1.4 옵션 3 — Device ID

저자 명시: “A device ID is an immutable ID tied to a specific device. Because it is immutable, these IDs are considered identifiable.”

Device ID 의 특성:
  - Device 의 hardware/serial 기반
  - Immutable (변경 불가)
  - Cross-device 안 됨 (각 device 별 ID)
  - Longitudinal stability 강 (device 사용 동안)

장점:
  - 가장 stable longitudinally (device 단위)
  - Long-term effect 측정 가능 (device 단위)

단점:
  - PII (개인 식별 정보) 분류 가능
  - Privacy 강한 규제 (HIPAA·GDPR 의 personal data)
  - 사용자가 device 변경 시 ID 변경
  - 가족 공유 device 시 multi-user 한 ID

2.2.2 3 가지 ID 의 trade-off

2.2.2.1 Functional Perspective

저자 명시: “From a functional perspective, the main difference between these different IDs is their scope.”

Scope dimensions:
  - Cross-device coverage
  - Longitudinal stability
  - Sign-in 의존성

2.2.2.2 Decision Tree

"Cross-device 일관성 필요?"
  Yes → Signed-in user ID 권장
  No → Continue

"Sign-in process 자체 testing?"
  Yes → Cookie 또는 device ID 필요 (사용자가 sign-in 전)
  No → Signed-in 가능

"Long-term effect 측정 (수개월)?"
  Yes → Signed-in 또는 device ID (longitudinal stability)
  No → Cookie 도 가능

"Privacy 강한 규제 환경?"
  Yes → Pseudonymous ID 우선 (device ID 회피)
  No → Device ID 가능

2.2.2.3 Sign-up Process Experiment 의 사례

저자 명시: “If you are testing a process that cuts across the boundary of a user signing in, such as a new user on-boarding process that includes a user signing in for the first time, then using a cookie or device ID is more effective.”

Onboarding 실험:
  Step 1: 사용자가 처음 visit (sign-in 안 함)
  Step 2: 사용자가 sign-up flow 진행
  Step 3: 첫 sign-in 완료
  Step 4: First experience

Signed-in ID 사용 시:
  Step 1, 2 의 ID 없음 (sign-in 전)
  Step 3 부터 ID 생김
  → Step 1, 2 의 행동 추적 불가
  → Onboarding flow 의 효과 측정 불가

Cookie/Device ID 사용 시:
  Step 1 부터 ID 있음
  Step 3 후 ID 가 user_id 와 매핑
  → 전체 flow 추적
  → Onboarding 효과 측정 가능

2.2.2.4 Long-term Effect 측정의 사례

저자 인용 (Hohnhold et al. 2015): users’ learned response to ads.

Ads 학습 효과:
  사용자가 ads 노출에 점진 학습
  - Day 1: 사용자가 ads 와 organic 결과 잘 구별
  - Day 30: 학습으로 patterns 인지 ↑
  - Day 90: 행동 변화 stable

Pseudonymous ID 사용 시 (cookie):
  사용자가 90 일 동안 cookie 변경 가능
  - Cookie 삭제 → 새 ID
  - Long-term tracking 깨짐
  - 학습 효과 측정 어려움

Signed-in ID 사용 시:
  같은 사용자 → 같은 ID 90 일 유지
  - Long-term tracking 정확
  - 학습 효과 측정 가능

이 사례가 longitudinal stability 의 가치. Long-term experiment 의 필수 조건.

직관 — 3 가지 ID 의 hybrid 사용

대부분 회사가 하나만 사용 안 함. Hybrid 가 표준.

2.2.2.5 Hybrid 패턴

Default:
  사용자가 sign-in 안 함 → cookie/device ID
  사용자가 sign-in 함 → signed-in user ID 로 transition

ID matching:
  Sign-in 시점에 device ID → user ID 매핑 저장
  같은 device 의 future visits 도 user ID 사용 (사용자가 sign-out 해도)

Cross-device aggregation:
  같은 user ID 의 모든 device 의 행동 통합
  Cross-platform 분석 가능

2.2.2.6 매핑 의 challenge

Device → User mapping 의 issue:
  - 가족 공유 device (1 device, multi-user)
  - 같은 user, multi-device
  - Sign-in 변경 (한 device 에서 다른 account 로 switch)

Identity graph:
  - Device 와 user 의 매핑 graph
  - Many-to-many relationships
  - 시간 따라 변경

2.2.2.7 Identity Graph 의 운영 (사전지식)

대형 회사의 identity 운영:

1. Device fingerprinting:
   - Browser, OS, screen, language 의 조합
   - Probabilistic matching

2. Sign-in event tracking:
   - 같은 user 가 다른 device 에서 sign-in
   - Device → user mapping 업데이트

3. Email/Phone matching:
   - 같은 email 의 multi-device 통합
   - Privacy-aware (hashing)

4. Behavioral matching:
   - 비슷한 행동 패턴
   - ML 으로 likely-same-user 추정

이 identity graph 가 modern A/B 분석의 silent infrastructure. 사용자 인지 못 함, but 분석 quality 의 거대한 부분.

2.2.3 IP Address — 비추천

저자 강조: “One final option that we do not recommend unless it is the only option is IP address.”

2.2.3.1 IP 사용의 use case

저자 명시: "IP-based variant assignment may be the only option for infrastructure changes, such
as for comparing latency using one hosting service (or one hosting location) versus another, as
this can often only be controlled at the IP level."

예시:
  - Hosting service A vs B 의 비교
  - CDN edge 의 비교
  - Network routing 변경 실험

2.2.3.2 IP 의 fundamental 문제

저자 강조: “we do not recommend using IP addresses more generally, however, because they vary in granularity.”

2.2.3.3 Granularity 의 양극단

1. 사용자 의 IP 변경:
   - 사용자가 집 (Wi-Fi A) → 직장 (Wi-Fi B) 이동
   - 같은 사용자의 다른 IP
   - 같은 사용자가 다른 variant 받을 수 있음
   - 일관성 깨짐

2. 회사·ISP 의 IP 공유:
   - 대형 회사: 직원 1000+ 명이 1 IP (firewall)
   - 학교·도서관: multi-user
   - 같은 IP 가 multi-user
   - 한 unit 에 다양한 사용자 mix

함의:
  - Statistical power: 너무 적은 unique IPs (firewall)
  - Variance: 너무 높음 (한 IP 의 user 다양성)
  - Skew: 일부 IP 가 거대 (firewall) → outlier
  - Outlier issues: aggregate 큰 unit 의 영향

2.2.3.4 결론 — IP 는 last resort

IP 사용 권고:
  - Infrastructure-only 실험 (unavoidable)
  - User experience 실험에는 절대 회피
  - User experience 실험은 항상 user-level ID

2.2.4 Sub-user Level Randomization — 조건부 허용

저자 명시: “Randomization at a sub-user level is useful only if we are not concerned about carryover or leakage from the same user (see Chapter 22), and the success metrics are also at the sub-user level (e.g. clicks-per-page, not clicks-per-user). It is often chosen in favor of increased power that comes from the increase in sample size.”

2.2.4.1 Sub-user level 의 사용 조건

Sub-user level OK if:
  1. Carryover 없음 — Page 1 의 행동이 Page 2 행동에 영향 안 줌
  2. Leakage 없음 — Variant 들 사이 interference 없음 (Ch.22)
  3. Sub-user metric 만 사용 — clicks-per-page, time-per-page

Sample size 의 advantage:
  Page-level: N = 100 × users
  User-level: N = users
  → 100 배 더 많은 sample
  → Statistical power ↑

2.2.4.2 적용 가능 시나리오

1. Stateless feature:
   - 각 page 가 independent
   - 예: search result ranking (사용자 history 무시 시)

2. Server algorithm 비교:
   - Page rendering algorithm 비교
   - User behavior 와 무관

3. Performance 실험:
   - Page latency 측정
   - 같은 page 의 다른 server 처리

2.2.4.3 적용 불가 시나리오

1. Stateful feature:
   - Personalization, recommendation
   - User history 사용

2. UI 변경:
   - Visual change 가 사용자에 visible
   - Inconsistent variant 시 confusion

3. User-level metric:
   - Retention, LTV, sessions

이 조건 결정이 sub-user randomization 적용의 hard test.

3 왜 필요한가

ID 선택·analysis 매칭 잘못 시.

Variance underestimate — Page-level 분석 의 false confidence
Bot 영향 noise — Outlier 가 결과 왜곡
Long-term tracking 실패 — Cookie 의 instability 로 retention 측정 불가
Cross-device 분석 불가 — Sign-in ID 없이 multi-platform user 식별 못 함
Onboarding 실험 무력화 — Signed-in ID 만 사용 시 sign-up flow 측정 못 함

올바른 선택 시.

정확한 variance — Bootstrap·delta method 또는 일치 매칭으로 trustworthy
Robust 분석 — User-based metric 으로 outlier 보호
Long-term tracking — Stable ID 로 다년 실험 가능
Cross-device 분석 — Signed-in 으로 holistic
모든 flow 측정 — Cookie + signed-in hybrid 로 sign-up 도 측정

이 선택이 platform design 의 핵심. 한 번 정한 후 backfill 어렵다.

4 응용 사례 — 회사별 ID 전략

회사	Default ID	Cross-device	Long-term
Google	Signed-in (Google Account)	강	강
Facebook	Signed-in	강	강
Amazon	Signed-in (대부분) + cookie (anonymous browse)	강	강
Netflix	Profile + signed-in	강 (profile 단위)	강
News sites	Cookie (anonymous read) + signed-in (subscribe)	약	중
Banking	Signed-in (강제)	강	강
Mobile games	Device ID + 가능 시 user ID	중	강 (device)

대부분: signed-in user ID + cookie/device hybrid. 100% 한 ID 만 사용하는 회사 거의 없음.

5 코드 예시 — Bootstrap vs Delta Method 비교

User-level randomization + page-level CTR 분석에서 두 방법의 비교.

import numpy as np
import pandas as pd
from scipy import stats

rng = np.random.default_rng(42)

# 가상 데이터: 1000 users, user-level randomization, page-level CTR
n_users = 1000
true_lift = 0.05  # +5% lift on CTR

# 각 user 의 pageviews 와 clicks
data_records = []
for i in range(n_users):
    user_id = f"user_{i:04d}"
    treatment = rng.choice([0, 1])
    n_pageviews = max(1, int(rng.lognormal(3, 1)))  # heterogeneous pageviews
    base_ctr = 0.05  # 5% baseline
    user_ctr = base_ctr * (1 + true_lift) if treatment else base_ctr
    n_clicks = rng.binomial(n_pageviews, user_ctr)

    data_records.append({
        "user_id": user_id,
        "treatment": treatment,
        "pageviews": n_pageviews,
        "clicks": n_clicks
    })

df = pd.DataFrame(data_records)

# === 분석 1 — 잘못된 page-level 분석 ===
print("=== 잘못된 page-level 분석 ===")
t = df[df["treatment"] == 1]
c = df[df["treatment"] == 0]
t_clicks = t["clicks"].sum()
t_pv = t["pageviews"].sum()
c_clicks = c["clicks"].sum()
c_pv = c["pageviews"].sum()
t_ctr = t_clicks / t_pv
c_ctr = c_clicks / c_pv

# 잘못된 SE — page-level binomial 가정 (variance underestimate)
naive_se_t = np.sqrt(t_ctr * (1 - t_ctr) / t_pv)
naive_se_c = np.sqrt(c_ctr * (1 - c_ctr) / c_pv)
naive_diff_se = np.sqrt(naive_se_t**2 + naive_se_c**2)
naive_z = (t_ctr - c_ctr) / naive_diff_se
naive_p = 2 * (1 - stats.norm.cdf(abs(naive_z)))

print(f"T CTR: {t_ctr:.4f}, C CTR: {c_ctr:.4f}")
print(f"Lift: {(t_ctr - c_ctr)/c_ctr*100:.2f}%")
print(f"Naive SE (잘못): {naive_diff_se:.5f}")
print(f"Naive Z: {naive_z:.2f}, p: {naive_p:.4f}")

# === 분석 2 — Delta Method (정확) ===
print("\n=== Delta Method 분석 ===")

def delta_method_ratio_se(group):
    """ Per-user X (clicks) / Y (pageviews) 의 ratio variance. """
    X = group["clicks"]
    Y = group["pageviews"]
    n = len(group)
    X_mean = X.mean()
    Y_mean = Y.mean()
    Var_X = X.var()
    Var_Y = Y.var()
    Cov_XY = np.cov(X, Y)[0, 1]
    R = X_mean / Y_mean
    Var_R = (1 / Y_mean**2) * (Var_X + R**2 * Var_Y - 2 * R * Cov_XY)
    SE_R = np.sqrt(Var_R / n)
    return R, SE_R

t_R, t_SE = delta_method_ratio_se(t)
c_R, c_SE = delta_method_ratio_se(c)
delta_diff_se = np.sqrt(t_SE**2 + c_SE**2)
delta_z = (t_R - c_R) / delta_diff_se
delta_p = 2 * (1 - stats.norm.cdf(abs(delta_z)))

print(f"T CTR (delta): {t_R:.4f}, SE: {t_SE:.5f}")
print(f"C CTR (delta): {c_R:.4f}, SE: {c_SE:.5f}")
print(f"Delta SE (정확): {delta_diff_se:.5f}")
print(f"Delta Z: {delta_z:.2f}, p: {delta_p:.4f}")

# === 분석 3 — Bootstrap (정확) ===
print("\n=== Bootstrap 분석 ===")

def bootstrap_ctr(group, n_bootstrap=1000):
    """ User-level resample 의 CTR 분포. """
    ctrs = []
    for _ in range(n_bootstrap):
        sample = group.sample(n=len(group), replace=True)
        ctrs.append(sample["clicks"].sum() / sample["pageviews"].sum())
    return np.array(ctrs)

t_bootstrap = bootstrap_ctr(t, n_bootstrap=1000)
c_bootstrap = bootstrap_ctr(c, n_bootstrap=1000)
bootstrap_diff = t_bootstrap - c_bootstrap
bootstrap_se = bootstrap_diff.std()
bootstrap_z = (t_bootstrap.mean() - c_bootstrap.mean()) / bootstrap_se
bootstrap_p = 2 * (1 - stats.norm.cdf(abs(bootstrap_z)))

print(f"Bootstrap mean diff: {bootstrap_diff.mean():.5f}")
print(f"Bootstrap SE: {bootstrap_se:.5f}")
print(f"Bootstrap Z: {bootstrap_z:.2f}, p: {bootstrap_p:.4f}")

# === 비교 ===
print("\n=== 비교 ===")
print(f"True lift: {true_lift*100:.2f}%")
print(f"\nMethod        | SE       | Z      | p-value | 결론")
print(f"-" * 60)
print(f"Naive (잘못)   | {naive_diff_se:.5f} | {naive_z:6.2f} | {naive_p:.4f}  | over-confident")
print(f"Delta Method  | {delta_diff_se:.5f} | {delta_z:6.2f} | {delta_p:.4f}  | 정확")
print(f"Bootstrap     | {bootstrap_se:.5f} | {bootstrap_z:6.2f} | {bootstrap_p:.4f}  | 정확")

예상 출력 (시드 42 — random 변동).

=== 잘못된 page-level 분석 ===
T CTR: 0.0518, C CTR: 0.0496
Lift: 4.46%
Naive SE (잘못): 0.00109
Naive Z: 2.05, p: 0.0407

=== Delta Method 분석 ===
T CTR (delta): 0.0518, SE: 0.00164
C CTR (delta): 0.0496, SE: 0.00149
Delta SE (정확): 0.00222
Delta Z: 1.01, p: 0.3137

=== Bootstrap 분석 ===
Bootstrap mean diff: 0.00229
Bootstrap SE: 0.00220
Bootstrap Z: 1.04, p: 0.2998

=== 비교 ===
True lift: 5.00%

Method        | SE       | Z      | p-value | 결론
------------------------------------------------------------
Naive (잘못)   | 0.00109 | 2.05 | 0.0407  | over-confident
Delta Method  | 0.00222 | 1.01 | 0.3137  | 정확
Bootstrap     | 0.00220 | 1.04 | 0.2998  | 정확

직관 — 시뮬레이션의 핵심 메시지

이 시뮬레이션의 4 가지.

1. SE 의 2 배 차이

Naive: 0.00109
Delta/Bootstrap: 0.00220~0.00222

Naive 가 SE 를 2 배 underestimate. 이유: page-level i.i.d. 가정이 hold 안 함 (같은 user 의 page 들이 correlated).

2. Statistical decision 의 reverse

Naive: p=0.04, "통계적 유의"
Delta: p=0.31, "통계적 유의 아님"
Bootstrap: p=0.30, "통계적 유의 아님"

→ Naive 의 결론 (launch) 은 잘못
→ Delta·Bootstrap 의 결론 (insufficient evidence) 이 정확

이 reverse 가 잘못된 분석의 가장 위험한 함정. False positive launch 발생.

3. Delta vs Bootstrap 의 일치

두 방법 모두 비슷한 결과 (SE ≈ 0.0022, p ≈ 0.30). 다른 가정·계산이지만 결과 일치 → 둘 다 정확.

실무 선택:

Delta method: 빠름 (computational simple), formula 기반
Bootstrap: 가정 없음 (분포 free), 계산 비싸지만 robust

Mature platform: 둘 다 implement, default 는 delta, 의심 시 bootstrap 검증.

4. True lift 와 estimate 비교

True lift: 5.00% Naive estimate: 4.46% (lift 자체는 비슷) Delta estimate: same Bootstrap estimate: same

Lift estimate 자체는 비슷, but variance 가 결정적. Variance 잘못 추정 → 잘못된 통계 결론.

5.0.0.1 함의

User-level randomization + page-level metric 시:

Naive 분석 절대 사용 안 함
Delta method 또는 bootstrap 필수
Sample size 가 충분 큰 경우 두 방법 일치
Sample size 작거나 분포 skewed 시 bootstrap 우선

이것이 modern A/B platform 의 표준. Naive 분석은 platform 자체에서 차단.

6 Ch.14 시리즈 마무리

2 편 완료:

F14-0 — Ch.14 개관, granularity spectrum, 두 핵심 질문, SUTVA·cluster
F14-1 — Randomization vs Analysis matching, 3 가지 ID, IP 위험, sub-user 조건

다음: Ch.15 (Ramping, 4 편) — 단계적 노출 의 SQR framework.

7 관련 주제

선행

다음 챕터

F15-* — Ch.15 Ramping (SQR Framework)

관련 챕터

F18-* — Ch.18 Variance/CUPED — Variance 추정의 정확성
F19-* — Ch.19 A/A Test — Variance 검증
F20-* — Ch.20 Triggering — Coarser randomization, finer trigger
F22-* — Ch.22 Leakage — Carryover, network spillover

다른 카테고리 연결

Statistics — Bootstrap — Resampling methods
Statistics — Delta Method — Ratio variance
Statistics — i.i.d. 가정 — Independence
Engineering — Identity Graph — Cross-device identity