데이터 드리븐으로 일하는 회사에서 A/B 테스트는 가장 쉽고, 명확하고, 효과적인 방법론이 아닐까 싶습니다.
쉽고 자주 쓰이기에 무의식적으로 무작정 실험만 돌리는 상황이 생길 수 있을 것 같아 A/B 테스트 진행시 주의사항, 사전에 확인해야할 체크리스트를 만들어봤습니다. 물론 더 있을 수 있겠으나 이 사람은 이렇게 정리했구나 정도로 봐주시면 좋을 것 같습니다.
하단에는 이 글을 작성하면서 참고했거나 도움이 될만한 소스들을 공유했으니 추가로 보시면 도움이 될 것 같습니다.
A/B 테스트 체크리스트
현실적 유의성 기준을 설정했는가
현실적 유의성에 대해 얘기하기 전에 가상의 상황을 설정해보겠습니다.
-쿠팡에서는 리뷰를 자세하게 남기도록 여러 실험을 진행중이다.
-리뷰를 자세하게 남긴 것을 직접적으로 측정하기 어려우니 대리 지표(proxy metric)로 리뷰 글자 수를 선택하여 리뷰 글자 수 개선을 진행했다.
위 실험에서 실험집단과 대조집단 사이의 리뷰 글자 수 차이가 통계적 유의성을 만족시킬만큼 차이가 났다면 바로 그 실험은 성공했다고 결론 내릴 수 있을까요? (대충 아니라는 내용 + 과거 썰 풀겠다는 내용)
대학교에 다닐 때 팀플로 분석 업무를 주제별로 나누고 발표만 제가 한번에 하던 상황이었는데 특정 사이트의 Oauth에 따라 게시글 내용 글자 수가 통계적으로 유의하게 차이난다는 결론이 나왔던 적이 있습니다. 발표를 준비하던 저는 내용을 믿기 어려워 재확인을 했는데, 통계적 유의성은 확실히 있었으나 글자 수 차이가 0.x개 밖에 안 되었습니다. 글자는 최소단위가 1개인데 연속형으로 평균적 차이를 비교하니 0.x개 차이가 나왔고 이것이 하필 통계적으로 유의하게 나온 것이죠.
위 사례에서 현실적 유의성을 사전에 정의하고 글자 수가 10글자 이상 차이나면 현실적으로 유의한 것으로 했다면 문제점을 쉽게 발견할 수 있었을텐데 p-value에 집중하다보니 잘못된 결론을 내린 것이죠.
또한, 회사에서의 실험은 그 실험을 위해 리소스가 투입되는만큼 현실적 유의성이 정말 중요할 수 있습니다. 쇼핑 페이지 전환에 걸리는 레이턴시를 낮추었을 때 구매전환으로 얼마나 이어지는지를 테스트했을 때, 통계적으로 유의하게 구매전환으로 이어지더라도 그 레이턴시를 낮추기 위해 그리고 그것을 전체 유저 대상으로 적용시키기 위해 서버 자원이 많이 사용된다면 현실적으로 구매전환율이 일정 기준 이상 개선되지 않으면 어느정도의 딜레이가 있더라도 현행 유지를 선택할 수도 있는거죠.
Goal Metric / Driver Metric / Guardrail Metric은 무엇인가
Goal Metric
- 회사의 장기적인 목표 지표이며 Success / North Star / Primary Metric 등으로 불림
- AU, 매출, 영업이익 등
Driver Metric
- Goal Metric을 실험으로 바꿔나가기는 쉽지 않기 때문에 개별 실험에서 Goal Metric을 대신할 수 있을만한 대체 지표
- 위 현실적 유의성에서 가상 상황 속 리뷰 글자 수 지표도 Driver Metric이 될 수 있음
- 비교적 단기적인 비교를 위한 지표
Guardrail Metric
- 실험을 통해 개선하려는 것과 별개로 망가지면 안 되는 지표
- 예) 구독 취소율, 에러 수
각 지표는 팀마다 실험마다 달라질 수 있지만 사전에 지표를 설정하지 않고 실험 후 A안과 B안 사이에 어떤 차이가 있었는지 분석하는 것은 좋지 않음
새로움 효과에는 어떻게 대응할 것인가
우리 프로덕트에 새로운 기능이 추가되었습니다. 새로운 기능을 실험하기 위해 A는 기능 추가 B는 현행 유지를 하였을 때, 새로움 효과로 인해 실제 효과보다 과장된 결과를 얻을 수 있습니다.
- 새로움 효과의 두 가지 시나리오
- 새로운 기능이 신선해서 일단 사용 (참신효과, Novelty effect)
- 새로운 기능에 거부감을 느껴 일단 사용하지 않음 (초두효과, Primacy effect)
이 경우는 측정이 쉽지 않지만 아래와 같은 방법으로 대응할 수 있습니다.
- 대상을 새로운지도 모르는 신규유저 코호트로 한정하여 진행한다
- 장점: 기존 배경지식이 없는 유저들을 대상으로 하여 새로움 효과를 제거할 수 있다
- 단점: 신규유저 대상으로는 결과가 좋았는데 막상 전체로 확장하니 반응이 안 좋을 수 있다.
※ 서든어택에 방패 아이템을 추가했는데 유저들이 암묵적 룰로 방패는 비매너로 정의하고 쓰면 신고까지 한다고 한다. 기존 유저들은 이미 그들만의 바꾸고 싶지 않은 취향이 있을 수 있다.
- 실험을 충분히 긴 시간 지속하여 충분한 시간이 흐른 시점의 효과 차이를 측정한다
특정 날짜에 따라 유저의 행태가 달라 수 있는가 (Seasonality 이슈)
과거 공모전에서 얻은 온라인 쇼핑몰 데이터를 분석했을 때 사람들이 월요일에 쇼핑을 많이 하는 것을 확인했습니다. 당시에는 월요병으로 정의하였는데 이처럼 월요일이나 주말 등 특정 날짜에 유저의 행태가 달라질 수 있습니다. 또한, 서비스 중에는 결제가 월초(1일)에 다른 기간보다 쏠리는 경우도 있을 수 있습니다. 이처럼 특정 날짜에 따라 결과가 크게 바뀔 것으로 예상되는 경우 해당 기간을 모두 실험 기간에 포함해야 보다 정확한 결과를 얻을 수 있습니다.
따라서 일시적일 수 있는 효과는 바로 결론 내리지 않고 충분한 기간을 주어야하며, “하루 해봤는데 A가 좋네요. 실험 그만하고 A로 진행하죠” 같은 전형적인 데이터 피킹(data peeking) 행위는 피해야 합니다.
다중검정 실험인가
동시에 여러 실험을 할 때 기존에 사용하던 통계적 유의성 기준을 그대로 사용하면 잘못된 결론을 낼 확률이 높아질 수 있습니다. 즉, 특정 실험결과가 좋지 않은데 좋은 것처럼 통계 결론이 나올 수 있습니다. 유의수준이 0.05일 때 하나의 실험에서 95%는 맞지만, 여러 실험을 동시에 하게 되면 (1-0.05)3 로 85.74%가 맞게 되고 잘못된 결론을 낼 확률이 10% 이상이 됨을 의미하죠. 검정의 대상이 많아지면서 1종 오류의 확률을 높일 수 있게 되는 건데 이에 대한 해결책으로는 본페로니 교정과 FDR 교정이 있습니다.
- 본페로니 교정
- n개의 가설을 동시에 검정하는 다중검정을 시행할 때, 각 가설을 검정의 크기 alpha / n과 신뢰구간 100(1 - alpha/n)%로 검증하는 교정법
- 지나치게 보수적이라는 단점 존재
- FDR 교정
- FDR(False Discovery Rates)은 1종 오류의 수 / 기각한 가설의 수로 기각역을 보정하는 방법
어뷰징 유저 제외 기준을 마련했는가
지표를 운영할 때 가장 답답한 경우 중 하나가 어뷰징으로 인해 지표가 망가지는 상황일 것입니다. 배달앱에서 장바구니에 담고 배달로 이어지는 과정을 실험한다면 지표로 주문완료 건수 / 장바구니에 담은 건수 를 사용하겠죠. 그런데 회사의 배달비 정책을 역으로 계산하기 위해 누군가 장바구니에 담고 배달비 확인하고 장바구니에서 제거하는 과정을 반복적으로 한다면 해당 유저가 소속된 그룹의 지표가 크게 손상될 수 있습니다. 이런 어뷰징 유저가 속해있을 때는 A안이 더 좋게 나왔다가 어뷰징을 제거하니 B안이 더 좋게 나올 수 있는거죠. 샘플 수를 무한정 늘리는 방법도 있겠지만 어뷰징 유저 제외 기준을 세우고 분석시 이들을 제외하는 방법이 조금 더 현실적일 수 있습니다.
봐야할 주요지표가 많을 때 OEC는 어떻게 계산할 것인가
실험을 할 때 보고 싶은 주요지표가 많을 수 있습니다. 제가 좋아하는 킬링타임용 먼치킨 만화들은 주인공이 힘, 스피드, 인성, 동료 등 모든 지표에서 세계관 최고지만 현실은 지표마다 순위가 바뀌는 경우가 많습니다.
OEC(Overall Evaluation Criteria)는 이렇게 지표가 갈릴 때 통합된 수치를 통해 효과를 측정하는 개념입니다. 라면 맛을 테스트 한다고 해볼까요? 맛 / 맵기 / 영양성분 등으로 평가 할 수 있겠죠. 이렇게 만들어진
수치에 가중치를 곱해 더한 것을 OEC라고 할 수 있습니다. 아래의 경우 OEC는 3.7점이 나오겠네요.
| 기준 | 점수 | 가중치 |
| 맛 | 4 | 0.5 |
| 맵기 | 3 | 0.3 |
| 영양성분 | 4 | 0.2 |
전혀 어려운 내용은 아니지만 운영 과정에서 논쟁이 생길 수 있으니 사전에 부서간 협의가 되는 것이 좋겠습니다.
네트워크 효과가 있을 수 있는가
기본적으로 A/B 테스트는 개별 대상이 서로에게 영향을 주지 않을 것을 전제로 하지만 네트효과가 나타날 수 있는 SNS 서비스는 A/B 테스트 결과가 과장되게 나올 수 있습니다.
이런 경우 개인 단위가 아닌 네트워크 단위로 테스트를 하는 방법도 가능합니다.
마치며
이렇게 A/B테스트 전에 우리의 실험이 어떤 문제점이 있을 수 있는지 생각해 볼 수 있는 체크리스트를 만들어봤습니다. A/B테스트를 진행하시는 분들, 공부하시는 분들께 도움이 되었으면 좋겠습니다. 감사합니다.
참고자료
Udacity A/B 테스트
프로덕트 오너
Data Interview Pro
Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing
Harvard Business Review
숫자에 약한 사람들을 위한 통계학 수업