Tech#1. What is A/B TEST? - 이커머스에서 쉽지만 꼭 필요한 분석

조회수 833

안녕하세요! 윙잇에서 서비스기획을 담당하는 김준호입니다.
윙잇에서는 어떤 A/B 테스트를 하고 있고, 그 중 꼭 필요한 분석은 무엇이 있을지 소개해보려 합니다.


일반적으로 IT 부서의 주요 업무 목표는 대다수의 사용자가 불편함을 느끼지 않고, 서비스를 효율적으로 활용할 수 있도록 하는 것입니다. 하지만, 다양한 사용자를 대상으로 하는 이커머스 환경에서 모든 고객의 니즈를 파악하는 것은 불가능에 가깝습니다. 그래서 정량 데이터를 토대로 통계 분석을 수행하고, 이를 통해 서비스 효율에 대한 검증을 합니다.

저는 간편식 식품 커머스 윙잇의 서비스를 개선하는 기획자로써 다양한 데이터 분석을 시도했습니다. 여러 데이터 분석 방법론이 존재하겠지만, 이커머스 환경에서는 대체로 예측력에 비해 설명력이 중요하며, 그 중 가장 확실하고 편리하게 가설을 검증할 수 있는 직관적인 분석은 A/B 테스트라 생각합니다.

#1에서는 제가 윙잇에서 배우고 활용하고 있는 A/B 테스트에 대해 공유하겠습니다.


정의

*이미지 출처: https://knowledgemarble.tistory.com/84


A/B 테스트는 A 집단(as-is)에 비해 B 집단(to-be)의 통계적 유의성을 검증하는 분석 방법론입니다.
두 집단 중 어떤 집단이 큰 성과를 보이는지, 어느 정도의 통계적으로 유의한 영향을 미치며, 집단 간 상관관계는 어떤지, 그리고 결과의 신뢰도 등을 정량적으로 검증하는 분석입니다.
이를 위해서 특정 변수에 대한 response를 테스트하고, 어떠한 변수가 통계적으로 더 효율적인지 정량적으로 판단함으로써 단일 독립변수에 대한 두 가지 버전을 비교합니다. 과학&의학 분야에서 대체로 무작위 비교 연구(RCT: Randomized-controlled trial)로 통용되는 방법론을 이커머스 환경에 적용한 분석이라 할 수 있습니다.



목적

더욱 효율적인 User Experience(=UX)를 위해 단순한 UI 수정부터 로직 개편까지 여러 방면의 개선을 통해 서비스는 고도화됩니다. 그 중 몇몇 간단한 사항에 대한 기안이 있지만, 그 결과는 확인하기 전에는 명백한 근거를 알 수 없습니다. 그리고 이러한 교착 상황은 꽤나 자주 발생하곤 합니다.

이러한 교착 상황을 해결할 수 있는 간단하고 쉬운 분석이 A/B 테스트입니다. 특정 지표에 대한 원인을 파악하기 위한 cost를 최소화하고, 가설을 설정하여 검증하며, 그 결과를 통해 개선하는 것이 효율적입니다. 또한, 가능한 한 최대한 많이 자주 반복하는 것이 중요합니다.

A/B 테스트 진행 목적은 개선하고자 하는 대안의 유의성 검증이 주된 목적이지만, 항상 대안이 원본에 비해 통계적으로 유의한 결과를 확인하는 것이 목표가 아닙니다. 개선사항으로 판단하고 기안한 부분이 원본에 비해 부정적인 영향을 미치는 것은 아닌지 검증하기 위해 [통계적 유의성 없음]의 결론를 도출하는 것이 목적이 되기도 합니다.



도구

처음 A/B 테스트를 위해서 사용했던 툴은 (부분적으로) 무료 분석 툴인 Google Optimize(이하 GO) 였습니다.
Google Tag Manager(이하 GTM)를 통해 페이지 조회, 이탈, CTA 클릭 등을 툴에 연동하여 다양한 전환율을 검증하였습니다. 하지만, GO는 표본을 수집하는 시간이 오래걸리고, 그 집계된 데이터의 신뢰도와 타당도를 직관적으로 검증하기에 수월하지 않았습니다. 통계 분석에 대한 이해도가 높은 사람이 명확하게 변수를 설정하고 가설을 설립하는 경우가 아니면, 그 결과 데이터에 대한 신뢰를 하기 어려웠습니다. 또한, 서버단 A/B 테스트를 위해서는 추가 개발 공수가 많이 드는 점도 한계점이었죠.

이에, 저희 윙잇에서는 올해 6월부터 Hackle이라는 유료 분석 툴을 도입하였습니다. 윙잇 product와 SDK를 연동하였고, 퍼널 전환 검증 방식은 GO와 비슷한 형태로 운영해오고 있습니다.

*이미지 출처: https://www.rocketpunch.com/companies/hackle
*이미지 출처: https://hackle.io/ko/service

SDK의 장점은 서버단 테스트도 추가 공수를 들이지 않고 가능하며, Hackle 자체에서 필터 기능이 있어 개발 공수를 최소화할 수 있다는 점입니다. 또한, 표본이 집계되는 과정을 실시간으로 볼 수 있어 잘못된 방향으로 설계된 것이 확인되면 테스트를 금방 롤백(Roll-back)하고 원인을 파악하여 수정하기도 수월하다는 점이 있습니다.
물론 유료이며, 앞서 장점으로 언급한 여러 기능이 모두 비용과 연결되어 있다는 단점이 있지만, 그만한 가치가 있다고 판단되어 현재까지도 지속적으로 활용하고 있는 좋은 툴입니다.



*이미지 출처: https://dashboard.hackle.io/experiments

 

단계 

  1. 가설 수립

    A/B 테스트는 가설을 세우고 이를 바탕으로 실험을 통해 결과를 얻습니다. 이를 통해 도출한 결과를 바탕으로 추가적인 가설을 세워 결과를 도출하는 연속적인 과정으로 진행됩니다. 이러한 A/B 테스트의 특성으로 인해 전체 주기의 도입이 되는 가설 수립 단계에서 올바른 길의 방향성이 정해집니다. A/B 테스트의 가설은 특정 요소를 어떻게 수정/개선하여 어떤 지표를 도출할 예정인지 결정하는 단계입니다. 더 나아가, 데이터 수집 및 추적 방법 또한 미리 고려해두어야 합니다.


    *이미지 출처: https://zephyrus1111.tistory.com/28


  2.  실험 진행

    실험 진행 단계는 세부적으로 3단계로 나눌 수 있습니다.

    1) 분기
    분기 단계에서는 앞서 설정한 가설에 따라 원본과 대안을 보여줄 트래픽을 분리합니다. 트래픽을 분기할 때는 독립변수 데이터가 섞이지 않도록, 즉, 각각의 데이터가 서로에게 영향을 미치지 않도록 설정해야 합니다. 섞이게 되면 서로에게 영향을 미쳐 독립적이지 않게 되어 bias가 발생하기 때문입니다. 직접 A/B 테스트 기능을 개발할 때는 여러 기술적인 부분을 숙지해야 하지만, GO, Hubspot, VWO, Unbounce, Hackle 등 다양한 tool을 활용하면 편리합니다. 윙잇에서는 현재 Hackle 툴을 활용하고 있습니다.

    2) 구현
    A/B 테스트에 동원되는 트래픽이 문제없이 분기가 되었다면, 원본과 대안 집단을 잘 분할하고 구현하면 됩니다. 특별한 규칙 없이, 버그가 없도록 꼼꼼히 구현하는 것이 가장 중요합니다.

    3) 지표 추적

    • 마지막으로 지표를 추적하기 위한 준비가 필요합니다. 직접 개발을 통해 환경을 구현한 경우, 어떠한 쿼리로 확인할 지, 어떤 tool을 활용할 것인지 등 모든 부분을 검토해야 합니다. 하지만, 앞서 언급한 다양한 A/B 테스트 tool을 사용할 때는 해당 툴에서 요구하는 추적 방식을 따르면 된다. Hackle을 활용한 퍼널 전환% 분석을 할 때는 GTM을 활용하고, 서비스에 SDK를 연동하여 추적합니다.

  3. 결과 분석
    A/B 테스트가 시작된 후부터는 데이터를 계속 볼 수 있습니다. 데이터를 트래킹할 때 중요한 점은 A/B 테스트 기간이 짧으면 안됩니다. 하지만, 반대로 너무 오래 걸리면 현업에서 활용하기 어렵습니다. 주어진 시간은 한계가 있기 때문이죠.
    그래서, A/A 테스트를 통해 테스트를 위한 적정 기간을 알아낼 필요가 있습니다. A/B 테스트의 결과 분석을 도울 다양한 계산기가 많이 존재하며, 대체로 신뢰구간 90%, 95%, 99%에서 유효성을 검토합니다. 이커머스 환경에서는 대체로 신뢰구간 90%에서 유효성이 검증되면 통계적 유의성이 있다고 판단하는 경우가 다수 있습니다.



    *이미지 출처: https://zephyrus1111.tistory.com/28


    결론을 도출할 때 대체로 빈도주의(=Frequentist) 분석 방법론을 통해 통계적 유의성을 검증하지만, value나 sample size가 부족할 때에는 베이즈주의(=Bayesian) 방법론을 활용하기도 합니다.

    • 적정 샘플 사이즈 계산기 : https://www.evanmiller.org/ab-testing/sample-size.html
    • Frequentist(빈도주의) 계산기: https://neilpatel.com/ab-testing-calculator
    • Bayesian(베이즈주의) 계산기: https://abtestguide.com/bayesian


*이미지 출처: https://neilpatel.com/ab-testing-calculator

A/B 테스트는 A 집단(as-is)에 비해 B 집단(to-be)의 통계적 유의성을 검증하는 분석 방법론입니다.
두 집단 중 어떤 집단이 큰 성과를 보이는지, 어느 정도의 통계적으로 유의한 영향을 미치며, 집단 간 상관관계는 어떤지, 그리고 결과의 신뢰도 등을 정량적으로 검증하는 분석입니다.
이를 위해서 특정 변수에 대한 response를 테스트하고, 어떠한 변수가 통계적으로 더 효율적인지 정량적으로 판단함으로써 단일 독립변수에 대한 두 가지 버전을 비교합니다. 과학&의학 분야에서 대체로 무작위 비교 연구(RCT: Randomized-controlled trial)로 통용되는 방법론을 이커머스 환경에 적용한 분석이라 할 수 있습니다.



마무리

A/B 테스트에서 통계적인 유의성이 검증되는 경우는 극히 드뭅니다.
집단 간 차이가 확실하면 의사결정을 할 때 용이하겠지만, 불행히(?) 그런 경우는 드뭅니다. 그렇기 때문에, 많은 사람들이 “A/B 테스트는 절대 실패하지는 않지만, 성공하기도 어렵다”고 합니다. 따라서, A/B 테스트를 최대한 많이, 자주 돌리는 것이 중요하다고 생각합니다. 첫번째 가설을 검증하기 위한 A/B 테스트를 진행하고, 그 결과를 통해 새로운 인사이트를 발견할 수 있을 것입니다. 그 인사이트를 토대로 또 다른 새로운 가설을 설립하여, 검증하는 연속적인 검증이 필요합니다.  


Correlation does not imply causation.

많은 분들이 A/B 테스트에 대해 오해를 하고 있는 부분이 상관관계와 인과관계에 대한 정리입니다. 상관관계는 인과관계의 정의가 다른 점은 인지하지만 결과를 분석하는 과정에서 그 차이를 망각한 상태로 결론을 도출하는 경우가 많은데 항상 이를 고려하여 bias가 발생하지 않도록 유의해야 합니다.


이어지는 아티클 읽기