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