Давайте представим человека, в чьем попечении находится сайт крупного интернет-магазина. Оговоримся сразу – описанные в статье приёмы подходят практически под любые бизнес-сферы: e-commerce, банковскую, недвижимость, СМИ и т.д. Так вот, наш главный герой строит воронки в Google Analytics, знает проблемные места со слабым KPI и вместе с командой постоянно проверяет гипотезы по их улучшению.
С другой стороны, прочитав о том, что Voice of the Customer позволяет отвечать на вопрос «Почему болит?» (в противовес «Где болит?» в аналитике), он стал собирать фидбек от пользователей. Настроил опросы на показ в тех самых проблемных участках воронки, получил и даже разложил обратную связь по категориям.
Но когда дело доходит до непосредственной работы над ошибками, возникают первые сложности. Важно понимать, как на проблемы пользователей смотрят разработчики, когда вы ставите им задачу и перенаправляете расплывчатый отзыв в стиле: «Поиск не работает». Они заходят на сайт, вводят несколько поисковых запросов, не находят никакой ошибки и отправляют тикет обратно с пометкой «Баг не найден».
Чтобы исправить проблему, им нужно чётко понимать, что именно «чинить». Как правило, разработчикам для этого нужно воспроизвести баг собственноручно. А вероятность повторить его вне контекста близится к нулю.
«Сегодня в 20:51 я пытался оформить заказ на робот-пылесос, но при добавлении в корзину мне сначала не дали выбрать адрес доставки по улице Россошанская, д.37 (ошибка «Выбранного дома не существует»), а потом высветилось, что невозможно осуществить самовывоз, поскольку товар отсутствует на складе. Хотя на странице с товаром такой информации не было!» – пример ценного подробного отзыва, ошибку из которого можно сразу же воспроизвести и проверить.
Но в большинстве случаев пользователи напишут: «Переработайте поиск», «Не могу зайти в личный кабинет», «Выскакивает ошибка при вводе кредитной карты», – слишком неоднозначный фидбек. Грандиозно, что они в принципе рассказали о проблемах, но как их теперь интерпретировать?
На самом деле, у протагониста этой статьи уже есть весь необходимый инструментарий, чтобы «расшифровать» проблемы клиентов. Речь о связке фидбека от пользователей и веб-аналитики.
У вас фидбек вяжет
Google Analytics и Яндекс.Метрика присваивают своим клиентам уникальный идентификатор – ClientID. Он анонимен, но позволяет отслеживать действия каждого «носителя» CID на сайте. Это значит, что соединив платформу по работе с фидбеком с системой веб-аналитики, можно с большой вероятностью воспроизвести проблему, о которой пишет пользователь.
Например, если в личном кабинете UX Feedback интегрировать доступы к GA или ЯМ, то к каждому отзыву будет прикрепляться ClientID автора. Это помогает нам «расщеплять» даже самый общий фидбек, быстро исправляя конкретные баги.
Например, в поиске по сайту сети гипермаркетов для дома и дачи. Жалоб было много, но только 10% из них содержали конкретные примеры: «Почему, когда я ввожу весы, мне показываются сваи?» Остальные 90% пользователей оставались непонятыми: «Не работает поиск», «Не могу найти товар».
Связав фидбек с аналитикой, мы получили мощный инструмент. Сначала при помощи ClientID выделили в Google Analytics всех людей, которые писали о проблемах с поиском. После этого создали соответствующий сегмент и в отчете по поисковым запросам увидели, что конкретно пользователи пытались найти на сайте. Дальнейшее – дело техники. Каждый из «проблемных» запросов стало возможно повторить, а значит отправить разработчикам наглядное ТЗ.
Похожий кейс применяется нами с другим клиентом. Например, когда пользователь в недоумении пишет, что цена на сайте отличается от цены в корзине в меньшую сторону.
В таком случае, находим сессию по ClientID и определяем товар, про который пишет пользователь.
Чтобы воспроизвести ошибку, достаточно было самим добавить его в корзину.
Нетипичная связка
Связывать фидбек и веб-аналитику можно и в других ситуациях. Например, вебвизор в Яндекс.Метрике тоже способен показать, что побудило пользователя оставить тот или иной отзыв.
На сайте одного из клиентов мы получили комментарий: «Неудобно находить акции и применять скидки». Найдя по ClientID запись сессии и просмотрев её в вебвизоре, поняли, что пользователи, знающие о конкретной акции, с трудом находят её среди других актуальных предложений.
Другой пример – пользователь оплатил товары, получит их самостоятельно, но недоволен, поскольку для них не существует доставки. Потенциально это приводит к потере клиента, но в данной ситуации нам повезло. При помощи GA определяем регион, из которого был оставлен отзыв.
По списку товаров в заказе определяем, для каких из них до сих пор не была доступна доставка в данном регионе.
Даже самые популярные обычно отзывы для сайтов с большим количеством страниц – о скорости загрузки – можно «препарировать» и протестировать. В таких случаях мы смотрим на устройство, с которого была совершена сессия, а также на список ссылок, которые открывал пользователь.
Это не сложно и космически продуктивно
Таким образом, на стыке Voice of the Customer и систем веб-аналитики рождаются новые инсайты. Даже по самым неоднозначным отзывам можно разобрать, какая именно ошибка произошла у клиента, и до мельчайших деталей её воспроизвести.
Связывая фидбек, GA и Яндекс.Метрику, мы можем получать инсайты:
- из неочевидного фидбека о любой проблеме: «Не получается зайти», «Не нажимается кнопка» и т.д.
- о багах и ошибках, о которых пользователи пишут чуть подробнее
- про недостаток информации: в карточках товаров, в подсказках, при оформлении заказа и т.д.
- о просмотренных пользователем страницах с определенных устройств
- об источниках трафика (при этом проводя опрос о целях посещения сайта): какие из них больше всего привлекают целевую аудиторию
В UX Feedback интеграция с Google Analytics и Яндекс.Метрикой занимает несколько минут, и использование связки становится совершенно несложным. Но при этом даёт практически полное представление о проблемах продукта.
