데이터 팀의 미션과 발전 단계
데이터 조직의 미션은 신뢰할 수 있는 데이터를 바탕으로 부가 가치를 생성하는 것이다.
데이터가 매출에 어떻게 영향을 끼치는지 확인 필요
데이터 조직이 하는 일 - 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 테스트 프로세스
- 가설 세우기 : 왜 필요하고, 어떤 형태의 효과가 예상되고, 어떤 이슈들이 있을지 등을 정함
- 구현
- A/B 테스트를 사용자에게 노출(Rollout)
- Iteration(반복) -> A/B 테스트가 노출되는 퍼센트를 바꿈
- 새로운 기능이 좋으면, 모든 사용자에게 기능 노출
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)
'STUDY > DevCourse' 카테고리의 다른 글
[데브코스][데이터 분석] A/B 테스트 과정 (0) | 2024.05.21 |
---|---|
[데브코스][데이터 분석] 추천 시스템과 추천 시스템 알고리즘 (1) | 2024.05.16 |
[데브코스][데이터 분석] 데이터 마이닝 실습 (0) | 2024.05.16 |
[데브코스][데이터 분석] 데이터 마이닝 (0) | 2024.05.16 |
[데브코스][데이터 분석] 딥러닝 모델을 활용한 문장 분류 실습 (1) | 2024.05.15 |