Продуктовая аналитика: принципы, подходы, инструменты

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

Усложнение организмов приводит к появлению у них нервной системы, а развитие компаний приводит их к необходимости внедрения собственной продуктовой аналитики. Отбор компаний на современном рынке идет в том числе по совершенству их «нервной системы».

Достижение целей маловероятно без адекватной картины мира. И чем сложнее внешняя среда тем чаще эта картина мира должна пересматриваться.

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

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

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

Содержание

1. Что такое продуктовая аналитика
   • Продуктовая аналитика и бизнес аналитика
   • Как компании решают проблему данных
   • Проблема с профессиями
   • Будущее создания продуктов
2. 4 принципы культуры продуктовой аналитики
   • Гибкость
   • Автономность
   • Доступность
   • Неопределенность
3. Инструменты продуктовой аналитики
   • Сбор данных
   • Визуализация данных

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

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

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

1. Отличия продуктовой аналитики от бизнес аналитики

Gartner определяет продуктовую аналитику как специализированное приложение бизнес-аналитики для сбора отзывов о продуктах. Это определение — суть проблемы.

Исторически, роль Business Intelligence (бизнес аналитики) состояла в хранении правды об истории компании. Какими были продажи 3 года назад? Каков был операционный бюджет в прошлом месяце? Сколько платящих клиентов у нас на этой неделе? В компромиссе между скоростью и точностью последний всегда побеждал. Анализ может быть пакетным, если он является всеобъемлющим. Ранее не требовалось самому обрабатывать данные, потому что «правдивость» должна была проверяться централизованной командой до предоставления отчетов всем отделам или сотрудникам. Если вам нужно было выполнить какой-то специальный анализ самостоятельно, вы экспортировали данные в мощный Microsoft Excel. Привет, сводные таблицы!

Теперь это устаревший подход для гибкой продуктовой команды в современной культуре «двигайся-быстро-нарушай-правила». Возможность исследовать все данные о поведении пользователей в режиме реального времени может стать для команды конкурентным преимуществом.

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

2. Как большинство компаний решают проблему данных

Компании старшего поколения — технологические компании, созданные во время первого бума доткомов, и все остальные клиентские бизнесы — в значительной степени полагаются на централизованные команды BI, которые сейчас управляют огромными данными и хранилищами с использованием Informatica, Hadoop, BigQuery, Redshift и т.п.

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

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

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

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

3. Проблема с профессиями

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

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

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

Вместо того, чтобы посвятить свое драгоценное время построению будущего, они застряли, помогая всем остальным догнать настоящее.

4. Как выглядит будущее создания продуктов

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

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

Для этого требуется целое поколение инструментов корпоративной аналитики, встроенных в большой стек данных (Redshift, Spark и др.), которые не только готовы к будущему, но и просты в использовании для всех. До сих пор инструменты самообслуживания в продуктовой и маркетинг аналитике изо всех сил пытались выйти за рамки сложных запросов / просмотров страниц для сложных запросов, в результате чего команды были разочарованы. Продуктовый инструментарий по-прежнему являются утомительной работой для больших команд. Будущее будет принадлежать платформе, которая не только мгновенно генерирует понимание, но и использует лучшие в своем классе практики машинного обучения, чтобы помочь командам выяснить, какие вопросы задавать!»

4 принципы культуры продуктовой аналитики

Клемент Кайлоль описывает как они у себя в компании построили культуру принятия решений на основе данных, каких принципов придерживаются, и какие инструменты выбирают. Мне особенно понравился его материал, так как я полностью поддерживаю его взгляд на проблему гибкости Google Analytics и любовь к Google Tag Manager и Amplitude. Далее прямая речь.

«Я начал работать в ManoMano в качестве продакт менеджера в апреле 2018 года, после 4 лет анализа данных в Google, и консультирования ведущих рекламодателей на французском рынке. Недавно я взял на себя инициативу в проекте, направленном на улучшение аналитических возможностей его Feature Team (особой команды, далее — FT).

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

Продуктовая аналитика должна занимать центральное место в технологических компаниях, информируя о дорожных картах продуктов и, наряду с качественными исследованиями пользователей, защищать продакт менеджеров от страшного эффекта HiPPO (на англ. — highest paid person’s opinion, на рус. — мнение самого высокооплачиваемого лица). Но, по моему опыту, это очень похоже на подростковый секс: все о нем говорят, но немногие действительно им занимаются.

Это связано с новизной в этой области и нехваткой опыта среди руководителей.

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

Вопреки тому, что могли бы предположить некоторые читатели, изменение нашего стека инструментов было не решением само по себе, а результатом переосмысленной «культуры работы с данными», вращающейся вокруг четырех принципов, которые мы называем AAAA (Autonomy, Accessibility, Agility and Agnosticity): автономность, доступность, гибкость и неопределенность.

1. Гибкость

Профессионалы, которым приходилось настраивать продуктовую аналитику, знают, что это связано с высокой стоимостью входа, потому что первое, что вам нужно сделать, — это составить план измерений (measurement plan).

План измерений — это документ, который содержит определение ваших KPI (key performance indicators) высокого уровня вместе с событиями и свойствами событий, которые необходимо записать для оценки этих KPI.

Например, вы хотите знать, зависит ли ваш коэффициент конверсии от стоимости доставки.

Чтобы узнать это, вам понадобится записать 5 типов событий:

1. Общее количество посещений вашего сайта — сессий.
2. Количество посещений, с которых начинается воронка продаж -  добавить в корзину.
3. Количество посещений, завершенных на последнем шаге воронки продаж -  транзакции.
4. Количество посещений, завершенных на шаге оформления доставки -  отказ.
5. Стоимость доставки для 3 и 4 пунктов.

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

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

Для такой продуктовой аналитики сбор ВСЕХ данных это не правильный подход. Так как он увеличивает процент шума (неинтересные биты данных) по отношению к сигналу (самые ценные данные) и никогда не обеспечивает удовлетворительный уровень детализации при одновременном замедлении выполнения запросов: анализ данных становится рутиной и избегается, когда это возможно.

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

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

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

Это поднимает вопрос о праве владения: кто несет ответственность за поддержание плана измерений?

2. Автономность

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

1. Это создает зависимость от одной команды и заполняет её backlog — для большинства компаний у «выделенной» группы обычно есть и другие задачи — это приводит к распараллеливанию.
2. Это устанавливает транзакционные отношения между FT и командой продуктовых аналитиков, что может привести к возмущению и плохому понимания проблем бизнеса.
3. Ни один специалист в здравом уме не присоединился бы к такой команде: те, у кого есть опыт, хотят налаживать процессы, а не брать на себя операционную роль. Делегирование таким людям низкоквалифицированных задач приводит к снижению их производительности и текучести кадров.

В ManoMano вместо выделенной группы, право владения принадлежит каждой FT, которая несет ответственность за свое собственное отслеживание в автономном режиме. На уровне FT отслеживание становится частью критериев приемлемости: программное обеспечение должно не только приносить пользу пользователю и быть безошибочным, но также должно быть измеримым с точки зрения дизайна.

Это изменение в праве владения допускает аналогичное изменение в «культуре работы с данными»: успех в разработке продукта определяется заранее и может быть оценен любым желающим.

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

3. Доступность

Доступ к данным по продуктовой аналитике — наш самый важный принцип. Это то, что делает компанию действительно управляемой данными. По какому определению?

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

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

Google, пожалуй, является самой data-driven компанией на Земле. И при оценке я смотрю не на число её докторов наук в области данных, а скорее тот факт, что продовольственная команда стимулируется на основе исследований удовлетворенности. Меню составляются, и ежеквартальные бонусы присуждаются на основе оценок, которые избалованные гуглеры дают своим бесплатным обедам.

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

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

4. Неопределенность

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

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

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

Как вы можете добиться этого распределительно-централизованного оксюморона? Здесь пора рассказать о нашем стеке инструментов.

Инструменты продуктовой аналитики

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

Наша система отслеживания должна была быть централизованной, но редактируемой для всех и под контролем нашего руководящего органа. Она не должна быть зашита в нашем коде, позволяя нам регулярно внедрять гибкие улучшения и гарантировать нашу свободу изменять наш стек в день, который мы выберем. Мы определили два решения: системы управления тегами (Tag Management Systems) и другие сборщики данных, по типу Segment.

1. Сбор данных (Google Tag Manager vs Segment)

В мире продуктовой аналитики появление Segment вызвало некоторый шум. Он кажется вездесущим, и уровень его принятия был высоким в течение последних нескольких лет. Насколько я понимаю (хотя, я никогда не работал с ним напрямую), его главное преимущество — интеграция. Segment собирает данные и распределяет их среди любых сторонних решений, которые вы выберете, без дополнительной разработки на вашей стороне. Это быстро и надежно (опять же, на основании полученных отзывов) и уменьшает количество вызовов javascript на вашем сайте.

<

Однако чем больше мы изучали его плюсы и минусы, тем менее очевидным для нас становилось его принятие. На самом деле, команда инженеров по обработке данных уже настроила SnowPlow для записи логов и внедрила бесплатную версию Google Tag Manager (GTM) для установки маркетинговых тегов. Основные сильные стороны Segment — интеграция и распределение данных — в то время не казались нашим приоритетом.

Системы управления тегами, из которых GTM или Tealium являются наиболее известными вариантами, стали недооцененным решением для организации нашей продуктовой аналитики. Обычно используемые бизнес-командами для реализации рекламных трекеров, они фактически позволяют детально запускать события, включать / выключать управление кодом и имеют интуитивно понятные пользовательские интерфейсы. По своей сути GTM является программным обеспечением для управления кодом: пользователи работают с ветвями (так называемыми рабочими пространствами) и запрашивают у коллег утверждение / публикацию внесенных изменений.

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

В области GTM мы смогли внедрить наш процесс гибкого улучшения с еженедельными итерациями: с понедельника по четверг любой член любой FT может свободно добавлять события в открытую ветку (копируя заранее установленного шаблона и соблюдая строгие правил наименований) ; в пятницу Совет рассматривает ветку и выливает код в мир.

Последним знаком вопроса в нашем стеке было решение для визуализации данных продуктовой аналитики.

2. Визуализация данных (Google Analytics vs Tableau vs Amplitude)

Говорят, старые привычки сложно отмирают, и я могу только согласиться. За последние несколько лет работы в Google мой ответ на любой вопрос аналитики состоял из двух слов: Google Analytics (GA).

Я поддерживаю его, потому что я все еще думаю, что GA — фантастический инструмент для получения реальной оценки стратегии онлайн-маркетинга и улучшения атрибуции. Однако я пришел к выводу, что он не справляется с продуктовой аналитикой, то есть с способностью быстро перемещаться по различным параметрам и легко их визуализировать. Конечно, он позволяет отслеживать события, в комплекте со свойствами события (custom dimensions, custom metrics), но для визуализации этих данных вам часто приходится создавать плоские таблицы и экспортировать их в электронные таблицы, что просто ужасно.

Корпоративная версия Google Analytics 360 делает вид, что решает эту проблему, экспортируя логи веб-сайтов в BigQuery. Но она эффективно утопит вас в море данных, которые будут стоить вам целой команды по анализу данных (вдвое дороже лицензии).

Как указывалось ранее, в ManoMano уже есть структура для сбора детальных данных веб-сайта через SnowPlow. Данные, собранные SnowPlow, уточняются, корректируются и направляются в наше озеро данных, где они доступны нашим конечным пользователям с помощью популярного инструмента визуализации данных — Tableau. Я не буду вникать в Tableau из-за отсутствия реальных знаний, но я знаю, что это тоже невероятный инструмент. Тем не менее, использование Tableau для наших нужд продуктовой аналитики создало зависимость от команд по проектированию и анализу данных, необходимых для создания соответствующих кубов данных. А это противоречило нашему принципу автономии и доступности и было позже отброшено.

Решение, которое мы в итоге выбрали, Amplitude, очень часто встречалось в наших интервью. Наряду с Segment, кажется, что он определяет стандарты продуктовой аналитики, определенно в результате того, что компания-разработчик продукта разрабатывает решение для людей, работающих с продуктами: просто-напросто, без помех, быстро и интуитивно понятно. Хотя мы все еще находимся в процессе освоения его использования и, возможно, испытываем недостаток в некоторой перспективе, он уже произвел на нас впечатление. В основном благодаря своему совместному характеру работы (визуализации могут быть отмечены закладками, ими можно обмениваться и комментировать), что способствует формированию data-driven мышления.

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

Это чрезвычайно простая и соблазнительная идея: это «хлеб с маслом», серебряная пуля руководителя. «У нас проблемы с Y или Z? Ну, это только потому, что нам не хватает чудо-инструмента, который решит все наши проблемы в одно мгновение!» Такое мышление — это способ избежать жесткого, холодного, аналитического взгляда на слабые стороны компании.

Я обнаружил, что стартапы не могут позволить себе роскоши избегать своего отражения в зеркале.

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

У каждой системы есть свои недостатки и слепые зоны. Некоторые читатели могут возразить, что, хотя мы утверждаем, что не зависим от инструментов, на самом деле мы в значительной степени полагаемся на Google Tag Manager — и это было бы справедливо. Мы могли бы также упомянуть, что нашему управлению потребовалось несколько итераций, чтобы понять, что мы взяли на себя слишком много и всё еще должны объяснить, как этот процесс работает внутри компании.

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

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

Связанные материалы >> кто такой менеджер, кто такой предприниматель, кто такой продакт менеджер, продакт менеджмент, проджект менеджмент, регулярный менеджмент, профессиональный менеджмент, тайм менеджмент.