몇 달 전 ‘그로스해킹 – 이보다 더 과학적일 수 없다’ 라는 포스팅을 통해 계량적으로 접근하는 그로스 해킹이 ‘논문’ 형식으로 발표 된다는 사실을 소개한 적이 있는데, 며칠 전 내가 예전에 다녔던 링크드인과 그 회사를 인수한 마이크로소프트에서 일하는 데이터 과학자들이 ‘웹사이트 A/B 실험에 대한 7가지 법칙’이라는 논문을 2014년 KDD 학회에서 발표한 자료를 접하게 되었다. 비록 몇 년 지난 자료지만 지금도 충분히 적용될 수 있는 것 같아 내 경험을 덧붙여 짧게 정리해서 공유.
(참고: 여기서 ‘법칙’은 rule of thumb, 즉 ‘어림잡은, 혹은 대략 적용되는’ 법칙이라고 해석하면 됨)
1. 작은 변화가 주요 지표에 큰 변화를 줄 수 있다
나의 그로스 해킹 시리즈에서 반복적으로 언급했지만 그로스 해킹의 핵심은 속도감 있게 많은 양의 실험을 수행하여 (홈런이 아닌) 단타로 점수를 내는 것이다. 많은 실험을 빨리 실행하기 위해서는 코딩을 적게 해야하고, 코딩을 적게 하려면 제품과 사용자 경험을 가급적이면 최소한으로 바꾸어야 한다. 이렇게 자주 ‘값 싼’ 실험을을 계속적으로 하다보면 ‘어쩌다가 걸려서’ 홈런이 나오는 땡큐한 상황이 간간히 나올 때가 있다. 논문은 MSN 웹사이트의 링크를 ‘새 탭에 보이기’, 그리고 Bing 검색 엔진의 검색 결과 색깔 실험이 그런 좋은 예라고 언급한다. 나 역시 링크드인에 있을 때 Upgrade 버튼을 파란색에서 노란색으로 바꾸어서 좋은 결과를 내었었고, 업그레이드 페이지 (chooser page라고 부름)에 배열을 다르게 함으로 수십 억 단위의 연간 추가 수익을 냈던 경험이 있다. (아래 자료 참고)
.
2. 대부분의 경우 실험의 결과가 지표에 큰 변화를 주지 않는다.
#1 법칙으로 흥분 했다면 제발 워~ 워~. 지난 번 포스팅에서도 중요하게 언급된 부분인데 대부분의 실험은 지표에 미미하거나 아예 영향을 주지 않는 경우가 대부분이다. 너무 큰 변화를 목격한다면 홈런을 외치기 보다는 어디 코드에 버그가 있는지 의심부터 해 봐야 하는 것이다. 잊지 말자… 단타싸움!
3. 케바케 (Your Mileage Will Vary)
어느 다른 회사의 어떠한 온라인 실험이 대박을 쳤다고 나도 그것을 따라하면 대박을 낼 수 있을 것이라는 기대를 하고 많은 투자를 하면 낭패를 보기 십상이다. 고객 구성, 제품의 특성, 주변 상황 등 모든 것 들이 다른 상황에서 동일한 실험 결과를 기대하는 것은 당연히 무리일 수 밖에 없다. 내가 파란색 버튼에서 노란색 버튼으로 재미 봤다고 해서 내가 아는 스타트업들에게 ‘모두 버튼을 노란색으로 바꾸세요~’ 라고 할 수 없는 이유가 바로 여기에 있다.대신 이렇게 남들이 성공했을 때 사용했던 접근했던 방식을 best practice로 일반화할 수 있다면 (예: 몇 가지 색깔의 변화로 실험을 해 보세요) 자신의 상황에 더 유연하게 적용할 수 있을 것이다.
참고로 이 반대 상황도 마찬가지이다. 사람들을 만나다 보면 꼭 ‘내가 해봐서 아는데, 이것은 절대 될 수가 없어’ 라고 주장하는 사람들이 있다. 그렇게 ‘답정너’인 태도보다 어떤 상황에서 이런 식으로 실험을 했는데 잘 안되었던 이유는 이런것 저런것 같다 라고 분석적인 태도를 취하고 그 교훈을 바탕으로 더 개선된 아이디어로 다시 도전할 수 있는 자세를 가지는게 더 바람직하다.
4. 웹사이트의 속도는 정말 정말 정말 중요하다
어떤 새로운 사용자 경험을 실험할 때 그것이 실제 웹사이트 속도에 얼마나 미치는지 점검하는 것이 좋다. 큰 회사들을 latency를 측정할 수 있는 도구들이 다 있겠지만 이런 화려한 도구가 없더라도 웹 브라우저의 디버그 툴 (크롬의 경우 오른쪽 클릭 > Inspect > Network) 을 사용, 페이지 각 콤포넌트들의 로딩 시간 등을 잴 수 있다. 인터넷 기반 서비스는 모든 것이 다 같은 경우 (all else equal) 웹사이트의 속도가 느려지면 핵심 지표의 성과도 낮아지기 마련이기에 반드시 신경쓰고 모니터링 하는 버릇을 들이자.
5. 클릭 이탈을 막는 것은 어렵다. 클릭을 다른 곳으로 유도하는 것은 (그나마) 쉽다
Bing 검색엔진의 주요 지표중 하나는 클릭 이탈이다 (검색 결과를 클릭하지 않고 사용자가 이탈해 버리면 검색 결과가 형편 없다는 뜻). 마이크로소프트 개발자들이 이 지표 움직이려고 별 노력 다 해봤는데 의미있게 움직이는데 실패했다고 한다. 그나마 다행인 것은 사용자가 어디 클릭하는지는 충분히 영향을 줄 수 있다고. 이 법칙에서 나온 사용자 행동을 일반화 시켜 받아드리면 장바구니 담아두고 결제를 포기하는 사람들을 잡는 것 보다 장바구니에 아이템을 담을 때 조금 더 비싸거나 사용자에게 적합한 상품을 선택하도록 유도하는 것에 투자를 하는 등, 전자상거래 분야에 적절하게 적용할 수 있을 것 같다.
6. 복잡한 실험 설계를 피해라
‘실험 하는 김에 이런 것도 한번 알아보면 좋지 않을까?’의 똑똑해 보이려는 생각과 행동이 의도치 않은 문제점을 유발할 수 있다. A/B 테스트가 아닌 A/B/C/D 등의 다변수 실험을 할 경우 더 많은 트래픽이 필요로 할 뿐만 아니라 코드도 더 복잡해지고 (버그 위험!) orthogonality를 제대로 확인하지 않으면 왜곡된 실험 결과를 초래, 심지어는 웹사이트의 ‘폭망’으로 이어질 수 있는 위험이 있기 때문이다. 이것의 좋은(?) 예로 Knight Capital이라는 금융회사가 버그가 있는 코드를 실험 환경을 거치지 않고 바로 배포를 하여 $460M (4척6백만 달러!)라는 손실을 낸 일화가 논문에 소개된다. 간단하고 깔끔한 코드로 아주 적은 트래픽을 대상으로 실험을 수행 후 결과에 따라 트래픽을 점진적으로 늘린 다음 실험으로 넘어가는 것을 습관화 하길 추천한다.
7. 충분한 사용자를 확보한 후 실험에 임하라
통계의 매력은 작지만 의미있는 표본을 통해 전체 집단의 결과를 추정하는 것이다. 그로스 해킹 및 계량적인 마케팅 기법은 이런 의미있는 표본이 있을 때 제대로 힘을 발휘할 수 있다. 만약 사용자 수가 많지 않다면 실험을 더 오래 돌리거나, 제품에 더 큰 변화를 주는 이상적이지 못한 선택을 해야 할 것이다 (= 늦은 의사결정 또는/혹은 더 많은 위험 수반). 아니면 차라리 마케팅과 제품 개발의 본질로 돌아가서 ‘고객이 무엇을 원하는지’를 발품 팔아 그들에게 직접 피드백을 듣고 그것을 바탕으로 의사결정을 하는것이 낫다 (= do things that don’t scale). 다음 도표는 논문에서 제시한 적절한 표본 집단의 크기. 역시 유동성이 큰 매출 지표는 꽤 많은 사용자들을 표본집단으로 필요함을 알 수 있다.
