Я твой продукт анализировал

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

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

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

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

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

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

Очень прикольный тред про поиск работы. Как кастомизировать своё резюме под ATS и значительно увеличить колличество откликов.

https://twitter.com/venus_in_moss/status/1785239928378441930?t=12AKm8lj5etTqaWsqBv9Yg&s=19

Это буквально любой DS-отдел, с которым я работал 🙂

Ну мы или не мы?

📌 Про лучший онбординг

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

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

Итак, первое что там было из необычного — план и расписание. Обычно у тебя просто есть пара задач на испыталку, но чаще ничего нет, вкатываешься по ситуации.

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

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

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

Тут же объяснял нам внутреннюю терминологию и систему метрик, что важнее и за чем нужно следить.

В закрепление он закидывал нам “домашки” в виде не душных статеек и видосов, чтобы мы больше прониклись внутрянкой. Загрузка была часа по 2-3 в день, но так и было задумано.

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

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

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

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

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

Параллельно, в течение всего процесса были синхро с HR-ом команды, где ты рассказывал всё ли тебе понятно и всё ли нравится.

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

После этой мини-практики нас уже отдали в наши продуктовые команды.

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

#кулстори

📌 Условия case в конструкциях join

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

Представь ситуацию — у тебя в БД есть таблица заказов, где каждый заказ связан либо с id залогиненного пользователя, либо с его id гостя. Нам надо объединить данные о заказах с информацией о клиентах, выбирая тип клиента в зависимости от наличия информации о пользователе. Например, нужно имя юзера, но если он не был залогинен в текущей сессии, то ищем его имя по его гостевому id:

🔵orders — таблица заказов с полями order_id, customer_id и guest_id
🔵customers — таблица клиентов с полями customer_id и name

select o.order_id,
       c.name
from orders o
  left join customers c on c.customer_id = 
       case when o.customer_id is not null then o.customer_id
            else o.guest_id end

#сниппеты

📌 Про мой худший онбординг

“Если в первую неделю вам кажется что работа говно — вам не кажется”.

Кулстори про худший онбординг, который я застал в своей практике.

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

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

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

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

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

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

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

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

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

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

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

В итоге за первый месяц я научил своего ментора как устроены данные в ML, почему user_id у него и у меня это вообще разное, сопроводив скриптом на сотню строк как их стандартизировать, как получить нужный массив из json’а который нужно собрать из строки и ещё кучу всяких таких нюансов. Он посидел, поофигевал от того что как-то чёта всё сложнее чем ему казалось, но мне уже было всё равно 🙂 я допинал месяц и пулей оттуда свалил.

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

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

#кулстори

На улице днём было +29, жарили шашлыки в парке. Как у вас выходные проходят?)

📌 Идеи и гипотезы

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

А иногда наоборот, сидишь с дизайнером или продактом, обсуждаешь какое-то исследование и они сами собой возникают. Как так то?

А дело было в неправильном понимании терминологии.

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

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

Задачей аналитика является генерация именно гипотез. Генерация идей это что-то про менеджмент продукта.

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

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

Так что, если ты вообще не творческий, не бойся строки в вакансии об “умении генерировать идеи”, скорее всего там про гипотезы.

Прикольный эксперимент. Чел создал супер резюме прогера джуна и хотел посмотреть конверсии в отклик и оффер. Но что-то пошло не по плану.

С одной стороны, статистика грустная, с другой — по словам HR-ов из комментов — олимпиадники склоны к оверинжинирингу и сложно переобучаемы. Для многих нанимающих такой джун — это ходячий редфлаг 🚩

В твиттере наткнулся на видос, у которого незаслуженно мало лайков.

Если ты рассылаешь резюме для поиска работы, то обязательно посмотри. База по найму глазами рекрутера — про 6 секунд на резюме, почему навыки должны быть сверху и т.д. Можно вынести какие-то идеи по доработке своего резюме, чтобы успешнее проходить HR-отбор.

Они обсуждают в контексте рынка США, но глобально работа HR не особо сильно меняется от региона к региону.

https://youtu.be/fEZaI7b6fi4?si=YQg0ccRE90hMhRcO

📌 Алгоритм цепей Маркова

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

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

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

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

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

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

Перейдём к реализации. Тут всё просто:

1️⃣ Клонируем себе репозиторий.

2️⃣ Готовим данные в строгом соответствии с гайдом: первая колонка — ID юзера, вторая — название узла цепочки (например, событие или название посещённой страницы), последняя — время в цифровом формате. Названия колонок удаляем, сохраняем файл в worklist.csv.

3️⃣ Пропускаем таблицу через python-скрипт, запускаем, получаем на выходе файл Graph.gexf.

4️⃣ Открываем файл через Gephi, и там уже настраиваем оформление.

#инструменты

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

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

Тем временем, наши американские коллеги занимаются действительно важными исследованиями 🙂

https://naked-science.ru/article/medicine/vypivayushhie-vmeste-supr

📌 Сомнительные рабочие практики

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

Прокомментирую со своей стороны:

🔵Переработки. Абсолютное зло, тут даже что-то обсуждать странно. С огромной натяжкой это может быть ок, если это заранее оговорённая разовая история с доплатой ради какого-то великого (не для тебя, конечно) дела. Но не вот эти ежедневные, потому что надо было вчера. Горят сроки, сгори и ты 😄

🔵Активность в слаке вне рабочее время. В том же твиттере часто бомбят потому что “начальник написал мне в 9 вечера!”. Ну написал и написал, может он только что вспомнил и отправил чтобы не забыть, подумаешь. А вот если ты считаешь что это не ждёт до утра, или, что ещё хуже — он так считает — это уже звоночек.

🔵Созвоны по любым вопросам. Активность чуть более чем бесполезная и должна умереть вообще. Одно дело, когда вопрос объёмный и важный, есть протокол, и по итогам это выливается в какие-то артефакты, типа задач или документации. Совсем другое когда это созвон ради созвона, особенно если разбирается 1-2 вопроса, которые нужно просто прояснить. А если по итогу ничего нигде не документируется, можно считать вы просто прожгли время нескольких человек.

🔵Дейлики. Спорная тема, причём чем дольше работаешь, тем больше переходишь в лагерь “оно ненужное”. Полно статей по тайм-менеджменту, и ни в одной никто всерьёз не пытается защищать дейли. Они создавались как 15-ти минутные синхро внутри команды с общей задачей, но переросли в какой-то мутный мит, где половина присутствующих никак не задействована в задаче другой половины. Часовые дейли, на котором одновременно присутствует и бэк и дизайн обожаю всей душой. Они оправданы только в случае когда у вас кроме этого инструмента синхронизации больше ничего нет. Если есть хотя бы слак и джира, то я не вижу ни одной причины оставлять их. Совсем другое дело это викли, раз в неделю. Вот тут смысл уже есть, но он немного в другом 🙂

📌 Метрика Retention Rate (2/2)

Ещё одним нюансом в расчёте RR является окно расчётов.

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

График RR часто строят в пределах 30 дней. Контрольными точками обычно являются 1, 3, 7, 14, 21 и 30-й дни.

В этой схеме выделяют три сегмента:

🔵Краткосрочный RR — это R1-R3, показывает первые впечатления, чтобы увеличить эти показатели нужно работать с первыми сессиями.

🔵Среднесрочный RR — промежуток где-то между R7-R14, самый сложный в управлении, обычно где-то здесь должно происходить раскрытие A-ha момента.

🔵Долгосрочный RR — от R21 и выше, почти не управляемый сам по себе сегмент, во многом он зависит от успешности первых двух.

На что вообще обращать внимание на графике? Во-первых нужно оценивать эти сегменты, они помогут понять где можно поработать над удержанием, всё ли ок с первыми сессиями и происходит ли “щелчок” на средней дистанции.

Во-вторых, ищи плато. Ближе к долгосроку график выравнивается, вот тут происходит формирование кор-аудитории. И чем раньше оно начинается, тем лучше.

P.S. Надо завязывать с двойными постами, конечно 😅

📌 Метрика Retention Rate (1/2)

Показатель удержания (RR) — одна из главных метрик приложений SaaS. Показывает насколько приложение “увлекает” пользователей.

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

Есть два типа расчёта этой метрики:

🔵N-day, или классический способ — расчёт в точности на день. В такой концепции RR 7-го дня (R7) показывает сколько юзеров вернулось именно на 7-й день после первого запуска.

🔵Rolling — более гибкий подход, здесь R7 показывает сколько юзеров вернулось на 7-й день или позже.

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

У метода Rolling есть весомый нюанс — он не стабилен. Исходя из определения, если юзер установил приложение, потом забросил его и вернулся через месяц — у тебя поплывут все значения на все дни до, т.к. каждый учитывается по условию “вернулся на день N или позже”.

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

📌 Один из способов запроса воронки

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

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

🔵В этом примере есть экран, страница или любой другой индикатор что юзер попал на страницу логина,

🔵потом жмякнул по авторизации через смс

🔵и успешно залогинился, попав на главную.

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

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

Забирайте, пользуйтесь 🙂

# Собираем данные по первому шагу
with login as (
  select user_id,
         timestamp as login_screen_dt
  from db
  where date(timestamp) >= current_date - 30
    and event = 'screen_view'
    and screen_name = 'login'
),

# По второму
sms_screen as (
  select user_id,
         timestamp as sms_screen_dt
  from db
  where date(timestamp) >= current_date - 30
    and event = 'screen_view'
    and screen_name = 'sms'
),

# По третьему
home_page as (
  select user_id,
         timestamp as home_page_dt
  from db
  where date(timestamp) >= current_date - 30
    and event = 'screen_view'
    and screen_name = 'home_page'
)

# Склеиваем это всё
select ls.*,
       ss.sms_screen_dt,
       hp.home_page_dt
from login ls
  left join sms_screen ss on ls.user_id = ss.user_id
                         and ls.login_screen_dt <= ss.sms_screen_dt
                         and date(ls.login_screen_dt) = date(ss.sms_screen_dt)
  left join home_page hp on ss.user_id = hp.user_id
                        and ss.sms_screen_dt <= hp.home_page_dt
                        and date(ss.sms_screen_dt) = date(hp.home_page_dt)

#сниппеты