[A/B 테스트] A/B테스트 설계부터 결과 분석까지

이전 포스팅에서는, A/B테스트에 대한 검증 과정만 다뤘었는데 이번 포스팅에서는 A/B테스트의 구체적인 목적부터 설계까지의 전 프로세스를 담아볼려고 한다.

 

1. A/B 테스트는 왜 하는 것일까? 실제 사례를 바탕으로 알아보자

래는 넷플릭스의 A/B 테스트 예시이다. 

기존의 A화면과 , 유저가 원하는 모습대로 개편한 B의 테스트 화면이다. 사용자는 B를 원한다고 말하지만 사실 상 매출을 올려주는 화면은 가입률을 증가 시킨 A였던 것이었다. 이처럼 A/B 테스트는 정량적인 데이터를 바탕으로 평가하기 때문에, 의사결정자의 직관 혹은 사용자의 말에 의존하는 것보다 시간 및 비용 낭비에 대한 위험성이 적다. 또한 효과를 눈으로 검증할 수 있기 때문에 이미 여러 기업에서 새로운 기능을 평가하고 디자인을 개선하여 인터페이스를 최적화하거나 마케팅 효과를 극대화 하기 위해 사용하고 있다.  

 

 

https://www.2e.co.kr/news/articleView.html?idxno=209836

 

우리는 A/B 테스트를 통해 아래의 질문들에 대한 답변을 얻을 수 있을 것이다.

(1) 우리의 고객은 무엇에 가장 크게 반응할까? 

(2) 우리 제품의 방향성을 어느쪽에 중점을 두어 수립해야 할까? 

(3) 인터페이스를 어떻게 개선해야할까? 

 

2. 그렇다면 A/B 테스트는 어떻게 설계하고 진행하는 것일까? 

(1)  가설 수립 및 실험 설계 

i. 가설의 핵심은 어떠한 요소를 어떤 방식으로 바꿔서 어떤 지표를 바꿀 것인지 특정해야한다. 

원본 A를 대안 B로 바꾸면 지표 X가 Y하게 변할 것이다. 

* 이 때 주의할 점은, A를 B로 바꾸는 것 외에는 모두 같은 조건이어야 한다. 

예를 들어 버튼의 모양을 바꾸는 것이 A/B테스트 대상인데,다른 부분까지 개선해 버린다면 지표 변화의 원인이 버튼 때문인지 특정할 수가 없기 때문.

 

 

 ii. 실험 모수와 기간은 어떻게 정하면 좋을까? 

<모수 통제 >

테스트 시기와 타겟, 사용자의 방문 국가 및 지역, 유입 사용자의 속성 등은 동일하게하여 외부 요인을 최소화 

 

< 샘플 사이즈 설정 >

크면 클수록 좋다. 하지만 여건 상 큰 샘플 사이즈를 얻기 힘다면, 적정 샘플 사이즈 계산기를 통해 어느 정도의 모수가  확보되어야 신뢰도를 얻을 수 있을지 확인해볼 수는 있다. (이외에도 구글에 검색하면 많은 계산기가 있으니 참고!) 표본 크기는 통계적 유의성을 위해 반드시 고려가 필요하다. 

Adobe Target Sample Size Calculator

 

 

 < 기간 설정 > 

이 또한 정해진 기간은 없다. 다만 너무 짧은 기간동안에는 결과를 수집하기 어렵고, 너무 긴 기간 동안에는 사용자들의 행동이 변할 가능성이 있으니 각자 앱의 특성을 고려해서 적절한 기간을 설정하는 것이 필요하다. 단! 처음에 정해둔 기간은 지키는 것이 필요하며 요일별 편차가 발생할 수 있기 때문에 최소 7일 이상을 권장한다. 

• linkedin, netflix: 1주
• Google: 2주
• Airbnb: 4주

(2)  실험 진행 

 i. 분기 

분기는 수립된 가설에 따라 각각 원본 A와 대안 B를 보여줄 트래픽을 분리하는 작업이다. AB 테스트 기능을 직접 개발하는 경우라면 DB의 PK값처럼 고유한 식별자가 그 기준이 될 것이다. (PK가 홀수면 원본 A, 짝수면 대안 B) 

보통은 구글 옵티마이즈, 허브스팟, VWO, 옵티마이즐리, 언바운스 등 많은 AB테스트 툴에서 기본으로 제공하는 기능이기 때문에 기술적인 부분은 패스하도록 하겠다.  

https://dewberry9.github.io/starting-google-optimize

처음 시작하는 구글 옵티마이즈 + AB 테스트 실무 팁 | 매거진 입맛

 

 ii. 구현 

 

버그가 없이 꼼꼼히 만들면 된다. 결과에서 예상과 너무 다른 값이 나온다면 특정 브라우저에서 작동하지 않는 등 문제가 있는지 확인하는 것이 필요 

 

 iii. 지표 추적 

직접 개발한 경우라면 DB에서 볼지 등 결정하면되는 것이고, 엠플리튜드나 믹스패널과 같은 외부 추적 툴을 사용할 것인지 결정하면 된다.

 

 

(3) 결과 분석

이제! 들어오는 데이터에 대한 수확을 해야한다. 

위에서 설정한 가설이 원본 A를 대안 B로 바꾸면 지표 X가 Y하게 변할 것이다. 

결과는 원본 A를 대안 B로 바꿨더니 지표 X 가 실제로 30% 상승하였다. 정도로 나올 수 있을 것이다.

물론 실제 경우에 이정도로 상승하는 경우는 많이 없고 1~2% 상승도 유의미 하게 받아들여주는 경우가 있다.

 

-> 그렇다면 group B의 CTR4%가 group A의 CTR3%보다 높으면 그걸로 끝인가? 

 

이 경우 유효한 차이에 대해서 통계적 검증을 실시하면 된다.  실험을 반복했을 때도 그 결과가 나올지를 확률적으로 검증해보며 결과를 파악하면 되는 것이다. 

 

< A/B 테스트 검증 파이썬 예제 >

[A/B 테스트] A/B테스트와 파이썬 예제

 

 

< A/B 테스트 검정 계산기>

A/B-Test Calculator - Power & Significance - ABTestGuide.com

 

이렇게 통계적 검증까지 완료한 후 ,설 부터 시작해서 실험 설계 과정, 결과 분석 및 도출 인사이트까지 보고서에 담으면  우리는 A/B 테스트 한 사이클을 완료한 것이다!  

 

3. 망하는 A/B 테스트의 지름길 

1. 무가설 

- 가설 설정은 A/B 테스트의 시작이자 끝이다.

 

2.통제 변수 관리 실패 

- 통제 변수를 잘 관리하지 못해 가설에서 정의한 독립 변수 외에 다른 변수가 종속 변수에 영향을 미쳤다면 테스트 결과가 오염될 수 있다.

 

3.결과값에 대한 단순 수치 비교 

- A그룹의 전환율이 3%, B그룹의 전환율이 3.5%였다고 해서 B그룹이 좋으니 B로 서비스를 개선하면 됩니다. 라는 말은 위험하다.

- 통계적 검정을 통해 우연에 의한 결과와 실제 효과를 구분해야한다. 

 

5.엿보기와 조기 중지 

- 정해진 테스트 기간을 다 채우지 않고 p-value에 따라 중단하는 등, 실험자의 인위적 조작은 결과를 오염 시킬 수 있다.

 

6.과거에 대한 맹신 

- 이번 A/B 테스트 결과가 1년 뒤에도 똑같을거라고 맹신하면 안된다. 데이터는 유저 / 시장 / 계절 등 다양한 요인에 따라 변동되기 때문

 

 

이렇게 A/B테스트의 전 과정과 주의할 점에 대해 살펴보았다. 다음번에는 A/B 테스트 관련 툴을 직접 사용해보는 포스팅을 작성하며 본격적으로 A/B테스트와 친해지도록 노력해야겠다. 

 

[ 참고자료 ] 

https://www.2e.co.kr/news/articleView.html?idxno=209836  

https://dewberry9.github.io/3step-ab-test 

https://publy.co/content/6909 

https://blog.hackle.io/post/conquering-abtest-3

https://www.beusable.net/blog/?p=2854 

https://whatispm.tistory.com/83

https://brunch.co.kr/@eliarhocapt/14

https://www.ascentkorea.com/ab-test/