프로그래머스 데이터분석 데브코스 1기 - 66일차

주제

A / B 테스트
1. A / B 테스트란?
2. A / B 테스트를 하는 이유와 애자일 A / B 테스트의 필요성
3. A / B 테스트의 프로세스
4. 테스트 분석을 위해 필요한 데이터
5. A / B 테스트 관련 문제

 

1. A / B 테스트란?

• 객관적으로 새로운 기능이나 변경을 측정 / 비교하는 방식
• 가설을 실험하고 검증하는 것(실제 고객들을 대상으로)
  • 예) 새로운 추천방식이 기존의 추천방식보다 매출을 증대시키는가?
    • 어떤 지표에서 어느 정도의 임팩트가 예상되는가? 
  • 하나의 컨트롤(기존 버전)과 하나 혹은 그 이상의 테스트로 구성
  • 보통 프로덕션 환경에서 2개 혹은 그 이상의 버전(Variants)을 비교
  • 베이스라인 버전(control) vs. 테스트 버전(test)
• 보통 서비스 내의 다른 영역을 테스트하는 A / B 테스트들은 독립적이라 생각하고 다수의 A / B 테스트를 동시에 실행하는 것이 일반적임

1.1 A/B 테스트를 사용하면 안되는 경우는?

1. 데이터가 없으면 테스트를 하면 안 된다!(No Data No A/B Test)
2. 버그 수정의 임팩트를 측정하는 경우 → 빨리 고치는 것이 좋다
3. 아직 구체적이지 않은 아이디어를 테스트하는 경우
   • A/B 테스트는 비용이 낮지 않고, 실제 트래픽에 영향을 줌
   • 구체적이지 않은 아이디어는 오프라인 테스트를 해야함(고객 설문조사 등)
   • Fake door testing
4. 가설없이 굉장히 랜덤한 아이디어 테스트
5. 비교대상 없이 굉장히 새로운 기능 테스트

 

2. A / B 테스트를 하는 이유와 애자일 A / B 테스트의 필요성

• 비즈니스 관련 지표가 개선되는지 객관적으로 측정하기 위해 진행함
  • 가설 기반의 실제 사용자 대상 비교
• 위험을 최소화하기 위함
  • 사용자 설문이 좋아도 실제 사용자들이 어떻게 반응할지는 알 수 없음
  • 초반에는 작은 비율의 사용자들에게만 새 기능을 노출시키고, 문제가 없다면 비율 증가

 

2.1 왜 A/B 테스트는 애자일(Agile)해야하는가?

• A/B 테스트를 측정하는건 매우 중요함
  • 하지만 너무 오래 걸리면 어떡하지?
• 여기서 "애자일"은 일(days) / 주(weeks)를 뜻함
• 애자일 A/B 테스트 = 애자일한 제품 개선 = 애자일한 회사
• 실험 기간 감소는 빠른 배포를 뜻한다
  • 만약 ML 기반 A/B 테스트를 한다면, 모든 과정을 자동화하는 것은 매우 중요함

 

3. A / B 테스트의 프로세스

1. A/B Test 제안 & 승인

• 가설이 담긴 한 페이지짜리 제안서
• 왜, 예상 임팩트, 발생가능한 문제들, 주인 등이 담겨있어야함

2. 구현과 질의응답(QA)

3. 발표(Rollout phase, 실제 사용자들에게 노출시키는 과정)

• Smoke test(~며칠)
  • 0 - 1% 정도 테스트 그룹에게 노출
• Initial ramp (~1 주)
  • 5 - 10% 정도 테스트 그룹에게 노출
  • 매출(혹은 KPI)에 따라 크기는 상이해짐
• Intermediate ramp (~몇 주)
  • 25 - 50% 노출
• Final ramp-up / 배포
  • 100% 노출시키고 배포를 위해 준비

4. 반복

5. 정기 리뷰(주마다 실험 리뷰 회의 진행 등)

 

3.1 A/B 테스트의 구성

• 코딩없이 테스트를 진행가능하게 하는 것이 목표
  • 자주 하는 A/B 테스트는 템플릿화가 가능함
• 보통 테스트하는 기능을 백엔드단의 flag로 관리하는 것이 일반적
• A/B 테스트 파라미터를 바꾸기 위한 UI 구성 :
  • 코드 수정없이 가능해야함
  • 예) 버킷 사이즈 변경, 테스트의 시작과 중단
  • 변경 기록을 저장하는 것이 중요함

 

4. 테스트 분석을 위해 필요한 데이터

• 사용자별 A/B 버킷 정보
  • 누가 A에 들어갔고, B에 들어갔는지...
• 사용자별 행동 정보
  • 어떤 아이템들을 보았고, 클릭했고, 구매했는지 등
• 위 두가지 정보를 조인하여 A와 B로 그룹핑하여 그룹간 통계 정보를 계산(매출액 등)

4.1 사용자별 A/B 버킷 정보

• 실험 사용자들의 버킷 정보라 필요함
• 누가 어느 버킷에 들어갔는지에 대한 정보를 로깅
• 테이블로 표현가능
  • 실험ID, variant ID, timestamp, user ID 등

4.2 사용자별 행동 데이터 - 퍼널 데이터

• 각 사용자 별로(혹은 각 디바이스 별로)
  • 어떤걸 조회했는지?
  • 어떤걸 클릭했는지?
  • 어떤걸 구매했는지?, 얼마였는지?
  • 사용하였는지?

4.3 이커머스 A/B 테스트 분석

• 실험 데이터와 퍼널 데이터를 조인하기(Transform → ELT)
  • 퍼널의 맨위부터 A와 B간의 숫자를 비교 가능
  • 여기에 사용자의 메타 정보를 추가하면 다양한 분석이 가능
• 보통 시니어 데이터 분석가가 이 분석을 하게 됨
• 최종적인 대시보드 예시 :

	A(Control)	B(Test)
User Size(*)	50	51
Impressions(**)	120	115
Clicks	10	15
Converted	3	1
Revenue	1	3

(*) User Size에서는 보통 둘의 크기가 통계적으로 동일하기를 바라며, 그게 아니라면 테스트 설정에 문제가 있음을 나타냄

(**) 새로운 기능이 Impressions의 수를 줄이는 영향이 있는 것이 아니라면 (*)와 마찬가지로 통계적으로 동일해야 한다. 다르다면 실험에 문제가 있음을 나타냄

 

5. A/B 테스트 관련 문제

• 데이터로 판단할 수 없는 결정이 있음 → Data Informed Decision
• 가설없이 혹은 대충 쓴 가설로 A/B 테스트를 하는 경우
• 분석에 필요한 데이터 품질이 낮은 경우
  • 샘플 사이즈가 충분히 큰가?
  • 버킷을 나눌 때 편향이나 왜도 없이 이루어질 수 있는가?
• 결과를 선입견없이 객관적으로 분석하지 못하는 경우
  • 내 이득을 위한 방향으로 분석하지 말자!
  • 선입견 없이 분석하려면 다른 사람들 앞에서 분석하기.
• A/B 테스트 사이의 상호작용 → Multivariate Tests
  • 여러 개의 테스트를 진행 중일 때, 실험 사이에 상호작용이 있을 수 있음
  • 상호작용을 발견하기는 쉽지 않음
  • 가장 안전한 방법은 실험을 하나씩 진행하는 것(시간이 많이 걸린다는 단점 존재)
• 데이터 인프라 비용
  • A/B 테스트 분석 파이프라인은 일반적으로 굉장히 비쌈
• 비교 대상이 하나가 아닌 경우
  • 한번에 한 개 이상의 변화를 테스트할 때
    • UI 변화와 새로운 추천 시스템을 동시에 테스트할 때
  • 컨트롤 사용자와 테스트 사용자가 똑같지 않을 때
• 얼마나 지켜보고 결정을 내릴 것인가?