A/B 테스트 과정 살펴보기

A/B 테스트 시스템 구성

• A/B 테스트 시스템: 런타임 시스템 + 분석 시스템
• A/B 테스트 시스템 구현 방법은 보통 SaaS를 사용하다가 직접 구현하는 식으로 고도화
  • SaaS를 사용하는 건  Front End 관련 테스트를 하는데 유용
  • 보통 Javascript를 웹사이트에 임베딩하는 형태로 작동
  • 내부 데이터와 함께 지표를 계산하려면 연동작업이 더 필요

 A/B 테스트 과정 전체적으로 살펴보기

• A/B Test Proposal & Approval
  
  • One pager with hypothesis
  • Discussion with stakeholders (주간 AB 테스트 리뷰 미팅)
• Implementation and QA
• Rollout 
• Iterations
  
  • 주간 리뷰 (주간 AB 테스트 리뷰 미팅)
  • 대시보드(Tableau, Looker, Power BI, 파이썬 노트북, …)
  • 속도가 중요 → Agile A/B Test
  • 결과가 좋으면 테스트 퍼센트를 증가 (Ramp-up)

Traffic을 A/B로 나누는 방법 이해하기

 A/B 테스트의 성격에 따라 userid를 사용할지 deviceid를 사용할지 결정한다. 

• userid:
  
  • 보통 서비스에 사용자 등록이 되는 순간 부여되는 유일한 ID
• deviceid
  
  • 로그인과 관련 없이 서비스 방문자에게 부여되는 ID로 보통 브라우저 쿠키를 이용해서 만들어짐
  • 브라우저 쿠키가 리셋되는 순간 다시 만들어짐
  • 이 ID는 사용자가 아닌 브라우저를 유일하게 지칭해 줌
  • 한 userid가 여러 개의 deviceid를 가질 수 있고 한 deviceid에 다수의 userid가 나타날 수도 있음
  • 단순 크롤링/스크래핑을 하는 봇의 경우 쿠키 지원을 안 하기에 이 정보가 없음

 Traffic을 A/B로 나누는 두 가지 방법이 존재한다.  

• 미리 모든 사용자를 A/B로 나누기
  
  • 로그인한 사용자를 대상으로 하는 경우 가능
  • 이 경우 다양한 각도에서 bias를 제거 가능
  • 비로그인 사용자를 대상으로 하는 A/B 테스트라면 불가능
  • A/B 테스트 중에 신규등록된 사용자에게도 적용 불가능
• 사용자를 동적으로 A/B 테스트 진행 중에 나누기
  
  • 일반적으로 사용되는 방법
  • 로그인한 사용자이건 아니건 적용 가능
  • 앞의 방법보다는 bias가 생길 가능성이 있음
  • 특히 interaction의 가능성이 있음

A/B 테스트 결과 분석이란?

 A/B 테스트는 경험이 중요하고 가설을 잘 세워야 한다. 그래서 A/B 테스트 결과 분석은 과학이 아닌 예술이라 볼 수 있다. A/B 테스트 실험을 제안한 사람이 분석하는 건 좋지 않다. 다양한 사람들이 모인 자리에서 결과를 분석하고 여러 의견을 듣는 것이 좋다. 이를 통해 경험 많은 사람들의 분석 방법을 다른 이들도 배울 수 있다.

 

 어느 서비스나 매출에 있어서 큰 손들이 존재한다. 큰 손들이 어느 버킷에 들어가는가는 분석에 큰 영향을 미친다. 이러한 사용자는 분석에 제외해야 한다. A/B 테스트가 아니더라도 큰 손들의 retention/churn rate을 살펴볼 필요가 있다. 그리고 봇 유저(scraper bot)가 한쪽으로 몰리는 경우 session/impression등에 큰 영향을 줄 수 있다. 그래서 항상 A/B 테스트 결과는 다양한 관점에서 바라봐야 한다. 

 

가끔은 가설이 덜 중요한 문제를 해결하려는 경우가 있으므로 가설에 대해 많은 질문을 하는 것이 중요하다. 그리고 정말 중요한 지표를 보고 있는지, 성공과 실패의 기준으로 더 중요한 지표가 있는지 항상 고민해야 한다. 무슨 테스트이건 기본으로 봐야 하는 중요 지표들(대표적으로 매출액이나 구매율)이 있다.

 

AB 테스트 분석 시각화 대시보드 요구 조건으로 다음 사항이 가능해야 한다.

• AB 테스트 전체 기간에 걸쳐 키 지표 비교 
• 일별로 키 지표의 비교
• 키 지표의 경우 통계적으로 유의미한지 무의미한지 표시(Color coding)
• 트래픽(사용자) 메타 데이터가 있다면 이를 바탕으로 필터링

유데미 추천엔진: A/B 테스트 과정

 유데미라는 회사에서 A/B 테스트를 하는 타임라인은 총 10개월이 소요되었다.

• 먼저 A/B 테스트 시스템 구축
  
  • 기존 Optimizely를 걷어내기로 결정
  • 런타임 시스템 구축: 다른 엔지니어링 팀과 협업
  • A/B 테스트 분석 시스템 구축: 데이터 엔지니어들과 분석가들이 협업
• 다음으로 A/A 테스트 수행
  
  • 검증 용도
• 총 20번의 A/B 테스트를 통해 ML 기반 추천엔진 론치
  
  • 기존 추천 방식은 마케터 중심의 규칙 기반 추천
  • 12%의 매출 증대 확인
  • 더 중요한 부분은 모든 것이 자동화되었다는 점