당신의 앱에 리뷰를 요청하는 올바른 방법

날마다 새로운 서비스를 소개하는 프로젝트 프로덕트 익스프레스 에 쓴 글을 제 블로그에도 옮깁니다.

언제나 읽어볼만한 글을 추천해주시는 기훈님 (유저스토리랩 디자이너) 이 공유해주셔서 아래의 글를 읽어보았습니다.

사용자에게 리뷰를 요청하는 더 나은 방법에 대하여

해당 글은 Circa 라는 뉴스 앱이 실제 적용했던 내용 The right way to ask users to review your app (영문) 을 참고하여 실제 진행해보고 간단한 소회(?)를 정리한 글입니다.

#

저희 회사에서도 모바일 어플리케이션 (옷깃, 150)을 운영하면서 리뷰를 요청하는 방법에서 조금씩 다른 방법들을 시도해보았습니다. 글에서 얘기하는 내용 중 몇 가지는 150에 잘 적용되어 있는 것 같습니다.

옷깃의 경우에는 서비스를 세번째 실행시켰을 때 즈음에 팝업을 이용해서 Rating 을 요청합니다. 아직 앱에 대한 경험이 적었을 때, 하트를 주면서 별점 리뷰를 남기라고 독려를 했습니다. 좀 꼼수스럽군요. 리워드를 주면서 리뷰를 남기게 요청하는 것은 현재는 스토어에서 금지하고 있는 것으로 알고 있습니다.

150은 설정 페이지에 <버그 신고 및 개선사항 문의하기>와 <평가 및 리뷰 남기기>를 분리해두었습니다. <버그 신고 및 개선사항 문의하기>는 메일로 보내게 되어있고, <평가 및 리뷰 남기기>는 다시 마음에 들었는지 / 불편한 점이 있는지로 질문을 분기하여 마음에 들었다고 선택했을 경우에는 Thank you 메시지와 함께 스토어에 5점을 남겨주시라 독려를 하고, 불편한 점이 있다고 선택한 경우에는 메일로 보내도록 되어 있습니다.

150에서 경험했던 부분은 유저스토리랩 부사장 봉간님이 메일로 답변 주신 내용을 옮깁니다.

150을 통해서 얻은 경험 몇가지

(1) 초기에 앱이 안정화 되기 전에 – 리뷰를 요청하는 것은 오히려 안 좋을 수 있습니다.

당연하지만 어떤 좋은 경험을 했을 때 리뷰/별점을 주는 것보다는, 나쁜 경험을 하고나서 항의를 하기 위해서 남기는 경우가 훨씬 더 반응이 잘 일어나기 때문입니다.

(2) 150의 경우 초기에는 앱의 실행 카운트를 계산해서 (이를 테면 100번 실행한다던지) 리뷰 팝업을 띄우는 형태로 진행을 했습니다. 이건 사용자가 일정 부분 활동을 한 뒤에 리뷰를 남기는게 좋을 것이라 예상했기 때문입니다.

위 링크가 그때 봤던 게시물이 맞네요. 아무튼 리뷰 점수가 별로여서 수정을 했는데요.

(3) 발생시점을 실행 횟수가 아니라, 좋아요를 받는 시점과 연동했습니다. 150에서는 예를 들어, LIKE를 1,000번 받으면 축하 내용이 알림에 표시되는데.. 이 시점과 연동해서 팝업이 뜹니다.

팝업은 위 게시물과 마찬가지로 – 앱에 대해서 평가를 묻고(150 앱은 어떠셨나요?), “마음에 들어요” 와 “불편한 점이 있어요”의 답변을 선택 할 수 있도록 한 뒤…

마음에 들어요로는 리뷰 페이지로 / 불편한 점이 있다고 할 경우는 메일 문의로 처리되었습니다.

또한, 어떤 사용자가 리뷰를 남기기 위해서… 구글플레이/앱스토어가 아니라, 앱의 설정 페이지를 방문할 가능성이 높다는 판단 아래, 150 – 설정 메뉴 아래에도 각각 “버그 신고 및 개선사항 문의하기”와 “평가 및 리뷰남기기”를 구분해서 링크를 제시하고.. 전자의 경우는 바로 메일 문의로, 후자의 경우는 한 번 걸러내기 위해서(악플을 다는 경우) 위 팝업이 떠서 분리하도록 했습니다.

(4) 실제로 저 액션을 하기 전과 후의 별점은 완전 다르다고 할 수 있을 정도로… 점수가 올라갔습니다. 물론 컨텐츠가 많아지면서, 개선 및 버그 수정 등의 이유도 복합적으로 작용했겠지만요.

#

원문의 내용을 간단히 소개하겠습니다. 언제, 누구에게, 어떻게 리뷰를 요청하는 게 좋을까에 대한 이야기입니다. 혹시 내용상 애매하거나 덧붙이고 싶은 내용이 있다면 코멘트 주세요.


# 1

3가지 단순한 원칙

1. 누군가의 경험을 방해하지 마라
2. 앱이 클래쉬나고 나서 앱 리뷰를 요청하지 마라. 바보짓이다.
3. 건설적인 피드백이 있을 수 있거나, 좋은 별점을 얻을 수 있는 때까지 리뷰 남기기 요청을 기다려라.

호텔 예약 앱이거나 (정말 쉽고 빠르게 예약을 할 수 있었다면?), 쇼핑 앱인 경우에 리뷰를 요청할 순간은 거래가 이루어질 때입니다. Circa 앱은 뉴스 앱이라 거래 transaction 가 이루어지는 앱이 아닙니다. Circa 의 경우, 3일에 걸쳐 최소 10번 이상 앱을 연 회원을 대상으로만 리뷰를 요청했습니다. 이 경우, 해당 사용자들은 충성도 있는 고객이라 볼 수 있고 만족스럽지 않아서 이에 대해 피드백을 하는 경우에도 건설적인 피드백을 받을 수 있다라고 가정했습니다.

# 2

Circa 의 경우에도 처음에는 Pop-up 형태로 리뷰를 요청한 모양입니다. 당연히 사용자들의 경험을 방해하기 때문에 별점이 딱히 좋지 않습니다.

02
Circa 는 피드 형태의 컨텐츠를 제공하는 뉴스 앱이기 때문에 피드의 중간에 레이팅을 해주기를 요청하는 것으로 개선했습니다.

01

어떤 서비스/앱이냐에 따라 어디에 리뷰 요청을 넣어야 할 지를 고민해볼 필요가 있을 것 같습니다. 쇼핑 앱이라면 주문이 끝난 이후에, 소셜 앱이라면 피드 내에 넣을 수 있겠죠?

# 3

그 전까지 리뷰 요청 내용은 직접적으로 “Would you mind rating Circa News? – No, thanks / Sure, I’ll rate” 묻고 있었으나, 질문을 아래와 같이 바꿉니다.

03
“Enjoying Circa News? – Not really / Yes!”

이 부분의 내용이 별 거 아닌데 좀 재밌습니다.

– 리뷰 해줄래? – 싫어 / 그래, 해줄께
– 우리 앱 잘 쓰고 있니? – 별로 / 응!

질문을 바꾸고, 그에 따라 사용자에게 받는 피드백을 다르게 가져갑니다.

“별로”를 선택한 사용자에게는 피드백을 줄 수 있겠냐고 묻고, “응!”을 선택한 사용자에게는 그럼, 앱 스토어에 가서 별점 좀 주라고 요청합니다.

심리학 등등을 가져다 여러가지 얘길 할 수 있지만 약간의 트위킹을 통해서 꽤나 괜찮은 결과를 낳을 수 있을 듯 합니다. 평점이 높은 리뷰는 스토어에 남게 되고, 불만이나 개선사항은 메일 등 내부에 보고되는 플로우가 됩니다.

애초에 “별로”라고 선택한 사용자 역시 충성 고객에 한해 해당 질문을 했기 때문에 이런 피드백은 의미 있는 피드백이겠지요.

조금 덧붙여서, 피드백을 받을 때는 네이티브 폼을 이용해서 피드백을 받는 게 사용자 경험상 더 좋을 것 같다는 얘기가 뒤에 이어집니다.

저희가 하는 서비스에서도 이러한 부분들을 잘 적용하면 좋을 것 같아서 간단히 정리해보았습니다.

22. 11월 2015 by yuno815
Categories: 서비스 기획 | Comments