BABY DAY를 공개하고 나서 가장 먼저 눈에 들어온 숫자는 가입자 수와 실제 기록 건수였다.
가입자가 늘고 기록도 쌓이니 반응이 있다는 건 알 수 있었다. 그런데 곧 한 가지 문제가 생겼다.
가입자는 보이는데 몇 명이 사이트에 들어왔는지를 몰랐다.
가입자 수만으로는 유입을 설명할 수 없다
홍보 글의 조회수가 크게 나온 날 실제 가입자도 늘었다. 하지만 웹 Analytics를 연결하지 않은 상태에서는 다음 질문에 답하기 어려웠다.
- 홍보 글에서 실제 BABY DAY로 몇 명이 넘어왔는가
- 방문자 중 몇 퍼센트가 가입했는가
- 가입하지 않고 기능만 둘러본 사람은 몇 명인가
- 어떤 화면에서 많이 나갔는가
- PWA 설치 안내까지 본 사람은 얼마나 되는가
가입자가 늘었다는 사실은 알 수 있지만, 왜 늘었는지는 알기 어려웠다.
나중에 Analytics를 붙여도 과거 행동은 돌아오지 않는다
코드나 데이터베이스 문제는 나중에 로그를 추가해 원인을 찾을 때도 있다. 하지만 방문 데이터는 계측하지 않은 기간을 뒤늦게 복원하기 어렵다.
초기에는 “사용자가 아직 적으니 나중에 붙여도 되겠지”라고 생각하기 쉽다. 하지만 사용자가 적을 때야말로 한 명이 어디서 이탈했는지 보는 것이 중요했다.
모든 이벤트를 처음부터 수집할 필요는 없다
출시 전에 이벤트를 수십 개 설계할 필요까지는 없었다.
BABY DAY라면 초기에 다음 정도만 있어도 충분히 많은 것을 볼 수 있다.
- 랜딩 또는 홈 방문
- 가입 시작과 완료
- 수유·수면·기저귀 첫 기록
- BabyTime 가져오기 시작과 완료
- PWA 설치 안내 클릭
- 스마트 알림 설정 진입
이 정도면 유입부터 첫 핵심 행동까지 어디에서 사용자가 빠지는지 확인할 수 있다.
제품 DB와 Analytics의 역할은 다르다
데이터베이스에는 사용자와 실제 기록이 남는다. 하지만 기록이 없는 계정이 왜 기록을 만들지 않았는지는 알기 어렵다.
Analytics가 있으면 가입 후 홈까지만 보고 나갔는지, 기록 화면까지 들어갔는지, 가져오기 기능에서 멈췄는지를 볼 수 있다.
이 경험 이후 Analytics는 서비스가 커진 뒤 붙이는 도구가 아니라 첫 사용자를 받기 전에 최소한으로 연결해야 하는 출시 준비물로 보게 됐다.