A/B 테스트

A/B 테스트 = 실험 (Split Test or Bucket Test) (색깔에 따라 ...)

다수의 Varient 로 구성됨 - 하나의 컨트롤(기존 버전) 과 하나 혹은 그 이상의 테스트 

 

A/B Test 

객관적으로 새로운 기능이나 변경을 측정/비교하는 방식

큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법

실제 유저(1%, 5% ...점점 늘려가보고) 에게 노출해보고 결정한다. 

 

가설 없는 A/B Test는 불가

• A/B Test는 기본적으로 가설을 실험하고 검증하는 것
• 예1) 새로운 추천방식이 기존의 추천방식보다 매출을 증대시키는가?
  • 어떤 지표에서 어느 정도의 임팩트가 예상되는가?
  • 가설을 나중에 결과에 비교하면서 생각지 못했던 다양한 배움이 생김
• 예2) 상품 체크아웃 페이지의 스텝을 줄이면 결제가 더 올라가는가?
  • 스텝을 줄이면 정말 매출이 올라갈까?
  • 사용자 관점과 개발자 관점은 굉장히 다를 수 있음

보통 프로덕션 환경에서 2개 혹은 그 이상의 버전을 비교 해본다.

• 베이스라인 버전("control") vs 하나 혹은 그 이상의 테스트 버전("test")
  • "control" : 현재 버전
  • "test" : 새 버전
• 보통 서비스 내의 다른 영역을 테스트하는 A/B 테스트들은 독립적이라고 생각하고 다수의 A/B 테스트를 동시에 실행하는 것이 일반적
• 하지만 상호작용이 있을 수 있다. 

 

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

 

회사의 데이터가 적은 경우

버그 수정 임팩트를 측정하는 경우 - 빨리 고치는 것이 중요

구체적이지 않은 아이디어 테스트 

가설없이 굉장히 랜덤한 아이디어 테스트

비교대상없이 굉장히 새로운 기능 테스트

 

A/B 테스트를 하는 이유

비지니스 관련 지표를 개선되는지 객관적으로 측정하기 위함 - 가설 기반의 실제 사용자 대상 비교

위험을 최소화하기 위함 - 아무리 사용자 설문이 좋아도 실제 사용자들의 반응을 알 수 없음 / 처음에는 작은 퍼센트의 사용자들에게만 새 기능을 노출시키고 문제가 없으면 퍼센트를 증가시킨다. 

 

--> 빠른 순환 주기로 A/B 테스트를 진행해 줘야 한다. 

 

전체적인 A/B test 프로세스

일주일에 한 번씩 A/B 테스트 미팅이 있다. 1) 새로운 A/B 테스트 제안 2) 실행중인 A/B 테스트 리뷰

제안할 때는 제안서를 작성, 하는 이유 

 

A/B 테스트 Configuration

코딩없이 A/B 테스트를 진행가능하게 하는 것이 목표 (자주 하는 A/B 테스트들은 템플릿화가 가능)

보통 테스트하는 기능을 백엔드단의 flag로 관리하는 것이 일반적

 

A/B 테스트 분석을 위하여 필요한 정보

1. 사용자별 A/B 버킷 정보 - 누가 A에 들어갔고 B에 들어갔는지

2. 사용자별 행동 정보 - 어떤 아이템들을 보았고, 어떤 아이템들을 클릭했고, 어떤 아이템들을 구매했는지

 

1과 2의 정보를 조인, A와 B로 그룹핑하여 그룹간 통계 정보 계산(매출액 등)