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

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

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

Что мы хотим отслеживать? Часто в когортный анализ засовывают метрики роста, типа 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/

📌 UX-артефакты в продуктовой аналитике

В дизайне, продакт-менеджменте и маркетинге есть такие популярные инструменты для проектирования пользовательского опыта, как например CJM (Customer Journey Map) и JTBD (Jobs To Be Done).

В общем смысле это методологии для построения хорошего UX твоего продукта.

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

🔵JTBD — это не столько про опыт в плане эмоций, сколько про фокус на задачах и целях, ради которых клиент “нанял” твой продукт. Цель этой методологии — понять что именно мотивирует клиентов приобретать и использовать продукт и какие "работы" они пытаются выполнить с его помощью.

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

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

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

☝️ Кроме того, это хорошее упражнение на развитие продуктового мышления.

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

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

📌 Оконки LEAD и LAG

Любое уважающее себя (но это не точно) техническое интервью обязательно содержит вопрос или задачку про эти функции. Понятия не имею откуда это пошло — не то чтобы это были какие-то сверхпопулярные оконки, скорее даже редкие, но имеем что имеем.

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

Смысл этих функций в притягивании соседа ДО или соседа ПОСЛЕ.

В общем виде выглядит как и любая другая оконка:

lag(some_col) over(partition by some_id order by some_dt)

Т.е. “внутри каждого потока some_id отсортируй строки по some_dt и достань мне предыдущее значение столбца some_col”.

Как и любую другую оконку можно засунуть эту конструкцию прямиком в select, в условие case или where, а при особом желании даже в join можно затянуть.

А что по примерам использования, когда полезно?

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

🟡При осмотре каких-то метрик на текущий момент, чтобы быстро сравнить с предыдущим периодом и показать разницу, растёт или падает. Такое чаще практикуется в репортах, когда нужна одна конкретная цифра “на сейчас” и стрелка вверх-вниз;

🟡При анализе оттока, чтобы быстро посчитать разницу в количестве дней от текущей даты и последней датой активности юзера. Хотя тут и есть более ходовой вариант через max(date), тем не менее юзабельно;

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

#собесы

Спёр в рабочем слаке) Ох, если бы оно всё было так просто 😄

Здраво, я тут чёт выпал на недельку, ну да ладно. Завтра будет кулстори как я учил SQL, работал, как потом понял что вообще нифига не умею на нём писать и как в итоге научился.

А пока гоу накидаем своих рабочих плейлистов 🙂

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

🎧 ностальгический (if u know u know) эмбиент на музыку Кая Розенкранца: https://www.youtube.com/watch?v=dJEngIaeEso&ab_channel=CraftofAmbience

🎧 просто 10 часов дождя с грозой 🙂 https://www.youtube.com/watch?v=l6fyiqeytaA&ab_channel=RainSoundNatural

Если думать не надо, то тут по настроению, разброс большой — от меланхоличных In Extremo и Corvus Corax (тут нужен мем про весьма специфичные вкусы), до драйвовых Talco или Goldfinger ✌️