내가 CTA 실험을 실패한 이유
실험 실패 여정기
글을 시작하면서
2024년을 회고하면서 가장 아쉬웠던 에픽을 하나 꼽으라고 했을 때, 저는 항상 CTA 실험을 이야기 했었습니다.
가장 공도 많이 들이고 큰 임팩트를 기대했던 실험이었지만, 여러 이유로 실험은 실패했고 더 이상 진행하지 못했습니다.
그저 실패한 일이라고 기억하기 아쉬워서, 이번 글에서 어떻게 이 실험을 시작하게 됐는지부터 왜 실패했는지에 대한 고찰을 해보려고 합니다... ✔️
문제 정의: 왜 CTA 실험을 설계했는가?
우리 제품에 결제 전환율이 갑자기 하락했던 이슈가 있었어요. 그때 제가 해결해야 했던 과제는 '결제 전환율을 올리자' 였는데, 결제 전환율을 올리기 위한 가설이 엄청 많고 우선순위조차 지정할 수 없는 상황이었어서 어떤 일부터 해결해야 하는지 파악하기 힘들었습니다.
그렇다고 아무거나 선택해서 해결하기엔 문제조차 제대로 정의되어 있지 않았기 때문에 낭비되는 리소스가 클 것이라고 생각했어요.
따라서 제품 개발 전 가설과 문제를 검증하는 방법은 무엇이 있을까? 고민하다가 CTA 실험을 선택하게 되었어요.
1) 가장 간단하게 가설을 검증할 수 있을듯함. 실패해도 큰 리스크가 없음
2) 큰 디자인, 개발 리소스 없이 기획자인 나의 리소스만 있으면 됨.
3) 강력한 CTA는 (문제 발굴의 목적 외에) 실제 결제 전환율도 함께 올릴 수 있을 거라고 기대함
제가 기대했던 효과는 위의 프로세스처럼 CTA 메시지로 고객에 대한 니즈 및 인사이트를 발굴하고 검증된 가설을 기능으로 릴리즈하는 거였습니다.
따라서 이탈 구간을 총 4가지로 나눴고, 가장 사용자들이 많이 이탈하는 구간, 하나를 선정해서 여러 가설을 펼치고 메시지로 풀었어요.
실험 진행 전, 사전 검증
제품 알림톡으로 실험 설계 전, 채널톡으로 아주 간단하게 실험을 진행하고 아래의 결론을 냈습니다. 그리고 실험 개발에 들어가도 되겠다고 판단했어요.
1) 여러 메시지를 보내보면서 CTA 메시지를 보내는 것이 안 보내는 것보단 낫다.
2) 메시지별로 사용자의 반응이 상이하다.
첫 번째 실험
이 실험의 큰 가정은 사용자별로 우리 제품에게 원하는 니즈가 다를 것이다 입니다. 따라서 사용자를 크게 두 가지로 나눈 게 실험의 핵심입니다. 가설을 검증하기 위해서 사용자별 타이밍과 메시지의 톤을 모두 다르게 설계했습니다.
여기서 가장 큰 전환을 이끄는 메시지가 바로 해당 고객군의 인사이트와 직결되는 요소라고 생각하고 실험을 진행했습니다.
제가 이 실험에서 가장 얻고자 기대했던 것은 고객군 + 문구 + 시점의 적합한 조합을 찾는 것이었습니다.
결과는 실패였습니다. 처음에는 의도한대로 사용자군별로 전환을 많이 이끄는 메시지가 달라서 성공한 줄 알았는데, 1) 데이터가 쌓인 걸 보니 위의 그래프처럼 결과치가 시기별로 정말 상이했어요. 2) 또한 사전 검증했을 때는, 어떤 메시지든 안 보낸 것보단 보낸 것이 낫다는 결과를 얻었는데 variant 1을 제외하곤 모두 not sending보다 전환율이 낮았습니다.
이 이유로 도저히 신뢰할 수 없는 실험이라고 판단하고 일단 실험을 중단했어요.
두 번째 실험
곧바로 두 번째 실험을 설계했어요. 저희 메시지의 destination이 목표 행동 (결제, 등록)과 무관한 페이지여서 혹시나 사용자의 행동을 방해한 것이 아닐까 싶었거든요. 따라서 destination만 변경한 후 다시 실험을 진행했습니다.
결과는 더 해석하기 힘들었어요. destination만 달리했을 뿐인데, 실험 결과가 완전 바꼈거든요.
이전 실험에서는 variant 1이 가장 유의미했는데, 이번 실험에서는 variant 3이 가장 전환에 유의미했어요. 나머지 변수들은 마찬가지로 not sending보다 전환이 낮았고요.
실험 결과가 너무 달라져서 도저히 두 실험 다 신뢰할 수 없었습니다. 미궁에 빠진채로 해당 실험도 종료가 되었습니다.
실험은 왜 실패했을까요?
1. 실험 설계가 복잡할수록 커뮤니케이션도 복잡하다는 걸 간과함
첫 번째 실험부터 고객군을 2가지로 나눈 게 가장 큰 실수였다고 봅니다. 고객군별로 4가지의 variant가 있었기 때문에 결국 8가지 경우의 수가 발생했고 이게 개발자와의 커뮤니케이션에 방해됐다고 봐요.
변수가 많았기 때문에 같은 PM, 심지어 저까지도 맥락을 관리하기 힘들었습니다.
2. 문제 정의에 많은 시간을 안 쏟음
고민을 많이 안 했기 때문에 실험 설계가 복잡했던 것 같습니다. 알림톡 메시지 개발에 대한 리소스를 낮게 책정했어요. 따라서 가설 설정 및 메시지 작성에 큰 리소스를 쏟지 않았어요. 빠르게 시작하는 것이 가장 중요하며 실수하더라도 언제든지 실험을 쉽게 중단 및 변동시킬 수 있다고 봤어요.
첫 번째 실험이 실패했을 때, 많은 고민을 하지 않았습니다. 단순히 destination이라는 문제라고 사소히 여겼고 빠르게 다음 실험을 진행하려고 했습니다. 실패에 대한 고민조차 하지 않은 채 두 번째 실험을 설계했기 때문에 당연히 이 실험도 실패일 수밖에 없었겠네요 .......
3. (결론적으로) 제품의 현재 상황을 간과함
CTA 실험은 우리 제품에선 한 번도 진행하지 않았던 이슈였어요. 따라서 어떤 개발자들도 이 이슈를 메인으로 관리하고 있지 않았습니다. 그렇기 때문에 더 세심하고 친절한 문서 정리 + 커뮤니케이션이 됐어야 했습니다. 하지만 저는 빠른 실험에 너무 몰두해있어서 정리에 소홀했습니다.
만약 이 실험을 다시 한다면?
이 실험이 현재 우리 제품에서 유의미한 결과를 도출할 수 있는지, 이 에픽을 관리할 리소스가 있는지, 실제로 개발에 드는 리소스 등등을 우선 검토했어야 합니다.
초반엔 아주 간단하게 실험을 설계할 거에요. 그리고 관련 인원들과 해당 컨텍스트를 이해하고 공유하는 속도에 맞춰서 CTA 실험을 고도화해야 합니다.
개발에 대한 리소스가 낮더라도 제 리소스가 낮은 게 아니라는 걸 명확히 인지하고 더 많은 시간을 쏟아서 문제 정의를 했어야 합니다.
특히 실험이 실패했을 때 바로 다음 실험을 진행하기 보다는, 실패에 대한 명확한 원인 분석 후 재설계해야 합니다.
그래도 유의미한 결과는 있어서 다행이에요!
1. 팀 레벨에서, 앞으로 CTA를 더 잘 보내고 잘 관리하기 위해서 메시지 자동화 기능을 개발 중이에요.
2. 사용자 레벨에서, (신뢰도는 낮지만) 유의미한 인사이트를 많이 얻었어요
- CTA 메시지가 아예 안 먹히는 사용자군을 찾았습니다.
- 메시지별로 전환 속도가 다르다는 것을 파악했습니다.
- 우리 사용자가 싫어하는 메시지 톤에 대한 인사이트를 얻었습니다.
