66-(1). A/B test

학습 주제

• 데이터 팀의 미션과 발전 단계
• A/B Test란 무엇인가?
• A/B Test 시스템 구성
• Traffic을 A/B로 나누는 방법 이해하기

주요 학습 내용

• 데이터 조직의 미션은?
  • 신뢰할 수 있는 데이터를 바탕으로 부가  가치 생성
    - Data is the new oil
    - but data can be a liability
    - 데이터의 잘못된 노출과 사용으로 인한 위험을 줄여야 한다.
• 데이터 조직이 하는일
  1. Decision Science
     • 고품질 데이터 기반으로 의사 결정권자에게 입력 제공
       - 데이터를 고려한 결정을 가능하게 해줌 vs. 데이터 기반 결정
       - ex) 데이터 기반 지표 정의, 대시보드와 리포트 생성 등을 수행
  2. Product Science
     • 고품질 데이터를 기반으로 사용자 서비스 경험 개선 혹은 프로세스 최적화
       - 머신 러닝과 같은 알고리즘을 통해 사용자의 서비스 경험을 개선
       - ex) 개인화를 바탕으로한 추천과 검색 기능 제공,
               공장이라면 공정 과정에서 오류를 최소화 혹은 기기 고장 예측등을 수행
• A/B Test
  • 실험과 같다 (Split Test or Bucket Test)
  • https://www.invespcro.com/blog/what-is-ab-testing-split-testing/
  • 다수의 변이로 구성됨
  • 객관적으로 새로운 기능이나 변경을 측정/비교하는 방식
  • 큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법
  • 가설없는 A/B Test는 불가! 
    - A/B test란 기본적으로 가설을 실험하고 검증하는 것
    - ex) 1. 새로운 추천방식이 기존의 추천방식보다 매출을 증대시키는가?
              - 어떤 지표에서 어느 정도의 임팩트가 예상되는가?
              - 가설을 나중에 결과에 비교하면서 생각지 못했던 다양한 배움이 생김
            2. 상품 체크아웃 페이지의 스텝을 줄이면 결제가 더 올라가는가?
              - 스텝을 줄이면 정말 매출이 올라갈까?
              - 사용자 관점과 개발자 관점은 굉장히 다룰 수 있음
  • 보통 프로덕션 환경에서 2개 혹은 그 이상의 버전을 비교
    - 베이스라인 버전 (“control”) vs. 하나 혹은 그 이상의 테스트 버전 (“test”)
    - “control”: 현재 버전
    - “test”: 새 버전
  • 보통 서비스내의 다른 영역을 테스트하는 A/B Test들은 독립적이라 생각하고 다수의 AB Test를 동시 실행하는 것이 일반적
    - 상호작용이 있을 수 있음
• A/B Test를 사용하면 안되는 경우
  
  • No Data No A/B Test
  • 버그 수정을 임팩트를 측정하는 경우
  • 아직 구체적이지 않은 아이디어 테스트
  • 가설없이 굉장히 랜덤한 아이디어 테스트
  • 비교대상없이 굉장히 새로운 기능 테스트
• 왜 A/B Test를 하는가?
  • 비지니스 관련 지표를 개선되는지 객관적으로 측정하기 위함
    - 가설 기반의 실제 사용자 대상 비교
  • 위험을 최소화하기 위함
    - 아무리 사용자 설문등이 좋아도 실제 사용자들이 어떻게 반응할지는 알 수 없음
    - 처음에는 작은 퍼센트의 사용자들에게만 새 기능을 노출시키고 문제가 없으면 퍼센트 증가
  • 애자일 A/B 테스트 = 애자일 제품 개선 = 애자일 기업
    - 출시에 이르기까지 평균 6번의 반복 작업이 필요하고 각 반복 작업에 1개월이 소요되는 경우 출시하는데 시간이 더 소요
  • 실험시간 단축 => 빠른 런칭
• A/B Test Process
  • A/B 시험제안서 및 승인
    1. 가설 세우기
         (이유, 예상 영향, 신뢰 수준, 시작할 MVP, 잠재적 문제, 소유자), (구현, QA 및 분석)
    2. 이해관계자와의 논의
    3. 구현 및 QA
    4. Rollout
    5. Iterations
       - 주간 리뷰 (주간 AB 테스트 리뷰 미팅)
       - 대시보드가 있으면 금상첨화 (Tableau, Looker, Power BI, 파이썬 노트북, …)
       - 여기서부터 속도가 중요해짐 -> Agile A/B Test
       - 결과가 좋으면 테스트 퍼센트를 증가 (Ramp-up)
         ■ 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% 
    6. 정기적 검토(주간 실험 검토 회의)
• A/B Test Rollout 단계
  1. Smoke test(~며칠)
     • 손상된 부분이 없는지 확인하기 위한 테스트 변형의 경우 0~1%
     • 테스트 변형이 올바르게 설정되었는지 확인
  2. 초기 램프(~1주)
     • 테스트 변형의 경우 5~10%
     • 규모는 수익(또는 KPI) 문제에 따라 달라집니다.
  3. 중간 램프(~몇 주)
     • 25%-50%
  4. 최종 램프업/출시
     • 100% 이후 테스트 변형 성공을 위한 전체 출시
• A/B Test 구성
  • 코딩없이 A/B 테스트를 진행가능하게 하는 것이 목표
    - 자주 하는 A/B 테스트들은 템플릿화가 가능함
  • A/B Test 구성
    - Hashing parameter (e.g. userid, deviceid)
    - Bucket size (% of traffic)
  • 보통 테스트하는 기능을 백엔드단의 flag로 관리하는 것이 일반적
  • 감사 목적으로 변경 이력을 유지하는 것이 중요
• A/B Test시 발생하는 문제들 
  • 어떤 결정은 데이터로 판단할 수 없음 => Data Informed Decision
  • 가설없이 혹은 대충 쓴 가설로 A/B Test를 하는 경우
    - A/B Test 남용 금지
  • 분석에 필요한 데이터 품질이 낮은 경우
    - A/B 테스트 또는 유입 경로에 버그가 있으면 품질 문제가 발생
    - 표본 크기가 충분히 큰가?
    - bias이나 왜곡이 없어야 한다.
  • 결과를 선입견없이 객관적으로 분석하지 못하는 경우
    - 보통 최소 일주일 정도는 기다리고,  자신에게 유리하게 해석하면 안된다.
    - 결과는 지식 공유를 위해 그룹 환경에서 해석되어야 하며, 집단적학습과 객관적 분석이 좋다.
  • A/B 테스트 간의 상호작용(상호복합) -> 다변량 테스트
    - 여러 A/B 테스트를 실행하면 둘 사이에 상호 작용이 있을 수 있습니다.
    - 상호작용이 쉽게 포착되지 않음
    - 가장 안전한 방법은 한 번에 테스트를 실행하는 것이지만 시간이 너무 오래 걸릴 수 있습니다.
  • 데이터 인프라 비용
    - A/B 테스트 분석 파이프라인은 일반적으로 비용이 매우 높음(에어비앤비 데이터 인프라 사용량의 70%)
  • 비교 대상이 하나가 아닌 경우
    - 한 번에 두 개 이상의 변경 사항 테스트
    - UI 변경과 새로운 추천을 동시에 테스트
    - 컨트롤 사용자와 테스트 사용자는 동일하지 않다.
  • 얼마나 지켜보고 결정을 내릴 것 인지?
    -  A/B 테스트의 성공 여부를 결정하기까지 얼마나 기다릴까?

---

• A/B Test 시스템 : 런타임 시스템 + 분석 시스템
• 구현 방법
  • 직접 구현
  • SaaS 사용
    - 많이 사용되는 서비스들
    1. Optimizely
    2. VWO
  • 대체적으로 Front End 관련 테스트를 하는데 유용
    - 보통 Javascript를 웹사이트에 임베딩하는 형태로 작동
    - 내부 데이터와 함께 지표를 계산하려면 연동작업이 더 필요
    - 보통은 SaaS를 쓰다가 직접 구현하는 식으로 고도화됨
• userid vs. deviceid
  • A/B 테스트의 성격에 따라 userid를 사용할지 deviceid를 사용할지 결정
    - 로그인한 사용자에게만 하는 테스트인가? 신규 vs. 기존 vs. 모두
    - 모든 방문자에게만 하는 테스트인가?
  • userid
    - 보통 서비스에 사용자 등록이 되는 순간 부여되는 유일한 ID
  • deviceid
    - 로그인과 관련없이 서비스 방문자에게 부여되는 ID로 보통 브라우저 쿠키를 이용해서 만들어짐
  • 브라우저 쿠키가 리셋되는 순간 다시 만들어짐
    - 이 ID는 사용자가 아닌 브라우저를 유일하게 지칭해줌
    - 한 userid가 여러 개의 deviceid를 가질 수 있고 한 deviceid에 다수의 userid가 나타날 수도있다
    - 단순 크롤링/스크래핑을 하는 봇의 경우 쿠키 지원을 안 하기에 이 정보가 없음
• 크게 두 가지 방법이 존재한다.
  1. 미리 모든 사용자를 A/B로 나누기
     • 로그인한 사용자를 대상으로 하는 경우 가능
     • 이 경우 다양한 각도에서 bias를 제거 가능
     • 하지만 비로그인 사용자를 대상으로 하는 A/B 테스트라면 이는 불가능
     • 또한 AB 테스트 중에 신규등록된 사용자에게도 적용 불가능
     • 넷플릭스가 사용하는 방법
  2. 사용자를 동적으로 A/B 테스트 진행 중에 나누기
     • 일반적으로 사용되는 방법
     • 로그인한 사용자이건 아니건 적용가능
     • 하지만 앞의 방법보다는 bias가 생길 가능성이 있음
       - 특히 interaction의 가능성이 있음
• 이후 Colab으로 트래픽 나누기 실습을 진행해보겠습니다.