뚱땅뚱땅 A/B 테스트 진행기

A/B 테스트는 도대체 어떻게 해야 하는 걸까?

양승화 저자의 '그로스 해킹'이라는 책을 읽었는데, 뒷부분에 A/B 테스트 진행 시 주의해야 하는 사항에 대해 말하고 있었다. 그 부분을 읽으며 정말 많이 찔리고 공감이 갔는데, 그 이유는 바로... 내가 그 모든 주의사항을 어겨본 적이 있기 때문이다. 결국 여차저차 테스트 A/B 테스트에 대한 이해도가 올라가긴 했지만 그 과정은 정말 쉽지 않았다. 아래 적는 글들은 A/B 테스트의 정답이라기보다는 내가 경험한 것들을 모아 모아 끄적이는 글이니 꼭 참고용으로만 보시는 것을 추천한다.

1. A/B 테스트란?

A/B 테스트란 변수 A와 B를 비교하여 어떤 변수가 더 효과적인지를 판단함으로써 단일 변수에 대한 두 가지 이상의 버전을 비교하는 테스트이다. A/B 테스트가 어떤 건지는 다른 글들이 훨씬 유익할 테니 줄이고, 개인적으로 테스트를 하면서 느꼈던 점들을 적어보려 한다. 내가 주로 진행했던 테스트 페이지는 장바구니와 상품을 리스팅 하는 페이지였는데, 주문 퍼널을 맡고 있었기 때문에 주요 변화들에 대한 테스트는 필수적이었던 때도 많았다.

A/B 테스트를 위해 사용하는 툴도 다양한데, 일반적으로 Google Optimize (GO)를 많이 쓰곤 한다. 처음에는 회사에서도 GO를 쓰다가 정확하지 않는 결과들이 나와 Hackle을 썼다. Hackle 사용기에 대해서는 추후 기회가 된다면 자세하게 적을 예정이다. 처음에는 Hackle을 사용하는 법 조차 숙지가 어려웠기도 하고, 정합성이 잘 맞지 않아 여러 번 맞춰가는 과정이 있었서 어려움을 겪었다. 툴 정합성을 위해 진행했던 테스트 방법은 A/A 테스트였는데, 일반적으로 단일 변수가 다른 A안과 B안을 비교하지만 A/A 테스트는 원본과 동일한 안을 비교하는 테스트다. 분배가 고르게 되었는지, 목표수치가 통계적인 유의미성을 띠지 않는지 등을 확인하는 테스트라고 할 수 있다. 처음에는 이 A/A 테스트를 전혀 사용하지 않았지만, 중간에 사용해야 하는 이슈가 생겼고 결론적으로는 해당 테스트 덕분에 툴 정합성을 잘 맞출 수 있었다.

테스트를 진행하다 보니 도대체 얼마동안 테스트를 진행해야 하는 거지?라는 생각이 들 때도 있었다. 통상적으로 A/B 테스트는 2주 동안 진행하는 경우가 많다고 한다. 그렇지만 한국인의 빨리빨리는 2주를 견디기 힘들어하는데..! 그래도 적어도 1주일의 시간은 필요하다. 특히 커머스에서는 1주일의 기간은 필수적인데, 요일에 따라 고객들의 구매 패턴이 다르기 때문에 일주일을 겪어봐야 고객들의 구매패턴에 맞는 결과가 나온다고 할 수 있다. 그럼에도 개인적으로는 2주를 선호한다. UX 변화는 물론 단순 UI 변화에 있어서도 기존 고객들의 적응 시간이 필요하기 때문에 1주일의 시간은 짧다는 것을 테스트를 통해 배웠기 때문이다. 또, 조금은 슬프지만, 우리가 쿠팡과 같이 트래픽이 거대하지 않기 때문에 충분한 모수가 모이기까지 1주일은 조금 부족한 시간이기 때문이다.

2. A/B 테스트 단계

테스트를 진행할 때 회사마다, 개인에 따라 단계가 다를 수 있다. 내가 진행하는 A/B 테스트의 단계는 아래와 같다.

1. 기획 시 A/B 테스트 여부 판단 필요

모든 기획에 A/B 테스트가 필요하지는 않다. 개인적으로 테스트가 필요하다 느낄 때는 1) 전환율이 떨어지고 페인 포인트는 보이지만 이를 해결하는 방안에 대한 확신이 없을 때, 2) 전환율에 대한 정확한 측정이 필요할 때(이것 때문에 떨어지는 게 맞나? 싶을 때), 3) 주문 및 결제에 큰 영향을 미칠 수 있을 것 같을 때이다. 물론 그 외에도 많은 이유가 있지만 커머스 플랫폼에서 일하는 주문 쪽 PM이기 때문에 위 3가지를 가장 많이 고려하는 편이다.

2. A/B 테스트 확정 후 관련 팀원들과 논의

테스트를 하기로 확정이 되면, DA (Data Analyst)와 지표에 대한 논의가 필요하다. 그 외에도 유관 부서가 있다면 유관부서가 원하는 데이터 지표들을 추리는 작업도 필요하다. 개인적으로는 DA가 없었던 시절에 A/B 테스트를 많이 진행했어서 스스로 지표를 생성하거나 대표님께 부탁하거나 개발자들과 상의하며 뚱땅뚱땅 맞춰가곤 했다.

3. Hackle 개발 환경에서 테스트 생성

Hackle에 대해서는 추후 더 자세하게 말할 시간이 있겠지만, 간단한 게 설명하자면 Hackle은 개발 환경과 운영 환경이 나눠져 있다. 개발할 때 테스트가 잘 분배되는지 QA를 하기 용이하게 개발 환경 버전이 있는데 개발에 들어가기 전 개발 환경에서 테스트를 생성해 놔야 해당 테스트 key를 가지고 개발자들이 연동할 수 있다. 물론 개발 환경에서는 목표를 세팅할 수 없는 등 제한이 있기도 하고 운영 환경과 헷갈리지 않도록 유의해야 한다는 점도 있다.

4. 개발 완료 후 테스트 QA 진행

테스트를 할 때, 개발자분들은 기획에서 정해진 페이지에서 테스트가 진행될 수 있도록 '분기'처리를 해주신다. 즉, 고객들이 다른 페이지에서는 다 똑같은 화면을 보고 원하는 페이지에서만 다른 화면을 볼 수 있도록 하는 것인데 이를 Hackle과 연동하는 것이다. 이러한 처리들이 잘 되어있는지, 그리고 각 화면에 고객들이 잘 분배되는지에 대한 확인은 필수이다.

5. 배포 후 운영 환경에서 테스트 세팅

QA까지 완료가 되면 배포를 진행하고 이후 Hackle 운영 환경에서 테스트를 세팅한다. 이때, 목표 수치를 세팅하는 등 작업이 필요하다. 나는 테스트 시작을 한 후에는 구글의 시크릿 모드를 켜서 여러 번 확인하며 테스트가 잘 분배되고 있는지 확인하곤 한다.

6. 테스트 결과 분석

테스트가 진행되는 와중에도 계속 데이터 추이를 보며 분석해야 한다. 물론 하루 이틀 만에 유의미한 결과가 나오는 건 아니지만 그럼에도 치명적으로 부정적인 결과가 나오거나 하는 등의 모니터링이 매일 필요한다. 특히, 장바구니나 주문하기 쪽을 담당하게 되면 더 예민해지는 것 같다. (일희일비하는 나와 같은 성격은 특히나.. 결과 분석 시 초연한 마음가짐을 가지는 것이..ㅎㅎ)  Hackle에서 제공하는 분석은 p-value를 기준으로 보여준다. 통계적으로 유의미성을 검증하는 방법 중 가장 많이 쓰이는 건데 제대로 설명할 수 없으니 찾아보시는 것으로..! 어쨌든 p-value 값이 0.5 이하가 될 경우 significant (줄여서 sig.) 표시가 뜨는데, 이는 결과가 부정적이든 긍정적이든 통계적으로 유의미하다, 즉 신뢰도가 높다는 뜻이다. 개인적인 경험에 비춰봤을 때 하루 이틀 정도 sig. 가 뜬다고 해서 이게 진짜 유의미한 결과는 아닐 가능성이 있다. 매일 유입되는 인원에 따라 모수가 매일 달라지기 때문이다. 그래서 sig. 가 뜨고 난 후 3일 이상 꾸준히 유지가 될 때, 테스트 결과를 해석하곤 한다.

테스트를 진행하는 과정에서 단연 제일 어려운 단계는 바로 1번과 6번이다. 이게 과연 테스트를 할만한 가치가 있을까? 에 대한 고민을 매분 하게 되고 테스트를 위해 팀원들을 설득하는 과정에도 흔들릴 때가 많다. 또 결과를 해석할 때는 아무래도 자의적인 해석이 많이 들어가기 때문에 내가 분석한 결과가 맞을까..? 에 대한 고민도 많아진다. 특히 sig. 가 잘 뜨지 않는 테스트의 경우 어떤 안을 배포해야 하는지 많은 고민에 빠지고는 한다. 유의미성이 아예 뜨지 않는 테스트의 경우에는 기획 시 가설에 맞는 안을 배포하기도 하고 재테스트를 진행하기도 한다. 어쨌든 이러저러한 고민들이 많다 보니 테스트를 통해 배포되었다고 하더라도 지속적으로 지표를 트래킹 하는 것은 필수적이다. 물론 나는 다른 일을 하다가 보면 놓치는 때도 많지만.. 어쨌든 그렇게 하려고 노력해야 한다.

3. A/B 테스트 주의사항

양승화 저자의 '그로스 해킹'에 A/B 테스트에 대한 논의가 그렇게 많이 있지는 않았지만 당시에 테스트와 관련해서 고민을 많이 하고 있었기 때문에 특히 공감이 많이 갔다. 책에 따르면 아래 7가지의 주의사항이 있는데, 그중 4가지를 내가 경험한 대로 해석해 보았다.

1. 무가설

A/B 테스트를 처음 시도할 때 무가설의 굴레에 빠지곤 한다. 가설을 세웠다고 생각하지만 테스트를 진행하고 결과를 보며 처음 세웠던 가설보다는 결과에 따른 가설이 세로 세워질 수 있다. 이때, 처음부터 제대로 된 가설을 세우지 않았기 때문에 중간중간에 흔들리는 결과가 일어날 수 있다. 개인적으로 진행했던 테스트 중에 배송지가 없는 고객들에게 배송지를 강제로 입력하게 한 후 주문하기 페이지로 넘어가도록 한 테스트가 있었다. 처음, 해당 테스트의 가설은 "장바구니에서 필수적으로 배송지 입력을 필요로 해도 전환율에 크게 영향을 미치지 않을 것이다"였다. 하다 보니까 해당 부분이 구매전환율 중 첫 구매 전환 시 도움을 준다는 것을 확인할 수 있었다. 그러다 보니 결과를 해석할 때 이건 첫 구매에 좋은 거야!라고 귀결이 되었다. 지금 생각해 보면 당연히 구매전환율 중 첫 구매에 더 영향을 주는 테스트라는 걸 알아야 했지만, 그때는 전체 구매전환율에 매몰되어 있어서 세부사항을 전혀 고려하지 않은 가설을 세웠었다. 물론, 생각한 것보다 결과가 좋았기 때문에 테스트는 성공적이었지만 초기에 충분히 여러 가지 상황을 염두에 두고 가설을 설정하지 못했기 때문에 개인적으로는 많이 배운 테스트라고 할 수 있다.

2. 통제 변수 관리 실패

통제 변수 관리 실패야말로 테스트를 진행하는 PM으로서 실수하기 정말 쉬운 케이스다. 특히 나는 기획을 할 때 오버로 기획하면서 실제 디자인, 개발 전 많이 쳐내는 편으로 테스트 진행 시에도 하나의 변수만 적용하는 훈련을 했어야만 했다. 바꾸는 건 좋은 거다라는 기조로 많이 바꾸다 보면 어떤 게 진짜로 영향이 있었는지 모를 때가 많다. 장바구니에서 무료배송 기준을 보여주기 위한 테스트를 진행할 때였다. 그때 본격적으로 테스트를 시작할 때이기도 하고 특히나 장바구니를 전체적으로 개편하는 것을 처음 도전했던 때라 힘이 많이 들어갔다. 그래서 대안을 무려 6개나 만들어 테스트를 진행했다. 대표적인 변화로는 1) 무료배송 기준을 보여주는 여부, 2) 무료배송 기준을 채우지 않았을 때 상품을 더 담을 수 있도록 하는 여부였다. 결론적으로 말하면, 실험은 우여곡절이 많았지만 결국 성공적이었다. 우여곡절이 많았던 이유는 대안이 너무 많았고 변수가 2개나 되었기 때문이다. 이후로도 한번 더 비슷한 실수를 하고 나서야 변수 관리를 제대로 해야 한다는 인식이 박히게 되었다.

3. 엿보기+조기 중지

1번과 똑같은 실험을 진행했을 때였다. 이 때는 추석이 끼여있었기 때문에 유입이 많이 없을 것으로 예상했었다. 그래서 원래는 일주일 이상 진행해야 했던 테스트였지만 무려... 5일 정도만 테스트를 진행하고 중단했던 경험이 있었다. 물론 sig. 가 뜨고 3일 정도 유지가 되었기 때문에 중단했지만 그럼에도 실험 기간은 좀 더 늘려서 테스트를 유지했더라면 어땠을까 하는 아쉬움이 있다. 이 이유 때문에 배송지 필수 입력 이후 실제 첫 구매가 뛰었지만 정말로 이게 얼마나 영향을 주었는지 측정이 어려워졌기 때문에 더더 아쉬움이 남는 것 같다. 다른 분들은 절대 이런 실수를 하지 마시길..^^ 나를 포함해서..^^

4. 시간의 흐름에 따른 차이를 살펴보지 않는 것

이 부분은 실패한 경험이라기보다는 배운 점이다. 진행했던 테스트 중에 카테고리 페이지를 완전히 개선했던 일감이 있었다. 카테고리를 먼저 보여주고, 이후에 브랜드 페이지와 기획전 페이지를 보여준 기존 안에서 브랜드 페이지를 상단에 올리는 등의 배치를 달리 한 테스트였다. 목적은 자체 PB 브랜드 페이지 진입률을 높이기 위해서였다. 처음에는 단순히 브랜드 페이지만을 상단에 올렸는데 장바구니 담기율과 주문 전환율이 유의미하게 부정적으로 떨어지기 시작했다. 1주일 정도 모니터링했을 때 너무 시그널이 좋지 않아 해당 테스트를 종료해야 하나 싶었다. 하지만, 개선안이 의도적으로도 심미적으로도 훨씬 낫다는 믿음으로 일주일만 더 지켜보자는 논의가 있었다. 거짓말처럼 8일째 되는 날, 장바구니 담기율과 주문 전환율은 복귀되었고 브랜드 페이지 진입률은 이전보다 20% 이상 높아져 해당 안을 배포한 경험이 있다. 시간을 충분히 둘 것. 메모메모!

마무리하며 적는 짧은 소감

작년 7월쯤부터 지금까지 재테스트들을 포함하여 12번이 넘는 A/B 테스트를 진행했다. 그중 성공적인 테스트들도 있었고, 실패한 테스트들도 있었고 애매한 테스트들도 있었다. 그러면서 내가 느낀 건, 테스트에 절대성은 없다는 것이다. A/B 테스트를 진행하고 성공한다고 해서 이게 100% 정답일 수는 절대 없고, 시간에 따라 성공이었던 테스트들도 결국 안 좋은 영향을 줄 수 있다는 것을 배웠다. 또 단순한 UI 변화도 고객들이 받아들일 시간이 충분히 있어야 한다는 것을 배웠다. 그 외에도 배운 건 너무 많지만 글쓰기 능력 한계로.. 여기까지만 적고.. 추가적으로 소감이 궁금한 사람은 개인적으로 물어보기 >_<

(브런치 글을 적으며 내 글쓰기 실력.. 얼마나 형편없는지 느껴져서 너무 슬퍼...)

아무튼 다음에는 뚱땅뚱땅 Hackle 사용기나.. 제로 투 원 기획이 어려운 이유.. 운영 기획이 어려운 이유.. 등등 중에서 한 가지를 들고 와보겠다❤