📌 Когортный анализ

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

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

Что мы хотим отслеживать? Часто в когортный анализ засовывают метрики роста, типа MAU, но на практике это применимо, разве что, в маркетинговом анализе. Мы же сейчас поговорим о продуктовом.

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

Давай разберём эту задачу на составные продуктовые шаги:

Первым шагом после установки может быть прохождение онбординга ➡️ Потом схватывание a-ha момента ➡️ Первая оплата ➡️ Последующая оплата.

Успешность этих шагов очень сильно привязана к UX (user experience), который даёт приложение. А именно UX нам и интересен в первую очередь, так как даже незначительные изменения в дизайне могут сильно упростить или усложнить жизнь юзеров.

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

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

Для полноты картины, в список метрик можно добавить продуктовый набор типа retention, ARPU, LTV или среднй чек.

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

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

🍿

https://telegra.ph/Pamyatka-po-SQL-05-15

📌 Откуда удобно заходить в ПА

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

Эта работа не просто про рисование квадратиков. Проект включает в себя много исследовательских моментов — построение всяких CJM / JTBD, персонажей, воронок, карточных сортировок, проведение интервью, построение карт метрик и иногда даже разметку событий и т.д. Такое углубленное изучение UX / экономики проекта.

Многие вещи оттуда отлично вписываются в продуктовую аналитику.

Из каких ещё сфер можно относительно легко зайти в ПА?

🔵Маркетинг (web). Как и проектирование, маркетинг сначала досконально изучает пользователей, их привычки, желания, цели и особенности поведения. А ещё бонусом опыт работы с инструментами веб-аналитики и понимание подкапотного устройства сайта на уровне HTML-CSS-JS.

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

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

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

🔵Ну и, конечно же, смежная аналитика (например, дата-). Хороший набор хардов, аналитическое мышление и умение работать с данными и делать выводы.

И это только то, что на поверхности 🙂

📌 Data Driven vs Data Informed

Мне нравится наблюдать за развитием аналитической культуры на рынке, и очень радует тенденция перехода от Data Driven к Data Informed подходу.

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

🔵Data Driven (DD) — это подход к принятию решений, завязанный исключительно на данные, цифры и результаты исследований. Если ты уверен что решение А будет правильным, но решение Б выглядит лучше на цифрах, то компания принимает решение Б без обсуждений.

🔵Data Informed (DI) — более лояльный подход к идеям, тут данные это просто хорошая точка опоры, но не истина в последней инстанции.

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

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

В геймдеве тот же Ubisoft со своими ассасинами — типичный пример 100%-ного DD. Делаем то, что работает, а инновации оставим господинам Винке и Кодзиме. Не в геймдеве чистый DD (до недавнего времени) это, пожалуй Netflix.

И вот теперь опять прослеживается тенденция переката от DD обратно к DI (что не может не радовать). Но в этот раз не от страха, а от осознания, что кроме цифр есть ещё и эмоции юзеров. Если раньше катили успешный, но не самый этичный тест, не думая, то теперь цифры противопоставляют потенциальной реакции пользователей и работают больше в сторону хорошего UX. Что очень правильно, так как успешный UX в первую очередь формирует привычку и лояльность.

А это самые дорогие метрики в перспективе.

Хотел написать пост про важность софт скилов, но youtube как по запросу вынес видос на тему. И он настолько базовый и в точку, что я даже не вижу смысла как-то ещё его дополнять, в общем, посмотрите лучше его, он прекрасен 🍿

https://youtu.be/OffQFYSI2qQ?si=r1g9pz7ghPM-wqnc

Ля чё нашёл 😃 Я это написал в апреле и забыл запостить сюда. Мои мысли на бесконечную тему универсализации метрик для оценки различных продуктовых фичей. Предлагаю свой вариант решения, с объяснением почему я сделал так и зачем вообще это всё.

Не истина в последней инстанции, но как один из вариантов 🍿

https://habr.com/ru/articles/807585/