📌 Про группировки пользователей

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

Давай разберёмся и больше не будем путать:

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

2️⃣ Когорты — это группы юзеров, объединённые общим событием в определённый период времени. Время тут ключевой фактор. Когорты могут быть за неделю, за меся, за год, это уже не так важно. Событие тоже не принципиально, это может быть как регистрация, так и первая покупка, например. Но это всегда с акцентом на период времени. Не бывает российской когорты, бывает когорта январская. Хотя никто не запрещает сегментировать когорты, но это уже другое! 🙂

3️⃣ Кластеры — это уже более редкое явление, когда сегменты обзывают кластерами, но всё равно ещё встречается. Так вот, кластер это группа, сформированная в результате анализа, которая строится на основе схожих характеристик или паттернов поведения, но критерии никогда не определены заранее (ты, конечно, знаешь весь список на момент запуска модели, но что там как повлияет всё ещё не понятно).

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

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

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

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