In-App-Review. Фильтруем негативные отзывы

Ни для кого не секрет, что, если пользователю не нравится ваше приложение — он с большой вероятностью оставит негативный отзыв. Но если его все устраивает — далеко не факт, что он захочет тратить время, чтобы поставить оценку в маркете.  

В результате итоговый рейтинг приложения может быть намного ниже, чем реальное впечатление пользователя.  

Google предложил свое решение этой проблемы – упростить сценарий выставления оценки при помощи In-App-Review.  

Мы в Кошельке поставили перед собой задачу – увеличить количество положительных оценок приложения, используя новое API. Для этого мы изучили его, интегрировали в свой продукт и провели ряд показательных тестов в попытках найти лучшее решение. Результаты нас порадовали. Если заинтересовались – прошу под кат. 

Пара слов об интеграции 

Ключевая особенность In-App-Review заключается в том, что пользователю не нужно покидать приложение и переходить в маркет, чтобы оценить его. Все, что ему надо сделать – это выбрать нужное количество звезд в появившемся на экране диалоге, и вуаля – оценка поставлена, юзер и разработчик счастливы! 

В документации процесс интеграции описан довольно неплохо. Все делается элементарно, и копипастить инфу сюда нет смысла. Однако реальность сурова, и даже при интеграции такого, казалось бы, простого API можно столкнуться с некоторыми неприятными моментами:

1. Диалог с оценкой появляется только на сборке, загруженной из Play Market. Не стоит об этом забывать и рвать на себе волосы в попытке понять, почему же диалога нет; 

2. Из первого пункта вытекает вопрос: а как тестировать? Этот вопрос также довольно неплохо описан в доке, к нему мы вернемся чуть позже; 

3. Разработчик никак не может узнать, был диалог показан или нет. API In-App-Review предоставляет колбэки, но информации, полученной от них, недостаточно, чтобы понять, увидел ли пользователь рейтинговалку. 

Что не так с колбэками? 

Для того, чтобы отобразилось окно с выбором оценки, в коде необходимо сделать две операции: 

1. Вызов метода requestReviewFlow 

   

   После выполнения запроса в случае успеха мы получим объект ReviewInfo, необходимый для отображения диалога, а в случае неудачи – ошибку.  

   Почему операция может завершиться неудачно? К примеру, если ваше приложение запущено на устройстве Huawei без Play-сервисов, то получение объекта ReviewInfo завершится с ошибкой, и вы сможете в этом случае перенаправить пользователя в AppGallery.

2. Непосредственно запуск рейтинговалки – вызов метода launchReviewFlow

   

   На этот метод также можно навесить колбэк, но узнать результат запуска диалога не получится. Все, что вы узнаете — что процесс In-App-Review завершен. Поставил пользователь оценку или нет, оставил ли он отзыв, увидел ли он вообще соответствующее окно с возможностью оценить приложение – тайна, покрытая мраком. 

   С этим нам пришлось просто смириться. Перенаправить пользователя в Play Market, если он не увидел диалог, или хотя бы собрать соответствующую аналитику, не получится. 

И чуть-чуть о тестировании 

Как уже было сказано выше, протестировать появление диалога можно лишь на сборке из Play Market. Чтобы это сделать, Google предлагает два способа: 

1. Internal test track: создаем тестовую версию в Play Console, загружаем туда apk-файл с реализацией API, затем формируем список тестировщиков, которым эта версия будет доступна для скачивания. После этого ждем, пока версия будет доступна для скачивания в Play Market; 

2. Internal app sharing: это что-то вроде тестового полигона, который позволяет сделать то же самое, что и способ, описанный выше, но при этом пропустить некоторые шаги, которые занимают много времени (тем самым освободив разработчиков и тестировщиков от необходимости дожидаться доступности сборки для скачивания). 

Сначала мы использовали второй способ. Он оказался довольно удобным, но с его помощью не получилось отправить отзыв – кнопка выставления рейтинга в этом случае была неактивна. Об этом также сказано в документации. По этой причине мы решили обратить внимание на первый способ.  

Отправили сборку в Play Market и стали ждать, пока новая версия будет доступна для скачивания. И вот, спустя несколько часов, мы увидели долгожданный диалог: 

Note: если в процессе тестирования вы обнаружите, что выполнили необходимые условия, а диалог не появился, дело может быть в Quotas. В In-App-Review имеются некоторые ограничения на частоту показа диалога и, возможно, ещё не прошло достаточно времени с момента последнего его появления.  

Вперед к экспериментам!

Теперь, когда стало ясно, как работает In-App-Review API, и учтены все нюансы, возникают логичные вопросы: что, если пользователь будет раздражен появившимся диалогом и решит поставить неудовлетворительную оценку? Или он ещё не успел достаточно времени провести в приложении, чтобы его оценить? 

В обоих случаях, вероятнее всего, пользователь решит поставить не более одной звезды. 

Вспомним главную задачу, которую мы перед собой ставили: увеличить количество положительных оценок приложения.  

Известно, что в подобных ситуациях многие разработчики идут на хитрость: процесс выставления оценки пользователем предваряется собственным диалогом с вопросом, нравится ли ему приложение. Если ответ положительный, юзер «допускается» к оцениванию продукта.

Документация In-App-Review четко говорит о том, что не стоит задавать пользователю вопросов, прямо касающихся его мнения о приложении. 

Мы решили провести ряд своих экспериментов в поисках ответа на вопрос: «Стоит ли спрашивать мнение пользователя перед отображением диалога оценки приложения?». 

Стартовая площадка

Перед тем, как мы запустили эксперименты, процесс сбора оценок был таким: 

1. Если пользователь провёл в приложении 14 дней или больше, мы показываем ему собственный pop-up Кошелька. 

2. Если в нашем диалоге пользователь поставил оценку 4 или 5, отправляем его в Play Market. 

В последние месяцы это давало следующие результаты: 

·      Среднее количество оценок в месяц: 8 тыс.; 

·      Среднее количество отзывов в месяц: 2.1 тыс.; 

·      Средняя оценка: 4,54. 

Для удобства дальше этот вариант будем называть control.

Эксперимент #1: с предварительным диалогом

В первом эксперименте мы решили поступить, как все, и злостно нарушили гайдлайны Google – оставили собственный диалог, в котором предлагали пользователю поставить оценку, и, если он выбрал 4 или 5 звезд, мы запускали процесс оценки с помощью In-App-Review.  

Назовем этот вариант «in-app-review».

Мы выкатили версию приложения с этим методом оценки на 2 месяца, и вот что получилось: 

• Среднее количество оценок в месяц увеличилось на 60% – с 8000 до 12800; 

• Средняя оценка увеличилась с 4,54 до 4,67; 

• Среднее количество отзывов немного снизилось – было 2100, а стало 2000. 

Процент пользователей, поставивших 5 звезд, увеличился с 80% до 84,9%. 

Общее распределение выглядит так: 

Этот вариант эксперимента положительно сказался практически на всех метриках. Слегка снизилось количество отзывов, но при этом заметно выросло количество оценок и общий рейтинг приложения.  

Вывод: от варианта control отказываемся в любом случае и проводим следующий эксперимент.

Эксперимент #2: без предварительного диалога

После проведения первого эксперимента мы набрались смелости, чтобы отказаться от фильтра плохих отзывов показа собственного диалога, и сразу запускать In-App-Review, как того требуют гайдлайны. 

Этот вариант назовем “only-in-app-review”.

 

Все ожидали, что количество оценок увеличится, но общий рейтинг значительно снизится. Тем не менее, мы решили рискнуть, и вот что получилось:

• Количество оценок в месяц выросло на 143% по сравнению с вариантом control и на 52% по сравнению с первым экспериментом; 

• Средняя оценка совсем немного упала по сравнению с первым экспериментом, но все равно осталась выше, чем в контрольном варианте; 

• Количество отзывов практически не изменилось. 

Процент пользователей, поставивших 5 звезд, выше, чем в контрольном варианте, но немного ниже, чем в предыдущем эксперименте. 

Вопреки нашим ожиданиям средняя оценка в последнем эксперименте практически не упала по сравнению с предыдущим, а если сравнивать с контрольным вариантом, то она даже выросла.  

Это было открытием для нас, так как казалось очевидным, что пользователи будут ставить куда больше негативных оценок, если дать им возможность сделать это напрямую. 

Вместо вывода

Перед проведением данных экспериментов мы были уверены, что Google необоснованно советует воздержаться от показа собственных диалогов пользователю с целью определить, нравится ли тому приложение — но результаты показали, что имеет смысл прислушаться к их совету. Вместо того, чтобы хитрить, достаточно подобрать удачный момент для запроса оценки и никакие «фильтры» не понадобятся. 

Средняя оценка в эксперименте с предварительным показом диалога составила 4.67, без показа – 4.63. Количество оценок в первом случае составило почти 13 тыс., во втором — 20 тыс. В итоге в качестве рабочего варианта мы решили выбрать вариант only-in-app-review по трём основным причинам: 

1. Средние оценки в двух вариантах эксперимента практически не отличаются; 

2. Этот вариант полностью соответствует гайдлайнам, описанным в документации; 

3. Количество оценок значительно увеличилось. 

На данный момент мы также берем во внимание, что какое-то из будущих обновлений приложения может оказаться неудачным. Тогда из-за отсутствия предварительного диалога может посыпаться шквал негативных отзывов. Поэтому на такой случай мы оставили возможность заново включить первый вариант эксперимента. 

Если что-то такое произойдет, мы обязательно дополним статью, чтобы вы знали, стоит ли сделать собственный диалог хотя бы для подстраховки.