Краткое руководство по анализу данных и проведению продуктовых исследований

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

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

Тут я хочу поделиться порядком действий, если хочешь — чек-листом, как я провожу аналитические исследования.

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

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

Задача на рисёрч обычно прилетает в формате пожеланий заказчика — “У нас есть проблема тут…”, “Мы бы хотели увеличить метрики там…” или “Хочется понять как работает фича N”. Как бы то ни было, скорее всего это не будет вопросом, на который можно однозначно ответить. И уж точно это будет не вопрос, опирающийся на имеющиеся данные.

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

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

Data-driven подразумевает принятие решений на основе данных. Понимание что делать по итогам исследования — это одна из основ data-driven подхода.

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

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

Важно также уточнить, есть ли какие-то ограничения, например исследуемая часть продукта доступна только на iOS или только в определённом гео.

Подытожим — целью этапа общения и погружения является:

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

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

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

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

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

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

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

Я обычно подхожу к майнингу в контексте исследования чуть более комплексно, чем к простому разведывательному анализу (EDA, exploratory data analysis).

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

1. Графики, диаграммы, таблицы

В R для обзорного анализа есть классный инструмент

2. Матрица корреляций

Описание и пример реализации

3. Линейная регрессия

Описание и пример реализации

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

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

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

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

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

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

Кластеризация

Обзор алгоритмов кластеризации

Классификация

Пример реализации Random Forest

SHAP для интерпретации моделей

Интерпретация моеделей с помощью SHAP

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

Самая интересная для заказчика часть — это, конечно, графики. Тут я не буду рассказывать какие графики для каких данных лучше использовать, надеюсь ты и так это понимаешь. Но если интересно погрузиться в эту тему, с удовольствием рекомендую книгу Александра Богачева “Графики, которые убеждают всех”. Она не очень объёмная, но при этом супер информативная.

В конце исследования нужно вернуться к началу — ключевой цели исследования. Зачем мы это делали? Какие ответы получили? Что можно порекомендовать?

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

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

Ещё один немаловажный вопрос — формат отчёта.

Не уверен, существуют ли какие-то стандарты документации исследований, обычно все делают как им удобнее. Кто-то предпочитает оформлять исследование в гугл-документах, кто-то питоновским блокнотом, мне ближе формат PDF. Я предпочитаю писать на R, а для рендера в PDF я использую R Quarto, мне он кажется более удобным, чем дефолтный markdown. Как подружить кириллицу и R Quarto я писал вот тут.

Экспериментируй, формат хорош тогда, когда удобен всем участникам.

В конце может возникнуть вопрос “Так это же база, зачем об этом писать? Разве не все так делают?”

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

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

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