×Закрыть

Чем занимается продуктовый аналитик: задачи и обязанности

Меня зовут Сергей, я Product Analyst в Wikr Group. До этого занимался аналитикой в компаниях Philip Morris и Genesis, в последней дорос до продуктового аналитика. В мои обязанности входил анализ всех метрик и определение вектора роста. Затем около полугода работал в Luxoft на позиции бизнес-аналитика, занимался построением алгоритмов и микросервисов. Но аутсорсинг мне не был так интересен, как развитие продукта, а потому вскоре я принял оффер от Wikr Group. Сейчас занимаюсь развитием мобильного приложения, которое будет решать проблемы людей в области здоровья.

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

Работа с данными

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

Такой подход — принимать решение в зависимости от полученных данных — называется Data Driven Development. К примеру, есть вопрос: на какую кнопку пользователи будут охотнее кликать — красную или зеленую? При DDD-подходе ответ находят с помощью A/B-тестирования: запускают тест, разделив аудиторию 50 на 50. Половине показывают красную кнопку, половине — зеленую. Если в результате оказывается, что пользователи чаще кликают на вторую, то принимаем решение убрать красную, оставляем только зеленую. Таким образом, мы предпринимаем только оправданные действия и постоянно улучшаем продукт.

Стоит учитывать, что на данном этапе нельзя просто доверять большему значению. Продуктовые аналитики применяют показатель статистической значимости. К примеру, что будет лучше в случае неравномерной разбивки трафика: выборка в 10 пользователей, из которых 2 сделали целевое действие, или выборка в 100 пользователей, из которых 10 сделали целевое? Если опираться только на относительные показатели, то будет ясно, что первая выборка 2/10 лучше. Но на самом деле на текущем этапе нельзя делать выводы, так как конверсия в целевое действие в 20% может быть случайностью.

На больших выборках получаем результаты с большим уровнем статистической значимости. Нормой для принятия решения считается уровень этого показателя > 95%

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

Однажды передо мной как перед руководителем отдела возврата пользователей стояла задача снизить спам-рейт почтовой рассылки. На входе у меня была доставляемость на уровне 80%, спам-рейт — 12-15%. Такой спам-рейт считается чересчур высоким. В результате работы удалось его снизить до 5%, потом стабилизировать на уровне 7% — практически в 2 раза. Чтобы добиться таких показателей, я разобрался в каждой метрике, запускал и тестировал воронки, отключал определенные письма.

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

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

Стратегия действий на основе RFM-анализа (расшифровывается как recency, frequency, monetary)

Основные задачи

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

Исследование. На текущей работе мне доверили создавать продукт с нуля. Моя первая задача заключалась в том, чтобы исследовать рынок, проанализировать конкурентов, решить, на какой рынок выходить в первую очередь. К примеру, стоимость пользователя в Штатах безумно дорогая, а потому для запуска первой версии продукта лучше обратить внимание на страны СНГ, Латинскую Америку, Индию. Трафик в этих странах дешевле, и они больше подходят, чтобы протестировать бета-версию, посмотреть, как она зайдет, куда будут кликать пользователи. Первая версия строится на предположениях и на анализе конкурентов: мы предполагаем, какой функционал будет нужен, а какой нет. Но после тестирования можно от догадок переходить к конкретным показателям.

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

Почему важно строить стратегию на такой длительный срок, а нельзя обойтись несколькими ближайшими месяцами? Прежде всего, это необходимо для выбора технологий разработки. В зависимости от функционала, который предполагается интегрировать на будущих этапах, выбирается платформа и технологический стек. К примеру, сейчас вам кажется подходящим вариантом использовать React Native для создания мобильного приложения, но если это приложение будет тянуть слишком много графических ресурсов, то через полтора года вы просто упретесь в потолок и окажетесь заложниками ситуации. То же самое с базами данных. MySQL — open source и удобное решение. Но если вы планируете хранить данные действий сотен тысяч пользователей, строить нейронные сети, то через 3-4 месяца придется все переделывать с нуля. А потому лучше все продумывать заранее и сразу предусмотреть, до каких масштабов будет разрастаться ваша аудитория.

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

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

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

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

Улучшение продукта. После первого релиза приходит очередь постоянной работы над тем, как улучшить продукт. A/B-тестирование, построение отчетности, аналитика — и становится понятно, что именно следует изменить или доработать. С первого раза хороший продукт не получится :) Сначала выпускают сервис с базовым функционалом, затем дорабатывают core-фичи и добавляют новые. К примеру, что первично для сайта знакомств? Анкеты, чат. И только потом приходит очередь дополнительных сервисов — системы виртуальных/реальных подарков и т. д. На вопрос, что и в каком порядке реализовывать, отвечает продуктовый аналитик.

Решения по улучшению продукта принимаются на основании «выхлопа» от нового функционала и потраченного на его реализацию времени. Можно применить показатель ROI — отношение ожидаемого прироста выручки к затраченному времени разработки. Сервис с наивысшим показателем имплементируется в первую очередь.

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

Главное — заранее видеть путь, куда вы идете: что будет интегрироваться на каждой фазе разработки. Вместе с тем, постоянные тесты корректируют первоначальный план: может, какое-то поведение пользователей на фазе № 2 просто отменит запуск фазы № 7.

Рабочие инструменты

Я работаю с Tableau — это инструмент анализа и визуализации данных. Он удобен для построения статистической отчетности — например, чтобы посмотреть, какой возврат имеем сегодня, как окупается маркетинг. Сервис позволяет строить воронки конверсии пользователей в определенные этапы: лендинг → регистрация → подписка на триальную версию → оплата → повторная оплата и т. д. Все показатели воронки относительные.

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

Для ресерча иногда использую SimilarWeb — этот сервис предоставляет небольшой срез по аудитории, который экстраполируется на всю выборку. Инструмент позволяет посмотреть, где в данный момент активны конкуренты, куда они сейчас пытаются выйти, каким объемом аудитории располагают. Эта информация помогает задать собственный вектор развития.

Портрет хорошего аналитика

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

Внимание к деталям. Вы должны быть на «ты» с данными, понимать, какие показатели откуда берутся. Это позволит не допускать ошибок или максимально быстро их выявлять. К примеру, мне однажды удалось по источникам трафика найти читера на нашем продукте: обнаружил, что 90% регистраций шли с одного IP-адреса. Оказалось, что наши партнеры нас обманывали. Внимание к деталям позволило на второй день идентифицировать сбой в системе, что сохранило в перспективе десятки тысяч долларов компании.

Стратегическое мышление. Нужно уметь смотреть на весь проект «с высоты». Лично мне добиться этого помогла аналитика и компьютерные науки.

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

Хорошие коммуникационные способности. Каждую идею нужно «продать» как пользователю, так и своей команде.

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

Открытость. Никогда не думайте, что вы знаете пользователей. Они совершенно другие!

Карьерные пути

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

Продуктовые аналитики растут из аналитиков, маркетологов, специалистов по закупке трафика, менеджеров. Желательно иметь базовые знания математики и статистики, уметь работать с аналитическими инструментами. Будет плюсом знание SQL.

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

Из интересных ресурсов я могу посоветовать:

  • PythonProgramming.net — отличный бесплатный ресурс, где затрагивают актуальные темы машинного обучения, статистики и базовой работы с Python.
  • Канал дейтинга Badoo — тут можно найти интересные лекции по продуктовой и почтовой аналитике, в частности Андрея Саса.
  • ФКН ВШЭ — школа компьютерных наук «Яндекса».

Из оффлайн: Genesis IT school — хорошая площадка для старта, где можно узнать о всех гранях большого бизнеса. Я там делаю доклады по возврату пользователей и почтовой рассылке.

LinkedIn

14 комментариев

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

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

На текущий момент у нас есть продуктовый дизайнер, с которым мы вместе принимаем решения в области дизайна.
По сути, я как продукт аналист даю базовый функционал который нам нужен в первом релизе, что бы продукт был полноценным, и пользователь мог удовлетворять с ним базовые потребности, но в перспективе я определяю функционал который будет интегрирован в фазе 1, 2, ... «Х».
Весь функционал, обсуждается с продакт дизайнером, и он заранее строит полную картинку приложения, что бы для внедрения функционала в фазе 3, ему не пришлось полностью перерабатывать интерфейс. То есть все элементы предусмотрены, но они станут видимы только после фазы «Х».
Список задач, приоритетных для разработки тоже строю я, высчитываю по формуле, которая описана в статье, но зачастую первыми идут те задачи, без которых невозможно запустить продукт. Важно запускать продукт как можно раньше, собирать данные и постепенно внедрять более крутой функционал.
Лиды проводят оценки задач, сколько займет по времени, проводят консультации, и вносят правки в схему данных. Вместе мы также принимаем решение, что функционал Х может и крутой, но очень трудоемкий, мы выкатываем более простую версию функционала, но наперед продумываем архитектуру так, что бы после вернуться к этому вопросу и безболезненно интегрировать полное решение. Тут технические лиды выступают в роли мощнейшей экспертизы.
Передо мной, как перед продуктовым аналитиком стоит задача наиболее быстрого запуска продукта, и дальнейшего его развития. И скажу честно, четких дедлайнов мне не ставили, это мое собственное желание — создать лучший продукт в своей нише.

Как удалось завоевать такое доверие?
Все описанные скилы я развивал долгое время, начиная от первого опыта в компании Кока Кола, и заканчивая генезисом. Когда пришел в WikrGroup я очень много вкалывал. Но не потому, что кто то стоял с палкой надо мной (мой руководитель гнал меня домой), а потому что это безумно интересно, изменять большой продукт, копать в данных, и давать рекомендации. За первые 2-4 недели (на позиции дата аналитика) я построил базовый репортинг, разобрался с ETL, научился работать с AWS (Redshift), выгребать любые срезы данных с Google Analytics и Facebook api. Далее проявил инициативу, раскопал несколько новых ключевых метрик, которые помогли компании, провели АВ тест.
После мне поступило предложение (через 2 месяца работы на позиции дата аналитика перейти в продакты нового продукта, новой ветки в компании), и я согласился. Как показывает предыдущий опыт — если предлагают развитие, без длительных раздумий соглашайся (тем более у меня была уже большая экспертиза в подобных вопросах), и довольно разносторонний опыт. Наверное это и сыграло. В отличии от аутсорса, продуктовые компании — компании в которых приветствуется инициатива и развитие людей, и именно в таких компаниях как WirkGroup можно при желании очень быстро вырасти.

Ух, энергия и энтузиазм аж зашкаливает. Так держать!!!

Спасибо! Буду стараться!

по сути, выполняя обязанности продакт-аналиста, вы еще и тянете на себе функции продакт-оунера

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

Елена, добрый день!
Спасибо за вопрос!
При создании текущего продукта, мы выходили из концепции того, что в корне должен быть именно базовый функционал, без которого продукт просто не сможет существовать, плюс мы должны понимать, на сколько рынок занят на текущий момент, и что мы сможем делать на этом рынке.
Условно если рынок занят только на 20 %, то достаточно просто вовлечь остальные 80 % этого рынка, проинформировать их, провести коммуникацию через рекламу.
Если же выходить на рынок. на котором уже ведутся жесткие баталии за каждого пользователя, то однозначно просто анализом конкурентов тут не обойтись.

Вы не поверите, но приложения, которые не имеют никакой инновационности, или какой то ключевой фичи взрывает и захватывают рынок только потому, что грамотно производят процесс закупки трафика , и только после, на этом скелете растет доп функционал.
Так планировали делать и мы:
— выделили основной функционал;
— определились с источниками трафика;
— выбрали рынок на который идем в первую очередь для тестов (там где можно сделать это дешево и безболезненно);
— запускаем продукт под этот рынок.
В процессе создания продукта, мы понимаем, какие данные нам нужны от пользователя, и начинаем строить архитектуру методов, которыми мы будем мотивировать пользователя отдавать нам данные, а если пользователь инвестирует свое время в Ваш продукт, банально отдавая данные, это вовлекает его , и ему уже сложнее слезть. А если у Вас получилось вовлечь пользователя в этот процесс каким то образом, это говорит о том, что Вы уже нашли свою ключевую фичу. Главное иметь четко прописанный план на 6-12 месяцев вперед (у меня уже построен план на полтора года, и различные ответвления изменения продукта, если наступит определенное событие Х).

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

По поводу данных, которые я использовал:
1. Similar Web — аналог Nielsen для торговли. Тут я увидел позицию каждого из конкурентов на конкретном рынке, возврат пользователей по индустрии, сравнительный анализ нескольких конкурентов.
2. Внутренние данные нашей компании (стоимость привлечения пользователей на этом рынке). Наша компания представлена по всему миру, и я просто не хотел изобретать велосипед, и врываться на те рынки, где нет сильной позиции компании WirkGroup. Следовательно первые тесты мы проведем «малой кровью», делая то, что мы уже умеем хорошо делать, минимизируя при этом все риски для компании в целом.
3. Исследования в различных областях, даже не связанные с продуктом. Широкий кругозор позволяет внедрять в подобные продукты именно те фишки, которых нет у конкурентов (некоторые крутые штуки позаимствовал с pythonprogramming.net). Главное придумать как Вы это будете применять.

По поводу литературы, я считаю, что нет универсальной книги для частного решения. А закапываясь в сотни страниц чужих мнений, Вы теряете свое виденье, и есть большая вероятность допустить ошибку. Если читать литературу, то только техническую. Полезно знать, какими возможностями обладает то или иное решение. Это поможет выжать по максимуму из определенной технологии, и не наламать дров в будущем. Я бы советовал посмотреть продуктовых аналитиков с Badoo , Wargaming, Yandex, но опять таки нельзя в тупую копировать все. Если, что — пишите )) буду рад помочь. Но опять таки, это мое виденье.

Супер! Спасибо большое за столь подробный и развернутый ответ. Добавилась к Вам в FB, так что будем на связи. :-)

очень интересно, спасибо что делитесь информацией!

Спасибо! Интересная и полезная статья! А как по Вашему, где лежит грань между Product Manager и Product Analyst?

Привет! Спасибо большое за отзыв!
Я бы сказал, что poduct analyst некий симбиоз product manager и product owner. Но продуктовый аналитики имеет несколько больший сдвиг именно в сторону дата аналитики. Построение воронок взаимодействия пользователей с продуктом, нахождение слабых мест в воронке и принятие решений на основании полученных данных в сторону оптимизации воронки. Лично я активно беру участие в составлении архитектуры самого приложения. Определяю и обсуждаю с дев командой схему данных для проведения АВ тестов, и в будущем буду знать как проект работает даже изнутри, в каком направлении движутся данные, и каких данных нам не хватает для принятия того или иного решения. Так что грань наверное лежит там, где продуктовый аналитик врывается со своими запросами не только в имплементацию ключевых фич продукта, но и в архитектуру самого приложения, когда ты понимаешь, что через пол года будем запускать тест Х, и для этого теста не придется перестраивать всю систему. Опять таки, продуктовый аналитик с данными на ты, и если имеется отклонение в значении, он знает, чем это вызвано, если параллельно крутится 10-15 тестов.

Накоментили на еще одну статью, Сергей. Спасибо.

Дякую, цікава стаття! Не думав що Продакт аналітик повинен бути настільки технічним..Пітон, Р, сіквел-нормальний такий джентльменский набір..

Дякую! З приводу технічних навичок — це мій особистий підхід який поки що ні разу не підводив, і я дійсно використовую це в роботі. Данний стек технологій дозволяє набагато оперативніше реагувати на зміни, особливо на ранніх стадіях розвитку продукту, коли умовно аналітики дуже завантажені іншими задачами. Ну і знову ж таки — «плавати в цифрах» дуже корисно.
У гарного продуктового аналітика завжди є відповідь на будь які відхилення від норми, (різке зростання чи спад). Без технічних навичок знайти цю відповідь буде дещо складно.

Подписаться на комментарии