Server vs Client 차이 — Release Process · Data Communication

App Store 심사 · Update 거부 · Wi-Fi only Telemetry · Battery·CPU trade-off 의 깊이 있는 풀이

Kohavi (2020) Ch.12.1~12.2 를 깊게 다룬다. Thin client (web) 와 thick client (mobile app) 의 본질적 두 차이 — release process 와 data communication — 의 메커니즘, 3 자 협력 (app owner, app store, end user), staged rollout 의 분석 한계, 5 가지 communication 제약 (connectivity, bandwidth, battery, CPU, memory) 의 trade-off 를 코드와 사례로 풀이한다.

Experimentation
A/B Test
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: Release Process 와 Data Communication 의 두 차이

Kohavi (2020) Ch.12 가 명시한 thin·thick client 의 본질적 차이는 두 축으로 환원된다.

축 1 — Release Process (배포 절차)

  • Thin (Web): 회사 1 자 통제. Server deployment 만으로 즉시 모든 사용자 적용.
  • Thick (Mobile App): 3 자 협력 (app owner + app store + end user). 각 단계가 지연·거부 가능. Multi-version 동시 활성.

축 2 — Data Communication (데이터 통신)

  • Thin (Web): 통신 안정·즉시·신뢰. 모든 사용자 행동이 server 에 실시간 도달.
  • Thick (Mobile): 통신 제약 5 가지 (connectivity, bandwidth, battery, CPU/perf, memory/storage). Trade-off ecosystem.

원문 (Ch.12): “Server 와 client 의 차이 두 가지가 online 실험에 영향을 준다: release process 와 data communication.”

핵심 통찰: 이 두 축이 모든 7 implications 의 root cause. 각 implication 은 둘 중 하나 또는 둘 모두에서 파생.

2 개념 및 원리

2.1 Difference #1 — Release Process

2.1.1 Web (Thin Client) 의 Release Process

2.1.1.1 Continuous Deployment 의 메커니즘
개발자 commit code
   ↓ (자동 trigger)
CI/CD pipeline:
   - Linting
   - Unit test
   - Integration test
   - Build artifact
   ↓
Staging 배포 (자동)
   ↓
Smoke test (자동)
   ↓
Production 배포 (자동 또는 manual approval)
   ↓
사용자 next request 시 새 version 적용

전체 cycle: 수 분~1 시간.

Frequency: Bing·Google·Facebook 등 대형 web 회사는 하루 수십~수백 번 deploy. 한 회사의 production code 가 매시간 업데이트.

2.1.1.2 Web 의 deployment 가 transparent 한 이유

저자 표현 (Ch.12.1): “the server pushes the data (e.g., HTML) to the browser, without interrupting the end-user experience.”

메커니즘:

  1. Stateless server response — 매 request 가 독립. 새 version 의 response 가 자연스럽게 다음 request 에 포함.
  2. Browser cache — 일부 static asset 은 cache 되지만 hard refresh 또는 cache busting 으로 해결.
  3. 사용자 행동 무관 — 사용자가 “update” 버튼 누르거나 restart 할 필요 없음.

이 transparent 한 deployment 가 web 의 본질적 advantage. 실험 variant 도 같은 메커니즘:

Server logic:
  if user_id % 2 == 0:
    response = variant_A  # 빨간 버튼
  else:
    response = variant_B  # 노란 버튼

사용자 입장에서 variant 가 random 으로 결정. Change of variant 도 즉시 reflected.

2.1.2 Thick Client (Mobile App) 의 Release Process

2.1.2.1 3 자 협력 model

저자 명시: “The release process involves three parties: the app owner (e.g., Facebook), the app store (e.g., Google Play or Apple App Store), and the end user.”

[당사자 1] App Owner (회사)
   - Code 변경, build 생성
   - App store 에 submission
   - Release notes 작성
   - Marketing 결정 (when to advertise update)

[당사자 2] App Store (Google Play, Apple)
   - 심사 (수 일~수 주)
   - 정책 위반 점검 (privacy, ads, content, dark feature)
   - 심사 통과 또는 reject
   - 통과 시 distribution

[당사자 3] End User
   - Update 알림 받음
   - Update 실행 또는 거부
   - 거부 시 옛 version 무한 유지
   - 일부는 자동 update 비활성화
2.1.2.2 단계별 지연·실패 risk
단계 지연 실패 risk
App owner 의 build 분~시간 0 (자체 통제)
App store 심사 1~14 일 5~10% (정책 위반 reject)
Distribution 도달 즉시~수 일 0
User update 결정 0 일~무한대 30~40% (거부)
Update 실행 분~시간 1% (download 실패)

Total: 새 version 의 80% 사용자 도달까지 수 주 이상 일반적.

2.1.2.3 Multi-version Coexistence 의 본질

저자 명시: “at any given time, there are multiple versions of the app out there that the app owner has to support.”

시점 t0 (새 version 출시):
  Version 1.0: 60% 사용자 (옛 version 유지)
  Version 1.1: 40% 사용자 (즉시 update)

시점 t0 + 1 주:
  Version 1.0: 30% (점진 update)
  Version 1.1: 70%

시점 t0 + 1 개월:
  Version 1.0: 10%
  Version 1.1: 80%
  Version 1.2: 10% (더 새 version 출시)

시점 t0 + 3 개월:
  Version 1.0: 5%
  Version 1.1: 30%
  Version 1.2: 50%
  Version 1.3: 15%

함의: 한 시점에 항상 4~5 개 version 이 동시 활성. 각 version 의 사용자 수 비율이 변화. 이 변화 자체가 분석의 confounder.

직관 — App Store 심사가 만드는 비대칭

App store 심사는 단순 “느림” 이 아니라 회사의 deployment 통제권 자체를 박탈한다.

Web:
  회사 결정 → 즉시 적용
  Latency: 0
  통제권: 100%

App Store:
  회사 결정 → 심사 신청 → 심사 결과 대기 → 심사 통과 → 사용자 도달
  Latency: 1~14 일
  통제권: 회사 ~50%, App store ~50%

심사 시간 외 추가 risk:

  1. 정책 변경 risk — App store 가 정책 갱신 시 기존 app 도 재심사 (소급 적용)
  2. Reject 의 모호성 — “정책 위반” 결정의 정확한 사유 불명. Appeal 절차 길고 불확실
  3. App store 외 제약 — 광고 정책, in-app purchase 분배 (Apple 30%), 결제 제약

이 비대칭이 회사 strategy 에 영향:

  • Web app 우선 — Mobile 외 channel 도 운영
  • PWA (Progressive Web App) — App store 회피 시도
  • Server-side 위임 최대화 — Client 변경 최소화로 심사 risk 줄임

따라서 Ch.12 의 “server-side 로 최대한 위임” 권장 (위 F-KOH12-0 참조) 이 회사 strategy 차원의 선택이기도 하다.

2.1.2.4 Staged Rollout 의 분석 한계

저자 명시 (Ch.12.1): “both the Google Play and Apple app stores now support staged rollout… Staged rollouts are essentially randomized experiments… Unfortunately, these rollouts cannot be analyzed as random experiments because the app owners do not know which users are eligible to receive the new app.”

2.1.2.5 Staged Rollout 의 메커니즘
회사가 새 version 1.1 출시 + staged rollout 1% 설정
   ↓
Google Play / Apple 이 random 1% 사용자에 배포
   ↓
회사는 이 1% 가 누구인지 모름
   ↓
1% 의 metric 모니터링 → 문제 없으면 5%, 25%, 100% 단계 확대
2.1.2.6 분석 한계의 메커니즘
Random experiment 분석 가정:
  - Treatment group: 알려진 사용자 set
  - Control group: 알려진 사용자 set
  - 두 group 의 metric 비교

Staged rollout 의 실제:
  - "Treatment group" = Google 이 선택한 1% (알려지지 않음)
  - "Control group" = 99% (알려지지 않음, but app owner 가 추적 가능)
  - 그러나 1% 의 ID 를 모르므로 직접 비교 불가
  - "Adopted" 사용자만 식별 가능 (실제 update 한 사람)

문제: "adopted" = "eligible (Treatment)" + "actually updated" 의 곱
  - Adopted 사용자는 selection bias (early adopter)
  - Eligible 사용자 전체와 다름
  - True ITT (intention-to-treat) 분석 불가
가정 — Staged Rollout 을 단순 A/B 로 분석하면

가정: “Adopted 사용자 vs Non-adopted 사용자” 비교 = randomized A/B.

결과:

  1. Selection bias — Adopted 는 frequent + Wi-Fi user 중심. Adopted vs Non-adopted 차이가 Treatment 효과가 아닌 사용자 selection 효과.

  2. Confounded effect — Adopted 사용자가 metric 자체 높음 (frequent → engagement ↑). 새 version 효과를 over-estimate.

  3. Non-adopted 의 의미 모호 — Non-adopted 가 (a) eligible 이지만 update 거부 (b) eligible 자체 아님 의 mix. 두 case 분리 불가.

해결: Quasi-experimental method (Implication 6 — F-KOH12-4 참조). Xu and Chen (2016) 의 adoption bias 보정 기법. 또는 자체 A/B framework 으로 staged rollout 대체 (variant 를 client 에 ship + server-side flag 로 통제).

2.1.2.7 Update 빈도의 사용자 비용

저자 강조 (Ch.12.1): “App owners may not want to frequently push a new client version. Even though there is no strict limit as how many times they can release a new version, each update costs network bandwidth for users and can potentially be an annoying user experience.”

Update 의 비용:
  - Network bandwidth: 50~200 MB / update
  - Battery (download + install)
  - Storage 추가 사용 (old version backup)
  - Notification fatigue ("또 update?")
  - Restart 필요 (Windows, iOS — 일부 경우)

함의: 회사가 update 빈도 제약 — 매주 출시 불가. 보통 monthly 또는 bi-weekly.

이 빈도 제약이 Implication 1 (parameterize) 의 직접 원인. 한 release 에 가능한 모든 variant 를 ship 해야 다음 release 까지 기다릴 필요 없음.

2.1.2.8 Sovereign Cloud 의 추가 제약

저자 명시 (Ch.12.1): “Some software, such as Exchange, runs in sovereign clouds that are restricted from calling unapproved services.”

일반 cloud (AWS, Azure):
  - 외부 service 호출 자유
  - 새 service 연결 즉시 가능

Sovereign cloud:
  - 정부·규제 승인된 service 만 호출 가능
  - 새 service 연결 시 별도 승인 절차
  - 승인 시간: 수 개월

대상: 정부·국방·금융·의료 등 sensitive 도메인. Microsoft Exchange 의 일부 deployment, AWS GovCloud, Azure Government 등.

함의: 이런 환경에서는 server-side 위임 자체 어려움. 새 service 호출 시 승인 → client-side 로직 비중 증가 → thick client 제약 강화.

2.2 Difference #2 — Data Communication

2.2.1 Communication Stack 의 5 가지 제약

저자 명시 (Ch.12.2): “data connection between the client and server may be limited or delayed” + “using the network may impact device performance and ultimately user engagement with the app.”

2.2.1.1 제약 1 — Internet Connectivity
Connectivity 분포 (실제 사용자 모집단):
  - 항상 online (Wi-Fi 직장+집): 30%
  - 보통 online (cellular + Wi-Fi mix): 50%
  - 가끔 offline (지하·터널·약전계): 15%
  - 자주 offline (개도국 일부 지역): 5%

저자 명시: “In some countries, users may be offline for days.”

함의:

  1. Server 변경의 client 도달 지연 — 새 config 가 device 에 push 되지 않음
  2. Telemetry 의 server 도달 지연 — 사용자 행동이 즉시 server 에 반영 안 됨
  3. 국가별 heterogeneity — 같은 실험이 국가별로 다른 timing 의 결과

저자 권고: “These delays vary by country or demographic and must be accounted for in instrumentation and downstream processing.”

2.2.1.2 제약 2 — Cellular Data Bandwidth
사용자의 data plan:
  - 무제한 (선진국 일부): 비용 0, 자유 사용
  - 월 10~30 GB: 일반 신경 안 씀
  - 월 1~5 GB: telemetry 비용 인지
  - 월 1 GB 이하: 모든 통신 비용 인지

App 의 telemetry 정책 옵션:
  1. 즉시 모든 통신 (사용자 비용 ↑, 사용자 불만 ↑)
  2. Wi-Fi only (정확성 ↑, but 도달 지연)
  3. Hybrid (즉시 critical event + Wi-Fi 시 batch sync)

저자 강조: “Most apps choose to send telemetry data over Wi-Fi only, which can delay when that data is received server side.”

함의: Wi-Fi only telemetry 가 표준. 따라서:

  • Telemetry 의 server 도달 평균 지연 = 24~48 시간
  • Wi-Fi user 의 데이터가 cellular-only user 보다 빨리 도달 → selection bias
  • 분석 시 “이 데이터가 모집단 대표성 있나” 점검 필요
2.2.1.3 Country Heterogeneity

저자 강조: “There can also be heterogeneity across countries, as mobile infrastructure in some countries is weaker than others when it comes to bandwidth, cost, and so on.”

국가별 mobile 인프라:
  - 한국·일본: Wi-Fi 풍부, cellular 빠름, plan 저렴 → telemetry 거의 무제한
  - 미국: Wi-Fi 보통, cellular 보통, plan 고가 → 사용자 비용 인지
  - 인도·아프리카: Wi-Fi 부족, cellular 약, plan 매우 비쌈 → 모든 byte 인지

이 heterogeneity 가 3 가지 실험 분석 함의:

  1. Country segment 분석 표준화 — 국가별 효과 분리 권장
  2. Country-specific config — 일부 국가는 더 적은 telemetry, 더 많은 cache
  3. Sample size 차이 — 일부 국가의 사용자가 데이터 수집 어려움 → 통계적 power 차이
2.2.1.4 제약 3 — Battery

저자 명시 (Apple 2018): “mobile devices in low battery mode have restrictions on what apps are allowed to do.”

Battery 와 telemetry 의 관계:
  - 자주 wake-up + send: battery ↓ 25~40%
  - Batch sync + 기회주의 (Wi-Fi 연결 시): battery ↓ 5~10%
  - Critical only + 긴 batch: battery ↓ 1~3%

iOS Low Power Mode 시 OS 가 강제:
  - Background app refresh 비활성
  - Push notification 빈도 제한
  - CPU clock 다운

함의:

  1. Battery 가 silent guardrail — 사용자가 “이 앱이 battery 잡아먹는다” 인지 시 uninstall. 직접 metric 으로 detect 어려움 (사용자가 원인 알리지 않음).
  2. OS 의 자동 제약 — iOS·Android 가 telemetry 자체를 제한. 회사 의도와 무관하게 데이터 누락.
  3. Low-end device 효과 — 새 device 보다 더 강한 OS 제약. Heterogeneity.
2.2.1.5 제약 4 — CPU·Latency·Performance

저자 명시 (Ch.12.2): “Even though many mobile devices behave like minicomputers nowadays, there are still lower-end mobile devices constrained by CPU power.”

CPU 비용:
  - Telemetry aggregation: ~1% CPU 추가
  - 자주 telemetry send: ~3~5% CPU
  - Heavy local logic (ML inference): ~10~20% CPU

CPU 사용 ↑ 의 결과:
  - App responsiveness ↓ (사용자가 lag 인지)
  - Battery ↓
  - Heat ↑ (long-term hardware 손상 risk)
2.2.1.6 Performance 의 사용자 행동 영향

Ch.5 (Speed Matters) 의 직접 연결. App responsiveness ↓ → 사용자 engagement ↓ → 모든 metric 하락. Treatment 가 telemetry-heavy 면 Treatment 자체가 inferior 처리 효과 발생 — confounder.

저자 권고 (간접): Treatment 의 CPU 영향을 별도 guardrail 로 모니터링. Battery·CPU guardrail 이 Implication 5 의 직접 원인.

2.2.1.7 제약 5 — Memory·Storage

저자 명시 (Ch.12.2): “Caching is one way to reduce data communication but impacts the size of the app, which impacts app performance and increases app uninstallment (Reinhardt 2016).”

Caching trade-off:
  Cache 많이:
    + Server 통신 ↓
    + Offline 동작 가능
    + Battery ↓
    - App size ↑
    - Storage ↓ (사용자 device storage 점유)
    - Uninstall ↑ (특히 low-end device)

  Cache 적게:
    - Server 통신 ↑
    - Offline 동작 제한
    - Battery ↑
    + App size ↓
    + Storage ↓ 적게
    + Uninstall ↓
2.2.1.8 Low-end Device 의 critical 경험
사용자 device 분포:
  - Flagship (iPhone 15, Galaxy S24): RAM 8GB, Storage 256GB → 여유
  - Mid-range: RAM 4~6GB, Storage 64~128GB → 주의
  - Low-end (개도국 주류): RAM 2~3GB, Storage 16~32GB → critical

Low-end device 사용자의 storage 점유 1GB 가 사용자에게 큰 불편. App 가 다른 photo·video 를 삭제하라고 강요하는 결과 → uninstall.

이것이 Reinhardt (2016) 의 발견 — app size ↑ → uninstall ↑ 의 정량 관계.

직관 — Trade-off Ecosystem 의 풀이

저자 표현 (Ch.12.2): “Communication bandwidth and device performance are all part of the same device ecosystem, with tradeoffs.”

5 가지 제약은 독립 아닌 상호 trade-off ecosystem.

Cellular 통신 ↑ (bandwidth ↑):
  - Battery ↓ (cellular radio 가 power 소모)
  - 사용자 plan 비용 ↑

Wi-Fi only telemetry:
  - Cellular 비용 ↓ (사용자에게 좋음)
  - Telemetry 도달 지연 ↑ (분석에 안 좋음)
  - Wi-Fi user 비중 ↑ (selection bias)

CPU 로 local aggregation:
  - 통신 양 ↓ (battery ↓)
  - CPU ↑ (battery ↑) — 두 효과 cancel
  - 결과는 device 별 다름

Storage 로 caching:
  - 통신 ↓
  - App size ↑ → uninstall ↑

매 trade-off 가 다른 trade-off 의 입력.

이 ecosystem 의 함의:

  1. 단일 metric 으로 평가 불가 — Battery 단독 또는 통신량 단독으로 결정 불가. 종합 ROI.
  2. 사용자 segment 별 다른 결정 — Flagship 사용자는 caching 많이, low-end 는 적게. Personalization.
  3. A/B 실험으로 trade-off 정량화 — 어떤 비율이 ROI 최적인가는 실험으로만 답.

이 자체가 A/B 실험의 기회 — 5 제약 사이의 trade-off 를 데이터 기반으로 결정. 그러나 실험 자체가 5 제약 영향 받음 → recursive problem.

해결: 2 단계 실험 (Ch.5 의 slowdown 실험 패턴 차용):

  • Stage 1: 극단 비교 (heavy telemetry vs minimal) → effect 의 magnitude 추정
  • Stage 2: Stage 1 결과를 anchor 로 fine-tune

이 패턴이 thick client 의 trade-off 결정 표준.

3 왜 필요한가

Server·Client 차이 무시 시.

  • Web 가정 분석 — Mobile 실험을 web 로직으로 분석 → false conclusion
  • Multi-version 무시 — Multiple version 동시 활성을 단일 version 로 가정 → SRM
  • Selection bias — Wi-Fi user, frequent user 중심 sample → 일반화 실패
  • Battery·CPU 무시 — 사용자가 silently uninstall → metric 추적 불가
  • Country heterogeneity 무시 — 글로벌 평균이 어떤 국가도 대표 못 함

차이 인지 시.

  • Mobile-aware 분석 — Wi-Fi telemetry 지연, multi-version coexistence 보정
  • Quasi-experimental — Staged rollout 의 selection 보정
  • Guardrail 다층 — Battery, CPU, storage, app size 모두 모니터링
  • Country segmentation — 국가별 효과 분리 표준화

이 격차는 mobile-first 회사일수록 critical. Web 80% + Mobile 20% 회사: small impact. Mobile 80% + Web 20% 회사: existential.

4 응용 사례 — Microsoft Office Monthly Release 의 운영

저자 강조 (Ch.12.3 Implication 1): “in a typical monthly release, Microsoft Office ships with hundreds of features that rollout in a controlled manner to ensure safe deployment.”

4.0.0.1 Microsoft Office 의 thick client 실험 운영
Monthly release cycle:
  Week 1~2: 기능 개발 + integration
  Week 3:   Internal beta (직원)
  Week 4:   External beta (early adopter)
  Week 5:   Stable release

Stable release 이후:
  - 100s of features 가 default off (feature flag)
  - Server-side flag 으로 단계적 활성화
  - 1% → 5% → 25% → 100% staged
  - 문제 발견 시 server 에서 즉시 off
4.0.0.2 실험과 release 의 관계
Feature 출시 흐름:
  1. Build 에 새 feature ship (default off)
  2. Build 출시 후 1 주 — 안정 adoption 확인
  3. Server 에서 5% 사용자에 feature on (실험 시작)
  4. 1 주 모니터링 (Treatment vs Control 비교)
  5. 통계적 유의 + guardrail 통과 시 25% 확대
  6. 추가 모니터링 후 100%
  7. 문제 시 즉시 server-side off

핵심: Build 와 실험을 분리. Build 출시는 monthly cycle 강제, but 실험 자체는 server-side flag 로 일별 운영.

이 분리가 Implication 1 (parameterize) 의 운영 결과. Build cycle 의 제약 안에서 web 수준 의 실험 속도 회복.

5 코드 예시 — Multi-version Coexistence 추적

새 version 출시 후 multi-version 분포의 시간 변화 시뮬레이션.

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt

rng = np.random.default_rng(42)

# 시뮬레이션 설정
n_users = 100_000
total_days = 90  # 3 개월

# 사용자 update 행동 model:
# - 30% Eager: 평균 1 일 후 update
# - 40% Normal: 평균 7 일 후 update
# - 20% Lazy: 평균 30 일 후 update
# - 10% Resistant: 평균 90 일 후 update

user_type = rng.choice(["Eager", "Normal", "Lazy", "Resistant"],
                      n_users, p=[0.3, 0.4, 0.2, 0.1])

# 각 user 의 update 까지 일수 (지수 분포)
update_means = {"Eager": 1, "Normal": 7, "Lazy": 30, "Resistant": 90}
update_days = np.zeros(n_users)
for ut, m in update_means.items():
    mask = user_type == ut
    update_days[mask] = rng.exponential(m, mask.sum())

# Version 출시 schedule
# v1.0: t=0
# v1.1: t=30
# v1.2: t=60

releases = {"v1.0": 0, "v1.1": 30, "v1.2": 60}

# 각 day 별 version 분포
def get_version_at_day(day):
    """ day 시점에 사용자가 사용 중인 version 반환 """
    versions = []
    for u in range(n_users):
        # 사용자가 받은 latest version
        active_version = "v1.0"
        for ver, release_day in releases.items():
            if day >= release_day + update_days[u]:  # release 후 update 시간 경과
                active_version = ver
        versions.append(active_version)
    return pd.Series(versions).value_counts(normalize=True).to_dict()

# 분석
days_to_check = [0, 7, 14, 30, 37, 60, 67, 90]
results = []
for day in days_to_check:
    dist = get_version_at_day(day)
    results.append({"day": day, **dist})

df = pd.DataFrame(results).fillna(0).set_index("day")
print(df.round(3))

예상 출력 (시드 42).

       v1.0   v1.1   v1.2
day
0     1.000  0.000  0.000
7     0.484  0.000  0.000
14    0.347  0.000  0.000
30    0.214  0.000  0.000
37    0.146  0.554  0.000
60    0.075  0.343  0.000
67    0.058  0.339  0.401
90    0.029  0.215  0.547
직관 — Multi-version 분석의 함의

이 시뮬레이션이 보여주는 3 가지.

1. 새 version 출시 후 1 주에 도달 ~50%

v1.1 출시 1 주 후 (day 37): 사용자의 55.4% 가 v1.1. 즉 출시 직후 1 주는 transition 기간. 이 기간 분석은 selection bias 강.

2. 이전 version 의 long tail

v1.0 의 90 일 후 비중도 2.9% (~3000 명). “Resistant” 사용자 — 영원히 update 거부. 회사는 이 사용자도 support 해야 하나? Bug fix 만 한정?

3. Multi-version 동시 활성

Day 67 에 v1.0 5.8% + v1.1 33.9% + v1.2 40.1% — 3 version 동시 활성. Day 90 에는 4 version 까지 가능 (v1.3 출시 시).

분석 함의:

  • Cohort analysis — 같은 version 사용자만 비교 (cross-version confounder 제거)
  • Time stratification — 출시 후 stable 도달 시점 (34 주) 후만 분석
  • User type adjustment — Eager vs Resistant 의 selection 보정

이 multi-version 인지가 thick client 분석의 첫 mindset shift. Web 분석에서는 거의 없는 차원.

또한 Version migration 의 자체 효과:

  • Eager 사용자: 새 version 의 효과 빠르게 수용 → 모든 v1.1 metric 이 높음 (selection)
  • Resistant: 옛 version 유지 → v1.0 의 metric 도 stable

따라서 v1.1 vs v1.0 비교 자체가 user characteristic 비교가 됨. 이 confounder 가 Xu and Chen (2016) 의 quasi-experimental method 의 핵심 motivation.

6 관련 주제

선행 — Ch.12 시리즈

다음 글

관련 챕터

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: