면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
AARRR 모델을 직접 적용해본 건 팀 프로젝트에서 소규모 서비스 지표를 분석할 때입니다. 회원가입부터 실제 사용까지 단계를 AARRR 순서로 정리해보니, 어디서 이탈이 가장 많은지가 한눈에 보였습니다. 저희 서비스는 `Acquisition`(유입)은 괜찮았는데 `Activation`(첫 경험)에서 이탈이 컸습니다. 가입 후 첫 기능을 쓰기까지의 흐름이 너무 많은 단계를 거쳐야 했던 구조가 원인이었습니다. 온보딩 단계를 줄이는 방향으로 개선하니 첫 기능 사용률이 올라가는 걸 직접 확인했습니다. 지표가 퍼널 어디에 있는지를 먼저 파악하는 게 개선 방향을 빠르게 잡는 방법이었습니다.
AARRR 프레임워크를 공부하면서 가장 인상 깊었던 건 `Retention`이 뒤쪽에 있지만 가장 중요하다는 점입니다. 유입과 전환을 아무리 잘해도 사용자가 다시 오지 않으면 계속 새로운 사람을 데려와야 하는 구조가 되기 때문입니다. 수업 사례 분석에서 `Retention`이 10%p 오르면 매출 영향이 `Acquisition` 개선보다 훨씬 크다는 연구 결과를 접했습니다. 개인 프로젝트로 만든 서비스에서 재방문율을 추적해봤는데, 일주일 뒤 재방문율이 30% 아래로 내려가는 시점에서 사용자가 빠르게 이탈하는 패턴을 발견했습니다.
AARRR에서 어느 단계를 먼저 고쳐야 하는지를 결정하는 것이 분석의 핵심이라는 걸 느꼈습니다.
AARRR 모델을 처음 배웠을 때 어렵게 느꼈던 건 각 단계가 이어지는 게 아니라 독립적으로 작동한다는 점이었습니다. Referral이 높아도 Retention이 낮으면 결국 성장이 아니라 회전에 가깝다는 걸 이해하는 데 시간이 걸렸습니다. 팀 프로젝트에서 지표를 분석할 때, 퍼널의 어느 단계에 초점을 맞출지를 팀원들이 제각각 생각하고 있었던 것을 발견했습니다.
AARRR로 단계를 명시적으로 구분하고 나서야 팀이 같은 목표를 보고 논의하는 것이 가능해졌습니다. 프레임워크의 가치는 분석 도구이기 전에 공통 언어라는 걸 그때 느꼈습니다. 공통 언어 없이 각자 다른 지표를 보면 논의 자체가 엇갈린다는 것도 그때 직접 경험했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.