[TIL] 데이터분석 데브코스 66일차 - 애자일 AB Test

데이터 조직의 미션

: 신뢰할 수 있는 데이터를 바탕으로 부가 가치를 생성하는 것

 

 

 

1. Decision Science

: 고품질 데이터를 기반으로 의사 결정권자에게 입력을 제공하는 것

• 데이터 분석가가 하는 일
• ex. 데이터 기반 지표 정의, 대시 보드와 리포트 생성 등
• Data Driven Decisions : 과거의 데이터를 기반으로한 결정으로, 혁신 보다는 최적화(지금 하는 일을 더 잘하는 것) 방향으로 진행됨
• Data Informed Decisions : 데이터를 고려한(참고) 결정으로, 최종 결정은 의사결정권자의 직관으로만 진행됨

※ AB 테스트는 이미 있는 데이터로 분석할 때 기존의 것과 비교하기 위해 사용된다.

 

 

2. Product Science

: 고품질 데이터를 기반으로 사용자 서비스 경험 개선 혹은 프로세스 최적화를 하는 것

• 데이터 과학자가 하는 일
• ex. 머신러닝 알고리즘을 통해 사용자 서비스 경험 개선, 개인화 추천, 검색 기능 제공, 공정 오류 최소화, 기기 고장 예측 등

 

 

데이터의 흐름

1. 서비스에서 직접적으로 데이터가 발생 or 써드 파티를 통해 간접적으로 데이터가 발생

2. 데이터 엔지니어가 데이터를 추출해서 분석에 용이하도록 변환한 후 데이터 웨어하우스에 적재

3. 데이터 분석가가 DBT로 분석에 사용하기 쉬운 새로운 테이블 생성

4. 데이터 과학자들이 ML 등을 사용하여 사용자 경험을 개선하거나 프로세스를 최적화

 

 

 

 

 

 

 

 

---

AB Test(= Split Test, Bucket Test, 실험)

: 실제 사용자를 대상으로 새로 만든 기능 혹은 변경을 기존 기능과 비교하기 위해 테스트하는 과정

 

• Randomized Controlled Trial의 온라인 버전
• Data Driven Decision의 과정
• 기본적으로 가설이 있어야 함 → AB 테스트는 가설을 실험하고 검증하는 과정
  • 필수 조건1) 어떤 지표를 기준으로 성공/실패를 측정하는지 (7:00~)
  • 필수 조건2) 
• 처음부터 50:50으로 하지 않고 1%의 트래픽에만 50:50으로 조금씩 나누어 점진적으로 수를 늘려 테스트를 수행
  → 큰 위험없이 새로운 기능을 테스트하고 빠르게 배울 수 있음
• 보통 서비스 내 다르 영역을 테스트하는 A/B test들은 독립적이라 생각하고 다수의 A/B Test를 동시에 실행함
• 프로덕션 환경에서 2개 혹은 그 이상의 버전(Variants)을 비교하는 방식
  • A : 기존 기능 = 베이스라인 버전(Control)
  • B : 새로운 기능 = 테스트 버전 (Test)

• 코딩 없이 테스트를 진행하는것이 목표 → 자주하는 테스트는 템플릿화
• 보통 테스트하는 기능을 백엔드단의 flag로 관리

 

 

Interations (상호작용) 13:00~

: 

 

AB Test를 사용하면 안되는 경우

• 데이터가 없는 경우
• 버그 수정의 임팩트를 측정하는 경우 (빨리 고치는게 best)
• 아직 구체적이지 않은 아이디어를 테스트하는 경우
• 가설없이 랜덤한 아이디어를 테스트하는 경우
• 비교 대상없이 새로운 기능을 테스트하는 경우

 

 

 

AB Test를 하는 이유

• 비즈니스 관련 지표가 개선되는지 객관적으로 측정하기 위해
• 실제 사용에 대한 위험을 최소화하기 위해

 

 

애자일 AB Test가 필요한 경우

• AB test를 구성하고 분석해서 ML모델을 구축하는데에는 시간이 소요된다.
• 얼마나 빠르게 AB test를 셋업할 수 있느냐가 제품이 개발되는 속도를 결정한다.

 

 

 

 

 

 

 

AB 테스트 프로세스

1. 가설 설정
2. 주간미팅에서 패널 형태로 리뷰 및 질의응답
3. AB Test 실행 및 QA
4. Rollout : 실제 사용자들에게 테스트
   1. Smoke test : 며칠 소요, 0~1%만 테스트
   2. Initial ramp : 1주일 소요, 5~10%만 테스트
   3. Intermediate ramp : 몇 주 소요, 25~50%만 테스트
   4. Final ramp-up/Launch : 100% 테스트하고 런치
5. 이러한 과정을 반복
6. 전체 트래픽의 50:50으로 들어갔을 때 새로운 기능이 더 좋은 결과를 나타내면 종료
7. 기존 기능보다 낮은 결과를 보인다면 Weekly Experiment Review meeting에서

 

 

 

 

 

 

 

 

 

AB Test 분석을 위해 필요한 데이터

1. 사용자별 AB Bucket 정보

• 실험별로 누가 A에 들어갔고 B에 들어갔는가
• Experiment ID, Variant ID, Timestamp, User ID 등 포함 ← 백엔드 엔지니어가 이러한 정보를 저장

 

2. 사용자별 행동 정보 (User Behavior Data, Funnel Data)

• 어떤 아이템을 봤는가 (Impressions)
• 어떤 아이템을 클릭했는가 (Click to Detail Page)
• 어떤 아이템을 구매했는가 (Purchase)
• 구매된 아이템이 소비되었는가 (Consumption)

 

► 데이터 분석가들이 위의 1, 2를 JOIN해서 A와 B로 그룹핑 → 그룹 간 통계 정보 계산

(여기에 사용자의 Meta data를 추가하면 보다 다양한 분석이 가능함)

 

 

 

 

 

 

 

AB Test에서 문제가 발생하는 경우

• Data Informed Decision의 경우 데이터로 판단 불가함
• 가설이 없거나 대충 쓴 가설로 테스트할 경우
• 분석에 필요한 데이터 품질이 낮은 경우
• 결과를 선입견없이 객관적으로 분석하지 못하는 경우
• 테스트 간 상호작용(Interactions)이 발생하는 경우 (3:00~
• 데이터 인프라 비용 → 리뷰 미팅때 어떤 테스트를 중단할지도 결정해야함
• 비교 대상이 하나가 아닌 경우