A/B 테스트 도구를 붙이면 화면 두 개를 나눠 보여 주고 숫자를 보여 줍니다. 어려운 부분은 도구가 아닙니다. 언제 멈출지를 언제 정하는가입니다.
테스트를 켜 놓고 매일 대시보드를 들여다보면, 초반에는 두 안의 수치가 크게 흔들립니다. 그러다 어느 날 우리가 만든 B안이 앞섭니다. 그때 멈추면 우연이 우리 편이던 순간을 결과로 기록하는 것입니다. 다음 주에 그 차이가 사라져도 우리는 이미 배포한 뒤입니다.
시작 전에 정하는 두 가지
표본 크기는 “몇 명이 봐야 판단할 수 있는가” 입니다. 전환율이 낮을수록, 그리고 발견하고 싶은 차이가 작을수록 더 많은 방문자가 필요합니다. 계산기는 여러 곳에 공개돼 있으니, 현재 전환율과 “이만큼 차이면 바꿀 가치가 있다” 는 기준을 넣고 나오는 숫자를 씁니다.
기간은 표본만으로 정하지 않습니다. 최소 한 주 단위의 온전한 주기를 채우세요. 평일과 주말의 방문자 성격이 다르고, 광고 집행이나 뉴스레터 발송이 특정 요일에 몰리기 때문입니다. 수요일에 시작해 금요일에 끝낸 테스트는 “B안이 좋다” 가 아니라 “목요일 트래픽이 다르다” 를 잰 것일 수 있습니다.
시작 전에 적어 두는 것
주 지표는 하나입니다. 클릭률 · 폼 제출 · 최종 전환을 다 놓고 보다가 “그중 하나는 올랐다” 고 말하는 것은, 여러 번 던져서 나온 눈을 고르는 것과 같습니다. 나머지는 참고 지표로 기록하되 판정에 쓰지 않습니다.
또 하나 — 가설은 한 문장이어야 합니다. “히어로 문구를 결과 중심으로 바꾸면 폼 제출이 늘어난다” 처럼요. 문구와 이미지와 버튼을 한꺼번에 바꾼 B안이 이겼다면, 우리가 배운 것은 “이 조합이 낫다” 뿐이고 왜인지는 모릅니다.
트래픽이 부족하면 어떻게 하나
정직하게 말하면, 많은 사이트는 A/B 테스트로 결론에 도달할 만큼의 트래픽이 없습니다. 이때 필요한 것은 기간을 무한정 늘리는 것도, 표본이 모자란 채 결론을 내는 것도 아닙니다. 다른 방법을 쓰는 것입니다.
사용자가 실제로 어디서 멈추는지 관찰하고, 폼 오류 로그를 읽고, 문의로 들어온 질문을 모으고, 유입부터 완료까지의 경로를 직접 걸어 봅니다. 이런 정성적 방법은 “몇 퍼센트” 를 주지 않지만 고칠 곳을 알려 줍니다 — 그리고 명백히 고장 난 곳을 고치는 데는 실험이 필요 없습니다.
마지막으로 도구 자체의 비용을 확인하세요. 클라이언트 측 테스트 도구는 화면이 그려지기 전에 개입하는 경우가 있어, 켜는 순간 첫 화면이 늦어질 수 있습니다. 도입 전후로 같은 URL 3회 측정 중앙값을 비교해 두면 나중에 원인을 찾느라 헤매지 않습니다. 실험을 절차로 굳히는 방식은 개발 워크플로우 아카이브와 작업 과정에서 볼 수 있습니다.
다음 회차
마지막 회차는 전환 감사입니다. 개별 요소를 실험하기 전에, 유입부터 완료까지의 경로 전체에서 사람들이 어디서 빠져나가는지 찾는 방법을 다룹니다.