나는 푸시가 서비스의 리텐션을 올릴 수 있는 치트키라고 생각한다. 잘 세팅해두면 그렇지 않을 때보다 일일 접속자 수와 리텐션을 1.5배 이상 개선할 수 있다. 리텐션을 측정하는 기준은 서비스 특성마다 다르지만 우리 서비스는 주간 재방문율을 쓰고 있다.
서비스의 리텐션 그래프를 막 10%포인트 이상씩 크게 개선하는 것은 어렵다. 앱의 카테고리, 핵심 기능과 컨셉에 따라 자연히 가지는 리텐션의 모습이 있기 때문이다. 예를 들어 주차별 리텐션이 아래와 같은 서비스가 있다고 가정해보자.
- 30%(1주차)→15%(2주차)→10%(3주차)→7%(4주차)
주요 인터페이스를 바꾸고, 디자인을 크게 개선한다면 이 정도로 개선될 것이다.
- 32%(1주차)→18%(2주차)→13%(3주차)→9%(4주차)
특정 버튼이나 기능의 사용률은 위치나 디자인에 따라 훨씬 낫게 할 수 있다. 서비스 재방문률은 어째 그렇지가 않다. 메인 디자인이나 인터페이스 바꿨다고 리텐션이 막 2배 올라가면 그 전 버전을 잘못 만들었다고 생각한다.
전체 앱의 1주 차 평균 리텐션은 20%가 채 되지 않는단다. 1주차 리텐션이 20%인 앱이 있다고 해보자. 1주차에 정기적으로 가는 푸시(같은 내용이라는 말 아님)를 잘 세팅해두면 30%까지 훅 높일 수 있다. 푸시를 리텐션 개선 치트키라고 첫머리에 쓴 이유다.
물론 숫자만 올라갔다고 서비스가 좋아졌다고 볼 순 없다. 당장 오늘의 숫자는 올라갔지만 불쾌함을 느낀 사용자들이 내일 오지 않을 수도. 충분히 그럴 수 있다. 하지만 더 좋은 경험을 줄 기회이기도 하다. 새로운 콘텐츠 소식을 알려주고, 사고 싶던 상품이나 관심 있던 상품 소식을 알려주고, 받아야 할 일정을 까먹지 않도록 확인해줄 수 있다.
나 푸시 오는 거 정말 싫어해. 짜증 나. 푸시 오면 앱을 지워버려.
이런 사람도 많지만 실제로 운영해보니 그 정도까진 아니다. ‘그래도 나는 푸시가 싫어!’라고 한다면 오늘 받은 푸시가 몇 개인지 떠올려보고 시스템의 푸시 목록을 둘러보라. 아마 생각했던 숫자보다 더 많은 푸시가 도착했을 거다. 실제 오는 푸시보다 체감은 덜 한다는 것! 이 푸시들 때문에 지우기로 결심한 앱도 거의 없을 거다. 이는 실제 발송되는 푸시 수에 비해 체감하는 푸시 수가 적다는 것과 생각보다 그렇게 불쾌하지 않다는 것을 뜻한다. 여전히 싫어하는 사람이라면 이미 조치를 해뒀을 것이다. 알림을 안 받아보거나, 무음인 채로.
푸시를 많이 보내면 앱을 지우는 사람도 많아지는 건 사실이다. 푸시를 잔뜩 보내서 일일 방문자 수가 유난히 높았던 날은 일일 기기 삭제 수도 다른 날보다 높았다. 나 뭐한 거야, 사용자 쫓아내고 넘나 많이 보냈다고 서버 무리 가서 개발자한테도 혼나고… 그렇다고 쫄면 안된다. 그렇게 지운 사람들은 푸시가 짜증 나서도 있겠지만 지울 계획이었던 앱의 존재가 생각나 겸사겸사 지운 거기도 하다. 즉 원래 안 쓸 사람들이다.
푸시를 거부감이 없을 정도로, 아니 거부감이 좀 생기더라도 앱을 떠나지는 않을 만큼 보내는 걸 잘해야 한다. 물론 잘못하면 나처럼 시스템의 몇만 개의 푸시를 발송하고 GA의 실시간 접속자를 보며 ‘오, 오 들어온다. 40명, 100명~’ 하고 킬킬대다가 서버가 다운되었다는 소식에 울게 된다.
푸시 동의율 높이기
제일 먼저 할 일은 푸시 동의율 높이기다. 안드로이드 평균 푸시 동의율은 70~80%, iOS는 30~40% 선이라고 한다. iOS 사용자의 반 정도는 푸시를 보내도 받아보지 않는다는 말이다. 보통 앱을 설치하고 나면 바로 푸시 수신 동의 팝업이 뜨는 앱들이 많다. 개발상으로 iOS 앱에서 이 푸시 설정 동의 팝업을 띄울 기회는 단 한 번뿐이라 이때 동의하지 않으면 서비스를 사용하는 동안은 영영 푸시 설정을 바꾸지 않을 확률이 높아진다.
이 푸시 동의율을 높이는 방법으로 앱 자체 제작 팝업으로 수신 동의 의사를 (재차) 물어보는 방법이 있다. 앱 실행할 때 바로 냅다 무는 것이 아니라 이 질문에 사용자가 ‘동의’할 때까지 잠시 보류해두는 것이다. 커스텀 팝업에 사용자가 ‘동의’하는 순간 시스템 팝업을 띄워 푸시 수신 동의율을 높이는 것이다. 푸시로 인한 혜택을 함께 안내하면 효과가 더 좋을 수 있다.
주기적으로 발송할 푸시 설계하기
이제 사용자 속성을 바탕으로 자동 푸시를 세팅해보자. 기본적으로 들어가야 할 푸시 종류들을 놓치고 있는 건 없는지 먼저 확인해보자. 사용자는 본인과 직접 관련된 것에는 거부감이 거의 없다. 내 글에 댓글이 달렸다고 온 푸시 메시지에 ‘아 뭐여. 내 글에 댓글이 달렸다고 푸시가 오고 난리여.’한 적은 없을 것이다.
댓글이나 좋아요 푸시는 사용자에겐 내 콘텐츠에 대한 일종의 보상이기도 하다. 내 글에 보인 반응, 다가오는 내 일정과 같은 종류의 푸시는 심리적 거부감이 거의 없고 누르는 비율도 높다. 운영자가 보낸 ‘(광고)지만 유용하죠, 하하, 저희가 좋은 물건을 가져왔다구요!’ 류 보다 훨~씬. 이런 푸시들은 기본적으로 빠짐없이 발송해야 한다.
푸시 기능이 MVP(Minimal Viable Product)나 초기 버전엔 때로 들어가지 않아도 되지만 앱을 업데이트해야만 푸시를 받을 수 있는 상황은 피해야 한다. 개발자분이 말할 거다. 그럼 기능을 넣는다는 거랑 거의 같은 말이라고. ‘푸시는 나중에 넣자’며 출시했다가 이미 가입한 사용자들에게 새 이벤트 소식 알릴 길이 없어서 SMS를 보냈다는 설화도 있다.
브런치에서도 조회 수가 1,000단위로 올라가거나 공유수가 10단위로 커질 때마다 알려준다. 왠지 기분이 좋아진다. 당신의 앱에도 사용자가 기분이 좋아질 푸시가 있을 거다. ‘당신이 좋아서 지금 들어오면 500원을 꽁으로 드려요’ 같은 푸시를 특정 조건이 만족하면 보내주기로 설계할 수 있다.
가입일로부터 1주 이내에 푸시를 보내는 것을 시작으로 주기적으로 새 콘텐츠를 보내도록 설계해보는 것도 좋은 방법이다. 앱의 콘셉트와 연관 있는 새 콘텐츠를 보내주는 것이 중요하다. 사용자의 속성이나 상태에 따라 달리 설계하는 것도 좋다. 그래도 시작은 큰 틀에서 운영을 시작해보는 게 학습에 좋다.
푸시 타이밍 정하고 개인화하기
사람들의 모바일 사용행태를 보면 출·퇴근 시간에 많이 쓰고 밤에 사용률이 피크 쳤다가 잘 시간이 되면서 사용률이 떨어진다. 평일은 8-10시 사이를 추천하고 주말은 1-2시도 좋다. 아무 생각 없이 모바일을 쓰면서 시간을 보내는 타이밍을 노려서 푸시를 보내는 것이다. 덕분에 다 이 시간에 보내서 이 시간대 푸시 경쟁률이 폭발했다고 한다 아니야 그럴 리는 없어
참여까지 유도해야 하는 이벤트라면 더욱 푸시 발송 시간에 따른 효과 차이가 크다. 진행했던 이벤트 테스트 중에서 열람률은 비슷한데 시간대에 따라서 참여율이 달랐던 적이 있다. 더 기꺼이 쉽게 참여할 수 있는 시간대가 따로 있을 수 있다. 푸시 대상이 직장인이라면 업무 시간보다는 집에 누워 있을 시간에 보내는 것이 더 참여율이 높을 거라고 예상해볼 수 있다.
메시지 상에 이름이나 닉네임을 넣어 부른다거나 사용자가 관심사로 설정한 태그나 키워드를 포함시켜 메시지를 보내면 그렇지 않은 것보다 당연히 더 관심 끌 수 있겠지.
스팸으로 느끼지 않도록
사용자가 스팸처럼 느끼지 않도록 해야 한다. 처음 관리자에서 간단히 설정해둔 것은 운영자 발 이벤트 푸시 등을 발송할 때 받은 지 12시간 이내의 사용자를 자동으로 타깃에서 제외하는 것이다. 앞서 말한 나와 직접적으로 관련된 내 글에 대한 반응 푸시를 이렇게 할 필요는 없다. 주로 광고나 이벤트를 알릴 때 적용하면 좋다. 한 사용자가 자동 푸시 조건이 중복으로 해당되어 동시간대 너무 많은 푸시를 받게 되는 것을 방지할 수도 있다.
잠을 방해하지 않도록 새벽 1시 이후에 발생한 푸시는 다음 날 오전에 몰아 보내주는 것도 방법이다. 나는 보통 사용자가 디테일하게 설정할 수 있도록 기능을 만들기보다는 시스템 설정을 보수적으로 세팅해서 운영하는 방법을 택할 때가 많다. 푸시 off 기능은 특정 푸시를 받아보기 싫어하는 사람들이 이탈하지 않도록 도와주지만 그렇게 하는 사람들은 전체 사용자 중에 일부기 때문이다. 쓰레기 스팸이 아닌 따끈한 밥에 스팸 한 조각처럼 느낄 수 있는 푸시를 보내자.
푸시 설정 무음, off 설정할 수 있게 하기
자동 푸시 설정과 함께 있어야 하는 기능은 종류별 푸시를 on/off 설정할 수 있는 기능이다. 수신을 원하지 않는 사람을 거부할 수 있도록 기꺼이 안내해야 한다. 그렇지 않다면 그 사용자를 떠나보내야 할 것이다. 아래와 같은 이유로 계속되는 경험담…
탈퇴사유: 아우 짜증 나 푸시 꺼지지도 않고 ㅗ
푸시를 다시 on을 할 기회도 여전히 놓치지 말자. iOS는 off 푸시를 on 하려면 굳이 굳이 설정 앱에서 해당 앱을 찾아서 푸시를 재설정해야 하기 때문에 off 시킨 사람을 on 시키는 것보다 애초에 동의율을 높이는 게 좋다. 시스템 푸시가 off 된 경우에 on을 하면 좋은 일이 생길 거라고 어필 하자.
반응 좋은 메시지로 최적화하기
푸시는 또 어떤 문구에 관한 사용자의 반응을 빠르게 테스트하는 데도 용이하다. 어떤 공동구매 소식을 알리려고 푸시를 보낼 때 아래 두 종류의 푸시를 1,000건씩 보내 푸시 클릭율을 비교해서 더 나은 전환율로 나머지 사용자에게 보내는 방법을 택할 수 있다.
(광고) ○○공동구매 할인 20%
(광고) 지금 이 푸시로만 할인받을 수 있는 꿀템이라구!
주기적으로 보낼 자동 푸시들도 가입일, 성별 등 기본적으로 동일한 속성을 가진 타깃에게 A/B 테스트를 해보면 어떤 푸시가 더 좋은지 파악할 수 있다. 이 방식으로 자동푸시를 최적화해두면 추가 리소스 없이 꾸준히 푸시를 통한 재접속자를 확보할 수 있다.
마치며
위에 나열한 ‘푸시를 위한 액션’ 중 가장 효과가 좋은 것은 아무래도 주기적으로 푸시를 세팅해두는 것이다. 사용자가 관심 있어 할 만한 새로운 콘텐츠로. 맞춤 자동 푸시는 초반에 잘 세팅해두면 리소스를 들이지 않고 전체적인 리텐션을 높일 수 있는 좋은 방법이다.
서비스 기획자라면 가입하는 각종 앱의 푸시를 on 해두고 나 자신을 관찰해보는 것도 푸시 설계에 도움이 될 것 같다. 사용자 모드로 넋 놓고 있다가 나도 모르게 훅 반응하게 되는 메시지를 만들 때마다 이유를 탐구해보는 거다. 이런 방법으로 최근에 맘에 드는 푸시 메시지를 발견해서 써먹기도 했다. 12시쯤이었던가…
자니?
‘이건 뭐 전 남자 친구도 아니고 뭐야.’ 하면서 피식하고 눌러보았다. 이런 위트 있는 푸시도 (나는) 좋다. 이걸 또 따라 하지 마시오. 점심시간에 ‘밥 먹니?’로 응용할 수도 있다.
원문: 수지의 브런치
