1 정의
Kohavi (2020) Ch.12.3 의 함의 6~7 은 A/B 로 직접 분석 불가능한 영역 을 다룬다.
| # | 함의 | 핵심 |
|---|---|---|
| 6 | Whole-app Release 의 Quasi-experimental | 새 version 전체를 A/B 로 분리 못 함. Adoption bias 보정 후 비교 |
| 7 | Multiple Devices·Platforms | 사용자가 multi-device 사용 시 ID 불일치 + cross-platform interaction 처리 |
원문 (Ch.12.3 Implication 6): “Not all changes on the new app can be put behind an A/B parameter. To truly run a randomized controlled experiment on the new app as a whole, bundle both versions behind the same app… This is not practical or ideal for most apps, as it can double the app size.”
원문 (Ch.12.3 Implication 7): “It is common for a user to access the same site via multiple devices and platforms… Different IDs may be available on different devices. As a result, the same user may be randomized into different variants on different devices.”
핵심 통찰: 모든 thick client 변경이 A/B 가능하지 않다. 새 version 전체, 다중 device 등 A/B 구조 외 영역에서는 quasi-experimental + holistic 분석 필요. 이 영역이 causal inference 의 적극적 응용 영역.
2 개념 및 원리
2.1 Implication 6 — Whole-app Release 의 Quasi-experimental Analysis
2.1.1 A/B 의 한계 — 무엇이 A/B 불가능한가
A/B 가능 영역:
- 단일 feature 의 on/off
- Algorithm parameter 변경
- UI element variant
- ML model variant
A/B 불가능 영역:
- 새 app version 전체 — 100s of features 동시 변경
- OS upgrade — 사용자 OS 변경 자체
- Architecture overhaul — 전체 architecture 변경
이 영역들이 whole-app release 의 본질.
2.1.2 A/B 로 강제 시 — Bundle 방식의 한계
저자 명시: “bundle both versions behind the same app and start some users on the new version, while keeping others on the old version. This is not practical or ideal for most apps, as it can double the app size.”
2.1.2.1 Bundle 방식의 메커니즘
Bundle app:
v1.0 코드 (옛 version 전체) +
v1.1 코드 (새 version 전체) +
Variant flag (어느 version 사용)
App size:
- 일반 single-version app: 100MB
- Bundle app: 200MB (2 배)
배포 후:
- Random 50% 사용자에 v1.0 활성
- Random 50% 사용자에 v1.1 활성
- 진정한 A/B 가능2.1.2.2 Bundle 의 비현실성
1. App size 2 배:
- 사용자 download 거부 ↑ (특히 cellular)
- Storage 압박 → uninstall ↑
- 새 사용자 acquisition 어려움
2. 유지·관리 부담:
- 두 version 모두 bug fix
- 두 version 모두 test
- 개발 비용 ~2 배
3. App store 문제:
- 일부 정책 위반 가능 ("hidden code" 검출)
- 심사 지연따라서 bundle 은 일부 critical 실험에만. 일반 whole-app 변경에는 비현실적.
2.1.3 Quasi-experimental 의 자연 분포
저자 명시 (Ch.12.3 Implication 6): “because not all users adopt the new app version at the same time, there is a period of time where we have both versions of the app serving real users. This effectively offers an A/B comparison if we can correct for the adoption bias.”
2.1.3.1 자연 발생 메커니즘
새 version 1.1 출시 후:
Day 1: 30% 사용자 update (eager)
Day 7: 50% 사용자
Day 14: 70% 사용자
Day 30: 85% 사용자
이 분포가 자연스러운 "Treatment vs Control":
Treatment: v1.1 사용자
Control: v1.0 사용자 (아직 update 안 한)2.1.3.2 Naive 분석의 함정
Naive 비교 (v1.1 vs v1.0):
v1.1 사용자: engagement 평균 70
v1.0 사용자: engagement 평균 60
차이: +10
해석 (틀림): "v1.1 이 +10 만큼 좋다."
실제: Adoption bias.
- v1.1 update 한 사용자 = "Eager adopter" (frequent + tech-savvy)
- v1.0 사용자 = "Lazy adopter" (rare + 보수적)
- 두 그룹 의 baseline engagement 자체가 다름
- 두 그룹의 차이는 "v1.1 vs v1.0" 효과 + "Eager vs Lazy" 효과의 mix2.1.4 Adoption Bias 보정 — Xu and Chen (2016)
저자 인용: “Xu and Chen (2016) share techniques to remove the bias in the mobile adoption setting.”
2.1.4.1 핵심 아이디어 — Pre-period Comparison
Pre-period (출시 전):
- 모든 사용자가 v1.0 사용
- 사용자별 engagement baseline 측정
Post-period (출시 후):
- 사용자가 v1.0 또는 v1.1 사용
- 사용자별 engagement 측정
DiD-like 분석:
- Eager adopter 의 baseline (pre) vs post 변화
- Lazy adopter 의 baseline (pre) vs post 변화
- 두 변화의 차이 = v1.1 의 효과2.1.4.2 메커니즘
pre-period post-period delta
Eager adopter: baseline_E v1.1_engage delta_E
Lazy adopter: baseline_L v1.0_engage delta_L
가정: 만약 v1.1 효과 없다면, delta_E = delta_L (둘 다 같은 자연 trend)
실제: delta_E - delta_L = v1.1 의 진정 효과이 difference-in-differences 가 adoption bias 의 자연 보정.
2.1.4.3 시나리오
Eager adopter:
Pre-period engagement: 80
Post-period (v1.1): 85
Delta: +5
Lazy adopter:
Pre-period engagement: 50
Post-period (v1.0): 53
Delta: +3
Naive 분석 (post-period 만):
v1.1 vs v1.0 = 85 - 53 = +32 (huge!)
해석: "v1.1 이 엄청 좋다"
→ 잘못. 대부분이 Eager vs Lazy 차이.
Quasi-experimental (DiD):
Eager 의 delta: +5
Lazy 의 delta: +3
v1.1 효과 = +5 - +3 = +2
→ v1.1 이 +2 만큼 좋다 (실제 효과)2.1.4.4 핵심 가정 — Parallel Trends
이 분석의 핵심 가정: 만약 v1.1 효과 없었다면 두 그룹의 delta 가 같았을 것.
이 가정이 깨지는 경우:
- Eager adopter 가 macro 변화에 더 민감 (예: 휴가 시즌)
- Lazy adopter 가 다른 macro 영향 (예: 노년 사용자의 계절 trend)
해결: pre-period 에서 두 그룹의 trend 일치 확인 (parallel trends test). 일치 안 하면 보정 어려움.
2.1.4.5 다른 보정 기법 (Xu and Chen 2016 의 detail)
Propensity Score Matching — Eager·Lazy 사용자 중 similar baseline 의 사람 매칭. Matched pair 의 delta 비교.
Inverse Probability Weighting — Adoption 확률을 model. 각 사용자에 weight 부여 후 가중 평균.
Synthetic Control — Lazy adopter 의 weighted combination 으로 Eager adopter 의 counterfactual 생성.
각 기법이 다른 가정. 데이터 특성에 따라 선택. 그러나 모두 adoption 자체의 selection 보정 이 공통.
이 영역이 causal inference 의 산업 응용 의 대표 사례. Mobile 분석가는 이 기법 학습 필수.
2.1.5 Quasi-experimental 의 한계와 Best Practice
2.1.5.1 한계
1. Causal claim 약함:
- A/B 보다 약한 evidence
- Hidden confounder 가능성
2. 통계적 power 부족:
- 자연 분포의 sample size 가 일정하지 않음
- 일부 segment 의 N 작음
3. Interpretability:
- DiD, IPW 등 복잡한 분석
- 사업 의사결정자에 explain 어려움2.1.5.2 Best Practice (사전지식 + 산업 표준)
1. Multiple methods triangulation:
- DiD + PSM + IPW 모두 적용
- 일치하면 신뢰 ↑
- 불일치 시 root cause 분석
2. Sensitivity analysis:
- 가정 변경 시 결과 robustness 확인
- "만약 hidden confounder 있다면 effect 가 어떻게 변할까"
3. A/B + quasi-experimental hybrid:
- 일부 critical sub-component 만 A/B
- 전체 release 는 quasi-experimental
- 두 결과의 일치성 확인2.2 Implication 7 — Multiple Devices·Platforms
2.2.1 사용자의 Multi-platform 행동
저자 명시 (Ch.12.3 Implication 7): “It is common for a user to access the same site via multiple devices and platforms, for example, desktop, mobile app, and mobile web.”
2.2.1.1 사용자 분포
Multi-platform 사용 빈도:
- Desktop only: 20%
- Mobile only: 35%
- Desktop + Mobile: 40%
- 3 platform 이상: 5%
Cross-platform 사용 시간 분포:
- Desktop: 작업 (오피스 시간)
- Mobile app: 통근, 점심, 저녁
- Mobile web: 검색·이메일 link2.2.2 함의 7-1 — ID 불일치 (Dmitriev et al. 2016)
저자 인용: “Different IDs may be available on different devices. As a result, the same user may be randomized into different variants on different devices.”
2.2.2.1 ID 의 platform 별 차이
Desktop (web):
- Browser cookie ID
- Sign-in 시 user ID
Mobile app:
- App-installed device ID (Apple IDFA, Android AAID)
- Sign-in 시 user ID
Mobile web (브라우저):
- 다른 cookie ID (app 의 device ID 와 다름)
- 같은 user ID 로 sign-in 가능
문제:
같은 사용자 (Alice) 가 desktop·mobile app·mobile web 다 사용 시:
- Desktop: cookie_dt_xxx
- Mobile app: device_app_yyy
- Mobile web: cookie_mw_zzz
→ 3 개의 다른 ID2.2.2.2 Variant 불일치의 메커니즘
실험 hash 기반 variant 결정:
variant = hash(experiment_id + device_id) % 2
Alice 의 desktop hash → A
Alice 의 mobile app hash → B
Alice 의 mobile web hash → A
결과:
Alice 가 같은 실험에서 다른 variant 보임
- Desktop 에서 A
- Mobile app 에서 B
- Mobile web 에서 A (같은 device 라서)
문제:
- 사용자 confusion ("어제는 X, 오늘은 Y")
- Cross-platform 행동 분석 어려움2.2.3 해결 — User-level Randomization
User ID 기반 randomization (sign-in 후):
variant = hash(experiment_id + user_id) % 2
Alice 의 모든 device 에서 같은 variant
Sign-in 안 한 device 에서는 device ID 사용
Hybrid:
Sign-in: user_id 사용
Sign-in 안 함: device_id 사용
Sign-in 후 cross-device sync (예: device → user 매핑 저장)2.2.3.1 Cross-device Mapping
사용자가 Alice 임이 확인되면:
device_id_X (desktop cookie) → user_id (Alice)
device_id_Y (mobile app) → user_id (Alice)
device_id_Z (mobile web cookie) → user_id (Alice)
이 매핑이 있으면:
- Alice 의 모든 device 가 같은 variant
- Cross-device 행동 합산 가능::: {.callout-warning} ## 가정 — User ID 기반 randomization 의 함정
가정: User ID 만으로 randomization 한다.
함정 1 — Sign-in 안 한 사용자
Anonymous browsing (sign-in 안 함):
- Cookie/device ID 만 있음
- User ID 없음
- User ID 기반 hash 못 함
→ device ID 로 fallback
문제:
Sign-in 후 → user ID 로 전환 → variant 변경 가능
같은 사용자가 sign-in 전 A, sign-in 후 B해결:
Stable randomization 의 priority:
1. 처음 사용한 ID 유지 (device 또는 user 중 먼저 도착한 것)
2. Sign-in 후도 device ID 의 variant 유지
3. 명시적 device → user 매핑 시점에만 transition함정 2 — User ID 의 multi-account
가족 공유 device:
- Account A 와 Account B 가 같은 device 사용
- Sign-in 변경 시 user_id 변경
- 같은 device 에서 variant 변경대부분 무시 가능 (rare case). 그러나 family-friendly app (Spotify, Netflix) 에서는 critical.
함정 3 — User ID 의 cross-product 일관성
같은 회사 의 다른 product:
- User ID 가 다른 product 에서 다른 variant 받을 수 있음
- 회사 단위 user experience 일관성 부족
해결: experiment ID 별 isolated randomization. Cross-product 는 별도 management.
:::
#### 함의 7-2 — Cross-platform Interaction
저자 명시: "There can be potential interactions between different devices."
##### Interaction 시나리오
Continue on Desktop / Mobile sync (Edge browser): - 사용자가 mobile 에서 article 읽다가 - Desktop 으로 sync → desktop 에서 계속 읽기 - Mobile 의 행동이 desktop 의 시작점
Email link → App or Mobile Web: - Amazon email click on mobile - 만약 Amazon app 설치 → app 으로 이동 - 미설치 → mobile web 으로 이동 - 두 경로의 user experience 다름
#### Cross-platform Confounder
저자 명시 (Ch.12.3 Implication 7): "the user experience on one platform (usually the app) can
be better than on another platform. Directing traffic from the app to the web tends to bring
down total engagement, which may be a confounding effect not intended by the experiment itself."
##### 시나리오
Treatment: Amazon email 의 click 이 mobile web 으로 (강제) Control: Amazon email 의 click 이 app 으로 (있으면)
분석: Treatment 사용자: mobile web 사용 → engagement 하락 (web < app) Control 사용자: app 사용 → 정상 engagement
결과: Treatment 가 inferior 처럼 보임
해석: - Treatment 가 정말 inferior? (변경의 효과) - 또는 Web 의 inferior experience 의 confounder?
실제: 후자. App→Web 의 platform downgrade 가 confounder.
##### 분석 함의
Implication 1 - Holistic 분석: - User 의 total engagement (app + web 모두) 측정 - 단일 platform metric 으로는 mislead
Implication 2 - Platform-specific guardrail: - Treatment 가 app→web 이동 유도하는지 추적 - Cross-platform traffic shift 가 confounder
Implication 3 - Cross-platform attribution: - 한 사용자의 다중 platform 행동을 single user 로 합산 - Conversion 의 cross-platform 분석
#### Cross-platform Holistic 분석의 메커니즘
사용자 Alice 의 행동: Day 1, Mobile app: 30 min, 5 actions Day 1, Desktop: 20 min, 3 actions Day 1, Mobile web: 5 min, 1 action
Total daily engagement: 55 min, 9 actions
분석: - User-level aggregation - Cross-device 매핑 필요 - 단일 metric 으로 holistic 평가
::: {.callout-tip}
## 직관 — Holistic vs Platform-specific 의 trade-off
대부분 회사가 platform-specific metric (mobile DAU, web DAU) 을 별도 추적. 이유:
- **Operational clarity**: Mobile team 은 mobile metric 으로 평가
- **Channel ownership**: 각 channel 의 책임 분리
- **단순성**: 측정 쉬움
그러나 user-centric 사고로는 holistic 이 정답:
- **사용자 가치**: Mobile + Desktop + Web 모두의 합
- **Cross-platform interaction**: 한 channel 의 변경이 다른 channel 영향
- **Long-term retention**: Multi-platform user 가 single-platform 보다 retention ↑
##### 실무 절충
Layer 1 (operational): platform-specific metrics - Mobile DAU, Mobile retention - Web DAU, Web conversion
Layer 2 (strategic): user-level holistic metrics - Total engagement (모든 platform) - Multi-platform user 비율 - Cross-platform conversion path
두 layer 가 다른 의사결정 input. Operational 은 단기 운영, strategic 은 장기 회사 ROI.
##### 사례 — Amazon 의 cross-platform 분석
Amazon 의 실험은 거의 항상 holistic. 이유:
- 사용자가 mobile app 에서 browse, desktop 에서 결제 (cross-platform conversion)
- Email click → app 또는 web (channel choice 가 conversion 영향)
- 한 사용자 의 여러 device 의 통합 view 가 필수
이것이 Amazon 의 user-centric 분석 표준. 다른 회사도 점차 수렴.
##### 사례 — Microsoft Edge 의 cross-device sync
Edge 의 "Continue on desktop/mobile" 기능 자체가 cross-platform user experience 의 가치 인지.
실험 분석도 자연스럽게 holistic.
이 trend 가 모든 multi-platform 회사의 미래. Single platform 사고에서 user-centric 사고로
전환.
:::
### Conclusions — Ch.12 의 요약과 진화
저자 마무리 (Ch.12 Conclusions): "We have devoted this chapter to the differences when experimenting
on thin vs. thick clients. While some differences are obvious, many are subtle but critical. We
need to put in extra care in order to design and analyze the experiments properly. It is also
important to point out that with rapid technological improvement, we expect many of the differences
and implications to evolve over time."
##### 4 가지 진화 방향
##### 진화 1 — Server-side 위임 증가
2010 년대: Mobile app 의 70% 가 client-side 2020 년대: Mobile app 의 50% 가 server-side (cloud-based) 2030 년대 (예측): 30% 만 client-side (edge computing 균형)
함의: Thick client 제약이 점차 약화. 실험 platform 도 server-side 위주로 통합.
##### 진화 2 — App Store 정책 변화
2020 ~ 현재: - EU Digital Markets Act → Apple/Google 의 alternative store 강제 - PWA (Progressive Web App) 표준 강화 - Side-loading 가능성
함의: - App store 의 power 약화 - 회사가 release process 더 통제 - Web vs Mobile 구분 모호
##### 진화 3 — 5G·Wi-Fi 6 의 통신 향상
2010: 3G/4G 일반 2020: 4G LTE 표준, 5G 시작 2030 (예측): 5G/6G 무제한 data
함의: Communication 제약 약화. Cellular 도 사실상 무제한 → telemetry 정책 전환 가능.
##### 진화 4 — Device 성능 향상
2010: 1GB RAM, 8GB Storage 2020: 4~6GB RAM, 64~128GB Storage 2030 (예측): 16GB+ RAM, 1TB+ Storage
함의: CPU·battery·memory 제약 약화. Local computation 더 자유롭게.
##### 진화에도 불변하는 원칙
변하지 않는 것: 1. Thin·thick 의 본질적 architecture 차이 2. 사용자의 multi-platform 행동 3. Selection bias 의 메커니즘 (frequent vs rare user) 4. Causal inference 의 fundamental challenge
진화하는 것: 1. 통신 비용 (체감 0 으로 수렴) 2. App store 의 control (점차 약화) 3. Device 성능 (지속 향상) 4. ML model 의 client-side 가능성 ↑
저자 통찰: thick·thin 차이의 일부는 시간에 따라 약화, but 본질적 분석 방법론 (selection bias,
multi-version coexistence, holistic analysis) 은 지속.
## 왜 필요한가
함의 6·7 부재 시.
- **Implication 6 부재** → Whole-app 변경의 impact 측정 불가. Adoption bias 에 분석 잘못
- **Implication 7 부재** → ID 불일치로 user confusion + cross-platform interaction 무시 → 분석
왜곡
함의 6·7 활성 시.
- **Implication 6**: Quasi-experimental 분석 능력 → A/B 외 영역도 인과 추정
- **Implication 7**: Holistic user-level 분석 → 산업 표준 user-centric
이 격차가 thick client 분석의 advanced level. Web 분석가가 thick 으로 transition 시 마지막 학습
영역.
## 응용 사례 — Microsoft Office 의 Whole-app Release 분석
##### Office 의 monthly release 의 분석 도전
Monthly release: - 100s of features 동시 변경 - 새 algorithm, UI, performance 개선 모두 묶음
A/B 가능한 부분: - 각 feature 의 server flag toggle (Implication 1) - Individual feature 의 effect 측정
A/B 불가능한 부분: - Build 자체 의 effect (UI overhaul, architecture) - 사용자 update 의 자연 분포
##### Office 의 Quasi-experimental 적용 (사전지식)
Pre-period (이전 build): - 모든 사용자 v17.0 - Engagement, performance, satisfaction baseline 측정
Post-period (새 build v17.1): - Eager adopter (60%): v17.1 - Lazy adopter (40%): v17.0 (아직)
분석: Eager (pre v17.0 → post v17.1): delta_E Lazy (pre v17.0 → post v17.0): delta_L (자연 trend baseline) v17.1 효과 = delta_E - delta_L
실제 결과 (가상): delta_E = +5% engagement delta_L = +1% (자연 trend, 시즌 효과 등) v17.1 효과 = +4%
이 quasi-experimental 분석이 monthly release 의 표준 평가. A/B 의 limitation 보완.
## 코드 예시 — Cross-platform User-level Holistic 분석
Multi-platform 사용자의 cross-device aggregation + variant 일관성 검증.
```python
import pandas as pd
import numpy as np
import hashlib
from typing import Optional
rng = np.random.default_rng(42)
# 가상 사용자 데이터
n_users = 1000
users = pd.DataFrame({
"user_id": [f"user_{i}" for i in range(n_users)],
"primary_device": rng.choice(["desktop", "mobile_app", "mobile_web"], n_users)
})
# 각 사용자의 여러 device ID
def generate_device_ids(user_id):
return {
"desktop_cookie": hashlib.md5(f"{user_id}_desktop".encode()).hexdigest()[:16],
"mobile_app_id": hashlib.md5(f"{user_id}_mobile_app".encode()).hexdigest()[:16],
"mobile_web_cookie": hashlib.md5(f"{user_id}_mobile_web".encode()).hexdigest()[:16],
}
users["device_ids"] = users["user_id"].apply(generate_device_ids)
# 시나리오 1: Naive (device-level) randomization
def get_variant_naive(experiment_id, device_id):
""" Device ID 별 random variant. """
h = int(hashlib.md5(f"{experiment_id}_{device_id}".encode()).hexdigest(), 16)
return ["A", "B"][h % 2]
# 각 사용자의 device 별 variant 비교
inconsistency_count_naive = 0
for _, row in users.iterrows():
user_id = row["user_id"]
devices = row["device_ids"]
variants = {dev: get_variant_naive("exp_001", dev_id)
for dev, dev_id in devices.items()}
if len(set(variants.values())) > 1:
inconsistency_count_naive += 1
print(f"=== Naive (device-level) ===")
print(f"Inconsistent variant 사용자: {inconsistency_count_naive} / {n_users}")
print(f"비율: {inconsistency_count_naive/n_users*100:.1f}%")
# 시나리오 2: User-level randomization (sign-in 후)
def get_variant_user_level(experiment_id, user_id):
""" User ID 기반 random variant. """
h = int(hashlib.md5(f"{experiment_id}_{user_id}".encode()).hexdigest(), 16)
return ["A", "B"][h % 2]
# 각 사용자의 device 별 variant 비교 (user-level)
inconsistency_count_user = 0
for _, row in users.iterrows():
user_id = row["user_id"]
# 모든 device 에서 user_id 기반 → 일관
variant = get_variant_user_level("exp_001", user_id)
# 모든 device 같음 → 0 inconsistency
print(f"\n=== User-level ===")
print(f"Inconsistent variant 사용자: 0 / {n_users}")
print(f"비율: 0.0%")
# 시나리오 3: Cross-platform engagement 합산
np.random.seed(42)
engagement_data = []
for _, row in users.iterrows():
user_id = row["user_id"]
variant = get_variant_user_level("exp_001", user_id)
# 각 platform 의 engagement
desktop_min = max(0, np.random.normal(20, 10))
mobile_app_min = max(0, np.random.normal(30, 15))
mobile_web_min = max(0, np.random.normal(5, 5))
# Treatment 가 mobile app engagement +10%, mobile web +20%
if variant == "B":
mobile_app_min *= 1.10
mobile_web_min *= 1.20
engagement_data.append({
"user_id": user_id,
"variant": variant,
"desktop_min": desktop_min,
"mobile_app_min": mobile_app_min,
"mobile_web_min": mobile_web_min,
"total_min": desktop_min + mobile_app_min + mobile_web_min
})
engagement_df = pd.DataFrame(engagement_data)
# Platform-specific 분석
print(f"\n=== Platform-specific 분석 ===")
for platform in ["desktop_min", "mobile_app_min", "mobile_web_min"]:
a_mean = engagement_df[engagement_df["variant"] == "A"][platform].mean()
b_mean = engagement_df[engagement_df["variant"] == "B"][platform].mean()
lift = (b_mean - a_mean) / a_mean * 100
print(f"{platform:20s}: A={a_mean:.2f}, B={b_mean:.2f}, lift={lift:+.2f}%")
# Holistic (user-level total) 분석
print(f"\n=== Holistic (user-level total) 분석 ===")
a_total = engagement_df[engagement_df["variant"] == "A"]["total_min"].mean()
b_total = engagement_df[engagement_df["variant"] == "B"]["total_min"].mean()
total_lift = (b_total - a_total) / a_total * 100
print(f"Total minutes per user: A={a_total:.2f}, B={b_total:.2f}, lift={total_lift:+.2f}%")예상 출력 (시드 42).
=== Naive (device-level) ===
Inconsistent variant 사용자: 488 / 1000
비율: 48.8%
=== User-level ===
Inconsistent variant 사용자: 0 / 1000
비율: 0.0%
=== Platform-specific 분석 ===
desktop_min : A=20.31, B=19.77, lift=-2.66%
mobile_app_min : A=30.27, B=33.20, lift=+9.69%
mobile_web_min : A=5.31, B=6.30, lift=+18.69%
=== Holistic (user-level total) 분석 ===
Total minutes per user: A=55.89, B=59.27, lift=+6.05%1. Naive randomization 의 inconsistency
48.8% 의 사용자가 device 마다 다른 variant. 거의 절반.
원인: 각 device 의 hash 가 random.
결과:
- 사용자 confusion (기기마다 다른 UX)
- Cross-device 분석 불가능
- 같은 사용자가 Treatment·Control 모두 경험이것이 Web 가정으로 mobile 실험 운영 시 자주 발생하는 silent issue. SRM detection 에서도 catch 어려움 (각 device 별로는 50/50).
2. User-level randomization 의 일관성
User ID 기반 → 모든 device 에서 같은 variant. 0% inconsistency.
조건: 사용자가 sign-in. Anonymous user 는 device 단위 → fallback.
3. Platform-specific vs Holistic 분석의 차이
Treatment B 의 효과:
- Desktop: -2.66% (noise)
- Mobile app: +9.69% (실제 +10% 의도)
- Mobile web: +18.69% (실제 +20% 의도)
- Holistic total: +6.05% (가중 평균)
Platform-specific 분석: - Desktop 의 -2.66% 가 noise 로 보임 → 무시 - Mobile app·web 모두 positive → launch 권고
Holistic 분석: - Total +6.05% 가 가중 평균 - 사용자 입장에서 합산 효과 (모든 platform 결합)
2.2.3.2 의사결정 차이
Treatment B 의 launch 결정:
- Platform-specific only: “Mobile 에서 강한 효과” → launch
- Holistic only: “+6%” → launch
- Both: “Mobile 에서 강한 효과 + Total +6%” → 명확한 launch
Treatment B 가 만약 mobile 효과 +10% but desktop 효과 -10% 이면?
- Platform-specific: mixed
- Holistic: 0% (cancel)
- Decision: launch 거부 (no net effect)
이 case 가 holistic 분석의 가치. Platform-specific 만 보면 mobile team 은 launch 요청, desktop team 은 launch 거부. Holistic 이 conflict resolution.
2.2.3.3 실무 적용
대부분 회사: 둘 다 본다.
1 차 분석: Platform-specific
- 각 channel 의 효과
- Channel-specific 의사결정
2 차 분석: Holistic
- User-level total 효과
- 회사 차원 ROI 결정이 dual analysis 가 user-centric 의사결정의 표준. Mobile-first 회사는 더 강하게 holistic 우선.
3 Ch.12 시리즈 결론
3.0.0.1 핵심 takeaway
1. Thin·Thick 의 본질적 차이:
- Release process: 1 자 통제 vs 3 자 협력
- Data communication: 즉시·신뢰 vs 5 가지 제약
2. 7 함의의 시간 축:
- 설계: Anticipate·Parameterize, Failsafe
- 시작: Delayed Logging
- 운영: Triggered Tracking, Guardrails
- 분석: Quasi-experimental, Multi-platform
3. 진화 방향:
- Server-side 위임 ↑
- 통신 제약 ↓
- Device 성능 ↑
- 본질 분석 challenge 는 지속3.0.0.2 Mindset Shift 의 4 단계
Stage 1 (Beginner): Web 사고 그대로
→ Mobile 실험 결과 unreliable
Stage 2 (Intermediate): Implication 1·3 인지
→ Feature flag, failsafe 적용
→ 일부 trustworthy
Stage 3 (Advanced): Implication 2·4·5 추가
→ Delayed logging, triggered, guardrail
→ Web 수준 trust
Stage 4 (Expert): Implication 6·7 추가
→ Quasi-experimental, holistic
→ Web 보다 더 user-centric 분석이 4 단계가 thick client 실험가의 maturity model. Phase F (Kohavi) 의 12 챕터 중 이 Ch.12 가 가장 thick client specific.
4 관련 주제
선행
- F12-0 — Ch.12 개관: 클라이언트 사이드 실험
- F12-1 — Server vs Client 차이
- F12-2 — 함의 1~3 (Anticipate, Delayed Logging, Failsafe)
- F12-3 — 함의 4~5 (Triggered Analysis, Guardrails)
Ch.12 시리즈 마무리 — 5 편 완료. 다음 Ch.13 (Instrumentation).
관련 챕터
- F13-* — Ch.13 Instrumentation — Client·server 계측
- F14-* — Ch.14 Randomization Unit — User-level vs device-level
- F19-* — Ch.19 A/A Test — SRM detection across platforms
- F21-* — Ch.21 SRM — Multi-version 의 SRM
다른 카테고리 연결
- Statistics — Difference-in-Differences — Quasi-experimental 의 핵심 기법
- Statistics — Propensity Score Matching — Adoption bias 보정
- Statistics — Inverse Probability Weighting — IPW 가중
- Causal Inference — Selection bias, confounding
- Engineering — Cross-platform Identity — User identity graph