📌 이 글은 [인프런] 카일스쿨의 'PM을 위한 데이터 리터러시' 강의 내용을 요약 정리한 것입니다.
실험 설계
실험
- 실험 = 성장을 위해 직관과 데이터를 모두 활용하는 방식을 사용하는 것
- 대표적인 실험 AB Test
- 정의: 앱, 웹에서 하나의 화면에 2가지 버전(A, B)을 동시에 배포해 지표를 확인하는 실험
- 직관과 데이터에 기반해 가설 생성
- 실험을 통해 가설의 결과 확인
- 이외에도 프로토타입을 만들어서 사람들이 설문조사를 하도록 하는 것도 실험
- 대표적인 실험 AB Test
- why? 실험을 해야하는 이유
- 데이터 기반 의사 결정 프레임워크를 만들 수 있으며, 더 좋은 결정을 할 수 있음
- 현실엔 불확실성이 너무 많기에 리스크를 줄이면서 진행해야 함
실험을 시작하는 기준
- 리소스 제한으로 모든 것을 실험할 수 있는 것은 아니며, 모두 다 실험해야 하는 것은 아님
- 중요하고 비즈니스 임팩트가 크거나 우리 회사에 도움이 될 만한 것 먼저 실행
- 1. 충분한 사용자 수가 존재하는 경우(최소 1,000명)
- 2. 평가 지표를 정의할 수 있는 경우(추상적X)
- 3. 사용할 수 있는 리소스가 존재하는 경우(개발, 데이터)
- 4. 실험군과 대조군이 서로 간섭하지 않는 경우(서로 영향 미치지 않는 경우)
- 5. 법적인 이슈가 없는 경우
- 6. 실험을 통해 배울 마인드가 존재하는 경우(초반 한 두 번 해봤을 때 안 되더라도 하나씩 배우려는 마인드)
실험할 리스트 파악하기
- 처음 실험을 진행한다면 많은 실험보단 "하나의 실험"을 잘 완수하는 것을 추천
- 비즈니스 임팩트가 큰 실험을 해보는 것을 추천
- 제품의 구매 퍼널 확인
- 제품 관점에서 제일 중요한 퍼널을 개선하는 것을 먼저 진행(ex. 버튼 색깔 AB Test X)
- 퍼널의 역순(즉, 결제쪽부터 확인)부터 시작해서 앞단으로 가면서 고민
- 전체 DAU가 아니라, 데이터로 실험할 영역에 하루에 몇 명이 접근하는지(pageview 등으로 파악) 확인해서 얼마나 영향을 미칠지 계산하기
주요 실험 소재
- (제품) 특정 화면에서 A라는 기능이 있는 경우와 없는 경우 전환율 차이는?
- (제품) 어떤 문구를 사용할 경우 전환율이 높을까?
- (제품) B라는 기능이 추가되면 신규 유저가 우리 제품에 더 만족할까?
- (마케팅) Push 메세지를 어떻게 보내야 전환율이 높을까?
- (알고리즘) 어떤 추천 시스템이 유저에게 더 잘 추천했다고 볼 수 있을까?
- (프로모션) 어떤 고객에게 할인 쿠폰을 줘야 효과적일까?
조직 실험 문화 역량 레벨
- 여러분이 속한 조직의 실험 문화 역량 레벨을 확인하고 하나씩 올리기 위해 무엇을 해야할지 고민해보기
AB Test
그래서 AB Test가 뭔데?
그거 왜 하는 건데?
어떻게 하는 건데?
AB Test가 필요한 경우
- 비즈니스 임팩트가 예상되는데 불확실성이 존재하는 경우
- 대규모 변경이 일어나는 경우(화면 등)
- 기존에 존재하지 않았던 새로운 기능
AB Test Process
- 프로세스는 아래 사진과 같음
- AB Test를 하기에 앞서, '이 Task는 AB Test가 꼭 필요한가?'를 고민하기!
- '실험 분석' 과정은 점점 플랫폼화 됨에 따라 자동화될 것
Foodie Express 예시
가설 및 지표 정의
- 귀무 가설: 추천 기능은 유저의 추천 클릭률에 영향을 미치지 않을 것이다(=기존과 차이가 없다)
- 대립 가설: 추천 기능은 유저의 추천 클릭률에 영향을 미칠 것이다(=기존과 차이가 있다)
- 대조군은 추천 기능이 없으므로 추천 클릭률 지표가 나올 수 없음 -> 이 경우, 대조군과 실험군의 페이지 전환율을 지표로 사용
- 수정한 귀무 가설: 추천 기능은 유저의 페이지 전환율에 영향을 미치지 않을 것이다(=기존과 차이가 없다)
- 수정한 대립 가설: 추천 기능은 유저의 페이지 전환율에 영향을 미칠 것이다(=기존과 차이가 있다)
- primary metric: 페이지 전환율(CVR)
ㄴ 분자: 결제 확인 페이지에 접근한 수
ㄴ 분모: 카트 페이지에 접근한 수
- secondary metric: 주문 전환율(CVR)
- guardrail metric: 해당 페이지의 이탈율
로그 설계
- User Property에 AB Test 내용 추가 필요
- experiments : {"experiment_name" : 0}
- 0 : 대조군, 1 : 실험군
- 여러 실험 진행가능하므로 Key, Value 스타일로 저장 ex. {"실험1": 0, "실험2": 0, "실험3": 1}
실험군, 대조군 데이터 확인
| 대조군(A) | 실험군(B) | |
| 결제 확인 페이지 접근 수 | 4279 | 4136 |
| 카트 페이지 접근 수 | 20198 | 20209 |
- 실험군, 대조군의 데이터 확인
- AB Test Calculator 활용해 p-value 값 계산: 0.0751 > 0.05
- 두 집단의 차이가 없거나(귀무가설이 맞다) 데이터를 더 수집해야한다는 결과가 나옴!
결과 분석 - 실험군 대조군 데이터 확인
- 이 상황에서 할 수 있는 것: 정해진 답은 없고, 상황에 따라 Action Plan이 다름
- 1) 추가 Segment 분석
ㄴ Segment 별로 차이가 존재하는 부분이 있는가?
ㄴ 최소주문금액 충족 여부에 따라 페이지 전환율 차이가 있는가?
- 2) 샘플이 필요하다면 얼마나 더 필요할끼?
ㄴ 무한정 기다릴 수는 없음
ㄴ AB Test Sample Size Calculator 등을 통해 계산하고 기다리기
- 3) 왜 의도한 결과가 나오지 않았을까? 기획에서 더 개선할 부분은 없을까?
ㄴ 실험 회고 후 추가 Action
여기서 핵심은 실험에 사용하기 위한 지표는
실험군/대조군 모두 다 확인할 수 있는 지표여야 한다!
AB Test의 핵심 요소
1) 실험 타겟
어떤 유저에게 Test를 진행할 것인가? 어떻게 A와 B를 나눌 것인가?
- 실험군(Experimental, Test Group)
- 특정 조작을 진행한 집단
- 새로운 화면, 새로운 Feature를 보여주는 경우
- 대조군(Control Group)
- 아무 조작도 하지 않은 그대로의 집단
- 기존 화면, 기존 Feature를 보여주는 경우
2) 지표
실험을 통해 어떤 지표를 개선하고 싶은가? 실험을 통해 어떤 값의 변화를 파악하고 싶은가?
- Success Metric(Primary Metric) : 기능의 성공을 확인할 수 있는 성공 지표
- Sub Metric(Secondary Metric) : 기능의 성공을 보조적으로 확인할 수 있는 보조 지표
- Guardrial Metric(Counter Metric) : 악영향을 미치면 안되는 가드레일 지표
- ex. 페이지 전환율 = 다음 페이지 방문 수/직전 페이지 방문 수
3) 실험 기간
실험을 언제, 어느 기간 동안 진행할 것인가?
- 실험에서 통계적으로 유의미함이 검증될 수 있는 샘플 수에 따라 달라짐
- 경험 상 최소 2주 정도는 지나야 샘플이 모이는 경우가 많음
- AB Test Duration Calculator (opens new window)등에서 필요한 샘플 수를 계산할 수 있음
- 외부 요소에 영향을 받는 시기가 적어야 함(프로모션, 연휴 등) => 계절성(시즈널리티)이 존재하면 이런 기간은 제외하고 실험 기간을 설정하는 것도 방법
4) 통계
- 빈도주의(Frequentist) 접근
- 일반적인 통계 분석 방법
- 다르다, 다르지 않다를 검정하는 방법
- 베이지안(Bayesian) 접근
- 빈도주의 대비 유연한 판단 방법
- "얼마나" 다른지를 통계적으로 예측
- 확률 개념으로 A보다 B가 몇 %가 좋다는 결과가 나옴
- 이 강의에선 빈도주의 접근만 다룸
- 통계학의 궁극적인 목표
- 기존 주장이 맞는가? 혹은 새로운 주장이 맞는가?를 확인하는 것
- 귀무 가설(Null Hypothesis, H0, 영가설)
- 우리가 증명하려는 가설과 반대의 내용
- 결과 차이가 없다
- 귀무가설이 채택되면 = 차이가 없다
- ex. a 기능이 전환율에 영향을 미치지 않는다
- 대립 가설(Alternative Hypothesis, H1)
- 우리가 증명하려는 가설
- 대립가설이 채택(귀무가설이 기각되면)되면 = 통계적으로 차이가 있다
- ex. a 기능이 전환율에 영향을 미친다
- P value
- P(robability) Value
- 통계적으로 얼마나 유의미한지를 설명하는 값
- 귀무 가설이 참이라고 가정할 때, 관찰한 결과나 그보다 극단적인 결과가 우연히 발생할 확률
- 일반적으로 0.05 미만인 경우에 통계적으로 유의미하다고 판단
AB Test 결과 해석 Decision Tree
실험 종료 기간 도래하면
- 가드레일 지표 확인
- 성공 지표 확인: 유의미한 상승이 있는가
- p-value 확인 시, 0.05 미만이면 귀무가설이 기각
- 즉, 두 집단의 차이가 있다 = 실험이 통계적으로 유의미한 영향을 미쳤다
- => 실험을 종료하고 전체 배포
실험 결과가 애매한 경우(Null이 나오는 경우)
=> A, B를 세그먼트를 나눠서 분석
- 신규 사용자, 기존 사용자 여부
- Demography
- 특정 이벤트를 경험한 사람인지 여부
- 방문 빈도
- 특정 유입 채널
=> 실험 전후로 A, B가 어떻게 변했는지,
특정 이벤트를 더 많이 한 집단이 있는지 확인
(참고)
초두 효과(Primary effect)
- 최초엔 반응하지 않고 시간이 지날수록 반응
신기 효과(Novelty effect)
- 최초에 신기해서 사용 => 안정화에 시간이 걸릴 수 있음
AB Test 잘 진행하기 위한 규칙
- 실험 전
-
- 실험의 목표가 무엇인지, 어떤 지표가 중요한지 미리 결정하기
- 실험의 결과 멘탈 시뮬레이션하기
ㄴ 실험이 잘 되었을 때/잘 안 되었을 때/실험결과가 Null일 경우엔 어떤 행동을 해야 할까? - 회사에 임팩트를 줄 수 있는 실험 진행하기
ㄴ 버튼 색상 바꾸기, 문구 바꾸기는 임팩트가 상대적으로 적으니 나중에 해도 무방.
ㄴ 퍼널 관점에서 사람들을 더 전환시켜 매출을 증대시키는 것 먼저 진행. - 실험을 통해 타겟팅할 잠재 고객 구체적으로 정의하기
ㄴ 전체 고객 대상도 가능하나, 점점 구체적으로 정의하는 것 필요. - 필요한 표본 크기, 최소 탐지 기간을 미리 추정하기
ㄴ 무작정 실험 돌리자 X, 대략 이정도 사용자 수라면 며칠 정도면 되겠다 O
ㄴ AB test period calculator 사용. - 처음부터 실험군 대조군을 50:50으로 배포할 필요는 없다
ㄴ 점진적으로 전체 중 5%씩 배포해서 확인하는 것도 가능. - 답정너 실험 진행하지 않기 (중요)
ㄴ 답을 정하고 실험하는 경우가 종종 있고, 정답이 아니면 데이터를 다르게 보려고 하는 경우 존재
ㄴ 언제나 답이 틀릴수 있음을 인지하고 미리 생각해보기
-
- 실험 중
8. 실험이 진행되는 기간에 사내 전파하기
ㄴ 기술 조직 뿐 아니라, 마케팅팀, CS 팀에도 전파해서 혹시 실험에 영향받는 이슈 있다면, 바로 확인 가능한 파이프라인 마련
ㄴ 실험으로 인해 악영향을 미치는 것을 피하기
9. 계획한 전체 기간에 Test를 실행한 후, 끝나고 통계적 유의성을 확인
ㄴ 통계적 유의성은 실험기간 끝난 후 확인
ㄴ 실험 중간에는 데이터가 잘 들어오는지 확인하는 것에만 초점
10. 실험 중간에 결론내지 않기
ㄴ 실험 중간에 변형할 경우 아예 의미 없어짐
ㄴ 가드레일 지표가 급격히 떨어진 것이 아니라면 지켜보기 - 실험 후
11. 엄청 좋아보이는, 효과적인 결과가 나오면 의심하기
ㄴ 엄청 좋아보이는 숫자는 보통 계산 상의 실수가 있을 확률 높음
12. 항상 실험에 대한 내용을 잘 기록하고, 실험에서 깨닫고 배운 내용 기록하기
ㄴ 실험 문서 만들기(템플릿)
ㄴ 지속된 실험 경험으로 점점 더 좋은 실험 진행 가능
13. 분석 자동화 진행하기
ㄴ 실험 분석에 한정해 자동화하는 스크립트 개발
ㄴ 리소스가 부족하면 SaaS 적극적 이용(분석은 자동으로, 의사결정만 하면 됨)
실험 플랫폼
대표적인 실험 플랫폼
1. 무료 솔루션
- Google Optimize: Web(단, 23년 9월 서비스 종료)
- Firebase AB Testing: iOS, Android
2. SaaS(예산 투입 가능 시)
- Amplitude Experiment : PA(Product Analytics) 도구
- Mixpanel Experiment : PA(Product Analytics) 도구
- Optimizely(옵티마이즐리) : 실험 도구
- Hackle(핵클) : 실험 도구
- VWO : 실험 도구
3. 오픈 소스(인력투자 가능 시)
- GrowthBook
실험 플랫폼 선정 가이드
실험 플랫폼의 핵심 기능
1. Feature Flag
2. 테스트 그룹 분배
3. 지표 정의
4. 실험 기록
5. 실험 분석
1) Feature Flag
- 직접 Feature의 On/Off를 제어할 수 있는 기능, 쉽게 배포 조정 가능
2) 테스트 그룹 분배
- 테스트 그룹 분배기는 user_id + salt key를 해시 함수를 실행한 후, 결과값을 숫자로 변환
- 나온 숫자로 어떤 실험에 분배할지 결정
3) 지표 정의
- 실험에서 자주 사용되는 지표(전환율, 클릭률, 특정 이벤트 발생 여부)를 쉽게 정의할 수 있어야 함
- Part 4의 지표 파트에서 나온 개념들이 모두 포함되어야 함
- 커스텀하게 지표를 만들 수도 있어야 하며, 분자와 분모 조합으로 지표를 정의할 수도 있어야 함
- Metric Store가 존재하면 해당 지표를 그대로 사용할 수 있으면 좋음
4) 실험 기록
- 실험 진행 상황을 확인할 수 있는 공간
5) 실험 분석
- 실험 분석한 결과를 쉽게 볼 수 있어야 하며, 실험 결과(통계적으로 유의미한지 등)를 쉽게 알 수 있어야 함
- Segment 분석도 지원한다면 더욱 유용하게 활용할 수 있음
Amplitude Experiment: A/B Testing and Feature Flagging Powered by Customer Behavior | Amplitude
Today we’re launching Amplitude Experiment, an experimentation and feature management solution powered by analytics and customer behavior. Experiment is the first solution to provide a complete, end-to-end workflow from hypothesis to analysis that empowe
amplitude.com
읽어보면 좋은 참고 자료
해외 기업들의 실험 플랫폼
- Microsoft
- Netflix
- Airbnb
국내 기업들의 실험 플랫폼
- 우아한형제들
- 매스프레소
- 뱅크샐러드
- 버킷플레이스
- 데브시스터즈
- PUBG
- 하이퍼커넥트
- 당근마켓
- 네이버 서치ABT
'서비스 기획해요 > 강의 들어요' 카테고리의 다른 글
| [인프런] PM을 위한 데이터 리터러시_#13. 데이터 문화 만들기 (2) | 2024.11.23 |
|---|---|
| [인프런] PM을 위한 데이터 리터러시_#12. 의사 결정(Decision Making) (1) | 2024.11.22 |
| [인프런] PM을 위한 데이터 리터러시_#10. 메트릭 하이라키(Metric Hierarchy) (1) | 2024.10.18 |
| [인프런] PM을 위한 데이터 리터러시_#9. 데이터 레포트 작성, 데이터 시각화 (2) | 2024.10.17 |
| [인프런] PM을 위한 데이터 리터러시_#8. 프로젝트 회고 (1) | 2024.09.25 |
