초기 B2C 프로덕트가 정성 데이터 수집하는 법
사용자가 없는 초기 프로덕트는 정성 데이터를 어떻게 수집할 수 있을까?
사용자가 없는 초기 프로덕트는 정성 데이터를 어떻게 수집할 수 있을까?
MVP를 만들고 나면 ‘우리 이런 거 만들었는데 어때? 왜?’의 질문에 답을 찾아가야 한다. 사용자들이 좋아해준다면 베스트겠지만 처음부터 그런 경우는 드물다. 우리 서비스를 쓰지 않는다면 왜 쓰지 않는지, 어디를 어떻게 개선해야 하는지 알아내는 것이 중요하다.
이런 인사이트를 얻을 수 있는 지표로는 크게 정량 데이터와 정성 데이터가 있다. 다만 북카이브 같이 충분한 사용자가 없는 초기 프로덕트의 경우, 모수가 부족해 정량 데이터로 유의미한 인사이트를 얻기 힘들다. 따라서 정성 데이터를 수집하는 것이 무엇보다 중요하다.
그렇다면 아직 우리 서비스를 쓰는 사용자가 없는 상황에서 정성 데이터는 어떻게 모아야 할까? 북카이브는 여러 고민 끝에 다음과 같은 방법을 생각했다.
[방법1] 회원가입 정보 수집? : B2C와 B2B의 차이
의미 있는 정성 데이터를 모으기 위해서는 사용자를 직접 만나 이야기를 나누는 것이 가장 좋은데, 이전처럼 매번 지인에게 부탁할 수도 없고..그렇다고 타겟에 맞는 사람을 어디서 어떻게 찾을 것이냐가 문제였다.
그러다 내 이전 프로젝트(B2B SaaS)에서 회원가입 단계에서 연락처 정보를 받고, 직접 연락해 인터뷰를 진행했던 것이 떠올랐다. 당시 나름 응답률이 나쁘지 않았던 기억이 있어 우리도 해보면 어떨까 제안했고, 그렇게 진행해보기로 했다.
그러던 중 문득 이게 북카이브와 맞는 방법일까 의문이 들었다. 내가 만약 어떤 앱이 흥미로워 보여서 다운받고 한 번 써봤는데 갑자기 그 서비스 담당자에게 문자나 전화가 온다면? 이상하고 거부감이 들 것 같았다.
이것이 B2B와 B2C의 차이라는 걸 느꼈다.
B2B
1. 고객 LTV가 크고, 한 명 한 명과의 ‘관계’가 중요
B2B는 기업 고객 한 명 또는 한 팀의 계약으로 몇 천만 원의 매출이 나올 수 있는 구조이다. 또 B2C에 비해 더 좁은 범위를 타겟하기 때문에 고객의 수가 적다. 따라서 한 명 한 명과 라포를 형성헤 관계를 맺는 것이 중요하고, 전화나 메일 한 번으로 충분한 ROI를 얻을 수 있다.
2. 뚜렷한 사용자의 문제 인식과 니즈
B2B의 유저들은 B2C처럼 일상 속 작은 불편함보다는 업무 효율과 생산성 향상과 같은 명확한 목적이 있다. 따라서 연락처를 통한 인터뷰나 세일즈 연락에 상대적으로 열린 태도를 가질 가능성이 높다.
3. 개인정보 허들이 낮음
기본적으로 업무용 이메일을 사용한다. 또 나의 업무에 관련된 영역이기 때문에 연락처로 인터뷰를 요청하는 것에 대한 거부감이나 민감도가 비교적 낮고, 때로는 그것이 자연스럽다고 느껴지기도 한다.
B2C
1. 고객 단가가 낮고 수가 많음
B2B에 비해 광범위한 사용자를 타겟으로 하므로 그 수가 더 많다. 또 고객 단가가 상대적으로 낮기 때문에 사용자에게 일일이 컨택하는 건 비용 대비 효율이 낮다.
2. 개인 프라이버시에 민감
전화번호 제공 자체에 민감할 수 있다. 특히 북카이브의 경우 전화번호가 필요한 특정 기능이 없기 때문에 정보 제공 자체에 거부감이 커지고 서비스에 대한 신뢰도가 낮아질 위험이 있다. 사용자 입장에서는 앱 하나 설치했다고 메일이나 전화를 받는다면 스팸으로 의심해 반감을 느낄 수도 있다.
3. 사용자 여정이 짧고 충동적
B2C 제품은 호기심으로 한 번 설치해보고 그만두거나, 아주 짧은 판단으로 이용하는 경우가 많다. 때문에 개인 연락처로 정성 피드백을 수집한다고 하더라도 이탈이나 사용 이유를 명확히 알기 어렵고, 더 구체적으로 파고들기 어렵다. 또 그런 허수로 인한 리소스 낭비 문제로 이어질 수 있다.
이와 같은 이유로 B2C인 북카이브에서는 회원가입으로 연락처를 받아 데이터를 수집하는 건 무리라고 판단했고, 대신 다른 방법을 더 고민해보기로 했다.
[방법2] 건의함: 간단하게 사용자 의견 수집하기
우리가 생각해낸 다른 방법은 앱 화면에 ‘건의함’을 두는 것이다. 건의함은 앱 내에 사용자들이 자유롭게 의견을 남길 수 있도록 하는 장치로, B2C 앱 서비스에서 흔하게 볼 수 있다. 건의함으로 정성 데이터를 수집할 때는 다음과 같은 장단점이 있다.
장점
1. 접근성이 좋음
앱 화면 내에 배치되어 있어 사용자가 불편을 느끼는 즉시 쉽고 빠르게 의견을 남길 수 있다.
2. 실제 사용 맥락 반영
서비스에서 행동 직후의 생생한 피드백을 받을 수 있어 컨텍스트가 살아있는 의견을 모을 수 있다.
3. 부담이 적음
인터뷰나 UT처럼 시간을 들이지 않아도 되니 메이커 입장에서 더 효율적으로 사용자 목소리를 수집할 수 있다. 또 사용자 입장에서도 부담 없이 원할 때 바로 의견을 남길 수 있다.
단점
1. 수동적 피드백으로 인한 한계
건의함과 같은 방식은 휴먼 터치가 없어 직접 요청하는 것에 비해 효과가 떨어질 수 있고, 수동적으로 피드백을 받는 방식이기 때문에 불충분한 의견이 모일 수 있다.
2. VoC 품질의 문제 (부족한 구체성)
단편적이고 짧은 텍스트 기반의 피드백으로, 대부분 맥락이 부족하다. 충분한 정보 없이 ‘이게 불편해요’, ‘이런 기능이 있으면 좋겠어요’ 정도의 피상적인 수준으로 끝나는 경우가 많아 깊이 있게 파고드는 것이 어렵다.
그럼 건의함은 어떻게 설계해야 할까?
건의함의 주요 목표는 사용자들이 빠르고 쉽게 의견을 남길 수 있도록 하는 것이라고 생각한다. 최대한 이탈 없이 다양한 의견을 모으는 것이 중요하기 때문에 퍼널이 길어서는 안 된다. 나는 다음과 같이 건의함을 만들었다.
1. 사용자 언어를 활용한 카피라이트로 관심 유도
단순히 ‘여러분의 소중한 의견을 들려주세요’와 같이 일반적인 문구를 사용하고 싶지는 않았다. 서비스를 사용하면서 사용자들이 느끼는 실제 사고의 흐름을 반영해 관심을 유도하고자 했고, ‘이렇게 개선되면 좋겠어요’와 같이 사용자 생각과 언어를 반영한 카피를 활용했다.
2. 시선을 유도하되 앱 사용 방해 최소화
북카이브는 마이페이지가 없어 건의함을 홈 화면에 배치할 수밖에 없었다. 더 노출이 잘 된다는 장점은 있지만 그만큼 피로도를 높일 위험이 있다. 그래서 최대한 미사여구 없이 컴팩트하게 서비스 사용 및 시각적 방해를 최소화했다.
3. 객관식 + 주관식(선택)
우리는 객관식과 주관식 혼합형으로 설계했다. 객관식은 주요 플로우를 단계별로 나눠 옵션으로 제공했고, 주관식은 더 자세한 의견을 작성하는 칸으로 선택사항으로 두었다. 객관식은 줄글로 쓰기 귀찮은 경우에 간단하게나마 의견을 남길 수 있도록 어느 단계에서 불편함을 느꼈는지를 표시할 수 있다. 우리는 이 데이터를 통해 사용자들이 어느 부분에서 공통적으로 불편함을 느끼는지를 확인할 수 있다.
초기에는 더 구체적으로 작성한 옵션을 제공할까 생각했었다. 예를 들어 ‘스캔 인식의 정확도가 낮아요’라던가 ‘문장을 선택하는 부분이 불편해요’ 처럼 줄글 형태의 옵션 5-6개를 제공하는 방법을 고려했다. 하지만 문장 형태로 제공하면 일일이 읽는 것 자체로 번거로움이 커지고, 구체성이 있어 사용자 의견에 편향을 줄 수도 있다고 생각해 위와 같은 객관식 형태로 만들게 되었다.
실제로 받은 건의함 의견들. 우리는 베타 기간동안 약 50건의 의견을 수집했다건의함을 사용하면 이렇게 간단하고 효율적으로 사용자의 생생한 피드백을 수집할 수 있지만, 여전히 인터뷰만큼의 깊이 있는 정보를 얻기는 힘들다. 따라서 건의함은 보조적인 수단 정도로 적합하다고 판단했고, 깊이 있는 인터뷰를 할 수 있는 다른 방법을 찾아야 했다.
[방법3] 클로즈 베타 테스트: 정성 피드백 풀 확보하기
그 다음 생각해낸 방법은 클로즈 베타 테스트(CBT)이다.
클로즈 베타 테스트(CBT: Closed Beta Test)란, 신제품이나 신규 기능 공식 런칭 전 일부 사용자에게만 제한적으로 공개하고 피드백을 받는 테스트 단계를 말한다. CBT는 다양한 이점이 있지만, 그 중 초기 프로덕트 팀이 정성 피드백을 수집할 수 있는 좋은 경로가 되기도 한다.
CBT를 통해 모집한 테스터들은 일정 기간 동안 서비스의 베타 버전을 사용한 뒤, 메이커에게 사용 경험을 공유한다. 이 과정에서 건의함에서는 부족했던 깊이 있는 정성 데이터를 수집할 수 있다. CBT를 통해 VoC를 수집할 때 다음과 같은 이점이 있다.
1. 자연스러운 인터뷰 요청과 높은 수용성
위에서 말한 회원가입 방식과 달리, 사용자들이 자발적으로 참여한 베타 테스트라는 점에서 자연스럽게 인터뷰를 요청할 수 있다. 또 베타 테스터 참여자로서 해야 할 하나의 의무라는 인식을 주어 인터뷰 참여도를 높일 수 있다.
2. 빠르고 밀도 높은 피드백 루프
소수의 사용자와 가깝게, 반복적으로 소통할 수 있어 피드백 주기가 짧고 '제품 개선 → 피드백' 이터레이션의 선순환이 가능하다.
3. 깊이 있는 사용 경험 탐구
유저 인터뷰를 통해 건의함 데이터만으로는 부족했던 Why와 How를 구체화할 수 있다. 특히 베타 테스터라는 점에서 우리 서비스에 관심도가 높은 사용자들이기 때문에, 적극적인 피드백으로 사용 경험을 더 심층적으로 분석할 수 있다.
4. 초기 사용자 확보
베타 테스터 모집 그 자체로도 홍보 효과를 얻을 수 있다. 초기 베타 테스터로 참여한 사용자와 지속적인 피드백을 주고 받으면서, 단순 유저에서 공동 제작자의 인식을 심어줄 수 있다. 그렇게 피드백 루프를 확보하면서 충성도 높은 초기 유저를 만들 수 있다.
단 CBT는 적지 않은 리소스를 들여야 한다는 단점이 있다. 하지만 개인적으로는 제대로 된 정성 데이터를 수집하는 데 그정도의 리소스를 투입하는 건 낭비가 아니라고 생각한다. 그만큼의 이점이 크기 때문이다.
그렇게 우리는 지금까지 건의함 + CBT 인터뷰 데이터를 바탕으로 서비스를 개선 중에 있고, 특히 CBT를 통해 유의미한 정성 데이터를 많이 얻을 수 있었다.
초기 정성 데이터를 수집해 나가는 과정은 북카이브에게 단순 태스크가 아닌, 제품의 정체성을 찾아가는 여정인 것 같다. 아마 많은 초기 프로젝트나 스타트업도 마찬가지이지 않을까 싶다. 정성 데이터를 수집할 수 있는 다양한 경로가 있겠지만, 결국 각자의 제품과 팀에 맞는 방식을 찾아가야 한다. 우리는 앞으로도 어떻게 우리만의 방식으로 사용자와 더 가까워질 수 있을지 다양한 방법을 고민하고 실험해 볼 예정이다!
자세한 CBT 이야기는 다음 글에서 계속 >>
