Сегодня интерес к продуктовому анализу и экспертам в сфере продуктового менеджмента растет.

Об этом свидетельствуют исследования рынка продуктового менеджмента от HH.ru и ProductStar: https://orekhovo-zuevo.hh.ru/article/28845 

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

• Данный специалист обладает хорошей экспертизой в области анализа клиентских / пользовательских действий и может рассмотреть product-market fit (идея продукта, которая закрывает потребность рынка и обладает ценностью для потребителя) там, где его не увидят другие сотрудники;

• Он обладает ясным представлением о том, какая информация нужна для построения воронок и CJM (карта пути клиента), или где можно обнаружить боль клиентов;

• Этот сотрудник, как правило, имеет хорошую экспертизу в маркетинге, что определенно точно сокращает количество ситуаций недопонимания с топ-менеджментом.  

Это далеко не полный перечень навыков, но данный список помогает выделить экспертизу продуктового аналитика от других аналитиков.

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

Взглянем на некоторые из проблем, с которыми сейчас сталкиваются большие компании:

• Несогласованная друг с другом работа различных продуктовых команд внутри компании – независимые команды могут повторяться в исследованиях и получать при этом разные результаты;

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

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

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

На этом этапе появляется инсайт: «а почему бы не объединить маркетинговое направление CVM (управление потребительской ценностью или максимизация ценности клиента) с DataLake?» 

Потребность в сочетании новых компетенций

Для правильной реализации здесь отлично подойдут сотрудники, которые понимают, как искать ценность для клиента, и при этом плавают в озерах данных, как рыбы в воде. Таким специалистам потребуется проводить и большое количество коммуникаций с исследованиями внутри компании по разным направлениям, и множество аналитической работы с данными. Они смогут подключаться и к работе продуктологов, особенно с концепцией data-driven, и к работе дата-инженеров при организации хранилищ. Их целью будет поиск ответов на вопросы: на какую информацию имеет смысл сделать упор и какие данные компании принесут прибыль раньше, а какие не принесут ее вовсе? CDO (директор по данным) точно скажет «спасибо», когда результат от нового хранилища компания получит на пару кварталов раньше.  

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

А что на практике?

Рассмотрим одну из актуальных ситуаций. Имеется сайт компании, с которого считываются действия посетителей и складываются JSON-нами в Data Lake. Вряд ли дата-инженеры будут пытаться угадать – в какие таблицы и с каким атрибутами необходимо развернуть данные Яндекс.Метрики. По крайне мере, до момента появления задачи на расчет определенного показателя. А затем появляется потребность в новом показателе или агрегации, и каждый раз доработка витрины или генерация новой со всеми этапами разработки и тестов. Но можно поступить иначе. Почему бы не предоставить эти данные продуктовому аналитику, который владеет Python и NoSQL, и выдать ему Jupyter или Impala.

Проанализировав данные у него будет возможность, как минимум, заранее определить, что для вашего бизнеса время на сайте (ym:s:visitDuration) и глубина просмотра (ym:s:pageViews) – важны. Эти показатели (+20 иных) имеет смысл сразу распарсить в витрину, а другие 50 – не несут важной целесообразности, например: операционная система (ym:s:operatingSystem), потому что это никак не влияет на маркетинг при работе с каналами коммуникаций на связанных этапах. А как максимум, связав данные договоров компании с действиями на сайте, он предоставит вам развернутый CJM (Customer journey map – визуализация пути клиента) или качественную воронку с цифрами и их влиянием на unit-экономику на каждом из этапов.

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

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

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

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

Получится ли улучшить ваш проект?

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

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

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

Заключение

Правильный подход помогает получать от Data Lake максимум, несмотря на трудности, с которыми сталкиваются современные компании при работе с Big Data. Таким образом, аналитики с новым сочетанием компетенций не просто «закидывают» команду хранилища дополнительными задачами, а заменяют этот процесс на «покажите мне, где лежат данные, а я отвечу вам – где лежат деньги».