Продуктовая аналитика — двигатель ̶п̶р̶о̶г̶р̶е̶с̶с̶а̶ бизнеса

Делаете IT-продукт? Тогда вам не обойтись без продуктовой аналитики. Зачем она нужна, какие задачи решает и с помощью каких инструментов, как строится работа шаг за шагом — об этом мы поговорили с продуктовым аналитиком компании Wrike Кириллом Шмидтом.

— Кирилл, чем ты занимаешься и в какой отрасли?

Я продуктовый аналитик в компании Wrike. Занимаюсь анализом эффективности принятия решений при развитии IT-продукта — системы для управления проектами. С помощью нашей системы люди организуют совместную работу и быстрее достигают своих бизнес-целей.

Продуктовая аналитика — это все, что связано с развитием продукта и user experience. Такой вид аналитики нужен всем компаниям, которые хотят улучшить свой продукт.

Моя задача — с помощью аналитики помочь продукт-менеджерам понять, как можно улучшить продукт, поставить задачу, решить ее и впоследствии оценить, насколько мы действительно что-то улучшили.

— Какие виды аналитики, кроме продуктовой, вы еще используете?

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

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

— Как в целом построено взаимодействие продуктовой аналитики и менеджмента в компании?

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

Как проходит наша работа: продукт-менеджер «фонтанирует» идеями и планами. Мы обсуждаем эти идеи, выявляем проблему, выясняем, что именно нужно сделать. После определения задачи мы анализируем данные и рассказываем, что получилось.

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

— Из каких этапов обычно состоит работа над продуктом?

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

Из этой информации мы формулируем продуктовые гипотезы: что является проблемой пользователя и как мы можем ее решить. Затем вместе с командой разработки продумывается техническое решение, дизайнеры готовят макеты, а аналитики придумывают способ, которым можно оценить, что гипотеза ошибочна. Тут я не оговорился, т.к. опровержение идеи — это всегда более сильное доказательство, чем ее подтверждение. Для этого придумываются метрики, которые коррелируют с целевым поведением пользователя. На основании изменений этих метрик в дальнейшем и судят о правильности гипотезы.

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

В зависимости от ситуации мы либо можем проводить оценки в режиме A/B-теста (когда мы показываем новую продуктовую фичу только контрольной группе, а остальным показываем обычный опыт), либо смотреть на проникновение анонсированной фичи и ее применение в аудитории пользователей, либо оценивать обратную связь, либо — долю людей, которые выключили новую фичу.

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

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

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

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

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

— Какие инструменты вы обычно используете?

Я анализирую числа, поэтому работаю в основном с инструментами, которые помогают обрабатывать данные. Это BigQuery, R, Python, Tableau.

Есть бэкэндовые данные — данные, которые описывают взаимодействие с бизнес-логикой системы (что было изменено, что создано, что удалено, какие статусы у задач и т.д.). И есть данные трекинга, которые записывают детали взаимодействия пользователя с интерфейсом (на что кликнул, куда перешел, какой раздел открыл и т.д.). Это все загружается в хранилище данных и затем используется аналитиками, чтобы отвечать на вопросы заинтересованных лиц, строить какие-то модели и собирать аналитику в нужном контексте. Потом предоставить информацию либо с помощью питоновского скрипта, R-скрипта, систем BI, либо в виде презентации в Power Point.

— Какими метриками оперирует продуктовая аналитика?

В продуктовой аналитике используемые метрики зависят от продукта и того, какие цели он перед собой ставит. Wrike — система, которая разбивается на разные модули и фичи. Наша команда пытается оценить эффективность и полезность этих фич для пользователя. Мы пытаемся понять, сколько есть потенциальной аудитории для этой фичи, сколько людей ей реально пользуются. Какое количество попробовали один раз, сколько — несколько раз, сколько пользователей возвращаются к этой фиче регулярно. Другой момент — то, как люди в целом воспринимают продукт. Это мы оцениваем через опросы. А есть такие блоки, как, например, onboarding (этап, когда пользователь только увидел продукт и его надо с ним познакомить). В каком-то смысле он является продолжением маркетинга. Его метрики оценивают, понравился ли человеку наш продукт или нет, купит ли он его в дальнейшем. Так, все используемые метрики оценивают полезность для людей какой-то конкретной фичи.

В продуктовой аналитике нет конкретных ROI или ARPU, как в маркетинге. Мы используем в основном пропорции. Например, сколько людей воспользовались продуктом до его улучшения и сколько после. Или делаем это в рамках A/B-теста — эксперимента, где одной группе пользователей даем новую фичу, а другой группе не даем. Таким образом можно оценить эффект именно от фичи, т.к. эти две группы различаются только наличием либо отсутствием тестируемой фичи.

— Какой совет ты можешь дать тем, кто начинает строить продуктовую аналитику у себя в компании?

Самое ключевое: в аналитике нужно больше работать с проблематикой, а не кидаться сразу считать какие-то цифры. Так как сейчас данных очень много и они доступны, люди часто спешат просто что-то посчитать, не имея при этом конкретной задачи. Они что-нибудь считают, при этом это «что-нибудь» меняется абсолютно случайно и не связано ни с какими изменениями. В итоге получается такая рулетка — что-то сделано, но метрика, которая была выбрана, меняется по своим законам. В 50 % случаев специалисты молодцы, в 50 % — не молодцы, при этом неважно, что они там делали.

1. Понять, какая проблема есть у пользователя.
2. Придумать решение, которое снимает эту проблему.
3. Понять, как мы можем измерить, что проблема решена.
4. Реализовать это решение в режиме A/B-теста (идеальный вариант) либо понять, как мы можем при общей выкатке изолировать эффект новой функциональности от прочих факторов.
5. Подождать требуемое время для оценки эффекта фичи.
6. Оценить результаты внедрения фичи и принять решение о ее дальнейшей разработке.

Например, задача: улучшить user experience в нашем приложении. И здесь вопросам «Что такое user experience?» и «Что значит, улучшить user experience в числах»?" нужно уделить внимание. При этом нужно понимать, что задача улучшить user experience — довольно верхнеуровневая. Если в нее углубиться, можно выделить другие, более специфические. Например, уменьшить отток пользователей или сократить количество негативных отзывов. В итоге решение этих задач и влияет на user experience вашего продукта.