brunch

You can make anything
by writing

C.S.Lewis

by 재희 Oct 03. 2022

App까지 안전하게 모시겠습니다

연결률 개선, 그 대장정의 서막 (2)

목차

1. Amplitude User-path : 이탈 지점을 확인합니다

2. "앱으로 볼래요" 팝업창 : 최소 spec으로 실험합니다

3. 다이나믹 링크 : CRM의 유저 경험을 개선합니다




1. Amplitude User-path

    오르는 연결률을 분석하면서 유저들이 왜 이 기능에 설득되었는지를 알아내는 것도 중요하지만, 설득되지 않는 유저들은 어떤 지점에서 이탈하게 되었는지를 아는 것도 그만큼 (혹은 그 이상) 중요하다. Amplitude는 그 원인을 분석할 수 있도록 이탈에 대한 user-path 조회 기능을 제공하고 있다. 나는 이를 이용해 <부모회원>의 '신청서' 페이지를 본 <시터회원>들이 어떤 경로를 거쳐 이탈하게 되었는지를 살펴보았다.


    무려 34%에 달하는 유저들이 Web의 로그인 페이지를 봤다는 공통점을 갖고 있다. 여기서 질문. 유저들이 매번 로그아웃을 할 리도 없고, 왜 로그인 페이지를 보게 되는 걸까? → 아, App(이하 앱)만 사용하는 유저들은 우리가 Web으로 보내면 로그인을 해야 하겠구나. → 그럼 왜 우리는 유저들이 앱을 쓰는지 여부도 확인 안 하고 다 Web으로 보내고 있는 거지? → 아, 앱 스킴 호출 기능을 사용해야 되는데 이건 아직 staging 단계인 우리 앱 iOS 최신 버전에서만 작동 중이라 하위 호환 이슈가 크구나. 자 이제 어쩐다.


    개선점은 확실하다: 앱이 있는 <시터회원>들은 앱에서 '신청서' 페이지를 볼 수 있어야 한다. 그래야 앱 유저들이 불편하게 Web에서 로그인하다가 이탈하는 불상사를 막을 수 있다. 마지막으로, 이 작업이 우리의 Objective인 "부모는 마음에 드는 시터와 대화할 수 있다."를 달성하는 데에 기여하는지를 다시 한번 점검해보기로 했다. 앱에서 '신청서'를 본 <시터회원>들의 연결률이 ... 더 높네? 왜 더 높지? (사실 더 높을 줄 몰랐고 더 높을 이유도 없다) 앱을 사용하는 <시터회원>들이 구직에 대한 열의가 더 강하기 때문에 연결률이 높게 나오려나?


    그 원인이 무엇이든 간에, Web으로 떨어지고 있는 유저들을 앱으로 보내면 전반적인 연결률이 올라갈 것이라는 가설을 세우기에는 부족함이 없는 데이터였다. 우리 팀은 이 데이터를 믿고 앱 스킴 호출 기능을 사용하지 않고 이 가설을 검증할 수 있는, 최소 spec의 실험 아이템을 구체화하기 시작했다.


2. "앱으로 볼래요" 팝업창

    그렇게 완성된 아이템은 <시터회원>이 '신청서'로 연결되는 링크를 눌렀을 때, 앱으로 이동할 수 있는 옵션을 제공하는 팝업창이다. 이 피쳐를 기획할 때 가장 중요하게 생각한 부분은 UX Writing이었다. 개인적으로 정말 좋아하는 Joo Jun님의 브런치에서도 알 수 있듯이, Confirmshaming은 그 강도와 관계없이 지양해야 하는 writing 방식이다. 앱의 편리함을 강조하고 앱으로의 이동을 nudging하려는 목적은 헤드 메시지에서 달성하고, '불편하지만 웹으로 볼게요' 따위의 워딩은 애초에 고려하지도 않았다.


    여기에는 최종본만 멋있게 올려두었는데, 사실 디자이너 분과 20개에 가까운 시안을 만들었다가 폐기하는 과정을 거쳤다. 나중에는 스마트폰을 들고 있는 손 모양을 닥터 스트레인지 짤과 합성해주셨는데 여기 올려도 될지 모르겠어서 일단 생략한다. tmi 우리 팀의 sub KPI는 웃긴 짤 만들기다. 하여튼, 우리 팀은 이 피쳐를 빠르게 Web에만 적용한 다음 앱 진입 수 및 서비스 평균 연결률을 tracking해보았다.


6/21 팝업창 배포 이후 연결률이 상승하는 모습

    결과적으로 & 예상대로 서비스 평균 연결률은 우상향 그래프를 그렸다. '앱을 사용하는 <시터회원>들이 구직에 대한 열의가 더 강하기 때문에 연결률이 높을 것이다'라고 상정했던 인과관계는 생각보다 약했고, <시터회원>들을 앱으로 보내는 것이 연결(매칭)을 원하는 <부모회원>들에게도 도움이 된다는 점을 새롭게 알아낼 수 있었다. 이렇게 작은 사이즈의 실험으로 핵심 가설을 검증했을 때쯤, iOS 앱의 최신 버전 배포율도 80%를 넘기며 앱 스킴 호출 기능의 하위호환 이슈가 해소되었다.


3. 다이나믹 링크

    다이나믹 링크에서 앱 스킴을 직접 호출하면 앱이 있는 유저들은 더 이상 "앱으로 볼래요" 버튼을 누를 필요 없이, CRM 메시지의 링크를 타고 곧장 앱으로 이동할 수 있게 된다. 그런데 아무리 생각해도 유저들이 우리의 token 값이나 UTM parameter까지 전부 볼 필요는 없지 않나, 하는 생각이 들었다. 그래서 공수를 조금 더 들여서 카카오톡 알림톡 템플릿을 전면적으로 업데이트했다. 그리고 이 과정에서 예상치 못하게 CTA(Call-to-Action) 버튼명은 신중에 신중을 기해 골라야 한다는 점을 배울 수 있었다.


갑자기 옆길로 새는 듯 하지만, 막간 lessons-learned 공유

    [1차 개선 알림톡]에서는 "응답하기"라는 버튼을 적용해 직관적으로 다음 행동을 nudge하려고 했는데, 오히려 페이지 열람률이 [기존 알림톡] 대비 5%나 낮아졌다. 왜 CTA 버튼을 누르지 않지? 급히 팀원들과 논의해본 결과, "응답"이라는 단어가 곧바로 수락이나 조율로 이어질 것 같은 인상을 주기 때문이라는 가설이 가장 유력해 보였다. 부랴부랴 버튼명을 "신청서 확인하기" / "지원서 확인하기"로 수정하고 알림톡 검수 요청을 넣었다. 다행히도 우리의 가설이 맞았는지 [2차 개선 알림톡]이 배포된 후 1주일 만에 [기존 알림톡] 때의 열람률을 회복하였고, 2주부터는 그보다도 2%p 높은 열람률을 기록하고 있다.


    다시 연결률 이야기로 돌아가자면, 이렇게 CRM을 개선한 후 앱 사용 비율은 30% 가까이 증가했고 우리의 초기 가설처럼 서비스 평균 연결률도 지속적인 상승세를 보이고 있었다. 또, 앞서 언급한 [2차 개선 알림톡]에서 열람률이 높아지니 연결률도 덩달아 올라가며 (예상치 못한) 시너지 효과가 나타났다. 결국 더 많은 연결(매칭)을 불러일으키기 위해서는 '신청서' 열람률과 열람 과정의 개선이 선행되어야 했던 것이다. 다음 글에서는 앞단이 아니라, 뒷단에서 유저의 맥락을 이어 붙인 사례를 소개해볼 예정이다. 지금까지 소개한 프로젝트들 대비 scope이 작았기 때문에 분량이 다소 짧을 듯하다.

작가의 이전글 위대한 미션 - 한 사람의 꿈이 모두의 꿈이 된다는 것
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari