Описание. Аналитика продукта — это исследование взаимодействия пользователей с продуктом или сервисом. С помощью этого процесса команды по продукту могут отслеживать и анализировать вовлеченность и действия пользователей, а также представлять эти данные в наглядной форме. Таким образом команды могут улучшать и оптимизировать продукт или сервис.
Как менеджеры по продукту, мы используем любые возможности, чтобы лучше узнать своих клиентов, поскольку понимание их потребностей крайне важно для создания полезных продуктов. Это включает в себя проведение разговоров с клиентами и опросов, а также изучение аналитики продукта. Данные, которые мы получаем из аналитики, говорят о фактическом использовании продукта пользователями. У нас нет сведений о том, что они хотят сделать, или о том, как использование ими продукта выглядит с их или с нашей стороны.
Что касается отличия разработки программного продукта (и в чем строительство жилья могло бы несомненно выиграть) — это применение agile-методологии. Она позволяет нескольким командам быстро реагировать на изменения. Так как же agile‑методология, в основе которой лежат частые и непрерывные поставки, может существовать наряду с долгосрочным планированием проекта в целом? Можно ли создать реалистичный прогноз на длительный период времени, зная, что единственная постоянная — это изменение?
Руководителю продукта важно знать ответы на вопросы вроде «Сколько времени пользователи проводят в продукте каждый день?», «Какие действия они совершают чаще всего?» и «Какие функции наименее востребованы?». Это поможет понять пользователей и определить, как сделать работу с продуктом удобнее. В этой статье я расскажу, что такое аналитика продукта и для чего она нужна; как действительно понять пользователей, чтобы погасить «эмпатический долг»; и как использовать аналитику для разработки новых функций продукта.
Давайте начнем!
Попробуйте Jira Product Discovery бесплатно
Расставляйте приоритеты, ведите совместную работу, предлагайте новые идеи продуктов и добивайтесь результатов.
Что такое аналитика продукта?
Аналитика продукта — это исследование взаимодействия пользователей с продуктом или сервисом. С помощью этого процесса команды по продукту могут отслеживать и анализировать вовлеченность и действия пользователей, а также представлять эти данные в наглядной форме. Таким образом команды могут улучшать и оптимизировать продукт или сервис.
Для получения количественной оценки того, как пользователи работают с продуктом, сначала нужно наладить сбор аналитики. Идея заключается в том, чтобы инициировать событие для каждого действия, которое пользователь может выполнять в продукте. Так вы сможете получить общее представление о том, сколько человек пользуется функцией и как часто это происходит. Например, если вы хотите отследить, сколько раз пользователь нажимает определенную кнопку, можно инициировать событие с именем big-red-button.click («нажатие большой красной кнопки»). Так вы сможете увидеть, какие функции нуждаются в доработке и какие из них наиболее важны. Эту информацию можно использовать для расстановки приоритетов изменений.
Существует множество решений, которые предоставляют платформу для добавления и отслеживания аналитических событий. Начать знакомство можно с Google Analytics или KISSmetrics.
Команда Atlassian постаралась сделать так, чтобы каждый сотрудник мог получать доступ к данным и запускать собственные запросы и отчеты. Для этого мы применяем инструменты собственной разработки, но вы можете начать и с решения Google Analytics. Теперь все участники, от разработчиков до руководителей продуктов и дизайнеров, интересуются использованием и пытаются понять, какое влияние оказывают результаты нашей разработки.
«Долг эмпатии» — новый вид долга
Поговорим о новом термине — «эмпатический долг».
Аналитика в продукте может применяться для погашения эмпатического долга двумя способами: как качественная обратная связь, собранная посредством таких активностей, как проверка концепции и разговоры с клиентами, и как количественные данные, собранные внутри продукта через аналитику продукта и опросы NPS.
Возьмем в качестве примера Confluence. Этот продукт выпущен достаточно давно, однако сбор аналитики крайне ограничен для большинства его функций. Это относится и к дашбоарду, с которого большинство пользователей начинает работу с Confluence. Мы побеседовали с клиентами и собрали отзывы об этой функции, однако у нас не было необходимой аналитики продукта, чтобы получить количественную оценку и эффективно проанализировать использование. У нас было множество вопросов без ответов. Например:
- Насколько интенсивно используется дашбоард? Сколько раз пользователи обращаются к дашбоарду в обычном сеансе работы с Confluence?
- Для чего люди на самом деле используют дашбоард? Для получения всех обновлений? Для получения популярного контента? Для перехода к разделу?
- Какую информацию люди хотят видеть на дашбоарде? Можем ли мы определить лучшие варианты на основе действий, которые люди совершали после посещения дашбоарда?
Нам необходимо было найти ответы на эти довольно серьезные вопросы, прежде чем переходить к изменению одной из наиболее посещаемых страниц в Confluence. Если у вас нет аналитики по продукту или хотя бы по функции, которую вы планируете изменить, вы находитесь в аналогичной ситуации и должны быть очень осторожны при принятии каких бы то ни было решений. Пора погасить этот эмпатический долг!
При тестировании дашбоарда мы узнали, что одним из наиболее частых действий на панели мониторинга был просмотр «избранных страниц». Это было очень важное открытие: поначалу мы не считали это действие необходимым. Отсюда вывод: нужно в первую очередь гасить эмпатический долг. Если в вашем продукте нет аналитики, добавьте ее в первую очередь и начните использовать эти данные при принятии решений по продукту. В противном случае важные решения придется принимать вслепую. И помните: аналитика не лжет! Она показывает конкретные действия пользователей с продуктом, однако можно исследовать имеющиеся данные немного глубже и понять, чего они хотят на самом деле.
Тестирование будущего до его наступления
Кроме того, что аналитика продуктов помогает понять, как пользователи применяют существующие функции, она также полезна для тестирования новых функций и интерфейса. Если вы поставили четкую цель относительно степени использования новой функции, аналитика продукта поможет вам работать согласно старой мантре agile-методологии, которая гласит, что чем быстрее вы провалитесь и перейдете к следующей итерации, тем быстрее достигнете успеха.
Наш рабочий процесс обычно выглядит следующим образом:
- Определяем четкую гипотезу относительно изменения в продукте, например «мы ожидаем, что при увеличении размера поля для комментариев количество комментариев увеличится на 5 %».
- Выполняем самую дешевую реализацию этого изменения и загружаем любые необходимые аналитические события для проверки этой гипотезы.
- Развертываем изменение в подгруппе клиентов для проведения A/B-тестирования.
- Затаив дыхание, ждем результатов.
- Выполняем детальный разбор результатов, прибегая к помощи аналитика при работе над более сложными изменениями, и определяем успешность изменения.
Для дашбоарда мы разработали три очень «категоричные» панели, каждая из которых навязывала свой пример использования и правила поведения. Мы провели их через описанный выше процесс (хотя наша гипотеза была чуть сложнее), и в нашем случае он сработал весьма неплохо. Мы также узнали (иногда на собственном горьком опыте) о существовании нескольких распространенных подводных камней, о которых вам будет интересно узнать, прежде чем вы перейдете к этому способу тестирования новых возможностей.
- Нет ничего хуже, чем дойти до конца эксперимента и понять, что у вас нет нужных событий… Прежде чем начинать эксперимент, попробуйте провести анализ, используя фиктивные данные, и вы быстро обнаружите все пробелы в собираемых данных.
- Разработка гипотезы может занять много времени, но вам нужно убедиться, что она у вас есть и что вы сможете ее доказать или опровергнуть с помощью аналитики продукта, до непосредственного запуска. Анализ фиктивных данных перед выполнением запуска также будет полезен.
- Убедитесь, что тестирование проводится на достаточном количестве пользователей и в течение достаточно длительного периода времени. Убедитесь, что ваши результаты статистически значимы.
- Будьте готовы отбрасывать плохие идеи! Как я уже говорил, нужно тестировать возможности как можно быстрее и дешевле. Быстрый провал — это хорошо.
Просто не забывайте слушать и своих пользователей
Как я уже упоминал выше, знания на основе данных — это здорово, но если полагаться только на данные, порой можно упустить из виду общее восприятие пользователей. Кроме того, полная зависимость от данных может даже навредить, когда приходит время принимать решение, а у вас нет всех необходимых данных.
Аналитика продукта показывает, как люди на самом деле используют продукт или даже конкретную функцию, но такие знания могут быть весьма однобокими. Сочетание сведений, полученных из аналитических данных о продукции, с качественной обратной связью, полученной в ходе разговоров с клиентами, семинаров по тестированию концепции и дебатов, обеспечит более полное представление о происходящем и позволит создать лучший продукт.
