
이 글에선 어떤 걸 얻을 수 있나?
- 실험은 무엇이고 왜 하는가
- 어떻게 진행이 되는가
- 실험에 자주 쓰이는 용어들
A/B test의 개념
- 임의로 나눈 두 집단에 서로 다른 것을 보여준 후 어떤 집단이 높은 성과를 보이는지 정량적으로 평가하는 방식, '무작위 비교 연구' 라고 불리는 방법을 서비스에 적용한 것
- 간단히 말해 푸시메세지를 유저들에게 보내려 하는데, A 집단에겐 "24시간 할인"과 B집단에겐 "상시할인" 이라는 워딩을 했을 때 어느 쪽에서 더 반응이 좋은지를 테스트를 통해 결정하는 것.
A/B test 가 왜 필요한가?
1. 인과관계를 파악하여 유의미한 처치를 내리기 위해 (인과관계는 상관관계와 다르다)
- 상관 관계는 데이터를 통해서 가져올 수 있는 가장 베이직한 인사이트
예시 상황: 현재 유저의 < W2 사용 여부>와 <가입 후 3일 이내 A 기능 사용 여부>가 상관 관계가 있음을 확인한 상황이다. 그러면 유저들에게 가입 후 3일 이내 A 기능을 사용하도록 팝업을 띄워 유도하면 w2 사용비율이 늘까?
→ No. 상관도가 높다해서 그것이 원인이라고 말하기 힘들다. 고객에게 유용한 전략을 펼치기 위해선 그게 가능하게 만드는 원인을 파악해야 하고, 그것은 인과관계를 통해서 알 수 있다.
여름철 과일인 포도와 수박의 판매량은 판매량의 상관도가 높지만, 그렇다고 포도를 먹기 때문에 수박을 먹는다고 말할 수 없듯이, 다양한 외생변수 (시즈널리티, 마켓팅 이벤트 ) 등이 개입 하는 상황에서 정말 A 기능의 효과를 알기 위해선 인과관계를 파악해야한다.
→ A 기능의 사용여부에만 차이를 두고 외생변수의 차이로 인한 영향을 가능한 최소화 하여 인과 관계를 가장 잘 진단할 수 있는 최상위 방법론이 A/B 테스트(랜덤 테스트)
2. 현실적으로 대부분의 아이디어들은 실패할 확률이 더 높기에
Google과 같은 대부분의 IT 기업에서 실험한 아이디어 중 대략 2/3 정도가 실패로 나타난다( 출처: Kohavi, Crook and Longbotham 2009) . 즉, 우리가 생각하는 것과 유저들의 반응은 다를 가능성이 높음
→ 실험을 미리 해보면서 유저의 반응을 확인하는 게 매우 중요한 이유.
또한, 아이디어 실패는 매우 당연하게 일어나는 것이며 실패를 통해 무언가를 배우고 다음 단계로 나아가 더 실험의 가치를 더욱 증대시킬 수 있는 방법
→ 데이터 팀에서는 실험 진행에 대한 문서와 정보를 잘 남겨두어 서로의 실험들이 후에 도움이 될 수 있는 기반을 만들고 있다
그럼 A/B test 는 어떻게 설계되는가?
설계과정 :
- 기획
- 사용자 및 지표 설정
- 실험환경 세팅
- 각 실험군에 사용자 배치
- 실험 조치
- 실험 환경 재확인
- 결과 분석
위의 과정 중 분석가가 고려해야 하는 것이 많은 굵게 표시된 부분들에 대한 설명.
사용자 및 지표 설정
가설과 그에 따른 지표 설정 (목적 지표, 가드레일)
- 가설:
- 실험의 방향성과 목적을 정확히 하기 위해 설정. 실험을 하는 이유가 곧 이 가설 검증이기에, 가설이 없으면 실험은 진행될 수가 없음.
목적지표(Key metric)
- 실험의 성과를 결정하는 지표이자, 실험의 방향성을 담은 지표이걸 미리 정해 놓지 않으면 실험의 방향성이 제대로 정립 되지 않은 상태에서 실험이 진행이 되어버리고, 실험의 목적에 대해 진행이 되는 와중에 헤메일 수 있다. 실험을 왜 하는지, 무엇을 보고 실험군이 대조군보다 낫다, 아니다를 판단할건지를 미리 정해야함.
- 실험은 어떤 안이 더 나을까를 판단하려고 하는 것, 그럼 그 안이 더 낫다는 것을 무엇을 보고 판단하지? → 목적 지표(성과 지표)를 보고 판단.
- 직관적이며 구하기 용이한 지표
- 누구나 이해하기 쉽고, 양적으로 확인이 가능해야 한다.
- 목적지표의 종류
- 사용자 전환율 : A/B 테스트에 노출된 사용자 중 선택한 이벤트를 발생시킨 사용자의 비중을 계산.(예. 클릭률, 구매 전환율 등)
- 사용자당 평균 값 : A/B 테스트에 노출된 사용자 중 선택한 이벤트에서 발생시킨 값의 평균을 계산.(예. 사용자당 구매금액)
- 사용자당 평균 횟수 : A/B 테스트에 노출된 사용자가 선택한 이벤트를 평균 몇 번 발생시켰는지를 계산.(예. 사용자당 로그인 버튼 클릭횟수, 사용자당 랜딩페이지 조회수 등)
- cf) 평균이 아닌 다른 대표 값을 지정하는 것도 가능
- ex) 중앙값(이상치에 대한 민감도가 낮음) , 최빈값
ex) 24시간 세일, 상시할인 두 푸시 문구에 대한 목적 지표
목적 지표 : 푸시 클릭율
실험의 목적: 타기능으로의 전환 유도
가드레일 지표
- 이것만은 지켜야 한다는 지표
- 다양한 실험들은 그만큼 다양한 목적을 갖고 있기 때문에 그걸 우선시 하다보면 제품의 주요 지표의 하락을 가져올 수 도 있다. 하나를 얻으려다가 두개를 잃으면 안되다보니, 프로덕트의 주요 지표라든지 우리가 지켜야하는 지표의 경우 어느 정도의 하락까지는 감안하되 이 보다 낮아지면 안된다와 같은 것을 정해두어야 실험을 해야한다.
각 실험군에 사용자 배치: 실험군 분배 방식
비교를 하려면 기준이 되는 것이 있어야 한다.
실험군과 대조군
- 대조군(control) : 아무런 조치를 취하지 않은 유저군/실험의 목적에 따라 없는 경우도 존재
- 실험군(treatment, variant): 1개 이상으로, 가설의 검증을 위해 특별한 조치를 가하는 유저군.
- ex) 푸시 실험 : 어떤 푸시가 더 좋을지 알기 위한 실험으로 푸시를 내보내지 않는 대조군이 존재하지 않는 경우
- 실험군 A: "24시간 할인"이라는 워딩의 푸시를 받는 집단
- 실험군 B: "상시 할인" 이라는 워딩의 푸시를 받는 집단
Hashing
2020년도 중반까지는, 서버에서 직접 제어하는 방법으로 실험을 진행할 때, user_id 를 바로 % M 해서 나머지 N 에 따라 실험군/대조군을 결정
BUT, 이 방식은 실험이 많지 않을 경우엔 편리하고 유용하지만, 실험이 많아진다면 실험 결과 해석에서 문제가 발생함.
의도치않게 두 실험이 같은 M 을 쓰고 N 범위가 겹치는 경우가 발생했을 때, 각 실험에서는 자기 실험의 treatment 에 의한 effect 라고 해석하지만, 실제로는 두 실험의 effect 가 더해져 보강되거나 상쇄된 것일 수 있는 가능성이 존재하므로 → "HASHING" 을 이용
Sample size 예상
목적: 실험기간 동안 통계적 유의성이 보장될 만한 충분한 모수가 모일지 미리 확인하고, 실험군 비율이나 기간을 정하고자.
방법: power analysis를 이용하여 판단.
필요한 요소 :
- 예상되는 지표 차이의 크기
- 실험군, 대조군의 비율
- 유의수준 (주로 0.05)
- 검정력 (주로 0.8)
실험 결과 분석(지표를 어디서 어떻게 보나요?)
- 대시보드
- 실험의 주요 지표 추이를 daily 로 확인하고 쉽게 공유하기 위해
- 주요 지표들과 가드레일 지표를 대시보드에 올려서 쉽게 확인할 수 있도록 한다
- 한번 확인할 지표가 아니라 지속적으로 트래킹 할 지표들
- 최종 지표 값의 차 확인 ( 통계적 유의성 확인)
- 단순히 차이가 있다해서 의미가 있다고 보기 어려움, 그 차이가 유의미한지 통계적 유의성을 구해보고 p-value< 0.05 일때 신뢰도가 95%이상일 때 유의미한 차이라고 인지
실험 결론
- 실험군 A가 대조군에 비해 몇 퍼센트포인트 (%p) 증가 또는 감소로 실험군 A or 대조군으로 결정
- 차이에 대해선 %p, % 로 이야기가 되는데 %p 는 퍼센트 값의 절대적인 차이를 말하고, % 차이는 기준 값의 상대적인 차이를 말한다
- ex) 10%와 15%를 비교할때 %p 로는 5%p 차이라고 말하는 반면, % 로는 50%의 차이가 난다고 말함.
중요 포인트 💥
- 상관관계는 인과관계와 다르며, 실험은 인과관계를 파악하기 위한 최상위 분석 방법론 이다. 즉, 실험을 통한다면~때문에 ~이런 결과가 생겼다라고 말할 수 있는 가능성이 높아진다. 이를 바탕으로 고객에게 어떤것이 부정적 반응을 유도하는지 어떤것이 긍정적 반응을 유도하는 지를 배워나갈 수 있다.
- 실험을 시작할 땐 가설과 목적지표를 정하는 것이 매우 중요하고 이것이 실험의 방향을 잃지 않는데 도움을 준다.
- 실험하고 싶은 원인이 될 하나의 변수에 차이를 두어 대조군과 실험군을 구분하고, 그들의 지표 차이의 유의성을 확인하여 유의미한 차이를 바탕으로 가설을 검증한다.
Reference
- https://medium.com/bondata/causal-inference-인과-추론-소개-30cc9af08cbd
- Kohavi , Ron , Thomas Crook , and Roger Longbotham . 2009 . “ Online Experimentation at Microsoft. ” Third Workshop on Data Mining Case Studies and Practice Prize . http://bit.ly/expMicrosoft
- https://docs-kr.hackle.io/docs/set-metrics#step-3-목표-유형-선택하기
- https://www.slideshare.net/cojette/ab-150118831
- https://lumiamitie.github.io/data/why-ab-test/?utm_source=slack&utm_medium=geultto
'TALK' 카테고리의 다른 글
데이터 분석가 신입으로 입사했는데 사수가 없다고..? 오히려 좋아! (1) | 2022.06.12 |
---|---|
글또 7기를 시작하며 (0) | 2022.05.15 |
글또 6기 회고글 (0) | 2022.01.02 |
지표에 변화가 생겼을 때 원인을 어떻게 파악할까? (0) | 2021.12.19 |
글또 6기를 시작하며, 욕심은 내려놓고 일단 GO (0) | 2021.08.01 |