Саппорт: советы по сбору и передаче данных о багах разработке
Саппорт может стать крайне полезным инструментом в сборе данных, ведь именно техподдержка получает информацию из первых рук, еще до того, как данные дойдут до аналитики.
Published
17.10.2019
|
Екатерина Рогачева

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

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

Несомненно, чем быстрее вы получите информацию о новых проблемах и багах, тем оперативнее вы сможете их устранить. Саппорт может стать крайне полезным инструментом в сборе данных, ведь именно техподдержка получает информацию из первых рук, еще до того, как данные дойдут до аналитики. Итак, из каких ресурсов вы можете получить эти данные?

1. Обращения пользователей

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

  • Позволяйте пользователю выбрать категорию запроса перед отправкой обращения

Присвойте каждой категории свой тэг, который будет добавляться к письму при отправке. По этим тэгам настройте автоматическую сортировку разных типов запросов по отдельным папкам. Это позволит не только разделять разные типы обращений, но и оценивать масштаб проблемы: например, если обычный поток писем по категории “проблемы с соединением” составляет 100 писем в день, то увидев 200-300 обращений -- вы можете предположить, что существует какая-то проблема на сервере.

  • Запрашивайте или автоматически собирайте уточняющую информацию

Когда появляется новая проблема, для ее быстрого решения разработчикам могут понадобиться дополнительные вводные данные. Составьте список данных, которые будут прикрепляться к обращению. Например, ID игрока, название девайса, платформа и ОС устройства, уровень игрока, сервер (если у вас в приложении их несколько) и другая необходимая вам информация. Эти данные можно запросить и вручную, но, во-первых, это добавит лишние шаги во взаимодействие с пользователем, а во-вторых, вам придется тратить на это ценное время. 

2. Ревью в сторах

Разбор ревью позволяет не только влиять на оценку и повышать лояльность игроков к компании, но также собирать данные о багах. Существуют такие баги, которые не дают пользователям зайти в игру, соответственно и написать обращение оттуда они не могут. Зачастую в таких случаях они обращаются за помощью через отзывы в сторах, и очень важно следить за подобными ревью, ведь проблемы такого рода -- критичны. В Appstore и Google Play Store есть возможность следить за отзывами и отвечать на них через админские консоли, однако, в этих консолях ограниченный набор фильтров и не самый удобный интерфейс. На данный момент на рынке существуют различные готовые инструменты работы со сторами, которые упрощают процесс обработки ревью. Мы используем сервис AppFollow -- он предоставляет возможность удобно фильтровать ревью, собирает развернутую аналитику, позволяет тэгировать отзывы и многое другое. Помимо этого он дает возможность настроить синхронизацию со Slack: в отдельный чат будут приходить все ревью по проекту с выбранным вами количеством звезд, что дает вам и команде разработки в любой момент следить за новыми отзывами.

3. Внутриигровые опросы

Для того, чтобы собрать более точный фидбек, вы можете настроить кастомные окна опросов внутри приложения. Они будут показываться на различных этапах взаимодействия пользователя с игрой и предлагать ему оценить тот или иной элемент интерфейса или поделиться мнением о том, что ему понравилось, а что -- нет. Например, вы можете показывать игроку форму-опрос сразу после завершения очередной игровой сессии. Там вы дадите ему возможность по пятибалльной шкале оценить качество соединения, баланс и другие интересующие вас аспекты. В статье про работу с целевой аудиторией я приводила в качестве примера фичу Rate Us, в которую также можно встроить внутриигровой опрос. Заранее продумайте, в каком виде вы будете выгружать собранный фидбек, чтобы его было удобно обрабатывать.

Коммуникация с командой разработки 

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

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

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

Следить за динамикой процента обращений по конкретной категории от общего числа не всегда достаточно. Например, за прошлый релиз к вам обратились 1000 человек, и 10% из них пожаловались на плохое соединение, т.е. 100 человек. А за следующий релиз вы получили 200 обращений, из них уже 20% оказалось жалобами на плохое соединение, т.е. 40 человек. Это значит, что при равном количестве установок за релиз, ситуация с соединением улучшилась, хотя процент обращений по категории возрос. Поэтому следует выбирать категории, процент обращений по которым держится на одном уровне, и сравнивать остальные категории обращений с ними. В качестве ориентиров можно выбрать такие категории как: жалобы на принудительную рекламу, высокие цены, pay to win и т.д.

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

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

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

Read more

About devtodev

devtodev is a full-cycle analytics solution developed by games industry professionals specifically for game developers that helps you convert players into paying users, improve in-game economics, predict churn, revenue and customer lifetime value, as well as analyze and influence user behavior.