[DEV] A/B 테스트

1. A/B Test

• Split Test / Bucket Test 라고도 부름
  • Randomized Controlled Trial의 온라인 버전
• 다수의 Variant로 구성됨
  • 하나의 컨트롤 (기존 버전)과 하나 혹은 그 이상의 테스트
• 보통 귀무가설 사용
• 처음에는 한 쪽에 1% 정도만 부여를 하고, 50%까지 점점 늘려감

• 객관적으로 새로운 기능이나 변경을 측정/비교하는 방식
  • 객관적: 실제 사용자에게 노출시켜서 반응을 보는 것
• 큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법

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

• 실제 프로덕션 환경에서 2개 혹은 그 이상의 버전을 비ㅣ교
  • 베이스라인 버전 (‘control’) vs. 하나 혹은 그 이상의 테스트 버전 (‘test’)
  • 보통 서비스 내의 다른 영역을 테스트하는 A/B Test들은 독립적이라 생각하고 다수의 A/B Test를 동시에 실행하는 것이 일반적
    • 하지만 상호작용이 있을 수 있음

A/B Test를 사용하면 안되는 경우

• data가 없는 경우
• 버그 수정의 임팩트를 측정하는 경우
  • 그냥 빨리 고치는 것이 좋음
• 아직 구체적이지 않은 아이디어 테스트
  • A/B Test의 비용은 저렴하지 않음, 또한 실제 트래픽에 영향을 주기 때문에 신중해야 함
  • offline testing이나 user servey 등으로 아이디어의 의미를 테스트해볼 수 있음 -> 구체화
  • Fake door testing
• 가설없이 굉장히 랜덤한 아이디어 테스트
• 비교대상없이 굉장히 새로운 기능 테스트

A/B Test를 하는 이유

• 비즈니스 관련 지표가 개선되는지 객관적으로 측정하기 위함
  • 가설 기반의 실제 사용자 대상 비교
• 위험을 최소화하기 위함

왜 A/B Test는 애자일해야 하는가

• A/B Test를 set up, 분석하는데 오래 걸릴수록 회사의 발전 속도가 느려지는 것

2. 전체적인 A/B Test 프로세스

• 일주일에 한 번씩 A/B Test 미팅 (Proposal & Approval)
  • 새로운 A/B Test 제안
    • 간단하게
    • 어떤 부분을 바꾸고 싶은지, 바꾸고 싶은 이유, 기대 효과(어느 지표로), 얼마나 자신있는지, 어떻게 하면 될 지, 어떤 이슈들이 있을지
  • 지금 실행중인 A/B Test review
• Implementation & QA
• Rollout
• Iterations
• Periodic Review

Rollout Phases

• Smoke test (~ few days)
  • 0-1%
• Initial ramp (~ 1 week)
  • 5-10%
• Intermediate ramp (~ few weeks)
  • 25-50%
• Final ramp-up / launch
  • 100%

A/B Test Configuration

• 코딩없이 A/B Test를 진행 가능하게 하는 것이 목표
  • 자주하는 A/B Test들은 템플릿화가 가능함
• A/B Test Configurations
  • Hasing parameter (userid, deviceid ..)
• 보통 테스트하는 기능을 백엔드 단의 flag로 관리하는 것이 일반적
• A/B Test Parameter를 바꾸기 위한 UI 생성
  • 코드 변경 없이
  • bucket size 변경, start/stop 등

3. 필요한 데이터

• 사용자별 A/B 버킷 정보
  • 누가 A, B에 들어갔는지
  • A/B Test별로 필요
• 사용자별 행동 정보
  • 어떤 아이템들을 보았고
  • 어떤 아이템들을 클릭했고
  • 어떤 아이템들을 구매했는지
  • …

• 위 두 정보를 조인
• A, B로 그룹핑하여 그룹간 통계 정보 계산 (매출액 등)

Funnel data

• Impression
• Click

Result

• Experiment data와 Funnel data join (Transform -> ELT)
  • 사용자의 메타 정보를 추가하면 다양한 분석이 가능
• 보통 시니어 데이터 분석가가 분석을 하게 됨

BI Dashboard

• Tableau 주로 이용

4. A/B Test 시 발생하는 문제들

• 어떤 결정은 데이터로 판단할 수 없음 -> Data Informed Decision
  • 어떠한 결정은 직관에 따라 결정해야 할 때도 있음
• 가격은 A/B Test로 결정할 수 없음!
• 가설없이 혹은 대충 쓴 가설로 A/B Test를 하는 경우
• 분석에 필요한 데이터 품질이 낮은 경우
  • A/B Test에 버그가 있거나 Funnel에 퀄리티 이슈가 있는 경우
  • A와 B가 50:50이 아닌 경우
  • 샘플이 충분히 큰지 확인
• 결과를 선입견없이 객관적으로 분석하지 못하는 경우
  • 악용될 경우 개인의 이익과 팀의 이익을 위해 충돌이 생길 수 있음 (정치적)
  • 항상 group setting
• Interactions (상호작용) 문제
  • 여러 A/B Test를 동시에 진행하는 경우 그 간의 의존도가 생길 수 있음
  • 이상한 상호작용 -> 사용자의 행동을 바꿔버릴 수 있음
• 데이터 인프라 비용
• 비교 대상이 하나가 아닌 경우
  • 기본적으로 하나만 바꿔서 비교
  • 어떤 변화가 영향을 미친 것인지 알기 어렵기 때문
• 얼마나 지켜보고 결정을 내릴 것인지

5. A/B Test 과정

• A/B Test 시스템은 런타임 시스템과 분석 시스템으로 구성

구현 방법

• 직접 구현
• 회사가 작은 경우 SaaS 사용
  • Optimizely
  • VWO

6. traffic을 나누는 방법

userid vs. deviceid

• A/B Test 성격에 따라 결정
  • 로그인한 사용자에게만 하는 테스트인가
  • 모든 방문자가에게 하는 테스트인가
• userid
  • 보통 서비스에 사용자 등록이 되는 순간 부여되는 유일한 id
• deviceid
  • 로그인과 관련없이 서비스 방문자에게 부여되는 id로, 보통 브라우저 쿠키를 이용해 만들어짐

방법

• 미리 모든 사용자를 A/B로 나누기
  • 로그인한 사용자를 대상으로 하는 경우 가능
  • 다양한 각도에서 bias 제거 가능
  • 비로그인 사용자, A/B Test 중에 신규등록된 사용자에게 적용 불가능
  • 넷플릭스
• 사용자를 동적으로 A/B Test 진행 중에 나누기
  • 일반적으로 사용됨
  • 로그인하지 않아도 적용 가능
  • 앞의 방법보다는 bias가 생길 가능성이 있음
    • 특히 interacion의 가능성이 있음