1 정의

정의: Plan 단계의 핵심 결정

실험 설계 1 단계 (Plan) 에서 분석가가 결정하는 4 가지 (Buisson, 2021, Ch.8):

Business Goal: 회사의 궁극적 목적 (한 단어, 측정 안 해도 OK)
Target Metric: Business Goal 을 정량화한 측정 가능 변수
Intervention: 변경되는 것 (Treatment)
Behavioral Logic: 1 → 4 → 3 → 2 의 인과 메커니즘

이 4 결정이 실험의 전체 방향 결정. 잘못 결정하면 실험이 통계적으로 완벽해도 비즈니스적으로 실패.

직관 — Goal 과 Metric 의 분리가 왜 필요한가

분석가의 자연스러운 직감: “Goal 이 매출이면 Metric 도 매출. 같지 않은가?”

분리의 가치:

Goal: 회사의 진짜 의도 (정성적 표현 가능)
Metric: 측정 절차가 명확한 변수

분리 없이:

“이 실험으로 매출 늘리고 싶다” — 진의는 명확하지만 측정 어떻게?
“고객 경험 개선” — 측정 불가

분리 후:

Goal: “더 좋은 고객 경험”
Metric: “예약 후 7 일 내 NPS 점수 ≥ 8”
진의 + 측정 절차 모두 명시

→ Goal 이 비즈니스 합의의 도구, Metric 이 분석가의 도구.

2 Business Goal — 한 단어 합의

2.1 좋은 Goal 의 조건

Goal 의 단계

회사의 궁극 목적은 “이익”. 그러나 이익은 너무 추상적. 한 단계 구체화:

차원	예	적합성
너무 추상	“이익 증가”	모호 (어떻게?)
한 단계 구체	“매출 증가” / “비용 감소” / “retention 증가” / “가격 결정”	권장
너무 구체	“이번 분기 ROI 정확히 12.5%”	유연성 부족

권장: 한 단계 구체. 합의 가능 + 다양한 metric 매핑 가능.

직관 — Goal 의 합의가 드러내는 부서 갈등

흔한 시나리오 (재방문):

마케팅: “비용 줄이고 싶다”
제품: “매출 늘리고 싶다”
운영: “만족도 늘리고 싶다”
경영: “ROI 향상”

같은 실험에 대해 4 개 부서가 4 개 Goal 가정. ToC 명시 안 하면 결과 해석 모호:

실험 결과: “매출 +5%, 비용 +2%, 만족도 무변화”
마케팅: “비용 +2% 라 실패”
제품: “매출 +5% 라 성공”
운영: “만족도 무변화 무관”

같은 결과, 3 가지 결론. 의사결정 마비.

해결: 실험 시작 전 단일 Goal 합의.

“이 실험은 매출 증가를 측정한다. 비용·만족도는 측정 안 함.”

부서들이 동의 안 하면 그 실험 안 함 또는 분리.

→ Goal 명시가 합의 도구. 작성 시간 1 시간 vs 분쟁 1 달.

2.2 Goal 결정 시 고려 사항

Goal 후보 평가

후보 Goal	측정 가능?	비즈니스 의미?	합의 가능?
이익 (profit)	어려움 (장기)	명확	어려움 (각자 해석)
매출 (revenue)	쉬움	명확	쉬움
비용 (cost)	쉬움	명확	쉬움
고객 retention	어려움 (시간 필요)	명확	중간
만족도 (satisfaction)	보통 (설문)	약함 (인과 약)	어려움
브랜드 인식	어려움	약함	어려움

권장 default:

매출, 비용, retention 중 하나
회사 전략에 직결
측정 절차가 단순

→ 분석가가 첫 번째 Goal 후보 제안 → 비즈니스 파트너 동의 → 시작.

3 Target Metric — 정량화

3.1 Trade-off — Profit-distance vs Noise

두 극단

Target Metric 의 선택은 two trade-off:

[이익에 가까움]                    [개입에 가까움]
        │                                │
   매출 (downstream)              클릭률 (upstream)
        │                                │
   noise 큼                       noise 작음
        │                                │
   비즈니스 의미 강                비즈니스 의미 약

분석가가 양극 사이 적절한 점 선택.

직관 — Trade-off 의 비유

비유: 사과 농사.

사과 수확량 측정: 비즈니스 의미 직접, 그러나 6 개월 기다림 + 날씨 등 noise
꽃 개수 측정: 빠르고 noise 작음, 그러나 꽃 → 사과 사이 인과 약함 (수분 실패 등)
잎 색깔 측정: 매우 빠르고 정밀, 그러나 비즈니스 의미 거의 없음

분석가의 결정:

비즈니스 의미와 측정 효율 사이 균형
일반적으로 “꽃 개수” 같은 중간 metric (leading indicator)

→ Target Metric 은 항상 trade-off. 절대적 정답 없음.

3.2 Leading Indicator (선행 지표)

정의

Leading Indicator: 궁극 결과 (Lagging) 의 인과 선행 변수.

예:

Lagging (궁극)	Leading (선행)
LTV (3 년)	3 개월 booking 금액
매출	전환율
사용량	sign-up
구매	카트 추가
만족도	재방문율

Leading 의 장점:

빠른 결과 (몇 일 vs 몇 달)
Noise 작음 (단계 적음)
실험 효율 높음

Leading 의 단점:

비즈니스 의미 간접
Lagging 과의 관계 검증 필요

직관 — Leading Indicator 의 사전 검증 의무

Leading 을 사용하기 전:

“이 leading 이 정말 lagging 으로 이어지는가?”

검증 방법:

과거 데이터 회귀: \(\text{Lagging} = \beta \cdot \text{Leading} + \cdots\)
만약 \(\beta\) 가 통계적·실용적으로 유의 → leading 사용 OK
만약 약함 → leading 변경 또는 lagging 직접 사용

AirCnC 사례:

Lagging: 매출 (1 년)
Leading 후보: Booking Probability (1 주)
검증: 과거 데이터에서 booking probability 가 매출과 강한 상관 → OK

→ Leading 의 효과가 lagging 으로 전이되지 않으면 실험은 의미 없음. 사전 검증 필수.

3.3 AirCnC 의 결정 — Booking Probability

결정 이유

후보:

Revenue (매출): 효과 있는데 noise 큼 (개별 booking 금액 분산 큼)
Booking Amount (예약 금액): 1-click 이 금액 자체에 영향 주는 이유 없음
Booking Probability (예약 확률): 효과 + noise 작음 ✓
Click Rate (클릭률): 너무 upstream — 클릭 후 이탈 가능성

선택: Booking Probability.

근거:

1-click 이 직접 영향 주는 metric (이탈 줄임)
이진 변수 → 분산 작음
매출과 인과 관계 명확 (probability × amount = revenue)

직관 — Probability 가 왜 noise 가 작은가

이진 변수 (\(X \in \{0, 1\}\)) 의 분산:

\[\text{Var}(X) = p(1-p)\]

\(p = 0.25\): 분산 = 0.1875
\(p = 0.5\): 분산 = 0.25 (최대)

연속 변수 (예: booking amount) 의 분산:

\[\text{Var}(X) = E[X^2] - E[X]^2\]

(분포 따라 다양, 보통 더 큼)

비교 (AirCnC 가상):

Booking Amount 분산: 30000 (분포 넓음)
Booking Probability 분산: 0.18 (이진)

같은 효과 검출에 필요한 표본:

Amount: 100,000 명
Probability: 5,000 명

20 배 차이. 실험 비용이 1/20.

→ Target Metric 의 분산이 작을수록 실험 효율 ↑. 이진 metric 가 자주 선호.

4 Target Metric 의 3 가지 함정

4.1 함정 1: 측정 불가

“쉬워졌다” 의 함정

WRONG 시나리오:

“1-click 버튼이 예약 경험을 더 쉽게 만든다.”

분석가의 질문:

“쉽다” 어떻게 측정?
누가 판단?
임계값?

답이 없으면 측정 불가. 실험 결과 평가 불가.

CORRECT 시나리오:

“예약 완료 후 즉시 발송된 2 문항 설문에서 ‘예약 과정의 용이성’ 점수 (1~5) 가 평균 4.0 이상.”

명확한:

측정 도구 (설문)
측정 시점 (예약 직후)
임계값 (4.0)

→ 측정 절차의 명세화 = Metric 의 자격.

직관 — “Easier” 같은 단어의 함정

“Easier”, “better”, “improved” 같은 단어는 명사가 아닌 비교형. 비교 기준이 없으면 의미 없음.

분석가가 이런 단어 들으면:

“Easier 라는 의미를 정확히 어떻게 측정?”

답을 강제. 답 없으면 metric 없음 → 실험 안 함.

이 단호함이 분석의 신뢰 보호.

4.2 함정 2: Laundry List

다중 metric 의 함정

WRONG 시나리오:

“성공 = 예약률 OR 예약 금액 OR 만족도 OR NPS 향상.”

문제: 4 개 metric 중 1 개라도 통계적 유의 → 결론 “성공”.

False positive 위험:

4 개 독립 metric, 각 α = 0.05
1 개 이상 유의 확률 = \(1 - (1 - 0.05)^4 \approx 0.19\)
19% — 5% 가 아닌 19% false positive

→ 진짜 효과 없는 실험에서도 19% 확률로 “성공” 보고.

CORRECT:

1 개 primary metric (예: 예약률)
1~2 개 secondary metric (Bonferroni 보정)
사전 명시 + 사후 변경 안 함

직관 — Multiple Testing 보정

만약 정말 3 개 metric 측정해야 한다면:

α_per_test = α_total / N_tests
α_per_test = 0.05 / 3 ≈ 0.017

Bonferroni 보정:

각 metric 의 p-value < 0.017 일 때 유의
실험 검출력 ↓ → 큰 표본 필요

이 비용을 알면 분석가가 자연스럽게 metric 수를 줄임.

→ “Laundry list” 가 비싸다는 인식이 metric 절제 동기.

4.3 함정 3: 사후 결정

P-Hacking

WRONG 시나리오:

분석가가 사전: “예약률을 metric 으로 사용.”

실험 후: 예약률 변화 없음. 그러나 세션 시간 +12% (우연).

분석가의 잘못된 선택:

“예약률 변화 없지만 세션 시간 늘었다 → 부분 성공.”

문제: 결과 본 후 metric 변경 → false discovery.

여러 metric 을 측정 + 결과 좋은 것만 보고하는 것은 19 세기 유사과학 패턴.

CORRECT:

실험 시작 전 metric 명시 (preregistration)
결과 분석에서 사전 metric 만 사용
다른 패턴은 “additional finding” 으로 별도 보고 (별도 실험 필요)

직관 — Preregistration 의 표준화

임상 시험에서 preregistration 표준 (FDA 의무):

실험 시작 전 hypothesis + metric + 분석 방법 등록
결과 발표 시 등록 정보와 비교
일치하지 않으면 부정 행위

비즈니스 분석에도 적용:

내부 시스템에 ToC + metric 등록
결과 보고 시 등록 시점 metric 명시
사후 변경은 명시적 표시 (제안 가능, 그러나 별도 실험 필요)

→ Preregistration 이 분석 무결성의 첫 보호선.

5 OEC — 종합 평가 기준 논쟁

5.1 OEC 의 정의

Overall Evaluation Criterion

OEC = 여러 metric 의 가중 평균을 단일 점수로.

수식:

\[ \text{OEC} = \sum_{i} w_i \cdot \text{Metric}_i \]

예 (AirCnC):

\[ \text{OEC} = 0.5 \cdot \text{BookingProbability} + 0.3 \cdot \text{NPS} + 0.2 \cdot \text{Revenue} \]

장점:

단일 숫자 의사결정
Trade-off 명시
Multiple testing 회피

Buisson 의 우려

Buisson (책 저자) 의 경고:

“OEC 가 명확함보다 모호함을 만들기 쉽다.”

이유:

가중치 합의 어려움: 0.5 + 0.3 + 0.2 의 근거? 부서마다 다른 가중치 선호.
결과 해석 불투명: “OEC = 0.5 늘었다” — 무슨 의미?
Mechanism 분석 어려움: 어느 metric 이 OEC 변화의 원인? 별도 분석 필요.

대안:

1~3 개 primary metric 명시 + 각각 보고
비즈니스 파트너가 종합 판단

비즈니스 분석에서 OEC 는 큰 회사 (Microsoft, Google, Booking.com) 가 선호. 작은 팀에서는 1~3 metric 가 default.

직관 — OEC vs 분리 metric

같은 실험을 두 방식으로 보고:

OEC 보고:

“OEC = +0.05 (95% CI [+0.02, +0.08])”

분리 보고:

“Booking Probability +2%p (95% CI [+1, +3]). NPS +0.3 (95% CI [+0.1, +0.5]). Revenue +1.5% (95% CI [-0.2, +3.2]).”

분리 보고가:

각 metric 의 효과 명확
어느 metric 의 효과가 강한지 보임
Revenue CI 가 0 포함 → 그 metric 만 따로 점검 필요

OEC 보고는 단순하지만 정보 손실.

→ 분석가의 default: 분리. 비즈니스 파트너가 OEC 원하면 추가로 계산.

6 Intervention — 작은 변화 우선

6.1 “1-click” 의 implementation

실제 구현 결정

“1-click booking 버튼” 한 줄 뒤의 결정:

결정	후보
위치	페이지 상단 / 중앙 / 하단
색깔	기존 파스텔 / 강조 빨강
텍스트	“1-click 예약” / “바로 예약” / “Quick Book”
사용 조건	모든 고객 / 결제 정보 등록 고객만
클릭 후	예약 완료 / 확인 페이지 / 영수증

각 결정이 실험 결과에 영향. 분석가의 선택:

모두 한꺼번에 변경 (omnibus) → 효과 분리 못 함
가장 핵심만 변경 (minimal) → 효과 정확히 측정

색깔과 1-click 의 confounding

위험 시나리오:

1-click 버튼 = 빨간색 (강조)
기존 버튼 = 파스텔 (눈에 안 띔)

실험 결과: 예약률 +5%

해석 후보:

1-click 의 효과 (실제 의도)
빨간색 (눈에 띔) 의 효과 (보너스)
둘 다

실험으로 분리 못 함. 두 변경이 동시에.

→ 실험 결과 의미 모호. “1-click 의 효과 = +5%” 라고 보고 못 함.

해결:

색깔만 별도 실험 (intervention A)
1-click + 색깔 동일 실험 (intervention B)
B - A = 1-click 의 순효과

6.2 Buisson 의 권장 — Smallest Possible Intervention

단계별 실험

권장 절차:

Step 1: 색깔 변경 실험 (vs 기존)
   효과: 예약률 +1%

Step 2: 위치 변경 실험 (vs 기존)
   효과: 예약률 +0.5%

Step 3: 1-click 변경 실험 (vs 기존, 색깔/위치 같음)
   효과: 예약률 +3%

Step 4: 통합 실험 (1-click + 빨강 + 위치)
   효과: 예약률 +4.5% (= 1 + 0.5 + 3 의 가산성 점검)

가산성이 깨지면 (interaction effect) → 추가 분석.

이 절차의 비용:

4 개 실험 (3~6 개월)
각 결과의 명확성 확보

vs 한꺼번에:

1 개 실험 (1~2 개월)
결과 모호함, 다음 실험 가이드 없음

→ 단계별이 비용 ↑ 시간 ↑ 정보 ↑. 빠른 실패와 빠른 학습.

직관 — Smallest Intervention 의 비유

비유: 약 처방의 결정.

A 약 + B 약 + C 약 동시 처방 → 효과 좋음? 부작용? 어느 약 때문?
A 약만 처방 → A 의 효과 명확
B 약만 처방 → B 의 효과 명확
통합 처방 → 가산성 점검

의사가 abrupt 한 다중 처방을 안 하는 이유 = 분석가도 omnibus 안 해야 하는 이유.

→ 단순함 + 분리가 분석의 명료성.

6.3 Multiple Implementations of Same Concept

직관 — 다중 1-click 디자인 비교

대안: 한 실험에서 4 개 1-click 디자인:

그룹	디자인
Control	기존 (no 1-click)
Treatment 1	1-click 빨강 + 상단
Treatment 2	1-click 빨강 + 하단
Treatment 3	1-click 파스텔 + 상단

분석:

4 개 비교 → 1-click 의 일반 효과 추정
디자인 차이도 동시 측정

만약 4 디자인 모두 효과 비슷 → 1-click 자체의 효과 (디자인 무관) 만약 디자인마다 효과 큰 차이 → “implementation matters”

→ 1 실험에서 더 풍부한 정보. Multi-armed Bandit 같은 도구 사용 가능.

7 Behavioral Logic — 사전 검증

7.1 CD 표현

1-click 의 behavioral logic

1-click 버튼 (intervention)
    ↓ (가설 1: 시간 단축?)
예약 프로세스 시간 (mediator 1)
    ↓ (가설 2: 시간 → 이탈?)
이탈률 (mediator 2)
    ↓ (가설 3: 이탈 ↓ → 완료 ↑?)
예약 완료 (target metric)
    ↓ (가설 4: 완료 → 매출?)
매출 (business goal)

4 개 가설. 각각 사전 검증 가능.

7.2 사전 검증 절차

가설별 검증 도구

가설	검증 방법	데이터	비용
1: 시간 단축	UX 테스트 (10 명 stopwatch)	prototype	50 만원 + 1 주
2: 시간 → 이탈	과거 데이터 회귀	6 개월 booking	무료 + 1 일
3: 이탈 ↓ → 완료 ↑	동일 (회귀)	동일	무료 + 1 일
4: 완료 → 매출	회계 데이터	거래 데이터	무료 + 1 일

전체 검증 = 약 1 주 + 50 만원.

본 실험 (3 개월 + 수억) 의 시작 전 점검.

직관 — 검증 결과 별 행동

가설별 검증 결과:

가설 1 reject (시간 단축 안 됨, prototype 문제) → 실험 안 함, intervention 재설계
가설 2 reject (시간 ↔︎ 이탈 무관) → 다른 mediator 가정, behavioral logic 재고
가설 3 reject (이탈 자체 작음) → 이탈 줄여도 효과 미미, intervention 재고
가설 4 reject (완료 → 매출 약함) → 다른 goal 고려

각 reject 가 분석가의 시간을 절약. 본 실험 시작 전에 재설계.

→ 가설의 사전 검증이 분석의 첫 게이트.

7.3 Best Case Scenario

효과의 상한 추정

ToC 의 가설이 모두 100% 맞을 때 효과:

가설 1: 시간 단축 약 50% (1-click 의 의도)
가설 2: 시간 단축 → 시간 이탈자 100% 회복
가설 3: 시간 이탈자가 전체의 30%
가설 4: 완료 → 매출 직접

Best case 효과 = 30% (= 시간 이탈자 비율).

비교:

구현 비용: 1 억
매출 baseline: 100 억 / 년
30% 증가 = 30 억 / 년 → 1 억 회수 가능

→ Best case 가 손익분기 넘으면 실험 진행. 안 넘으면 실험 안 함.

직관 — Best Case 가 손익분기 못 넘는 사례

상상: best case = 5%, baseline = 1 억, 구현 비용 = 5000 만.

5% × 1 억 = 500 만 / 년
5000 만 회수에 10 년 필요

비즈니스 의사결정:

10 년 ROI = 0% — 다른 투자가 더 좋음
실험 안 함

이 1 시간의 ToC 분석으로 6 개월 실험 비용 (인건비 + 기회 비용) 절약.

→ 분석가의 ToC 가 비즈니스 의사결정 도구.

7.4 Most Likely Scenario

현실적 효과 추정

Best case 의 50% 가정:

시간 이탈자 30% × 1-click 회복률 50% = 15% 효과

이 most likely 가 sample size 결정의 입력:

MDE = 5%p (손익분기)
기대 효과 = 15%p (most likely)
Power = 80%
α = 0.05

→ Sample size 산출 (E-BUI8-3 자세히).

직관 — Anchoring 회피

심리학 함정:

분석가가 손익분기 (MDE) 를 먼저 알면 → 그 숫자에 anchoring → “달성 가능” 으로 추정 편향
“5% 가능성? 응, 가능할 듯” (실제로는 의심해야)

권장 순서:

Most Likely 먼저 추정 (independent)
MDE 비교 후 확인
만약 most likely < MDE → 실험 의미 없음, 진행 안 함

이 순서가 분석가의 자기기만 회피.

→ Anchoring 회피가 ToC 의 honest 평가 도구.

8 Behavioral Decomposition

8.1 비즈니스 metric 분해

직관 — Revenue = Customers × Probability × Quantity × Price

비즈니스 metric 의 분해:

Revenue = N_customers × P(buy) × Quantity × Price

각 component 의 변화 가능성:

N_customers: 1-click 이 신규 고객 안 만듦 (영향 없음)
P(buy): 1-click 이 예약률 ↑ (영향 직접)
Quantity: 1-click 이 예약 건수 안 바꿈 (영향 약)
Price: 1-click 이 가격 안 바꿈 (영향 없음)

따라서 Target Metric 으로 P(buy) 가 적합. Revenue 는 직접 사용 시 다른 component 의 noise 만 추가.

→ 비즈니스 metric 의 분해가 적절한 Target Metric 도출.

직관 — 분해의 추가 가치 — 다른 component 점검

비즈니스 파트너가 우려: “예약률 늘었지만 예약 금액 줄었다면?”

ToC 의 명시:

“1-click 은 예약률에만 영향. 예약 금액은 변화 없음 (변화 시 별도 분석).”

만약 실험 후:

예약률 +5% — 예상대로
예약 금액 -10% — 의외 변화

분석가의 대응:

ToC 위반 — 다른 메커니즘 발견
별도 분석 (어떻게 1-click 이 금액에 영향?)
Production 결정 보류

→ 분해 + 사전 ToC 가 사후 발견의 explanatory framework.

9 코드 예시 — Plan 단계 자동화

9.1 Goal·Metric 검증 함수

from dataclasses import dataclass
from typing import List, Optional


@dataclass
class TargetMetric:
    """Target Metric 의 자체 검증."""
    name: str
    description: str
    measurement_procedure: str
    threshold: Optional[float] = None
    expected_baseline: Optional[float] = None
    is_leading: bool = False
    leading_validated: bool = False  # Leading 인 경우 사전 검증 여부

    def validate(self) -> List[str]:
        """Metric 의 자격 검증."""
        warnings = []
        if not self.measurement_procedure:
            warnings.append("측정 절차 명시 안 됨")
        if "쉬워" in self.description or "더 좋아" in self.description:
            warnings.append("비교형 단어 사용 — 측정 기준 모호")
        if self.is_leading and not self.leading_validated:
            warnings.append("Leading indicator 인데 사전 검증 안 됨")
        return warnings


# AirCnC 사례
metric_1 = TargetMetric(
    name="Booking Probability",
    description="예약 페이지 도착 후 예약 완료 비율",
    measurement_procedure="예약 페이지 PV / 예약 완료 행 비율 (분기별 집계)",
    threshold=0.30,
    expected_baseline=0.25,
    is_leading=True,
    leading_validated=True,  # 매출과의 관계 사전 검증됨
)

print("=== Target Metric 검증 ===")
print(f"Name: {metric_1.name}")
warnings = metric_1.validate()
if warnings:
    print(f"  경고: {warnings}")
else:
    print(f"  자격 OK")

직관 — 자동 검증의 가치

이 도구가 분석가에게 강제:

측정 절차 명시 (없으면 경고)
비교형 단어 회피
Leading 의 사전 검증

이 검증이 ToC 의 첫 게이트. 통과 못 하면 실험 시작 안 함.

9.2 Pitfall 자동 점검

def check_pitfalls(toc_metrics: List[TargetMetric]) -> List[str]:
    """Plan 단계의 함정 자동 점검."""
    issues = []

    if len(toc_metrics) > 3:
        issues.append(f"Metric {len(toc_metrics)} 개 — laundry list 위험. 1~3 개 권장.")

    for m in toc_metrics:
        for w in m.validate():
            issues.append(f"{m.name}: {w}")

    return issues


# 점검
metrics = [metric_1]
issues = check_pitfalls(metrics)
print("\n=== 함정 점검 ===")
if issues:
    for i in issues:
        print(f"  - {i}")
else:
    print("  통과")

9.3 Behavioral Logic 검증 — 회귀

import numpy as np
import pandas as pd
import statsmodels.api as sm


def validate_behavioral_logic(df, mediator: str, outcome: str, alpha=0.05):
    """Behavioral Logic 의 회귀 검증."""
    X = sm.add_constant(df[[mediator]])
    model = sm.OLS(df[outcome], X).fit()

    coef = model.params[mediator]
    pval = model.pvalues[mediator]
    is_valid = pval < alpha and abs(coef) > 0

    return {
        "mediator": mediator,
        "outcome": outcome,
        "coef": coef,
        "pvalue": pval,
        "is_valid": is_valid,
        "verdict": "Logic 일치" if is_valid else "Logic 의심",
    }


# AirCnC 가상 데이터 (시간 → 이탈률)
np.random.seed(42)
n = 1000
booking_time = np.random.exponential(2, n).clip(0.5, 10)
dropout = np.random.binomial(1, 0.05 * booking_time, n)  # 시간 길수록 이탈

df = pd.DataFrame({"time": booking_time, "dropout": dropout})

result = validate_behavioral_logic(df, "time", "dropout")
print("\n=== Behavioral Logic 검증 ===")
print(f"  {result['mediator']} → {result['outcome']}: coef = {result['coef']:.4f}, p = {result['pvalue']:.4f}")
print(f"  결과: {result['verdict']}")

직관 — 자동 검증의 한계

이 함수는 단순 회귀로 검증. 한계:

Confounding 미점검 (다른 변수가 시간과 이탈 모두 영향)
비선형 관계 미점검
Causality 와 correlation 의 구분 어려움

분석가의 보강:

CD 로 confounder 식별 + 통제
Sensitivity analysis
도메인 직관 통합

→ 자동 검증은 first filter. 깊이 있는 분석은 사람.

10 관련 주제

10.1 Ch.8 의 형제 글

E-BUI8-0 Theory of Change overview — Ch.8 전체 흐름
E-BUI8-2 무작위 배정 시점·수준 — 단계 2
E-BUI8-3 검정력 분석 (부트스트랩) — 단계 3

10.2 이전 챕터

E-BUI4-3 데이터 검증과 반복 정제 — Ch.4: CD 짓기

10.3 Phase F (Kohavi A/B Testing) cross-link

Phase F — Trustworthy A/B Testing 의 OEC 와 metric 분해

10.4 카테고리 진입점

Experimentation 학습 로드맵 — 11 Phase × 7 교재 매핑