실험 조직으로 거듭나기_체계적으로 실험하기
완성된 가설 뼈대에 살 붙이기
목차.
1. 한 놈만 팬다!.
2. 뱀의 꼬리가 길면 밟힌다.
3. 이미 만든 실험 환경, 조금만 손 보자!
4. 관련 아티클
하나라도 해당되면, 재밌게 읽을 수 있어요!
1. 그로스, 실험 문화를 팀에 도입하고 싶다.
2. 어떻게 가설을 설정해야 할지 모르겠다.
3. 실험을 진행한 경험이 없다.
이전 글에서 '어떤 가설'을 '어떤 방식'으로 증명하는지를 이야기했다. 하지만, 아직 완벽하지 않다. 여기까지는 가설 뼈대를 만든 수준이고, 여기에 살을 붙이는 작업이 필요하다. 참/거짓을 판단할 기준으로 어떤 지표에 집중할지, 실험을 얼마나 진행해야 할지 등을 결정해야지 비로소 가설 설정 단계가 끝나고, 실험을 진행할 수 있다.
뼈와 살, 모두 있어야 한다! (출처 : 아웃백)가설 검증 프로세스는 대략 아래와 같다. 이전 글에서 (1) ~ (2) 단계를 다뤘다면, 이번 글에선 (3) ~ (5) 단계를 다루고자 한다.
(1) 검증할 가설을 선택한다.
(2) 가설 검증 방식을 결정한다.
(3) 검증 지표와 목표 수치를 결정한다.
(4) 실험 기간을 결정한다.
(5) 기존 실험 환경을 튜닝해 최적의 실험 환경을 만든다.
(6) 실험을 진행하고, 검증 데이터를 모은다.
(7) 데이터를 분석해 가설을 검증한다.
(8) 학습한다.
이전 아티클에서 이어집니다.
(3) 한 놈만 팬다!
핵심 지표에 집중해야 한다.
앞 단계에서 집중할 가설을 결정했으니, 이제 이 가설의 참/거짓을 판단할 기준을 결정해야 한다. 이때, 개인적 경험이나 주관적 견해가 아니라, 데이터 기반의 정량 지표에 집중해야 한다. 데이터를 기준으로 삼아야지 객관적 판단을 내릴 수 있다.
실험이 시작되면, AB 테스트 또는, 프로덕트 배포를 통해 고객 로그 데이터를 일정 기간 동안 수집한다. 이렇게 수집한 로그 데이터는 PV(page view, 페이지 뷰), CTR(Cilck Through Rate, 클릭률), DT(Duration Time, 체류 시간) 등의 다양한 지표로 변환된다. 가설을 검증할 때, 앞선 모든 지표를 모두 신경 쓰고 분석하는 건 비효율적이다. 특히, 증명하고자 한 가설과 전혀 관련 없는 지표는 굳이 분석할 필요가 없다. 따라서, 가설과 가장 연관 있는 핵심 지표를 찾는 게 중요하다. 이 핵심 지표를 중심으로 두고 분석을 진행해야지, 가설 검증을 효율적으로 할 수 있다. 실험이 끝나는 날에 핵심 지표가 목표 수치에 도달했다면, "이 가설은 참이다!"라고 판단한다.
한 놈만, 아니 핵심 지표만 팬다. (출처 : 라디오스타)사례를 살짝 볼까요?
(1) 검증할 가설 : 고객은 신사업 부서로서 기술에 관심이 많을 것이다
(2) 가설 검증 방식 : AB 테스트
(3) 검증 지표와 목표 수치 : 소개 영상(A안) 보다 기술 데모 영상(B안)을 보여주면, CTR은 6 % 상승할 것이다.
메이아이의 홈페이지에서 진행한 AB 테스트를 예시로 들어보자. KR인 '홈페이지를 통한 고객 컨택 수'가 목표 수치보다 저조했고, 이 문제 현상을 해결해야 했다. 당시에 홈페이지에선 메이아이의 EO 소개 영상을 푸시 알림으로 보여주고 있었다. 미팅 로그를 확인한 결과, 처음 연락 온 고객의 상당 수가 신사업 부서 소속임을 확인했다. 따라서, '고객은 신사업 부서로서 기술에 관심이 많을 것이다'로 가설 방향을 설정했다.
푸시 알림으로 AB 테스트를 진행하기로 했고, 버튼의 CTR을 핵심 지표로 설정했다. 최종적으로, '소개 영상(A안) 보다 기술 데모 영상(B안)을 보여주면, CTR은 6 % 상승할 것이다.'를 검증할 가설로 설정했다. AB 테스트 결과, 기술 데모 영상(B안)의 CTR이 목표 수치인 6 % 보다 훨씬 높은 7.9 %에 도달했고, 결과적으로 가설이 참임을 확인했다.
소개 영상(A안) vs 기술 데모 영상(B안)핵심 지표는 후행 지표가 아닌, 선행 지표로!
PV(page view, 페이지 뷰), CTR(Cilck Through Rate, 클릭률), DT(Duration Time, 체류 시간) 등 다양한 지표가 존재하며, 효율적인 가설 검증을 위해선 핵심 지표에 집중해야 한다. 그렇다면, 수많은 지표 중에서 어떤 것을 핵심으로 삼아야 할까? 바로, 선행 지표에 집중해야 한다.
지표는 크게 선행 지표와 후행 지표로 분류된다. 선행 지표는 어떤 상황 및 현상이 일어나기 이전에 발생하는 지표고, 후행 지표는 상황 및 현상이 일어난 뒤에 나타나 결과를 파악할 수 있는 지표다. 예를 들어, 프로덕트의 판매 영역에서 '리텐션', '유저 수'는 선행 지표로 볼 수 있다. 리텐션이 높고, 유저 수가 높을수록 제품의 판매 활성화로 이어진다. 반대로, '매출'은 후행 지표로 볼 수 있는데, 제품이 팔려야지 매출이 상승하기 때문이다.
검증 지표로 후행 지표가 아닌, 선행 지표에 집중해야 한다. 후행 지표는 여러 요소에 의해 영향을 받으므로, 현상 및 상황을 보다 명확히 파악하는 데 어려움이 있다. 가령, 매출이 떨어진 것만 보고 원인을 파악하기 어렵다. '리텐션 감소', '유저 수 감소' 혹은 둘 다 동시에 일어났을 수도 있다. 이처럼, 실험에 의한 영향은 선행 지표에서 더 직접적으로 반영된다. 따라서, 선행 지표를 활용해야지 더 명확한 가설 검증이 가능하다.
목표 수치, 기존 데이터를 참고하자
처음 가설 검증을 해보는 사람은 목표 수치를 어느 정도로 설정해야 할지 감이 잘 잡히지 않는다. 목표로 잡은 수치가 적당한지 아닌지 확신이 서지도 않는다. 사실, 어떤 수치가 옳고 그른지는 현재 상태에서 판단할 수 없고 없고, 실험이 끝난 후에 실제 데이터를 봐야지 알 수 있다. 목표 수치 설정의 핵심은 분석 방향을 설정하는 데 있다. 따라서, 구체적인 수치에 연연할 필요 없이, 최소한의 유의미함만 갖고 있으면 된다.
기존 데이터를 참고하면, 유의미한 목표 수치를 쉽게 설정할 수 있다. 고객 반응을 더 유도하기 위해 버튼의 문구를 바꾼다고 해보자. 기존 버튼의 CTR(Click Thoruh Rate, 클릭률)이 6 %라고 한다면, 검증 데이터로 몇 %를 설정하는 게 좋을까? '기존 버튼 문구에 문제가 있다'는 가설에서 시작했으므로, 일단 6 % 이상 높게 설정해야 한다. 6 % 보다 높은 9 ~ 10 % 정도를 목표 수치로 설정해야지 어느 정도의 유의미함을 가졌다고 볼 수 있다.
기존 데이터를 ‘해석’해서 목표 수치를 설정해야 한다.(4) 뱀의 꼬리가 길면 밟힌다.
실험 기간에 절대적 진리는 없다.
샘플의 수와 실험 기간은 비례한다. 실험 기간이 길수록, 그만큼 더 많은 샘플 수를 얻게 된다. 샘플 수는 많을수록 좋다. 하지만, 뱀의 꼬리가 길면 밟힌다라는 말이 있듯이, 한 가지 실험만 너무 오래 진행하는 건 비효율적이다. 차라리, 또 다른 실험을 새로 하는 게 효율적이다. 따라서, 통계적 유의성을 가질 정도의 샘플 수를 확보 가능하도록 실험 기간을 설정해야 한다.
너무 긴 실험 기간 비효율적이다. ( 출처 : 내셔널 지오그래픽 )실험 기간은 프로덕트에 따라서 유동적이어야 한다. 샘플 수는 결국 '고객'에 영향을 받는데, 프로덕트에 따라서 고객 특성이 천차만별이다. B2B 프로덕트는 B2C 프로덕트에 비해 고객 수가 매우 적어서 단기간에 모수 확보가 어렵다. 같은 B2C 프로덕트라고 해도, 산업군에 따라서 재방문이나 체류시간 등도 현저히 달라진다.
검증 방법 중 하나인 AB 테스트는 통계를 기반으로 하기 덕분에 샘플 수의 타당성을 쉽게 검증할 수 있다. p-value를 통해 통계의 유의미성을 판단할 수 있고, 이를 바로 분석해주는 툴도 존재한다. 반면, XYZ 가설 검증은 그 자체만으로 샘플 수 타당성을 검증하기 어렵다. 가령, 전체의 10 %라고 해도 샘플 수가 10명일 때와 100명일 때의 타당성은 매우 다르다. 1명의 반응만 바뀌어도, 전자는 10%가 바뀌는 반면에 후자는 1% 밖에 바뀌지 않는다. 이런 경우, 추가 해석과 판단이 필요하다.
AB 테스트의 샘플 수에 따른 유의미성을 보여주는 툴 ( 출처 : neilpatel )검증하고 배우고 학습하고!
'린하게 일하기'의 핵심은 학습(learn)에 있다. 가설 검증도 학습의 일환이기에, 가설을 빠르게 검증해서 배운 후, 다시 새로운 가설에 뛰어드는 게 좋다. 따라서, 실험 기간도 1~2주 정도만 잡는 게 좋다. 1~2주 후에 봤을 때, 샘플 수가 충분하지 않다고 판단하면 다시 실험을 연장한다. 반면, 충분하다고 생각하면 학습하고 다음 가설 검증을 준비하는 게 더 효율적이다.
(5) 이미 만든 실험 환경, 조금만 손 보자!
실험 시작 전, 마지막 검토!
핵심 지표, 목표 수치와 실험 기간을 모두 결정했다고 바로 실험을 진행하지 않는다. 그 전에 반드시 검토할 부분이 있다. 바로, 현재 실험 환경이 핵심 지표를 충분히 수집할 수 있는지 확인해야 한다. 실험을 진행했는데 뒤늦게 데이터 누락이나 로스 등을 발견하는 불상사가 일어나면 안 된다.
효율적인 가설 검증 싸이클을 위해서, 처음부터 데이터를 수집할 수 있는 실험 환경을 만드는 게 좋다. 기반 환경이 있다면, 매 실험을 진행할 때마다 환경을 새로 만드는 대신에 기존 환경에서 약간의 튜닝만 하면 되므로 효율적이다. 가령, 새롭게 버튼을 추가했다면, 이 버튼의 트래킹만 GTM에 설정하면 된다.
실험 환경을 쉽게 관리하는 방법
프로덕트에서 유저가 어떤 행동을 했을 때, 이를 어떤 데이터가 보여주는지 모두 외울 수 없는 노릇이다. 이때, Miro 등을 활용해 기록하면 실험 환경의 관리에 도움이 된다. 나 같은 경우, 프로덕트의 각 이미지를 캡처하고 어떤 이벤트가 일어나는 때, 어떤 데이터가 생성되는지 미로에 적어놓는다. 다른 팀원도 이를 참고해, 실험 환경을 쉽게 이해할 수 있다.
이 단계까지 왔으면, 바로 실험을 진행하면 된다. 다음 글에는 실험을 어떻게 진행해야 하는지와 실험이 끝나고 어떻게 분석을 하는지에 대해 이야기해보자.
미로를 활용해 실험 환경을 정리하고, 변경다음 아티클로 이어집니다.
관련 아티클
https://tjrichard.github.io//blog/article_summary-4/
https://blog.ab180.co/posts/how-to-find-north-star-metric
https://groobee.net/2019/08/05/northstar-metric-kpi/
https://blog.gangnamunni.com/post/AB-test-Baisc/
https://neilpatel.com/ab-testing-calculator/
