A/B 테스트 (실험)

유효한 A/B 테스트에는 다음이 필요합니다: 명확하게 정의된 가설('무료 체험 시작' 버튼 텍스트를 '14일 무료 체험'으로 변경하면 클릭률이 10% 증가할 것이다'); 단일 측정 지표(테스트 시작 전에 합의된 '주요 지표'); 사전 계산된 표본 크기(원하는 통계적 검정력 80%와 유의 수준 0.05를 사용하여 검정력 분석 계산기 사용); 정의된 실행 시간(테스트가 잘 되는 것처럼 보여도 A/B 테스트를 조기에 중단하지 마십시오. 이는 위양성률을 극적으로 증가시킵니다); 그리고 사용자들을 변형에 무작위로 할당하는 것(요일이나 다른 상관 변수에 의해서가 아님). Product Ops는 실험 프레임워크를 구축합니다. 즉, 도구, 테스트 SOP 문서화, 검정력 분석 수행, 실험 후 통계 분석 실행 등을 담당합니다.

가장 위험한 A/B 테스트 실수는 '엿보기(peeking)'입니다. 즉, 미리 정해진 표본 크기에 도달하기 전에 결과를 확인하고 결과가 긍정적으로 보일 때 조기에 중단하는 것입니다. 이는 자연적인 분산을 악용하여 명시된 유의 수준을 훨씬 초과하는 비율로 위양성을 생성합니다. 다른 일반적인 함정으로는: 너무 많은 변형을 동시에 테스트하는 것(변형당 표본을 희석시키고, 실행 시간을 연장하며, 해석을 복잡하게 함); 사전에 정의된 주요 지표 대신 보조 지표를 측정하는 것; 신기함 효과(사용자는 첫 주 동안 새로운 것에 더 많이 참여하다가 기본 상태로 돌아옴)를 고려하지 않는 것; 그리고 결과를 세분화하지 않는 것(전반적으로 승리한 변형이 가장 가치 있는 고객 세그먼트에서는 실패할 수 있음) 등이 있습니다. Product Ops는 모든 실험, 가설, 결과 및 결정을 문서화하는 A/B 테스트 로그를 유지하여 팀이 학습한 내용을 기관의 기억으로 만듭니다.

성숙한 실험 프로그램은 인프라, 문화, 거버넌스를 필요로 합니다. 인프라: 실험 플랫폼(Statsig, Optimizely 또는 LaunchDarkly와 같이 실험 기능이 내장된 feature flag 도구), 주요 지표를 측정하기 위한 신뢰할 수 있는 분석 이벤트 추적, 그리고 통계 분석 템플릿. 문화: '이를 검증하기 위해 어떤 실험을 실행할 수 있을까?'라는 질문으로 결정에 이의를 제기할 수 있는 팀 규범과 직관에 반하더라도 실험 결과를 따르는 리더들. 거버넌스: 예상되는 영향과 실현 가능성에 따라 우선순위가 정해진 실험 백로그, 결과를 읽기 전에 통계적 유효성을 검증하는 검토 프로세스, 그리고 모든 PM이 결과에 접근할 수 있도록 하는 결과 데이터베이스. Product Ops는 이 세 가지 차원을 모두 소유하며, 실행된 실험 수, 통계적으로 유의미한 결과를 보인 비율, 그리고 누적 영향(성공적인 실험으로 인한 지표 개선)에 대해 매월 보고합니다.