Что каждый менеджер продукта должен знать об анализе продукта

Данные, которые мы получаем из аналитики продукта, рассказывают о фактическом использовании продукта пользователями.

Sam Tardif Sam Tardif
Browse topics

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

Что касается отличия разработки программного продукта (и в чем строительство жилья могло бы несомненно выиграть) — это применение agile-методологии. Она позволяет нескольким командам быстро реагировать на изменения. Так как же agile‑методология, в основе которой лежат частые и непрерывные поставки, может существовать наряду с долгосрочным планированием проекта в целом? Можно ли создать реалистичный прогноз на длительный период времени, зная, что единственная постоянная — это изменение?

Для менеджера по продукту ответы на вопросы «Сколько времени пользователи проводят в продукте каждый день?», «Какие действия они выполняют чаще всего?» и «Какие функции используются меньше всего?» невероятно важны: это помогает понять пользователей и найти способы улучшения их опыта. В этой статье я расскажу, что такое аналитика продуктов и почему необходимо ее использовать; как действительно понять пользователей, чтобы погасить «эмпатический долг»; и как использовать аналитику для разработки новых функций продукта.

Давайте начнем!

Введение в аналитику продукта

Для получения количественного понимания того, как пользователи используют продукт, сначала необходимо обеспечить сбор аналитики. Идея заключается в том, чтобы инициировать событие для каждого действия, которое пользователь может выполнять в продукте. Так вы сможете получить общее представление о том, сколько человек использует функцию и как часто. Например, если вы хотите отследить, сколько раз пользователь нажимает определенную кнопку, вы можете инициировать событие с именем «big-red-button.click» («нажатие большой красной кнопки»). Так вы сможете увидеть, какие функции нуждаются в доработке и какие из них наиболее важны. Эту информацию можно использовать при определении приоритетов для изменений. 

Аналитика продукта | Atlassian — тренер по agile
Подсказка

Существует множество решений, которые предоставляют платформу для добавления и отслеживания аналитических событий. Начать знакомство можно с Google Analytics или KISSmetrics.

В Atlassian мы постарались сделать так, чтобы каждый сотрудник мог получать доступ к данным и запускать собственные запросы и отчеты. Для этого мы применяем инструменты собственной разработки, но вы можете начать и с инструментов Google Analytics. В результате все, начиная от разработчиков и заканчивая руководителями проектов и дизайнерами, начали интересоваться использованием и пытаться понять, какое влияние оказывают результаты нашей разработки.

«Долг эмпатии» — новый вид долга

Поговорим о новом термине — «эмпатический долг».

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

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

  • Насколько интенсивно используется дашбоард? Сколько раз пользователи обращаются к дашбоарду в обычном сеансе работы с Confluence?
  • Для чего люди на самом деле используют дашбоард? Для получения всех обновлений? Для получения популярного контента? Для перехода к разделу?
  • Какую информацию люди хотят видеть на дашбоарде? Можем ли мы определить лучшие варианты на основе действий, которые люди совершали после посещения дашбоарда?

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

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

Тестирование будущего до его наступления

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

Наш рабочий процесс обычно выглядит следующим образом:

  • Определяем четкую гипотезу относительно изменения в продукте, например «мы ожидаем, что при увеличении размера поля для комментариев количество комментариев увеличится на 5 %».
  • Выполняем самую дешевую реализацию этого изменения и загружаем любые необходимые аналитические события, чтобы проверить эту гипотезу.
  • Развертываем изменение в подгруппе клиентов для проведения A/B-тестирования.
  • Затаив дыхание, ждем результатов.
  • Выполняем детальный разбор результатов, прибегая к помощи аналитики при работе над более сложными изменениям, и определяем успешность изменения.

Для дашбоарда мы разработали три очень «категоричные» панели, каждая из которых навязывала свой пример использования и правила поведения. Мы провели их через описанный выше процесс (хотя наша гипотеза была чуть сложнее), и в нашем случае он сработал весьма неплохо. Мы также узнали (иногда на собственном горьком опыте) о существовании нескольких распространенных подводных камней, о которых вам будет интересно узнать, прежде чем вы перейдете к этому способу тестирования новых возможностей.

Несколько плохих примеров, которые лучше не повторять
  • Нет ничего хуже, чем дойти до конца эксперимента и понять, что у вас нет нужных событий... Прежде чем запускать эксперимент с фиктивными данными, попробуйте провести анализ, и вы быстро увидите все нестыковки в собираемых данных.
  • Разработка гипотезы может занять много времени, но вам необходимо убедиться, что у вас она есть, и вы сможете ее доказать или опровергнуть с помощью аналитики продукта, до непосредственного запуска. Анализ фиктивных данных перед выполнением запуска также помогает это проверить.
  • Убедитесь, что вы проводите тестирование на достаточном количестве пользователей и в течение достаточно длительного периода времени. Убедитесь, что ваши результаты статистически достоверны.
  • Будьте готовы отбросить плохие идеи! Как я уже говорил, нужно протестировать возможности как можно быстрее и дешевле. Быстрый провал — это хорошо. 

Просто не забывайте слушать и своих пользователей

Как я уже упоминал выше, знания на основе данных — это здорово, но если полагаться только на данные, порой можно не заметить общее восприятие пользователей. Кроме того, полная зависимость от данных может быть несколько вредна, когда приходит время принимать решение, а у вас нет всех необходимых данных.

Agile-аналитика продукта | Atlassian — тренер по agile

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