Kwangmin Kim - Results Summary 와 Visualization — Scorecard · Segment Drill

1 정의

정의: Scorecard Visualization 의 본질

Kohavi (2020) Ch.16.3 의 시각화는 단순 표가 아닌 의사결정 도구. Trust 검증, hierarchy, statistical clarity, accessibility 의 4 차원이 결합.

1.0.0.1 4 가지 원칙

원칙	핵심
Trust Signal	SRM 등 trust check fail 시 scorecard 숨김 또는 명시 warning
Hierarchy	OEC + critical metric 강조, 덜 중요 metric 은 숨김 가능
Statistical Clarity	Relative change + significance + color coding
Accessibility	Audience (marketer~engineer) 별 layered view

원문 (Ch.16.3): “Ultimately, the goal is to visually summarize and highlight key metrics and segments to guide decision makers.”

핵심 통찰: 시각화는 데이터를 보여주는 도구가 아닌 decision quality 의 도구. 어떤 정보가 visible? 어떤 순서? 어떤 색? — 모든 design choice 가 의사결정자의 행동에 영향.

2 개념 및 원리

2.1 4 가지 원칙 — 깊이 있는 풀이

2.1.1 원칙 1 — Trust Signal Highlight

저자 명시: “Highlight key tests, such as SRM, to clearly indicate whether the results are trustworthy. For example, Microsoft’s experimentation platform (ExP) hides the scorecard if key tests fail.”

2.1.1.1 Microsoft ExP 의 SRM Gate

Scorecard 표시 logic:

if SRM_test_passed AND AA_test_passed:
    show_full_scorecard()
elif SRM_test_failed:
    show_warning("SRM detected — scorecard hidden")
    do_not_show_scorecard()
elif AA_test_failed:
    show_warning("AA test failed — results may be biased")
    show_scorecard_with_warning()

2.1.1.2 Why hide?

SRM 의미:
  - Treatment vs Control 사용자 비율이 design 과 다름
  - 50/50 design 인데 48/52 → 무언가 잘못됨
  - 분석 결과 자체 신뢰 불가

만약 scorecard 표시 시:
  - 사용자가 "+5% lift" 봄
  - 의사결정 시 사용
  - SRM 의 영향 인지 안 됨
  - 잘못된 launch decision

따라서 hide:
  - 결과가 invisible
  - 사용자가 "왜?" 질문
  - SRM 분석 → root cause fix
  - Fix 후 재실험

이 hard gate 가 platform 의 enforcement. Soft warning 은 사용자가 무시 가능.

2.1.1.3 Trust Check 의 list

Standard trust checks:
  1. SRM (Sample Ratio Mismatch)
  2. AA test (variance check)
  3. Pre-period equivalence
  4. Filter bias
  5. Coverage check (모든 사용자가 분석 포함)
  6. Variance estimation 정확성

각 check 의 결과가 dashboard 의 첫 부분에 visible. Pass 시 green, fail 시 red.

2.1.2 원칙 2 — Hierarchy

저자 명시: “Highlight the OEC and critical metrics, but also show the many other metrics, including guardrails, quality, and so on.”

2.1.2.1 Layered presentation

Top of scorecard:
  - OEC (단일 가장 중요한 metric)
  - Direction + magnitude + significance

Second layer:
  - Driver metrics (Ch.6)
  - User-facing metric (engagement, retention)

Third layer:
  - Guardrail metrics (Ch.6)
  - Performance, error rate, crash

Fourth layer (collapsible):
  - Diagnostic metrics
  - Local feature metric
  - Debugging info

2.1.2.2 사용자 의 cognitive load

1000+ metric 동시 표시:
  - 사용자가 "어디 보지?" overwhelm
  - Decision quality ↓

Layered hierarchy:
  - 사용자가 OEC 부터 봄
  - 의문 시 driver, guardrail 까지 drill
  - 필요 시 diagnostic 까지

이 hierarchy 가 cognitive load 의 progressive 분산.

2.1.3 원칙 3 — Statistical Clarity

저자 명시: “Present metrics as a relative change, with clear indications as to whether the results are statistically significant. Use color-coding and enable filters, so that significant changes are salient.”

2.1.3.1 Relative vs Absolute

Absolute:
  Treatment: $1.05 revenue/user
  Control: $1.00 revenue/user
  Difference: +$0.05

Relative:
  Treatment: $1.05 revenue/user
  Control: $1.00 revenue/user
  Lift: +5.00%

선호:
  Relative 가 cross-context 비교 가능
  Decision 의 input 으로 더 직관적
  대부분 platform 의 default

2.1.3.2 Color coding 의 표준

Green: Significant positive change (good)
Red: Significant negative change (bad)
Yellow: Marginal significance
Gray: Not significant (noise)

각 metric 의 direction 차이:
  Engagement ↑: green
  Latency ↑: red (latency 는 lower-better)
  Crash rate ↑: red

2.1.3.3 Filter 의 가치

사용자가 filter 가능:
  - "Show only significant" (p < 0.05)
  - "Show only OEC + guardrail"
  - "Show only mobile segment"

이 filter 가 1000+ metric 환경에서 navigation 의 본질.

2.1.4 원칙 4 — Accessibility

저자 강조: “scorecard visualizations should be accessible to people with various technical backgrounds, from Marketers to Data Scientists and Engineers to Product Managers.”

2.1.4.1 Audience 별 layered view

Marketing audience:
  - High-level metric only
  - Business KPI (revenue, conversion)
  - 단순 visualization
  - 통계적 detail 숨김

PM audience:
  - OEC + 주요 driver metric
  - Segment 분석
  - Decision 의 도구

Data Scientist:
  - 모든 metric
  - Statistical detail (p-value, CI)
  - Raw data access
  - Custom query

Engineer:
  - System metric (latency, error)
  - Code path 분석
  - Performance profiling

Executive:
  - Top-line summary
  - 분기 단위 누적 effect
  - Strategic 의 input

2.1.4.2 “Hiding” debugging metric

저자 명시: “This may also mean hiding some metrics, such as the debugging metrics from the less technical audience, to reduce confusion.”

Debugging metric 의 예:
  - Cache hit rate
  - Server-side latency p99
  - Database connection count

Marketing audience 가 보면:
  - "Cache hit rate ↓ 5%? 무슨 의미?"
  - Confusion
  - Trust ↓

해결:
  - Default view 에서 숨김
  - "Show advanced metrics" toggle
  - Audience 별 default 다름

2.1.4.3 Information Accessibility 의 culture

저자 강조: “Information accessibility helps establish a common language for definitions and a culture of transparency and curiosity, encouraging employees to run experiments and learn about how changes impact the business or how Finance can tie A/B test results to business outlook.”

Accessibility 의 effect:
  1. Common language: 모든 직원이 같은 metric 인지
  2. Transparency: 결과가 hide 되지 않음
  3. Curiosity: "왜 이 metric 변동?" 질문
  4. Experimentation culture: 더 많이 실험
  5. Cross-functional collaboration: Finance ↔ Engineering ↔ PM

이 cultural impact 가 visualization 의 hidden 가치.

직관 — Layered Accessibility 의 design pattern

2.1.4.4 공통 layer + audience-specific layer

모든 audience 의 base:
  - Top: OEC (single number)
  - Middle: 5~10 critical metrics
  - Bottom: trust check status

Audience 별 추가:
  - Marketer: business term
  - Engineer: system metric
  - DS: statistical detail
  - Exec: 분기 trend

2.1.4.5 Toggle 또는 Mode

Default: PM mode (가장 일반적)
Toggle: "Show advanced metrics"
Mode: "Engineer view", "Marketer view"

선택:
  - Toggle: 단순, 모든 사용자 가 같은 base 시작
  - Mode: 더 personalized, but more complex

2.1.4.6 사례 — Microsoft ExP 의 mode

Microsoft 의 audience modes:

PM Mode:
  - OEC, driver, guardrail
  - Segment 분석

Engineer Mode:
  - + Performance metrics
  - + Error logs
  - + Code path 분석

DS Mode:
  - + Raw statistical detail
  - + Multiple testing 보정
  - + Custom segment

Exec Mode:
  - 분기 cumulative
  - Cross-experiment 통합

이 mode 별 view 가 1000+ metric 환경의 navigation 도구.

2.2 Per-Experiment vs Per-Metric View

저자 명시: “The visualization tool is not just for per-experiment results but is also useful for pivoting to per-metric results across experiments.”

2.2.1 Per-Experiment View (default)

하나의 실험을 보는 관점:
  실험 X 의 모든 metric impact
  - OEC: +5%
  - Driver 1: +3%
  - Driver 2: +2%
  - Guardrail: no significant change

목적:
  - 이 실험을 launch?
  - 이 실험의 segment 효과?
  - 이 실험의 trade-off?

2.2.2 Per-Metric View (advanced)

저자 강조: “While innovation tends to be decentralized and evaluated through experimentation, the global health of key metrics is usually closely monitored by stakeholders.”

하나의 metric 을 보는 관점:
  Metric Y (예: revenue) 의 모든 실험 impact

  실험 A: +5% (launched)
  실험 B: +3% (in progress)
  실험 C: -2% (rejected)
  실험 D: +1% (in progress)
  ...

목적:
  - 이 metric 은 어떻게 trend?
  - 어느 실험이 이 metric 에 가장 영향?
  - 이 metric 을 hurt 하는 실험은?

2.2.2.1 Stakeholder 의 가치

Metric owner (예: Finance team 의 revenue):
  - 회사 의 revenue 가 어떻게 변하나?
  - 각 분기 launched 실험 의 cumulative effect?
  - Negative impact 실험 detect

Action:
  - Subscribe to metric
  - Email digest (top 영향 실험)
  - Approval process (negative 시 conversation)

2.2.3 2 가지 Optional Feature

저자 명시.

2.2.3.1 Feature 1 — Subscription

Stakeholder 가 metric 에 subscribe:
  Finance team → revenue
  Customer service → support ticket count
  Engineering → latency

Email digest (weekly):
  "Your subscribed metrics:
   - revenue: +1.5% this week (driven by experiment X, Y, Z)
   - error rate: -2% this week (driven by experiment A)"

이 digest 가 metric owner 의 awareness.

2.2.3.2 Feature 2 — Approval Process for Negative

저자 명시: “If an experiment has a negative impact, the platform can initiate an approval process, where it forces the experiment owner to start a conversation with the metrics owners before the experiment can be ramped up.”

Approval flow:

실험 X 의 ramp 시도:
  ↓
Platform 이 metric impact 분석:
  - Engagement: +5% (positive)
  - Revenue: -2% (negative, threshold 위반)
  ↓
Auto-trigger approval:
  - 실험 owner 에 notify
  - Revenue owner (Finance) 에 notify
  ↓
Conversation:
  - Trade-off 토론
  - Engagement +5% vs Revenue -2% 어느 우선?
  - Long-term effect 예상?
  ↓
Decision:
  - Launch with awareness
  - Modify experiment (revenue 보호)
  - Reject

2.2.3.3 Cultural impact

저자 강조: “Not only does this drive transparency regarding experiment launch decisions, it encourages discussion, which increases the overall knowledge of experimentation in the company.”

이 process 의 hidden benefit:

1. Transparency:
   - Negative impact 가 hidden 안 됨
   - Stakeholder 가 awareness

2. Learning:
   - 분야 별 trade-off 학습
   - Cross-functional knowledge

3. Better decisions:
   - 단순 OEC 만 보는 것이 아닌 systemic view
   - Conflicting metric 의 명시 처리

4. Ownership:
   - Metric owner 가 자기 metric 에 책임
   - Engineering decision 에 input

이 process 가 modern A/B platform 의 mature 단계.

2.2.4 Institutional Memory Gateway

저자 명시: “The visualization tools can also be a gateway to accessing institutional memory (see Chapter 8).”

시각화 도구 → 메타분석:
  per-metric view 가 자연스러운 메타분석

Metric Y 의 모든 실험 (3 년):
  - 200 개 launched 실험
  - Cumulative effect on Y
  - Pattern 식별 (어떤 type 의 변경이 효과?)
  - Best practice 도출

이것이 Ch.8 의 institutional memory 의 운영 도구.

2.3 Run·Fly 의 Advanced Features

저자 명시 (Ch.16.3): “as an organization moves into the Run and Fly phases of experimentation maturity, how many metrics your organization uses will continue to grow, even into the thousands.”

2.3.1 Feature 1 — Metric Categorization

저자 명시 산업 사례.

2.3.1.1 LinkedIn — 3 Tier

Tier 1: Companywide
  - Revenue, DAU, retention
  - 회사 단위 critical
  - 모든 실험에서 측정

Tier 2: Product Specific
  - 각 product 별 critical
  - LinkedIn Search, LinkedIn Recruiter 등
  - 해당 product 의 실험에서 강조

Tier 3: Feature Specific
  - 작은 feature 별
  - 해당 feature 실험에서 측정
  - 다른 실험에서는 hidden

2.3.1.2 Microsoft — 4 Tier

Tier 1: Data Quality
  - SRM, sample size
  - Trust check

Tier 2: OEC
  - 단일 가장 중요 metric
  - Decision 의 primary input

Tier 3: Guardrail
  - System health
  - User experience guardrail

Tier 4: Local features/diagnostic
  - Specific feature metric
  - Debugging info

이 tier 가 visualization 의 organization. Default view 가 tier 1~2, advanced 가 3~4.

2.3.2 Feature 2 — Multiple Testing

저자 명시 (Ch.16.3, Romano et al. 2016): “Multiple testing becomes more important as the number of metrics grow.”

2.3.2.1 문제

1000 metric × 0.05 alpha:
  Expected false positive: 50

실험가 의 question:
  "왜 이 metric 변동? Treatment 와 무관한데"
  답: 50 개의 False positive 중 하나

Confusion:
  - Decision 의 noise
  - "Significant" 의 의미 모호

2.3.2.2 해결 옵션

저자 명시 (Ch.17 cross-reference, Benjamini-Hochberg).

Option 1 — Strict p-value:
  alpha = 0.001 instead of 0.05
  False positive expected: 1 (out of 1000)

  Trade-off:
  + Less false positive
  - More false negative (real effect missed)

Option 2 — Bonferroni correction:
  Adjusted alpha = 0.05 / N_tests
  Conservative

Option 3 — Benjamini-Hochberg (FDR):
  Sort p-values
  Adjust threshold
  False discovery rate 의 control

Option 4 — User-controlled filter:
  Default: stricter threshold
  Toggle: 모든 marginal significance 표시

대부분 platform: Option 1 또는 Option 4 의 hybrid.

2.3.3 Feature 3 — Metrics of Interest 자동 식별

저자 명시.

2.3.3.1 Logic

factors = [
    metric_importance,  # company priority (tier)
    statistical_significance,  # p-value
    false_positive_adjustment,  # multiple testing
    direction_alignment,  # Treatment 기대와 일치?
    magnitude  # effect size
]

score = combine(factors)
highlight = score > threshold

2.3.3.2 예시 score

Metric A:
  - Importance: tier 1 (high)
  - Significance: p=0.001 (very strong)
  - Direction: aligned with hypothesis
  - Magnitude: +5% (large)
  Score: 10/10 → highlight

Metric B:
  - Importance: tier 3 (low)
  - Significance: p=0.04 (marginal)
  - Direction: unexpected
  - Magnitude: +0.2% (small)
  Score: 3/10 → don't highlight

2.3.3.3 “Unexpected” 의 가치

Surprising pattern detection:
  - 어떤 metric 이 expected 와 반대 방향?
  - 어떤 segment 에서 unusual?
  - 자동 highlight

이 surprising metric 이 종종 가장 중요한 insight:
  - Hypothesis 의 부족 인지
  - 새 feature idea
  - Bug 발견

2.3.4 Feature 4 — Related Metrics

저자 강조: “A metric’s movement or lack of movement can often be explained by other related metrics. For example, when click-through rate (CTR) is up, is it because clicks are up or because page views are down?”

2.3.4.1 CTR 의 분해

CTR = clicks / pageviews

CTR 변화:
  Option A: clicks ↑, pageviews same
    → 사용자가 더 click 함 (engagement ↑)
  Option B: clicks same, pageviews ↓
    → Pageview 가 줄어 ratio ↑ (engagement 그대로)
  Option C: clicks ↓, pageviews ↓ (더 많이 ↓)
    → 둘 다 ↓ but ratio ↑ (degraded)

같은 CTR ↑ 가 3 가지 다른 의미.

2.3.4.2 Related metric 의 중요성

CTR ↑ 만 보면:
  - "Engagement 좋아짐" 결론
  - Launch 결정

Related metrics (clicks, pageviews) 동시 보면:
  - Option A: launch (real engagement ↑)
  - Option B: investigate (왜 pageview ↓?)
  - Option C: reject (degradation)

이 related metric 분석이 surface-level decision 의 risk 회피.

2.3.4.3 Variance Reduction Variant

저자 명시: “Another example is metrics with high variance such as revenue. Having a more sensitive, lower variance version such as trimmed revenue or other indicators, allows more informed decisions.”

High variance metric:
  Revenue: skewed, outlier 많음
  - Median 0
  - Top 1% 이 80% revenue
  - 분산 매우 큼

Trimmed version:
  Revenue (top/bottom 1% 제거):
  - 분산 ↓
  - Sensitivity ↑
  - Same effect 의 더 빠른 detect

복합 사용:
  Both 표시:
  - "Revenue +5%, but only +2% in trimmed (top 1% noise)"
  - 더 정확한 understanding

가정 — Multiple Testing 무시 시

가정: 실험 platform 이 1000 metric 표시, alpha=0.05 의 standard threshold.

2.3.4.4 1 분기 후 시나리오

100 실험 × 1000 metric = 100,000 statistical tests
Expected false positive: 5,000 (5%)

실험가 의 confusion:
  - "Engagement 5% 가 statistically significant?" → 진짜?
  - 실제: 5,000 개 false positive 중 하나일 수 있음
  - Trust 위기

Decision 의 영향:
  - False positive launch (rejected 했어야 했음)
  - False positive로 decision metrics 왜곡
  - 분석가 의 reputation 위험

2.3.4.5 해결 — Multiple Testing Correction

Benjamini-Hochberg (FDR control):
  100,000 tests
  FDR target: 5%
  Adjusted threshold: 동적 (각 metric 의 p-value 따라)

결과:
  Significant metric 수 감소 (50% 정도)
  False discovery 5% 이내
  Trust 회복

2.3.4.6 Platform 의 enforcement

Modern platform:
  - Default: BH correction 적용
  - Marginal significance 는 다른 색
  - "Show all significant" toggle 시 noise 인지
  - 사용자가 의식적 결정

이 enforcement 가 1000+ metric 환경의 trust 의 본질. Platform 이 자동 보호.

3 왜 필요한가

Visualization 부재 또는 약함 시.

Decision quality ↓ — 잘못된 metric 강조, OEC invisible
Trust 위기 — SRM 같은 trust check 무시
Cognitive overload — 1000 metric 의 chaos
Multiple testing noise — False positive 가 decision 왜곡
Stakeholder 격리 — Metric owner 가 awareness 없음

활성 시.

Decision quality ↑ — OEC + significance 명확
Trust signal — SRM gate, AA test 자동
Cognitive load 분산 — Layered, audience 별
Multiple testing 보정 — BH 등 자동 적용
Stakeholder 통합 — Subscription, approval process

이 격차가 platform 의 의사결정 quality. 시각화는 단순 보기 도구가 아닌 decision tool.

4 응용 사례 — LinkedIn Concourse

LinkedIn 의 실험 dashboard (Concourse):

Top section:
  - 실험 ID, owner, 상태
  - Trust checks: SRM (passed/failed), AA (passed/failed)
  - 만약 SRM failed → 빨간 banner + scorecard hide

OEC section:
  - 단일 가장 중요 metric
  - Lift + p-value + CI
  - Color coded

Tier 1 (Companywide):
  - Revenue, DAU, retention
  - 모든 실험에서 표시

Tier 2 (Product specific):
  - LinkedIn Search 의 search quality
  - 해당 product 의 실험만 표시

Tier 3 (Feature specific):
  - 특정 feature metric
  - 해당 feature 실험만

Segment drill:
  - Country, device, user tier
  - 자동 highlight (unexpected pattern)

Multiple testing:
  - BH correction 자동 적용
  - "Significant after correction" badge

Subscription:
  - 사용자 별 metric subscription
  - Email digest

이 dashboard 가 LinkedIn 의 일별 운영. 모든 PM, engineer, DS 가 매일 access.

5 코드 예시 — Multiple Testing 보정 (Benjamini-Hochberg)

100 metric 의 BH correction 의 효과.

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

rng = np.random.default_rng(42)

# 가상 100 metric 의 p-value
# 가정: 90% 가 null (effect 0), 10% 가 진짜 effect
n_metrics = 100
n_true_effects = 10

# Null metric 의 p-value (uniform 0~1)
p_null = rng.uniform(0, 1, n_metrics - n_true_effects)

# True effect metric 의 p-value (small, 0.001~0.05)
p_true = rng.uniform(0.001, 0.05, n_true_effects)

# Combine
all_p = np.concatenate([p_null, p_true])
all_truth = np.concatenate([np.zeros(n_metrics - n_true_effects), np.ones(n_true_effects)])

# === Naive (no correction) ===
print("=== Naive (alpha=0.05) ===")
naive_significant = all_p < 0.05
naive_tp = sum(naive_significant & (all_truth == 1))
naive_fp = sum(naive_significant & (all_truth == 0))
print(f"Total significant: {naive_significant.sum()}")
print(f"True positive: {naive_tp}")
print(f"False positive: {naive_fp}")
print(f"FDR (false discovery rate): {naive_fp / max(1, naive_significant.sum()) * 100:.1f}%")

# === Bonferroni correction ===
print("\n=== Bonferroni (alpha=0.05/N) ===")
bonf_threshold = 0.05 / n_metrics
bonf_significant = all_p < bonf_threshold
bonf_tp = sum(bonf_significant & (all_truth == 1))
bonf_fp = sum(bonf_significant & (all_truth == 0))
print(f"Adjusted threshold: {bonf_threshold:.6f}")
print(f"Total significant: {bonf_significant.sum()}")
print(f"True positive: {bonf_tp}")
print(f"False positive: {bonf_fp}")
print(f"Power: {bonf_tp / n_true_effects * 100:.1f}%")

# === Benjamini-Hochberg ===
print("\n=== Benjamini-Hochberg (FDR=0.05) ===")
sorted_idx = np.argsort(all_p)
sorted_p = all_p[sorted_idx]
sorted_truth = all_truth[sorted_idx]

# BH threshold for each rank
ranks = np.arange(1, n_metrics + 1)
bh_thresholds = (ranks / n_metrics) * 0.05

# Find largest k such that sorted_p[k-1] <= bh_threshold[k-1]
significant_mask_sorted = sorted_p <= bh_thresholds
if significant_mask_sorted.any():
    last_significant = np.where(significant_mask_sorted)[0].max()
    bh_significant_sorted = np.zeros(n_metrics, dtype=bool)
    bh_significant_sorted[:last_significant + 1] = True
    bh_tp_sorted = sum(bh_significant_sorted & (sorted_truth == 1))
    bh_fp_sorted = sum(bh_significant_sorted & (sorted_truth == 0))
    print(f"Significant: {bh_significant_sorted.sum()}")
    print(f"True positive: {bh_tp_sorted}")
    print(f"False positive: {bh_fp_sorted}")
    print(f"FDR: {bh_fp_sorted / max(1, bh_significant_sorted.sum()) * 100:.1f}%")
    print(f"Power: {bh_tp_sorted / n_true_effects * 100:.1f}%")
else:
    print("No significant metrics")

# === 비교 ===
print("\n=== 비교 ===")
print(f"Method        | Significant | TP | FP | FDR    | Power")
print(f"Naive         | {naive_significant.sum():>11} | {naive_tp:>2} | {naive_fp:>2} | {naive_fp/max(1,naive_significant.sum())*100:>5.1f}% | {naive_tp/n_true_effects*100:>5.1f}%")
print(f"Bonferroni    | {bonf_significant.sum():>11} | {bonf_tp:>2} | {bonf_fp:>2} | {bonf_fp/max(1,bonf_significant.sum())*100:>5.1f}% | {bonf_tp/n_true_effects*100:>5.1f}%")
if significant_mask_sorted.any():
    print(f"BH (FDR=0.05) | {bh_significant_sorted.sum():>11} | {bh_tp_sorted:>2} | {bh_fp_sorted:>2} | {bh_fp_sorted/max(1,bh_significant_sorted.sum())*100:>5.1f}% | {bh_tp_sorted/n_true_effects*100:>5.1f}%")

직관 — 3 가지 방법의 trade-off

이 시뮬레이션의 메시지.

5.0.0.1 Naive 의 함정

Naive (alpha=0.05):
  - Many false positives (~5 of 90 null)
  - High recall (most true effects detected)
  - FDR 약 33% (false 의 비율)
  - Trust 약함

5.0.0.2 Bonferroni 의 conservative

Bonferroni:
  - Threshold 매우 strict (0.0005)
  - False positive 거의 0
  - Power 낮음 (true effect 의 일부만 detect)
  - Conservative trade-off

5.0.0.3 BH 의 균형

Benjamini-Hochberg:
  - FDR 5% control (false 의 비율 보장)
  - Power 보통 (대부분 true detect)
  - 산업 표준

5.0.0.4 실무 선택

Audience 별:
  Marketer: BH (단순, balanced)
  Engineer: Bonferroni (conservative)
  Data Scientist: BH 또는 custom

Default platform:
  - BH (가장 일반적)
  - Toggle 가능 (advanced user)

이 default 가 platform 의 enforcement.
대부분 사용자가 default 사용 → systemic FDR control.

6 Ch.16 시리즈 마무리

3 편 완료:

F16-0 — Scaling 의 motivation, 3 stage pipeline, dual NRT/batch path
F16-1 — Data processing (sort, clean, enrich), computation architecture
F16-2 — Visualization 의 4 원칙, audience accessibility, multiple testing

다음: Ch.18 (Variance/CUPED, 3 편).

7 관련 주제

선행

다음 챕터

F18-* — Ch.18 Variance/CUPED

관련 챕터

F6-* — Ch.6 조직 지표 (tier system)
F7-* — Ch.7 OEC — Decision 의 primary input
F8-* — Ch.8 제도적 기억 gateway
F21-* — Ch.21 SRM — Trust gate

다른 카테고리 연결