프로젝트 목록
대표 프로젝트FeaturedAnalytics EngineeringProduct AnalyticsMulti-GuardrailScenario Matrix
Project Detail

DecisionOps Lab

activation lift가 유의해도 D7 재방문·환불률·세션 활동 가드레일과 데이터 품질을 통과해야 Ship할 수 있는가?

synthetic 제품 이벤트를 DuckDB SQL mart, 23개 품질 gate, A/B evidence,
D7 재방문·환불률·세션 활동의 3개 가드레일과 7개 시나리오로 검토해

Ship·Retest·Hold·Investigate memo/report로 연결한 DecisionOps workflow입니다.

Decision Moment

질문이 바뀐 순간

이 프로젝트가 단순 분석에서 의사결정 구조로 넘어간 핵심 장면입니다.

Original Questionactivation이 개선되면 바로 Ship해도 되는가?
Reframed Question데이터 품질을 통과하고 D7 재방문·환불률·세션 활동이 악화되지 않을 때만 Ship하도록 결정 규칙을 재현할 수 있는가?
Key Evidence
23 quality checks · activation +3.97pp / p=0.000011 · D7 +0.97pp · refund -0.02pp · sessions +1.93% · 7 scenarios
Final Deliverable
SQL mart, quality gate, multi-guardrail experiment result, 7-scenario matrix, decision memo와 public reviewer report
What this proves
하나의 성공 지표를 복수의 위험 신호와 품질 조건 안에서 검토해 재현 가능한 의사결정 언어로 바꾸는 역량
Evidence Snapshot

근거 스냅샷

숫자가 있는 프로젝트는 검증 지표를 먼저, 데이터가 부족한 프로젝트는 확인 가능한 산출물 중심으로 정리했습니다.

SQL Layer

raw events → staging → intermediate → mart로 grain과 metric contract를 분리

Quality Gate

row count, null, accepted values, relation, duplicate, experiment balance 등 23/23 checks PASS

Primary Evidence

Variant A 30.15% → B 34.12% · activation +3.97pp · p-value 0.000011

D7 Revisit Guardrail

48.17% → 49.14% · delta +0.97pp · PASS

Refund Guardrail

0.22% → 0.20% · delta -0.02pp · PASS

Session Activity Guardrail

평균 세션 1.814 → 1.849 · relative delta +1.93% · PASS

7 Scenario Decisions

strong_positive=Ship · 3 guardrail risks/weak_evidence=Retest · neutral=Hold · quality_failure=Investigate

Verification

one-command runner와 GitHub Actions가 quality, experiment, matrix, memo, reviewer report를 생성

Claim Boundary

synthetic workflow이며 실제 제품 성과·사용자 행동·production business impact를 주장하지 않음

공개 접근

Public reviewer report

저장소 상태

Public repository

검증 상태

Multi-guardrail workflow verified · 2026-07-09

범위 상태

Synthetic · 3 guardrails · 7 scenarios

추천 직무

제품 데이터 분석 · Analytics Engineering · 실험·의사결정 분석

Signal Case Study실험 의사결정 workflow

1개 지표가 아니라 3개 가드레일과 7개 시나리오로 결정하기

synthetic 제품 이벤트를 SQL mart와 23개 품질 gate로 정리한 뒤 activation evidence를 D7 revisit, refund rate, session activity의 세 가드레일과 함께 읽고, 일곱 시나리오에서 Ship·Retest·Hold·Investigate 결정을 재현하는 분석 의사결정 workflow입니다.

DuckDB SQL23 Quality Checks+3.97pp Liftp=0.0000113 Guardrails7 ScenariosDecision MemoPublic Report
01Synthetic events
02SQL staging
03Intermediate models
04Mart layer
05Quality gate
06Primary metric
073 guardrails
087-scenario matrix
09Decision memo
10Reviewer report
01 Problem

activation lift만 보고 Ship하지 않기

주요 지표가 개선되어도 데이터 품질, 재방문, 환불, 사용 활동이 흔들리면 제품 결정을 그대로 밀어붙일 수 없습니다.

  • quality → primary metric → guardrails 순서
  • 좋은 lift도 downstream risk가 있으면 Retest
02 Data Model

raw event를 검토 가능한 SQL layer로 분리

raw users/events/sessions/payments/experiments를 DuckDB raw, staging, intermediate, mart layer로 나누고 reviewer artifact가 mart 결과를 읽도록 구성합니다.

  • mart_experiment_result
  • mart_decision_summary
  • mart_segment_performance
  • mart_retention_cohort
03 Quality Gate

실험 해석 전에 23개 품질 검사를 실행

row count, null, accepted values, referential integrity, duplicate와 experiment balance를 먼저 확인하며 quality_failure는 결과 해석 전에 Investigate로 분기합니다.

  • 23/23 PASS in default case
  • quality_failure=Investigate
04 Primary Evidence

activation 개선과 통계 근거를 확인

strong_positive 기본 사례에서 Variant B activation은 30.15%에서 34.12%로 +3.97pp 개선되며 p-value는 0.000011입니다.

  • A 30.15% → B 34.12%
  • +3.97pp
  • 95% CI +2.14pp~+5.80pp
05 Three Guardrails

재방문·환불·세션 활동을 함께 검토

D7 revisit, refund rate, average sessions를 독립 가드레일로 평가해 activation 개선이 이후 행동이나 비용 신호를 악화시키지 않는지 확인합니다.

  • D7 revisit delta +0.97pp · PASS
  • refund rate delta -0.02pp · PASS
  • avg sessions +1.93% · PASS
06 Seven Scenarios

가드레일별 실패와 약한 근거를 별도 재현

strong_positive, guardrail_risk, refund_risk, session_activity_risk, weak_evidence, neutral, quality_failure의 일곱 조건으로 결정 규칙이 한 결과에 고정되지 않았는지 검증합니다.

  • Ship: strong_positive
  • Retest: 3 guardrail risks + weak_evidence
  • Hold: neutral
  • Investigate: quality_failure
07 Decision Artifact

결과를 memo·matrix·public report로 남기기

quality report, experiment result, scenario matrix, decision memo와 GitHub Pages reviewer report를 같은 실행 경로에서 생성합니다.

  • one-command verification
  • machine-readable JSON + reviewer-facing artifacts
08 Boundary

synthetic workflow의 주장 범위를 유지

DecisionOps는 분석·검증·의사결정 설계 역량을 보여주는 synthetic-data workflow이며 실제 사용자 행동, 제품 성과나 production business impact를 증명하지 않습니다.

  • synthetic data only
  • production warehouse or live experiment operation 아님
Problem / Context

문제와 맥락

주요 도메인
제품 분석
역할
raw/staging/intermediate/mart SQL 설계 / 23개 data quality gate / A/B test evidence / D7·refund·session 3개 guardrail review / 7개 scenario decision matrix
기간
2026
형태
개인 프로젝트
Context

제품 실험은 주요 지표가 좋아졌다는 이유만으로 바로 Ship할 수 없습니다. DecisionOps Lab은 synthetic raw events를 검토 가능한 SQL layer로 정리하고 품질 gate를 먼저 통과시킨 뒤, activation evidence를 D7 revisit·refund rate·session activity와 함께 읽어 의사결정합니다.

Problem

제품 실험의 주요 지표가 개선되어도 데이터 품질이나 D7 재방문, 환불률, 세션 활동이 악화되면 신뢰 가능한 Ship 판단으로 이어질 수 없습니다.

Why it mattered

리뷰 가능한 의사결정 workflow는 raw data부터 SQL metric layer, 품질 gate, 통계 근거, 복수 guardrail과 최종 memo가 같은 실행 경로로 연결되어야 하기 때문입니다.

Data & Method

데이터와 접근

데이터
  • synthetic users / events / sessions / payments / experiments
  • DuckDB raw / staging / intermediate / mart tables
  • quality / experiment / scenario JSON reports
  • decision memo와 reviewer HTML report
접근
  • fixed seed와 scenario mode로 synthetic raw CSV 생성
  • DuckDB raw, staging, intermediate, mart SQL layer로 grain과 지표 정의 분리
  • 23개 quality checks를 실험 해석보다 먼저 실행
  • activation lift, p-value와 confidence interval 확인
  • D7 revisit, refund rate, average sessions의 세 guardrail 평가
  • 일곱 시나리오에서 Ship/Retest/Hold/Investigate 규칙 재현
  • decision memo, scenario matrix와 public reviewer report 생성
지표 / 기준
  • 23/23 quality PASS
  • activation +3.97pp · p-value 0.000011
  • D7 revisit delta +0.97pp
  • refund rate delta -0.02pp
  • average sessions relative delta +1.93%
  • 7 scenarios · Ship/Retest/Hold/Investigate
Output

결과물

raw CSV를 DuckDB raw·staging·intermediate·mart layer로 모델링하고 23개 quality checks를 실행했습니다. 기본 strong_positive 사례에서 activation은 +3.97pp, p-value 0.000011이며 D7 revisit·refund rate·session activity가 모두 PASS입니다. 같은 pipeline을 일곱 시나리오에 적용해 Ship 1개, Retest 4개, Hold 1개, Investigate 1개 결정을 memo와 public report로 생성합니다.

SQL staging / intermediate / mart layer23/23 quality gateD7 · refund · session 3 guardrails7-scenario matrix + decision memo/report
Key Insight

핵심 포인트

  • raw product events를 DuckDB SQL mart와 명시적 metric layer로 재구성
  • 23개 data quality gate를 실험 해석보다 먼저 실행
  • activation evidence를 D7 revisit·refund rate·session activity와 함께 검토
Limits / Notes

한계와 검토 메모

검증 범위와 추가로 확인해야 할 조건을 숨기지 않고 함께 남겼습니다.

  • synthetic dataset 기반이므로 실제 제품 성과, 실제 사용자 행동과 production business impact를 주장하지 않습니다.
  • 실험 결과는 workflow 검증용이며 실제 production A/B test나 인과적 사업 성과 검증이 아닙니다.
  • DuckDB 기반 portfolio workflow이며 production warehouse scale, orchestration이나 live data operation을 주장하지 않습니다.
  • guardrail threshold는 데모용 metric contract이며 실제 조직에서는 제품 맥락과 비용 구조에 맞춰 재합의해야 합니다.
  • 세그먼트 진단은 탐색 근거이며 다중 검정 보정이나 production rollout policy를 대체하지 않습니다.
Links

확인 가능한 산출물

공개 reviewer report, scenario matrix와 GitHub 문서에서 23개 품질 gate, 3개 guardrail, 7개 scenario decision과 synthetic claim boundary를 확인할 수 있습니다.

Case Studies

연결된 문제 해결 방식