A/B 테스트의 단점
고려할 요소 및 대안
고객에게 동일한 웹사이트의 여러 버전을 제공하여 상호작용을 유도하는 A/B 테스트는 웹사이트 운영자 사이에서 점점 더 보편화되고 있습니다. 이러한 테스트를 통해 기업은 유용한 피드백과 데이터를 얻을 수 있지만, 이것이 가장 효과적인 접근 방식인지에 대해서는 의문이 남습니다.
A/B 테스트의 결과는 흑백 논리처럼 단순하게 보일 수 있지만, 실제로는 여전히 많은 불확실성이 남아있습니다. 테스트 설계 자체가 테스트 담당자의 주관적인 편견에 따라 달라질 수 있으며, 고객들은 기대했던 최상의 서비스를 경험하지 못할 수도 있습니다. 게다가 테스트를 얼마나 자주 반복해야 하는지, 그리고 이것이 고객의 호감도에 어떤 영향을 미칠지에 대한 추가적인 의문도 남게 됩니다.
A/B 테스트는 사이트 A와 B 중 어느 쪽에서 완료율이 높은지 쉽게 파악할 수 있다는 장점이 있습니다. 또한 기존 사이트에 대한 혁신적인 아이디어가 효과적인지 검증할 수 있고, 대규모 사이트나 여러 사이트를 운영하는 경우 작은 부분부터 시작해 사이트 주요 페이지까지 확장하는 패치 테스트[1]를 수행할 기회를 얻을 수 있습니다. 구체적인 디자인 질문에 대한 해답을 얻을 수 있다는 점도 장점인데, 다양한 색상, 버튼 배치, 레이아웃, 이미지 등을 테스트하여 점진적인 개선을 꾀하는 것이 가장 일반적 예시입니다.
[1] 패치 테스트는 소규모 사용자 그룹에게 프로토타입이나 제품의 특정 기능을 실제 환경에서 제한된 시간 동안 사용하게 하여 사용성을 평가하는 방법입니다. 이를 통해 연구자는 실험실 환경보다 더 자연스러운 환경에서 사용자들이 제품을 어떻게 사용하는지 관찰하고, 잠재적인 사용성 문제나 개선이 필요한 부분을 식별할 수 있습니다.
A/B 테스트를 지양해야 하는 경우
그럼 이제부터 제가 생각하는 A/B 테스트를 하지 말아야 할 때는 언제일지 알아보겠습니다.
1. 사용자가 충분하지 않을 경우
특정 기능이나 웹페이지의 일일 활성 사용자 수가 1,000명 미만이라면 A/B 테스트를 실행하는 것은 큰 의미가 없을 수 있습니다.
효과적인 A/B 테스트를 위해서는 다양한 변형(다변량 테스트)을 실행해야 할 가능성이 높습니다. 이는 타깃 고객의 감소로 이어질 수 있으며, 최소 몇 달 동안 테스트를 진행해야 한다는 의미입니다. 매일 결과 확인에 시간을 낭비하기보다는 문제 해결에 집중하는 것이 효율적입니다.
일일 활성 사용자가 1,000명 이상이라면 사용자 불만이 없는지 확인하고, 변경을 통해 얻을 수 있는 가치가 있는지 신중하게 고려해야 합니다. 만약 문제가 있었다면 이미 인지하고 있었을 가능성이 큽니다.
2. 사소한 변경을 하고 있는 경우
Google이나 X처럼 많은 고객과 자원을 보유하고 있지 않다면, 작은 변경 사항들을 모두 테스트하는 것은 시간 낭비일 수 있습니다. 대개 적절한 수준의 테스트로도 충분합니다.
대신 변경 사항을 적용한 후 이전 결과와 비교해 보세요. 결과가 좋으면 그대로 진행하고, 나쁘면 언제든지 되돌릴 수 있습니다. 하지만 결과가 크게 달라지지 않아 시간 낭비가 될 수도 있습니다.
3. 이유를 파악하기 어렵습니다.
A/B 테스트의 가장 큰 단점은 결과적으로 어떤 선택이 더 나은 결과를 가져왔는지 그 이유를 명확하게 제시하지 못한다는 것입니다. 단순히 고객이 짙은 녹색 계열의 구독 버튼을 클릭했다는 사실만으로는, 그들이 왜 구독을 원했는지에 대한 근본적인 이유를 설명할 수 없습니다. 따라서 기능과 메시지를 개선하기 위해서는 원인을 파악하는 것이 중요합니다.
4. 고객과의 소통 부재.
많은 이해 관계자들은 고객과 직접 소통할 필요가 없다는 이유로 A/B 테스트를 선호하는 경향이 있습니다. 하지만 A/B 테스트를 제안하는 팀이 고객과의 소통 없이 진행하려 한다면, 해결하고자 하는 문제에 대해 최소 5명 이상의 고객과 충분히 논의한 후에 다시 제안하도록 안내해야 합니다.
5. 실패한 부분을 개선할 수 없습니다.
만약 당신의 사이트가 처음부터 사용성에 문제가 있었고, A/B 테스트의 여러 변형이 그 문제점을 반복하는 형태라면, 다른 사이트가 가진 근본적인 결함이 여전히 남아있을 가능성이 큽니다. A/B 테스트는 이러한 유형의 결함을 드러내거나 사용자의 불만을 밝혀내지 못하며, 사이트 문제의 원인을 파악할 수 없게 만듭니다. A가 B보다 더 많은 판매를 일으켰다고 해서, 그것은 단지 B와의 상대적인 비교일 뿐입니다. 원래의 사용성 문제를 해결하는 것이 훨씬 빠르고 더 나은 결과를 가져올 수 있습니다.
6. 지속적인 테스트가 필요할 수 있습니다.
테스트가 종료되면 데이터는 재사용할 수 없습니다. A/B 테스트를 추가로 진행하려면 새로운 기준선에서 시작해야 하며, 다른 유형의 테스트는 성공적인 웹사이트에 적용하는 것이 좋습니다. 마찬가지로, 거부된 버전에서도 유용한 정보를 얻을 수 있을 것입니다.
A/B 테스트의 대안
그렇다면 A/B 테스트를 대체할 수 있는 다른 방법이나 도구에는 무엇이 있을까요?
1. 사용자 행동 추적 (User behavior tracking)
사용자 행동 추적은 제품과 UX 개선에 필요한 통찰력을 제공합니다. 사용자가 제품과 어떻게 상호작용하는지 쉽게 파악하고, 다른 사용자도 같은 방식으로 행동하도록 유도할 수 있습니다. 또한, 사용자의 제품 상호작용 데이터를 수집하여 특정 사용자 집단에 효과가 있는지 확인할 수 있습니다.
유용한 도구로는 Google Analytics, Hotjar, Mixpanel, FullStory, Heap, Microsoft Clarity, Smartlook, UXCam, Usermaven, Dynatrace 등이 있습니다.
2. 세션 녹화 (Session recordings)
세션 녹화 기능으로 모든 커서 움직임을 정확하게 확인할 수 있습니다. 또한, 사용자 세분화 기능을 함께 활용하면 제품 사용에 성공한 사용자와 실패한 사용자가 제품을 어떻게 사용하는지 비교 분석할 수 있습니다.
도구로는 Mouseflow, LogRocket, PostHog, UXWiz, Popcorn Replay, MIDA, UXCam, Hotjar, FullStory, Microsoft Clarity, Smartlook 등이 있습니다.
3. 사용성 테스트 (Usability testing)
사용성 테스트는 UX 연구에 사용되는 A/B 테스트의 대안적인 방법입니다. 게릴라 테스트, 화면 공유, 시선 추적, 5초 테스트, 첫 번째 클릭 테스트와 같은 여러 기법을 통해 제품의 사용 편의성에 대한 중요한 정보를 얻을 수 있습니다. 또한, 세션 녹화는 사용자가 특정 작업을 수행해야 하는 경우와 같이 집중적인 내용이 필요한 사용성 테스트에 효과적으로 활용될 수 있습니다.
도구로는 UserTesting, UserZoom, Lookback, Maze, Optional Workshop, Lyssna, Loop11, Userfeel, Trymata, Hotjar, GetFeedback, User Interviews, UX Metrics 등이 있습니다.
4. 사용자 피드백 설문조사 (User feedback surveys)
새로운 기능이나 UI에 대한 사용자 피드백을 수집하는 효과적인 방법입니다. 기능을 사용하는 즉시 설문조사를 통해 만족도를 측정할 수 있습니다. 사용자 답변을 기준으로 사용자를 분류하고, 제품 사용 데이터와 교차 분석하여 패턴을 발견할 수 있습니다. 더 나아가, 설문조사에 정성적 질문을 추가하여 심층적인 이해를 도울 수 있습니다.
유용한 도구로는 ProProfs Survey Maker, Qualaroo, SurveyMonkey, Typeform, Qualtrics, Google Forms, Instabug, Survicate, Jotform 등이 있습니다.
5. 사용자 인터뷰 (User interviews)
사용자 인터뷰는 제품 사용성과 사용자 경험에 대한 정성적 데이터를 수집하는 데 더욱 효과적인 방법입니다. 인터뷰를 진행하면서 사용자와 상황에 맞춰 질문을 조정할 수 있기 때문입니다. 따라서 인터뷰 전에 명확한 목적을 설정하고, 이를 달성하기 위한 준비가 필요합니다.
유용한 도구로는 Contentsquare Interviews, Ethnio, User Interviews, Loop11, Lookback, Userfeel, Lyssna 등이 있습니다.
6. 베타 테스트 (Beta testing)
베타 테스트를 통해 제품을 일반에 출시하기 전에 실제 사용자 피드백을 수집하여 제품의 사용성을 안정적으로 테스트할 수 있습니다. 대상 사용자에게 제품 접근 권한을 제공함으로써 출시 전에 수정해야 할 문제점을 파악할 수 있습니다. 즉, 제품이나 기능이 최종 출시되었을 때 사용자의 참여와 전환을 유도할 가능성을 높일 수 있습니다.
도구로는 TestFlight, Google Play Beta Testing, Appaloosa, DeployGate, Installrapp, Applause 등이 있습니다.
7. 기능 플래깅 (Feature flagging)
기능의 노출 여부를 결정하는 것을 포함하며, 변경 사항을 적용할 때 다른 사용자에게 미치는 영향과 제품 사용 방식에 대한 검증을 가능하게 합니다. 예를 들어, 화면에서 바로 가기 버튼을 제거하는 것은 사용자의 불편을 초래하고 제품의 가치 실현 시간을 늦출 수 있습니다. 반면, 불필요한 버튼이나 탭을 제거하면 사용자가 관련 없는 기능에 주의를 뺏기지 않아도 되므로 사용상의 불편함을 줄이고 제품 활성화 속도를 높일 수 있습니다.
사용하는 도구로는 LaunchDarkly, Flagsmith, Optimizely, ConfigCat, Statsig 등이 있습니다.
분명 A/B 테스트는 다른 테스트 방법과 함께 활용하면, 현재 디자인을 개선하고 사용자의 이목을 끌거나 페이지에서 특정 과정을 완료하도록 돕는 효과적인 도구가 될 수 있습니다. 그러나 사용 편의성, 불만족도와 같은 요소는 측정하기 어렵기 때문에, 완전한 해결책이라고 보기는 어렵습니다. 따라서 사용성 테스트를 통해 사용자의 불만 사항과 문제점을 파악한 후, A/B 테스트를 통해 다양한 해결 방안을 시험해 보는 것이 좋습니다.
A/B 테스트가 항상 이상적이거나 적절한 것은 아닙니다. 테스트를 구현하기 전에 고려해야 할 요소와 A/B 테스트에 대한 대안적인 방법에 대해 논의할 준비가 되어 있어야 합니다.
A/B 테스트에 대한 여러분의 경험은 어떠신가요? 기대했던 만큼 유용했는지 궁금합니다
