[데브코스][데이터 분석] 애자일 A/B 테스트

데이터 팀의 미션과 발전 단계

데이터 조직의 미션은 신뢰할 수 있는 데이터를 바탕으로 부가 가치를 생성하는 것이다.

데이터가 매출에 어떻게 영향을 끼치는지 확인 필요

 

데이터 조직이 하는 일 - Decision Science

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

-> 데이터를 고려한 결정(data informed decisions)을 가능하게 해줌. 

-> 데이터 기반 지표 정의, 대시보드와 리포트 생성 등을 수행

* 데이터 고려한 결정(data informed decisions) VS 데이터 기반 결정(dat driven decisions)
- 데이터를 고려한 결정 : 데이터는 참고 수단이고 의사 결정권자가 결정(새로운 일을 할 때)
- 데이터 기반 결정 : 데이터를 보고 나타난 결과를 바탕으로 결정(A/B 테스트처럼 기능을 비교할 때)

 

데이터 조직이 하는 일 - Product Science

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

-> 머신러닝과 같은 알고리즘을 통해 사용자의 서비스 경험을 개선

ex. 개인화를 바탕으로 한 추천과 검색 기능 제공

 

A/B 테스트란 무엇인가?

A/B 테스트 = 실험 ( = Split Test or Bucket Test)

: 실제 사용자를 대상으로 하는 실험

ex. 50%에는 기존 기능 제공, 50%에는 새로운 기능 제공

-> 그 후 새로운 기능의 효과가 발생하면, 새로운 기능을 제공하는 사용자의 비율을 높이는 방식을 택함

 

- 다수의 Variant로 구성됨

: 하나의 컨트롤(기존버전)과 하나 혹은 그 이상의 테스트

 

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

- 큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법 (위험부담이 적음)

 

- 가설없는 A/B 테스트는 불가함

: A/B 테스트는 기본적으로 가설을 실험하고 검증하는 것임. 

 

ex. 새로운 추천 방식이 기존의 추천방식보다 매출을 증대시키는가?

-> 어떤 지표에서 어느 정도의 임팩트가 예상되는가

 

ex. 상품 체크아웃 페이지의 스템을 줄이면 결제가 더 올라가는가?

-> 스텝을 줄이면 정말 매출이 올라갈까? / 사용자 관점과 개발자 관점은 굉장히 다를 수 있음

 

- 보통 프로덕션 환경에서 2개 혹은 그 이상의 버전(Variants)을 비교

: 베이스라인 버전(control) VS 하나 혹은 그 이상의 테스트 버전(test)

* control : 현재 버전 / test : 새 버전

: 보통 서비스 내의 다른 영역을 테스트하는 A/B 테스트들은 독립적이라 생각하고 다수의 AB Test를 동시에 실행하는 것이 일반적

-> 한 사용자가 보통 여러 A/B 테스트에 속하기 때문에 이 상황 속에서 우리가 생각하지 못하는 결과가 발생할 수 있음

==> 결과에 상호작용이 존재할 수 있음

 

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

- No Data, No A/B Test (작은 회사일 경우)

- 버그 수정으로 임팩트를 측정하는 경우 (버그는 빨리 고치는 것임)

- 아직 구체적이지 않은 아이디어 테스트 (-> 가설을 확실히 세우고 의논하는 것이 필요)

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

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

 

왜 A/B 테스트를 하고 왜 애자일 A/B 테스트가 필요한가?

왜 A/B 테스트를 하는가?

- 비즈니스 관련 지표의 개선을 객관적으로 측정하기 위함

-> 가설 기반의 실제 사용자 대상 비교

 

- 위험을 최소화하기 위함

: 아무리 사용자 설문 등의 지표가 좋아도 실제 사용자들이 어떻게 반응할지는 알 수 없음 (동일한 조건에서 기능 테스트)

: 처음에는 작은 퍼센트의 사용자들에게만 새 기능을 노출시키고 문제가 없으면 퍼센트 증가

 

왜 A/B 테스트는 애자일해야 하는가?

: A/B 테스트는 초기 세팅과 결과 분석 모두 시간이 걸림

-> 이 과정이 빠르게 진행되면 서비스의 발전 속도가 빨라짐

 

A/B 테스트 프로세스

1. 가설 세우기 : 왜 필요하고, 어떤 형태의 효과가 예상되고, 어떤 이슈들이 있을지 등을 정함
2. 구현
3. A/B 테스트를 사용자에게 노출(Rollout)
4. Iteration(반복) -> A/B 테스트가 노출되는 퍼센트를 바꿈
5. 새로운 기능이 좋으면, 모든 사용자에게 기능 노출

 

Rollout

1. Smoke Test

: 굉장히 작은 퍼센트의 트래픽을 대상으로 반으로 나눠 A/B 테스트 진행

 

2. Initial ramp

: 앞선 과정에서 문제가 없으면 5~10%의 트래픽을 대상으로 진행

 

3. Intermediate ramp

: 25~50%

 

4. Final ramp-up

: 모든 100%의 트래픽에 새로운 기능 론칭

 

A/B Test Configuration

- A/B 테스트가 애자일하려면, 자주하는 A/B 테스트들은 템플릿화를 하여, 

코딩을 하지 않고도 진행할 수 있게 해야함. 

 

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

 

 

A/B 테스트 분석을 위해 필요한 데이터

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

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

 

=> 이 두 가지 정보를 조인하고, A와 B로 그룹핑하여 그룹간 통계 정보 계산(매출액 등)

 

A/B 테스트 관련 문제들

- 비교 대상이 없는 새로운 기능을 만드는 경우에는 A/B 테스트로 판단할 수 없음

- 가설 없이 혹은 대충 쓴 가설로 A/B 테스트를 진행하는 경우 문제 발생

- 데이터의 품질이 낮거나 데이터가 적을 때 문제 발생

- 결과를 선입견없이 객관적으로 분석하지 못한 경우

- 여러개의 A/B 테스트를 진행할 때, 조합이 제대로 되지 않으면 이상한 결과가 생길 수 있음

-> 넷플릭스의 경우에는 사용자를 미리 철저하게 나눠놓고 A/B 테스트를 진행함

 

- 데이터 인프라 비용 : A/B 테스트 시 굉장히 많은 데이터를 분석하기 때문에 비용이 많이 듦.

- 비교 대상이 하나가 아닌 경우 : 비교 대상을 제대로 명시해야 어떤 기능이 효과적인지 알 수 있음

- 얼마나 지켜보고 결정을 내릴 것인가? : 테스트의 성격에 따라 달라짐 -> 그룹이 판단하여 결정(개인 X)