Kohavi Ch.22.1~22.2 — Direct·Indirect Connection 6 사례 의 leakage 메커니즘

1 정의

정의: Connection (연결) 의 두 갈래

A/B 실험 의 leakage 는 매개체 (medium) 를 통해 발생. 매개체 의 가시성에 따라 2 갈래 (Kohavi, Tang, Xu, 2020, Ch.22).

• Direct connection: 두 unit 이 명시적 graph 로 연결. friendship, 통신, 같은 공간 같은 시간.
• Indirect connection: 두 unit 이 latent variable 또는 shared resource 로 연결. inventory, budget, training data, CPU, 시스템 상태.

직관

direct connection 은 눈에 보이는 매개체 — graph 가 있다. indirect connection 은 숨은 매개체 — 시스템 architecture 를 알아야 발견.

레슨: leakage 점검 시 항상 매개체 를 식별. 매개체 가 graph 라면 cluster·ego, 자원 이라면 split, 시간이라면 time-based, 사용자라면 unit 변경.

2 Direct Connection — 사례 2

2.1 Facebook · LinkedIn (사회 engagement)

Mechanism

2.1.0.1 가정

• 사용자 의 행동은 사회 neighborhood 의 행동에 영향
• 새 social engagement feature 의 가치 가 neighbor 사용 확률 에 증가

2.1.0.2 사례 (Eckles, Karrer, Ugander 2017; Gui et al. 2015)

• “video chat 을 친구가 사용하면 나도 사용한다”
• “친구가 message 하면 나도 reply 한다”
• “친구가 post 하면 나도 post 한다”

2.1.0.3 Treatment 시나리오

• LinkedIn “People You May Know” algorithm 개선 (Treatment)
• Treatment 사용자 의 invitation 발송 증가
• Control 사용자 가 invitation 받음 → Control 도 connection·메시지 증가
• 측정: total invitation·message 의 delta 가 underestimate

직관: 전파 의 비대칭

Treatment effect 가 Control 로 전파 되는 것: bias 가 underestimate 인 이유.

세계 1 (실험):
  Treatment delta = (T 효과) - (Control 의 baseline + spillover from T)
  = (T 효과) - (baseline + α·T 효과)
  = (1-α) · T 효과
  여기서 α 는 spillover 비율 (0 < α < 1)

세계 2 (full launch):
  실제 효과 = T 효과 (전부 Treatment)

→ 실험 측정 < 실제 효과 (1-α 배 underestimate)

α 의 크기는 graph 의 dense 와 engagement 강도 에 의존.

측정 신호

• 직접 spillover 측정: response metric (받은 메시지·invitation 의 reply rate)
• Bing/LinkedIn 의 historical data: spillover multiplier (메시지 1 건 → ecosystem value 0.5~0.7)

2.1.0.4 그림 22.1 (Kohavi 본문)

Treatment users send more messages → Control users receive → reply → Control metric (messages sent) 도 증가.

2.2 Skype Calls (양방향 통신)

Mechanism

2.2.0.1 가정

• 모든 call 은 2 명 이상 참여 — 본질적 direct connection
• call 품질 개선 → call 빈도 증가

2.2.0.2 Treatment 시나리오

• Skype 가 call 품질 개선 (Treatment)
• Treatment 사용자 call 발신 증가
• 발신 의 일부 가 Control 친구 에게 → Control 도 call 받음·answer
• Control 의 call 빈도 증가 (특히 callback)
• 측정: total call 의 delta 가 underestimate

직관: 비대칭 매개체

Skype 는 항상 양방향. message 는 비대칭 가능 (broadcast post 는 일방).

매개체 type	예시	spillover 강도
양방향 (synchronous)	call, video chat	매우 강
양방향 (async)	message, reply	강
비대칭 broadcast	post, like, share	중간
비대칭 publish-only	news feed view	약

레슨: 매개체 가 양방향 일수록 spillover 강함 → underestimate 큼.

3 Indirect Connection — 사례 6

3.1 Airbnb (Marketplace 재고)

Mechanism

3.1.0.1 가정

• 동일 inventory 가 Treatment·Control 사이 공유
• conversion 개선 시 booking 증가 → inventory 감소 → 다른 group 의 booking 도 감소

3.1.0.2 Treatment 시나리오 (Holtz 2018)

• Airbnb 가 conversion flow 개선 (Treatment 만)
• Treatment 사용자 의 booking +5%
• 동일 inventory → Control 사용자 가 볼 inventory 감소
• Control 의 booking -2% (inventory 부족 으로)
• 측정: delta = Treatment booking - Control booking → overestimate

3.1.0.3 수식

True effect (full launch):
  All users T → 모두 +5% conversion → inventory 도 더 빠르게 소진
  실제 booking 의 ceiling = inventory cap

실험 측정:
  Treatment booking: +5%
  Control booking: -2% (inventory contention)
  delta: 7% (실제는 5% 미만)

직관: 자원 경쟁 의 zero-sum

marketplace 의 inventory 는 zero-sum. T 가 차지 = C 가 잃음. delta 는 자동으로 overestimate (T 의 +x, C 의 -y, 합쳐서 (x+y) 의 큰 delta).

특히 공급 제약 marketplace (Airbnb, Uber, eBay) 에서 가장 심각.

3.2 Uber·Lyft (양면 시장)

Mechanism

3.2.0.1 가정 (Chamandy 2016)

• driver 의 supply 는 고정 (단기)
• rider 의 demand 가 변하면 가격·대기 시간 도 변함

3.2.0.2 Treatment 시나리오

• Uber 의 새 “surge price” 알고리즘 (Treatment)
• Treatment rider 의 ride opt-in 증가
• 동일 driver 풀 → driver utilization 증가 → 가격 상승
• Control rider 도 같은 가격 상승 → Control 의 ride 감소
• 측정: delta overestimate

직관: 가격 의 spillover

이건 일반 마켓플레이스와 다르다. 가격 자체가 spillover medium.

• Treatment 의 demand 증가 → 가격 ↑
• 가격 은 모든 사용자 에게 적용 → Control 도 영향
• Treatment 의 effect 가 Control 의 행동 을 변화

3.3 eBay (Auction)

Mechanism (Blake and Coey 2014)

3.3.0.1 가정

• 동일 item 의 입찰 자 들이 경쟁
• bidding 의 한계 가 다음 입찰 의 reserve

3.3.0.2 Treatment 시나리오

• Treatment 가 buyer 의 bidding 을 촉진 (rebate, promotion)
• Treatment 의 bid 가 더 높음 → winning bid 가 증가
• Control 의 winning 확률 감소 (T 가 우선)
• 측정: total transaction 의 delta overestimate

직관: 경쟁 의 zero-sum (Auction 버전)

inventory 와 비슷. 하나 의 item 에 대해 winning 가 경쟁 — Treatment win 증가 ⇒ Control win 감소.

수식:

P(C wins) = P(C bid > all others)
         = P(C bid > max(T bids))
T bid 분포 가 우 측으로 이동 → P(C wins) 감소

3.4 Ad Campaign (공유 budget)

Mechanism (Blake and Coey 2014; Kohavi et al. 2009)

3.4.0.1 가정

• 광고 캠페인 은 고정 budget (월 / 분기)
• click 비용 이 누적되어 budget 소진 시 광고 노출 중단

3.4.0.2 Treatment 시나리오

• Treatment 의 ad ranking 개선
• Treatment click 증가 → 공유 budget 빠르게 소진
• 월말 무렵 Control 광고 노출 감소 → Control click 감소
• 측정: delta overestimate (월말 효과 강함)

3.4.0.3 시간 의존 패턴

Day 1-15: budget 충분 → delta 비교적 정직
Day 16-30: budget 소진 → Control 의 노출 ↓ → delta 폭증

직관: 시간 의존 leakage

이 leakage 는 시간 에 따라 강도 가 변함. budget 소진 까지 의 시간 에 leakage 약함, 이후 강함.

레슨: ad campaign 실험 의 보고 시 기간 별 split 으로 leakage 진행 점검. 실무 해결책: budget split — variant traffic 비율과 동일하게 budget 할당.

3.5 Relevance Model (공유 학습 데이터)

Mechanism

3.5.0.1 가정

• relevance model 이 user click 데이터 로 학습 (continuous training)
• Treatment·Control 모두 의 click 데이터 가 공유 학습 데이터 풀 에 합류

3.5.0.2 Treatment 시나리오

• Treatment model 이 better click prediction (예: target.com 을 “shoes” 검색 의 1 위로)
• Treatment user 의 click 이 더 informative (model 이 학습 가능한 양질 데이터)
• 다음 학습 round → Control model 도 같은 양질 데이터 반영
• 시간이 지날수록 Control 의 ranking 도 개선
• 측정: 시간 흐를수록 delta underestimate

직관: 학습 의 cross-contamination

이 leakage 는 시간 dependence 가 가장 강함. 실험 초기 → bias 작음, 실험 후기 → bias 큼 (학습 누적).

해결: variant 별 분리 학습 — Treatment data 는 Treatment model 만, Control data 는 Control model 만. 단점: training data 가 절반 으로 → 작은 model 의 성능 저하.

3.6 CPU Contention (공유 hardware)

Mechanism

3.6.0.1 가정

• Treatment·Control 의 request 가 동일 server 에서 처리
• Treatment 의 bug 또는 새 feature 가 CPU 점유 가 큼

3.6.0.2 Treatment 시나리오

• Treatment 의 새 feature 가 CPU·memory 점유 증가
• 같은 machine 의 Control request 의 응답 도 늦어짐
• Control 의 latency 악화
• 측정: delta (Treatment latency - Control latency) underestimate (의 부정 효과)

직관: 의식하지 못하는 leakage

이건 가장 위험 — code 에 명시적 dependency 가 없는데 leakage. shared infrastructure 는 모든 곳에 있다 (cache, rate limiter, log pipeline, …).

해결: ramp 단계 (small datacenter → 1% → 10%) 에서 outlier 탐지 + monitoring. 실무: Treatment·Control 의 server 분리 (단, heterogeneity confounding 위험).

3.7 Sub-User Experiment Unit (page-level randomization)

Mechanism

3.7.0.1 가정

• 일반적으로 user-level randomization 이 표준
• 일부 실험 은 page·session·query 단위 randomization (smaller unit, more sample)

3.7.0.2 Treatment 시나리오

• Treatment 가 page latency 개선
• 같은 user 가 page 마다 다른 variant 경험 (mixed experience)
• 빠른 page 후 느린 page 시 — 행동 이 학습 효과 로 변화 (anchoring)
• Treatment effect 가 Control page 에 spillover

3.7.0.3 latent connection

• 매개체: 동일 사용자 — Treatment·Control page 모두 한 사람의 경험
• 사용자 의 학습·기억·기대 가 매개

직관: smaller unit 의 hidden cost

작은 unit 으로 randomize 하면 sample 증가 → power ↑. 하지만 user-level learning effect 가 있으면 spillover.

규칙: smaller unit 으로 갈수록 learning effect 가 없음을 가정 — 가정 점검 필수. 대부분 의 user-facing UI 변화 는 user-level 이 안전.

4 비교

사례	매개체	bias 방향	bias 강도	시간 의존	해결 패턴
Facebook 메시지	친구 graph	underestimate	중간	약	network-cluster, ego-centric
Skype call	통신 양방향	underestimate	강	약	network-cluster
Airbnb 재고	inventory	overestimate	강	중간	geo, time
Uber surge	가격·driver	overestimate	강	중간	geo, time
eBay auction	item	overestimate	중간	약	geo
Ad budget	공유 budget	overestimate	강	강 (월말)	budget split
Relevance model	학습 data	underestimate	강	강 (누적)	model split
CPU contention	hardware	underestimate (의 -)	변동	약	server split, monitoring
Sub-user unit	사용자 학습	underestimate	약~중	약	user-level fallback

5 Python 예시 — leakage 정도 시뮬레이션

import numpy as np

np.random.seed(2026)

def simulate_social_spillover(n_users=20000, alpha=0.3, true_lift=0.10):
    """
    direct connection 의 spillover model.
    alpha: T → C 전파 비율 (0 < alpha < 1).
    true_lift: T 의 진짜 lift.
    """
    assignment = np.random.randint(0, 2, size=n_users)
    base_p = 0.20

    # Treatment: 진짜 lift 적용
    p_t = base_p * (1 + true_lift)
    # Control: spillover 받음 (Treatment 의 alpha 배 effect)
    p_c = base_p * (1 + alpha * true_lift)

    p = np.where(assignment == 1, p_t, p_c)
    y = np.random.binomial(1, p, size=n_users)

    rate_t = y[assignment == 1].mean()
    rate_c = y[assignment == 0].mean()
    observed_lift = (rate_t - rate_c) / rate_c
    return rate_t, rate_c, observed_lift

for alpha in [0.0, 0.2, 0.5, 0.8]:
    rate_t, rate_c, obs = simulate_social_spillover(alpha=alpha)
    print(f"alpha={alpha:.1f}: T={rate_t:.4f}, C={rate_c:.4f}, "
          f"obs_lift={obs:.2%}, true_lift=10.00%, "
          f"underestimate_factor={(1-alpha):.1%}")

시뮬레이션 해석

α=0.0: spillover 없음 → 측정 lift ≈ 진짜 10% α=0.5: spillover 절반 → 측정 lift ≈ 5% α=0.8: spillover 강함 → 측정 lift ≈ 2%

직관: spillover 비율 α 만큼 측정 효과 가 (1-α) 배 축소 — direct connection 의 typical underestimate.

6 응용 / 진단 체크리스트

• 매개체 식별: 코드·architecture·graph·자원·시간·사용자 unit
• bias 방향 추정: 매개체 가 zero-sum 자원 → over, positive externality → under
• 시간 의존 패턴 점검: budget·learning 은 강한 시간 의존
• ramp 의 outlier 탐지 (small datacenter, 1% → 50% 비교)
• 의심 시 isolation 적용 — F22-3 의 4 갈래 중 매개체 에 맞는 것

7 관련 주제

• F22-0 overview — Ch.22 전체 지도
• F22-2 — Practical Solutions + Ecosystem Value
• F22-3 — Isolation 4 갈래 + edge-level + monitoring
• Ch.14 (F-KOH14) — Randomization unit 의 trade-off (smaller unit 의 leakage 위험)
• D-18 — Time-varying treatment (time-based randomization 의 친척)

출처

• Kohavi, Tang, Xu (2020). Trustworthy Online Controlled Experiments. Ch.22.
• Eckles, Karrer, Ugander (2017). “Design and Analysis of Experiments in Networks.”
• Gui, Xu, Bhasin, Han (2015). “Network A/B Testing.” WWW 2015.
• Chamandy (2016). “Experimentation in a Ridesharing Marketplace.” Lyft Engineering.
• Blake and Coey (2014). “Why Marketplace Experimentation is Harder.” EC 2014.
• Holtz (2018). “Limiting Bias from Test-Control Interference.” MIT Thesis.
• Kohavi, Longbotham et al. (2009). “Seven Pitfalls.”
• Barrilleaux and Wang (2018). “Spreading the Love in the LinkedIn Feed.”