Все компании сегодня любят «большие данные», и практически в каждой обязательно будет отдел аналитиков, занимающихся data science. Однако четкое понимание в индустрии о том, кто такой продуктовый аналитик и чем он отличается от data scientist или UX-исследователя, фокусирующихся на количественных методах, нет.

Все чаще встречается деление продуктовых аналитиков, которые:

• ставят цели и метрики, определяют вектор развития продукта
• исследуют природу явлений, выявляют причинно-следственные связи
• строят предсказательные алгоритмы

Например, похожим образом выглядит такая структура в компании Indeed:

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

Качественные против количественных

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

Qualitative before Quantitative: How Qualitative Methods Support Better Data Science

Поэтому в Wirke мы не проводим четкого деления между аналитиками, которые организуют качественные и количественные исследования. Наоборот, на наш взгляд, в небольшой команде (нас около 10 человек) требуется максимально уметь комбинировать эти навыки, применяя количественные методы для развития идей качественного анализа, который зачастую проводится совместно с продукт-менеджером и дизайнером.

Фактически, когда речь идет о проведении исследований, у нас два ожидания от аналитика. Он должен уметь:

1. находить перспективные точки роста продукта
2. валидировать проблему путем ее формулировки и масштабирования

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

1. Находим точки роста продукта

Аналитик – человек, который находит перспективные точки роста продукта за счет масштабирования проблем и задач.

Самый первый этап понимания любой задачи для продуктового аналитика – это определение, к какому классу проблем она принадлежит. Обычно выделяется три вида исследований:

• Поиск проблемы (problem discovery) — когда мы не знаем, какие проблемы существуют у пользователей вне конкретной продуктовой функциональности. Это, как правило, этап интервью.
• Валидация проблемы (problem validation) – когда мы вроде бы знаем, что есть определенные задачи, но мы хотим проверить что они есть у действительно большого числа пользователей. Это этап разнообразных опросов.
• Валидация решения (solution validation) – когда мы проверяем уже конкретные решения, которые придумали или запрототипировали. Этап прототипов или бета-тестирования.

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

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

Распознаем и анализируем разговоры

В Wrike есть подразделение аккаунт-менеджеров (customer success managers), главная задача которых — поддерживать клиентов не с целью продаж, а улучшения их опыта пользования продуктом. Они созваниваются с клиентами по видеосвязи, обсуждают их текущие боли, рассказывают лучшие практики, предлагают ворк-эраунды и сообщают о статусе разработки новых фичей. Все эти разговоры долгое время записывались и практически не использовались продуктовой организацией – пиэмы предпочитали лично общаться с аккаунт-менеджерами, чтобы получить некое общее представление о болях клиентов. Это могло добавлять элемент "испорченного телефона" и не всегда раскрывало контекст, в котором с этой проблемой сталкивался пользователь.

Одним из инициативных проектов продуктовой аналитики стала разработка pipeline, который превращал разговор в понятный текстовый формат. Используя Google Speech API, а также несколько дополнительных моделей для расстановки пунктуации, удалось максимально быстро получить представления о масштабах некоторых проблем и требований к функциональности на основе множества бесед менеджеров с клиентами, а не единичным интервью. Благодаря такому нехитрому источнику удалось осуществлять полномасштабный поиск по ключевым словам, завязанных на некоторую функциональность или проблематику, оценить характер пользователей, требовавших то или иное решение, а также понять контекст в котором это чаще всего всплывало. Сейчас мы также тестируем модель сентиментального анализа, который помогает нам автоматически отлавливать средний уровень удовлетворенности отдельными частями продукта и уведомляет об этом продуктовую команду.

2. Формируем, масштабируем и валидируем гипотезы

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

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

1. Формулировка гипотез – например: «пользователям-админам из определенной когорты важно иметь возможность выставлять счета на основе недельного отчета».
2. Сбор статистики использования – классическая задача аналитики – понять, способны ли цифры ответить на сформулированные выше гипотезы.
3. Сбор обратной связи – проведение исследования посредством маркетинга, рассылок или через внутренние инструменты обратной связи
4. Анализ и валидация результатов – проверка результатов на стат. значимость

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

Сбор обратной связи

Многие компании считают, что после того как они настраивают систему логирования, прикручивают аналитические сервисы вроде Google Analytics к своему продукту, подготовка платформы для проведения аналитики на этом заканчивается. Однако, к сожалению, при таком подходе забывается важнейший элемент – необходимость обратной связи с пользователем, возможности спросить его в нужный момент времени о его задачах и сложностях, перед которыми он сталкивается.

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

Мы используем внутренний инструмент QFF (qualitative feedback form) для формулирования и валидации гипотез и рассматриваем возможные сценарии пользовательского опыта в качестве трехступенчатой пирамиды (product > feature > interaction):

1. Уровень продукта
2. Уровень функциональности
3. Уровень конкретного взаимодействия

Остановимся на каждом из них немного подробнее и покажем, какие метрики мы используем для понимания их проблематики.

1. Уровень продукта

Здесь нам важно понять самые широкие, наиболее кросс-функциональные части воронки пользовательского опыта. Это стремление найти ответы на самые глобальные вопросы, будь то удовлетворенность продуктом в целом или набором функционала для решения какой-то одной задачи (например, согласование отпуска может потребовать взаимодействия функциональности календарей, статусов задач, алгоритмов планирования и т.п.).

Не существуют четко регламентированных метрик, которые необходимо применять в таких ситуациях, всегда есть нюансы. Однако, как правило, на этом уровне абстракции речь идет о метриках NPS (net promoter score) или SUS (system usability scale). Метрики не бесспорные, но, как правило, все же являются стандартами индустрии и помогают ориентироваться для целеполагания в масштабах нескольких кварталов.

2. Уровень функциональности

На этом уровне мы задаем уже более конкретные вопросы, которые касаются непосредственно определенного функционала. Из примера выше — мы можем уже отдельно смотреть не на проблему «согласования отпуска» вообще, а берем только конкретную часть продукта, например, календари. Насколько они удобны для восприятия? Для чего люди ими пользуются?

В зависимости от этапа нашего исследования могут отличаться не только вопросы, но и показатели, которые мы собираем с наших пользователей. Самое простое – уровень удовлетворения, который от задачи к задачи может считываться с помощью разных шкал (три смайлика или Likert scale), CES (customer effort score) — насколько трудно или легко пользователю реализовывать какие-то задачи.

3. Уровень взаимодействия

Задача этого уровня – оценить конкретную итерацию, которую совершил пользователь с продуктом (например, нажал некую кнопку). При этом важно, чтобы результатом этого взаимодействия было некое действие или решение, которое мы не можем замерить или проконтролировать. Как правило, здесь идет речь об уровнях удовлетворенности и принятии неких последующих решений: например, удалось ли менеджеру, смотря в календарь, понять, когда у сотрудника заканчивается отпуск? Подошел ли пользователю формат экспорта данных? Поскольку все дальнейшие действия происходят либо только в голове пользователя, либо за пределами нашего продукта, у нас отсутствует какой-либо иной метод оценки итерации.

Фактически уровень оценки взаимодействия – это попытка оценить метрику CSAT (customer satisfaction), которая часто используется в поддержке и других сервисах, где нужно поставить оценку конкретному событию. При этом, здесь также могут использоваться метрики вроде CES, но в более «локальной» формулировке.

Анализ и валидация результатов

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

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

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

Вместо заключения

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

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

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