당근마켓 중고차 직거래 역기획(3)
대혼돈의 서비스 기획
Prologue
https://brunch.co.kr/@0gamkim/2
https://brunch.co.kr/@0gamkim/4
글을 쓰고 난 후 여러 번의 수정을 했지만, 계속 부족한 부분이 보여 발행을 망설였는데요, 결론부터 말씀드리면 부족한 대로 발행하기로 결심했습니다. 고치고 고쳐도 완벽에 가까워질 수 없음을 알기 때문입니다.
글을 쓰던 업무를 하던 성격상 만족할만한 100%의 결과물을 만들기 위해 계속 노력하는 편입니다. 이러한 습관은 작업의 퀄리티를 높일 수 있는 장점이 있기도 하지만 시간 소요가 크고 나 혼자 만든 틀 안에 갇혀버리게 되는 단점이 있습니다.
서비스 기획을 하면서 실험과 검증의 반복이 결국 시장과 제일 Fit 한 Point를 만든다는 것을 배웠는데요, 결국 이 논리가 글쓰기에도 통용되는 것이 아닌가 싶습니다. 70%만 완성하고 나머지 30%는 평가와 반응을 보면서 수정해나가는 것이죠.
오늘 글에서는 역기획 글을 다시 읽으면서 놓쳤던 부분, 의문점에 관해 써보려고 합니다. 아직 그 해답은 찾지 못했습니다. 현재 찾아가고 있는 중인데요, 가능하다면 그 해답에 대해 다음 글에서 다뤄보려고 합니다.
1. 당근마켓 카테고리 아이콘 노출 순서에 대해 완전히 틀린 추측을 했습니다.
당근마켓 중고차 카테고리에 관련한 글을 시작하면서 중고차 직거래 카테고리가 첫 번째로 노출되기 때문에 중고차 카테고리가 당근마켓 안에서 우선순위가 높을 것이란 추측을 했습니다.
당근마켓의 카테고리 선택 화면 출처: 당근마켓결론부터 말하면 완전히 틀린 추측이었습니다. 지속적으로 모니터링을 한 결과 아이콘 순서가 바뀌기도 하더라고요. 다시 추측을 해보면 고객이 가장 많이 사용하는 카테고리를 우선적으로 노출하는 것 같습니다. 이 부분은 메일을 꼭 한번 보내봐야겠습니다.
2. 중고차 판매자에 대한 고려는?
이번 역기힉은 구매자 Side에 초점이 맞추어져 있습니다. 하지만 중고차 거래를 활성화하기 위해서는 판매자 Side의 고객 경험도 중요합니다.
현재의 당근마켓의 서비스 구조를 보면 보험이력, 주행거리 등을 등록하는 것은 판매자의 몫입니다. 그렇다면 성능점검도 판매자의 몫일까요? 만약 판매자가 성능점검을 해야 한다면 판매자의 고객 경험을 헤치진 않을까요? 동네 카센터에서 성능점검을 한 뒤 결제는 누가 해야 할까요? 해당 부분에 대한 고민이 적어 아쉬움이 많이 남습니다.
만약 판매자가 중고차 판매 정보의 모든 부분을 준비해야 한다면 '헤이 딜러'와 같이 간편 판매 서비스 대비 경쟁력이 약화될 가능성도 있습니다. 이에 대한 답도 찾을 필요가 있어 보입니다.
3. 실험 변수에 대한 고민
'동네 카센터를 통한 성능점검 기능'을 사용한 이용자들의 구매전환율을 지표로 측정하려고 했습니다. 차량의 성능점검을 하게 되면 구매전환율이 상승할까요? 오히려 차량의 문제를 더 많이 찾게 되어 구매로의 전환이 낮아지진 않을까요? 성능점검과 상관없이 애초에 차량이 매력적이었던 것은 아닐까요?
'동네 카센터에서의 차량 점검'은 차량 성능 정보를 잘 모르는 고객의 불편한 점을 해소해줄 수 있습니다. 그러나 불편한 점의 해소가 꼭 구매 전환율로 이어지지는 않을 것 같습니다. 차량의 실제 상태라는 변수의 영향이 크기 때문입니다.
즉, 이전 글에서 설정한 [‘동네 카센터에서 성능 점검하기’ 기능을 사용한 사용자의 차량 구매 전환율이 이용하지 않은 사용자보다 20% 높을 것이다.']란 가설은 애초에 실험을 통한 검증이 불가능한 가설인 것 같습니다. '오프라인 차량의 실제 상태'란 변수를 완벽하게 통제할 수 없으니까요.
4. 너무 넓은 실험 범위
기능을 검증하기 위해 실험을 설계하면서 어렵다는 생각을 많이 했습니다. 그 이유를 곰곰이 생각해보니 검증하려던 기능의 범위가 너무 넓었던 것이 이유가 아닐까 싶습니다. 기능의 범위가 넓은데도 불구하고 하나의 기대효과와 가설을 설정하려니 예측하지 못한 변수가 나타나거나 논리적이지 않는 경우가 생겼던 것 같습니다.
당근마켓 기술 블로그에서 실험에 관련한 아티클을 읽어보면 1주에 1번 기능 배포와 실험을 진행하는 것을 알 수 있습니다. 배포하는 기능의 범위도 좁은 편입니다. 좁은 범위의 개선은 명확한 기대 행동과 지표를 설정하기 용이합니다.
관련 자료를 알아보면서 OEC의 개념에 대해서 알게 되었는데요, OEC란 쉽게 말해 종합 평가 기준을 말하는 것으로 여러 가지 KPI를 합친 것을 말합니다. 즉 하위 평가 지표가 모두 충족되었을 때 OEC가 100% 충족되었다고 말할 수 있는 것입니다.
이전 글의 검증 방법을 수정해봐야겠습니다. 현재 기획한 [동네 카센터를 통한 성능 점검하기] 기능을 단계별로 쪼개서 주요 지표를 여러 개를 설정하고 이를 합쳐 OEC, 즉 최종 기대효과의 달성 여부를 확인해볼 계획입니다. OEC에 대한 자세한 개념은 아래 김희영님께서 작성하신 아티클을 통해 쉽게 이해할 수 있습니다.
https://playinpap.github.io/summary-of-indicator-concepts-explained-by-bread/
5. 카센터 사장님의 전문분야가 다르다?
얼마 전 자차의 타이어에 작은 균열이 있어 카센터를 들린 김에 차량 점검에 대해서 여쭈어보았는데요, 생각하지 못한 부분이 있었습니다. 바로 카센터 사장님마다 차량 브랜드에 따른 전문성이 다르다는 것이었습니다.
물론 큰 틀에서의 성능점검은 가능하나 현대차에 대한 전문성이 있으신 경우 벤츠차에 대한 성능점검은 조금 어려운 부분이 있다는 의견을 들을 수 있었습니다. 해당 부분에 대한 고민을 통해 기능을 세분화할 필요성이 있어 보입니다.
6. O2O 서비스 관리에 소요되는 리소스와 '당근미니' 전략
이전 글에서 당근 마켓의 비즈프로필을 등록한 동네 카센터가 많지 않다는 점을 말씀드렸습니다. 카센터와의 연결을 위해 전화나 채팅이 꼭 필요하기 때문에 최대한 많은 카센터 사장님이 비즈프로필을 등록할 필요가 있습니다. 또한 차량 점검이 가능한지에 대한 정보 업데이트도 동시에 필요합니다.
이 부분이 해결되지 않는다면 Next Step의 기획이 의미가 없어질 수 있습니다. 그러나 카센터 사장님의 연령대가 주로 5060인 점을 감안하면 비즈프로필 등록을 유도하기란 쉽지 않아 보입니다.
이전 글에서 나름의 아이디어를 바탕으로 홈 화면, 중고차 거래화면 등에서 성능점검이 가능한 카센터를 모집하려 해 봤지만 글을 퇴고하면서 고민해보니 실질적인 효과가 적을 수 있다는 생각이 들었습니다.
결국 일일이 사장님을 찾아 뵙고 비즈프로필을 등록시켜드려야 할까요? 동 단위로 시작해서 점차 범위를 늘려가는 로드맵을 그려봐도 리소스가 너무 많이 들어갈 것으로 예상됩니다.
그래서 다른 방향으로 솔루션을 고민해보았습니다. 바로 당근미니를 이용하는 방법입니다.
당근미니 출처: 당근마켓당근미니는 당근마켓 외부의 서비스와 업무협약을 맺고 당근마켓 내에서 외부 서비스를 이용할 수 있게 하는 기능입니다.
만약 성능점검을 대행해줄 수 있는 서비스와의 MOU를 통해 당근미니로 중고차 구매 시의 성능점검을 제공한다면 어떠할까요? 제가 작성한 기획안보다 개발, 관리 리소스를 훨씬 많이 줄일 수 있을 것으로 보입니다.
(좌)카바조 서비스의 정비사 경력 (중), (우) 카바조 서비스의 자세한 진단 리포트 출처: 카바조 서비스 홈페이지실제로 최근 주목받는 정비사 동행 서비스가 있습니다. '카바조' 라는 서비스인데요, 카바조에서는 직접 차량 정비사를 고용하여 성능점검 서비스를 제공하고 있습니다. 직접 고용 형태이다 보니 경력에 대한 인증이 확실하고 실제 후기의 반응도 높은 것을 볼 수 있었습니다. 또한 카바조 자체적으로 제작한 고품질의 진단 리포트까지 제공함으로써 차량 성능점검을 완벽에 가깝게 도와주고 있습니다.
또한 카바조에서 실제 성능점검 정비사로 일하시는 분들의 이력을 자세히 확인해보니 보통 카센터를 운영하시면서 부업으로 현재 카바조의 성능점검 정비사로 활동하시는 것을 확인할 수 있었습니다. '카바조'가 당근미니의 형태로 당근마켓 내에서 운영된다면 가까운 거리 순으로 성능점검 정비사와의 매칭을 유도할 수 있습니다. 이를 통해 '지역 커뮤니티 활성화'라는 전략적 목표도 달성이 가능해 보입니다.
즉, 이전 글에서 고민하였던 '동네 카센터를 통한 성능점검'을 실제 개발하는 것보다 '카바조' 서비스와의 MOU를 통해 중고차 직거래에서 가장 큰 문제였던 성능점검기록부의 부재를 해결하는 것이 리소스 관리, 기능의 퀄리티, 개발 소요시간에 있어 훨씬 합리적일 것으로 보입니다.
