벨로그 시작!
0. 나
나는 스타트업 CTO다.
팀이 아주 작아서 개발 팀장과 CTO 사이의 고민을 한 적이 있었다.
하지만 CO-FOUNDER로서 회사의 방향과 경영을 고민하고,
앞으로 더 고민하자는 의미에서 그냥 CTO가 되기로 결심했다.
한 명의 CTO로서, 한 명의 개발자로서
생각을 정리하고, 팀 내에서 일어나는 일들,
개발할 때의 시행착오들을 공유해 보고자 한다.
1. 리서치
나는 보통 어떤 Task를 시작하기 전에 미리 리서치해보고
진행하면서 필요할 때마다 구글링하는 편이다.
개발자 필수 덕목 1.구글링 2.영어 독해 구글 만세🙆♂️
수많은 분들의 시행착오를 보고 내 시행착오도 극복하는 편이다.
이때 사람마다 느끼는 바가 다르기 때문에
어떤 일이 지난 후에 보통 아카이빙을 해놓는다. 내 식대로 재해석하는 것이다.
평소에 개인 노션에 정리하던 내용을 나와 같은 상황으로 고통받는 분들에게
도움을 줄 수 있게 벨로그에 정리해보면 좋을 것 같다고 생각해 벨로그로 시작해본다.
첫 주제는 최근에 진행했던 클라이언트 A/B 테스트이다.
2. 플러터
현재 내가 만들어가는 서비스는 flutter기반의 앱 서비스이다.
2.1 내가 생각하는 flutter의 장점
- 러닝 커브가 낮음.
쉽다. JS랑 비슷하다는 말을 많이 들었는데
Java만 쓰던 내가 봐도 직관적이었고
만들어진 지 얼마 안 된 언어다 보니까 굉장히 편리한 기능도 많다.
이런것도 있나? 왠만하면 다 있다.
- 생산성이 좋음.
쉽다는 장점과 연결된다. 쉬워서 금방 익숙해지고 빠르게 작업할 수 있다.
또 하이브리드인 만큼 하나의 코드로 여러 플랫폼을 지원한다는 것 자체가
생산성이 높다. 처음 flutter를 접하고 한 달 정도 만에 익숙해진 것 같다.
3. 그로스해킹
우리 팀에서는 정기적인 회의를 통해서 중요 지표들을 살펴보고
문제를 찾아서 개선하거나, 가설을 세우고 검증하는 과정이 있다.
데이터 기반의 의사결정을 하는 그로스 해킹 팀이 되기 위한 과정이라고 생각한다.
4. 회원가입 퍼널 개선
최근 우리 팀의 목표 중 하나는 회원가입 퍼널을 개선하는 것이었다.
회원가입 퍼널이란? 유저가 처음 시작부터 회원가입 후 핵심 기능에 도달하기까지의 과정
현재 우리 서비스는 로그인이 필수적인데
사용자들의 이탈률을 계산해 보니 회원가입에서 이탈하는 사용자가 상당히 많았다.
실제로 다른 서비스도 회원가입 단계의 이탈률이 상당히 높다고 한다.
또 다른 여러 부가 기능들의 도달률이 저조하다는 것을 알았다.
많은 사용자가 편리한 기능들을 어떻게 사용하는지 모르고,
심지어 있는지도 모른다는 사실을 알게 되었다.
4.1 왜???
사실 이유는 간단하다.
나조차도 어떤 서비스를 사용할 때 회원가입을 해야 하면 귀찮아진다.
아직 어떤 서비스인지도 모르는데
내 개인정보를 제공하고 회원가입을 해야 한다고 하면
高...
또 안내가 부족하다.
예전에 가이드를 추가했던 적이 있었지만
서비스 본질적으로 직관성을 높여서 해결하자고 결론이 나서
많은 부분에서 직관성을 높이고 가이드를 없앴다.
사실 가이드가 필요하다는 것 자체가 서비스가 복잡하다는 것의 반증이기도 하다.
4.2 어떻게 개선할 수 있을까?
원래 우리 서비스는
스플래시(로딩) -> 회원가입 -> 핵심 기능의 순서였다.
조금 불친절한 서비스라고 생각할 수 있다. 서비스 소개의 부재였다.
그래서 우리는 서비스 소개를 추가하기로 했다.
4.3 뭐가 더 나을까?
서비스 소개를 추가하기로 했고 어디에 추가할지를 회의하던 중
두 의견이 첨예하게 대립했다.
서비스 소개는 당연히 앱을 켜자마자 나와야 사용자가 서비스에 대한 정보를 획득하고
자연스럽게 다음 단계로 유도할 수 있지 않나?
앱을 켜자마자 강제로 서비스 소개를 보게 한다면 거부감이 들고 어차피 스킵 할 텐데
회원가입을 한 사용자들에게 보여줘야 서비스 소개를 추가한 의미가 더 있지 않을까?
우리 팀은 공유하고 싶은 생각이 있거나
다른 사람의 의견이 필요한 일이 있으면 회의해서
회의를 꽤 자주 하는 편인데
결정해야 할 사항이 있을 때 회의하면 가끔 첨예한 대립이 생길 때가 많다.
이때 정답은 누구도 모른다.
그렇다면 ?
1. 레퍼런스 찾아보고 다시 결정
2. 언젠가 해보려고 했던 A/B 테스트
이번엔 2번으로 결정됐다. 데이터 기반 의사결정이다.
5. flutter A/B 테스트
5.1 firebase A/B 테스트
첫 글이라 서론이 길었다. 죄송🙇♂️
flutter에서 A/B테스트를 하는 방법을 찾아보니 firebase를 통해 하는 방법이 있었다.
내가 찾아본 레퍼런스들에 의하면 firebase A/B 테스트는 큰 맥락의 지표들을 확인할 수 있었다.
전환률, 이탈률, 사용자 수 등등
실제 우리가 궁금했던 회원가입 퍼널 이탈률지표는 따로 확인해야 했다.
그래서 간단한 API를 만들고 UI 플로우에 로직을 추가해 직접 해보기로 했다.
5.2 직접 A/B 테스트
원리는 간단하다.
1. 결과를 로그로 남기는 API 생성
2. UI에서 플로우를 A : 스플래시 - 서비스 소개 - 회원가입 , B : 스플래시 - 회원가입 - 서비스 소개를 앱 설치 시 적절히 나눠준다.
2번은 따로 생각나는 방법이 없어 앱 설치 시 시간의 초가 짝수냐 홀수냐에 따라 나눴다.
실측해보니 51:49로 적절히 분배되고 있음을 확인했다.
高... 좀 고전인가 아무튼 잘 된다.🤷♂️
6. 결과 및 고찰
실제로 사용자들의 이탈률은 서비스 소개를 추가한 후에 약 10%나 내려간 것을 확인할 수 있었다.
추후 게스트로 이용하는 기능을 추가해
회원가입 자체의 이유로 이탈하는 유저를 위한 기능도 추가할 예정이다.
6.1 이번 일로 알게된 인사이트
- 회원가입 자체가 큰 산이다.
많은 사람이 그렇고 나 또한 그렇지만 회원가입 자체가 거부감이 큰 것은 사실이다.
이 점을 간과하고 있었다. 이번에 크게 깨달았다.
- 스타트업의 그로스 해킹은 선택이 아니라 필수다.
핵심 지표들에 관심을 가지고, 이것을 개선하려는 끊임없는 고민이 결국
서비스의 개선 나아가 팀의 성장을 이끌어낸다.
이러한 일련의 과정들에 대해 고민을 하는 회사와 하지 않는 회사는
그 성장의 기울기가 다르다.
이전의 우리가 그랬고, 지금의 우리가 그렇다.
7. 마무리
앞으로 개발, 회사 내 이야기들을 담백하게 써 보겠다.
긴 글 읽어주셔서 감사하다.🙏
