📌 Условия case в конструкциях join
В SQL, наверное, моя любимая конструкция это кейсы. С ними можно вытворять почти всё что угодно. Например, не все в курсе, что через кейс можно даже джойнить таблицы.
Представь ситуацию — у тебя в БД есть таблица заказов, где каждый заказ связан либо с id залогиненного пользователя, либо с его id гостя. Нам надо объединить данные о заказах с информацией о клиентах, выбирая тип клиента в зависимости от наличия информации о пользователе. Например, нужно имя юзера, но если он не был залогинен в текущей сессии, то ищем его имя по его гостевому id:
🔵 orders — таблица заказов с полями
🔵 customers — таблица клиентов с полями
#сниппеты
В SQL, наверное, моя любимая конструкция это кейсы. С ними можно вытворять почти всё что угодно. Например, не все в курсе, что через кейс можно даже джойнить таблицы.
Представь ситуацию — у тебя в БД есть таблица заказов, где каждый заказ связан либо с id залогиненного пользователя, либо с его id гостя. Нам надо объединить данные о заказах с информацией о клиентах, выбирая тип клиента в зависимости от наличия информации о пользователе. Например, нужно имя юзера, но если он не был залогинен в текущей сессии, то ищем его имя по его гостевому id:
order_id, customer_id и guest_idcustomer_id и nameselect 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
#сниппеты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🤯19🔥2
📌 Про лучший онбординг
Про худший уже рассказал, справедливо будет рассказать и про самый топ, с которым я встречался.
Итак, первое что там было из необычного — план и расписание. Обычно у тебя просто есть пара задач на испыталку, но чаще ничего нет, вкатываешься по ситуации.
В этом плане не было списка задач, но был список тем для изучения и последовательное расписание ознакомительных сессий с каждой командой, с которой ты будешь пересекаться в работе.
Ответственным за онбординг был ПМ из аналитики. Вообще я никогда не видел у аналитиков отдельного ПМ-а, обычно это просто тимлид. Понятия не имею чем он занимался, но разработка онбординга была его задачей.
Так вот, началось всё из далека, первые пару недель у нас были только созвоны раз в пару дней, на которых он рассказывал про специфику бизнеса, как устроены биржи, кто с чего зарабатывает, кто как лицензируется и всё такое.
Тут же объяснял нам внутреннюю терминологию и систему метрик, что важнее и за чем нужно следить.
В закрепление он закидывал нам “домашки” в виде не душных статеек и видосов, чтобы мы больше прониклись внутрянкой. Загрузка была часа по 2-3 в день, но так и было задумано.
После погружения в бизнес, мы потихоньку начали знакомиться с инфраструктурой. Сначала была ознакомительная сессия с дата-инженерами, где они рассказали про данные, откуда берутся, как перетекают и где хранятся. Как обслуживается разметка, как заводить задачи на отдел и т.д. Затронули и всякие нюансы и проблемы, а так же показали костыли для их обхода.
Следующим этапом нам выделили по ментору, с которыми мы уже прошлись по базам, с которыми чаще всего придётся работать. Мы уже были подготовлены, поэтому таблицы выглядели знакомо, а все эти специфические колонки понятны.
Ещё была ознакомительная сессия с BI-командой, где нам показали какие есть борды, что актуально, а что не особо, где сверяться с расчётами и т.д. Не то чтобы нам это было сильно надо, но для общей картины пусть будет.
И последнее знакомство было уже с продуктовой командой, куда нас определяли. Тут довольно стандартно — чем занимается команда, кто есть кто и где какие зоны ответственности.
Параллельно с нашим погружением, ПМ аналитики организовал нам все доступы во все корп. системы и рабочим инструментам, которые аккуратно складывались в документы. Всё в одном месте, очень кайфово и очевидно, но я такого раньше не встречал 😅
Параллельно, в течение всего процесса были синхро с HR-ом команды, где ты рассказывал всё ли тебе понятно и всё ли нравится.
Весь этот процесс длился, наверное, месяц, может чуть больше. Потом начались первые боевые задачи совместно с ментором, их было по 1-2 штуки общих. Делать их было довольно легко. После всей теории, ощущения были как будто ты там уже давно работаешь и всё знакомо.
После этой мини-практики нас уже отдали в наши продуктовые команды.
Ребята потратили месяца два максимум для нашего погружения, но сразу после него мы были уже полноценные боевые единицы, которым смело можно было выдавать уже любые рабочие задачи.
#кулстори
Про худший уже рассказал, справедливо будет рассказать и про самый топ, с которым я встречался.
Для контекста — это был трейдинг. Тот онбординг-флоу, в который нас занесло (а нас было одновременно три новичка в разные команды) только тестировался и по итогу не прижился в компании, что, я считаю, огромным факапом.
Итак, первое что там было из необычного — план и расписание. Обычно у тебя просто есть пара задач на испыталку, но чаще ничего нет, вкатываешься по ситуации.
В этом плане не было списка задач, но был список тем для изучения и последовательное расписание ознакомительных сессий с каждой командой, с которой ты будешь пересекаться в работе.
Ответственным за онбординг был ПМ из аналитики. Вообще я никогда не видел у аналитиков отдельного ПМ-а, обычно это просто тимлид. Понятия не имею чем он занимался, но разработка онбординга была его задачей.
Так вот, началось всё из далека, первые пару недель у нас были только созвоны раз в пару дней, на которых он рассказывал про специфику бизнеса, как устроены биржи, кто с чего зарабатывает, кто как лицензируется и всё такое.
Тут же объяснял нам внутреннюю терминологию и систему метрик, что важнее и за чем нужно следить.
В закрепление он закидывал нам “домашки” в виде не душных статеек и видосов, чтобы мы больше прониклись внутрянкой. Загрузка была часа по 2-3 в день, но так и было задумано.
После погружения в бизнес, мы потихоньку начали знакомиться с инфраструктурой. Сначала была ознакомительная сессия с дата-инженерами, где они рассказали про данные, откуда берутся, как перетекают и где хранятся. Как обслуживается разметка, как заводить задачи на отдел и т.д. Затронули и всякие нюансы и проблемы, а так же показали костыли для их обхода.
Следующим этапом нам выделили по ментору, с которыми мы уже прошлись по базам, с которыми чаще всего придётся работать. Мы уже были подготовлены, поэтому таблицы выглядели знакомо, а все эти специфические колонки понятны.
Ещё была ознакомительная сессия с BI-командой, где нам показали какие есть борды, что актуально, а что не особо, где сверяться с расчётами и т.д. Не то чтобы нам это было сильно надо, но для общей картины пусть будет.
И последнее знакомство было уже с продуктовой командой, куда нас определяли. Тут довольно стандартно — чем занимается команда, кто есть кто и где какие зоны ответственности.
Параллельно с нашим погружением, ПМ аналитики организовал нам все доступы во все корп. системы и рабочим инструментам, которые аккуратно складывались в документы. Всё в одном месте, очень кайфово и очевидно, но я такого раньше не встречал 😅
Параллельно, в течение всего процесса были синхро с HR-ом команды, где ты рассказывал всё ли тебе понятно и всё ли нравится.
Весь этот процесс длился, наверное, месяц, может чуть больше. Потом начались первые боевые задачи совместно с ментором, их было по 1-2 штуки общих. Делать их было довольно легко. После всей теории, ощущения были как будто ты там уже давно работаешь и всё знакомо.
После этой мини-практики нас уже отдали в наши продуктовые команды.
Ребята потратили месяца два максимум для нашего погружения, но сразу после него мы были уже полноценные боевые единицы, которым смело можно было выдавать уже любые рабочие задачи.
#кулстори
🔥31❤10👍7
Очень прикольный тред про поиск работы. Как кастомизировать своё резюме под ATS и значительно увеличить колличество откликов.
https://twitter.com/venus_in_moss/status/1785239928378441930?t=12AKm8lj5etTqaWsqBv9Yg&s=19
https://twitter.com/venus_in_moss/status/1785239928378441930?t=12AKm8lj5etTqaWsqBv9Yg&s=19
X (formerly Twitter)
maiasmokk (@venus_in_moss) on X
2 оффера за 2 недели
тред о том, как я изменила подход к поиску работы в эмиграции после четырех месяцев безуспешных поисков, и за две недели получила возможность выбирать из двух отличных офферов
надеюсь, это поможет тем, кто сейчас в поиске!
тред о том, как я изменила подход к поиску работы в эмиграции после четырех месяцев безуспешных поисков, и за две недели получила возможность выбирать из двух отличных офферов
надеюсь, это поможет тем, кто сейчас в поиске!
👍10
📌 Про группировки пользователей
В анализе данных постоянно используются различные группировки пользователей. И очень часто я замечаю, что для многих (особенно продактов, но и для аналитиков) нет разницы в терминологии между сегментами, когортами и кластерами. Термины используют как карта ляжет, но это разные сущности и они по разному работают.
Давай разберёмся и больше не будем путать:
1️⃣ Сегменты — это группы юзеров на основе каких-то характеристик или поведенческих признаков. Сегментировать можно по гео, платформе, по демографии, лайфтайму, по экономическим показателям или по паттернам поведения. Да всё что угодно. Вообще, чаще всего, когда ты говоришь о группах — ты говоришь о сегментах.
2️⃣ Когорты — это группы юзеров, объединённые общим событием в определённый период времени. Время тут ключевой фактор. Когорты могут быть за неделю, за меся, за год, это уже не так важно. Событие тоже не принципиально, это может быть как регистрация, так и первая покупка, например. Но это всегда с акцентом на период времени. Не бывает российской когорты, бывает когорта январская. Хотя никто не запрещает сегментировать когорты, но это уже другое! 🙂
3️⃣ Кластеры — это уже более редкое явление, когда сегменты обзывают кластерами, но всё равно ещё встречается. Так вот, кластер это группа, сформированная в результате анализа, которая строится на основе схожих характеристик или паттернов поведения, но критерии никогда не определены заранее (ты, конечно, знаешь весь список на момент запуска модели, но что там как повлияет всё ещё не понятно).
В анализе данных постоянно используются различные группировки пользователей. И очень часто я замечаю, что для многих (особенно продактов, но и для аналитиков) нет разницы в терминологии между сегментами, когортами и кластерами. Термины используют как карта ляжет, но это разные сущности и они по разному работают.
Давай разберёмся и больше не будем путать:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🎉8❤4
Приветики, я тут пока затих, майские, сами понимаете 🙂
Махнули в автотрип по Черногории, 550км до побережья, и вдоль по всем интересным городкам.
Проехали заповедник, Херцег-нови и Пераст, сегодня Порто Монтенегро, Котор и Будва.
Шашлыков пока не обнаружено 😐
Махнули в автотрип по Черногории, 550км до побережья, и вдоль по всем интересным городкам.
Проехали заповедник, Херцег-нови и Пераст, сегодня Порто Монтенегро, Котор и Будва.
Шашлыков пока не обнаружено 😐
👍19❤8🔥5😁1
📌 Когортный анализ
Многие из вас слышали про когортный анализ, а кто-то даже его проводил. Но не все понимают как его использовать для управлением обновлениями.
Как мы уже ранее разобрали — когорты это группы аудитории с привязкой к какому-то временному интервалу. Например к месяцу установки приложения. Период лучше выбирать исходя из длительности спринта разработки. Спринт, по классическому определению, завершается релизом, а значит каждая когорта будет стартовать с какой-то своей версии продукта.
Что мы хотим отслеживать? Часто в когортный анализ засовывают метрики роста, типа MAU, но на практике это применимо, разве что, в маркетинговом анализе. Мы же сейчас поговорим о продуктовом.
Давай разберём эту задачу на составные продуктовые шаги:
Первым шагом после установки может быть прохождение онбординга➡️ Потом схватывание a-ha момента ➡️ Первая оплата ➡️ Последующая оплата.
Успешность этих шагов очень сильно привязана к UX (user experience), который даёт приложение. А именно UX нам и интересен в первую очередь, так как даже незначительные изменения в дизайне могут сильно упростить или усложнить жизнь юзеров.
Отслеживание этих шагов уже даст много информации — переделали онбординг, изменили главную страницу, сломали воронку — всё это быстро отслеживается на новой когорте.
В отличии от анализа метрик в динамике, когортный анализ помогает смотреть свежим взглядом на каждую новую версию продукта без привязки к истории. Вот на прошлой неделе всё было хорошо с прохождением каталога, а сейчас плохо — что сделали? Увеличили количество категорий. Окей, это нам не надо, откатываем.
Для полноты картины, в список метрик можно добавить продуктовый набор типа retention, ARPU, LTV или среднй чек.
Многие из вас слышали про когортный анализ, а кто-то даже его проводил. Но не все понимают как его использовать для управлением обновлениями.
Как мы уже ранее разобрали — когорты это группы аудитории с привязкой к какому-то временному интервалу. Например к месяцу установки приложения. Период лучше выбирать исходя из длительности спринта разработки. Спринт, по классическому определению, завершается релизом, а значит каждая когорта будет стартовать с какой-то своей версии продукта.
Что мы хотим отслеживать? Часто в когортный анализ засовывают метрики роста, типа MAU, но на практике это применимо, разве что, в маркетинговом анализе. Мы же сейчас поговорим о продуктовом.
Немного лирического отступления — у каждого приложения есть какая-то задача, которая ведёт к верхнеуровневым целям (например, заработать денег). Этой задачей обычно является формирование привычки пользоваться приложением у юзера и, как следствие, мотивировать его совершать много последовательных платежей.
Давай разберём эту задачу на составные продуктовые шаги:
Первым шагом после установки может быть прохождение онбординга
Успешность этих шагов очень сильно привязана к UX (user experience), который даёт приложение. А именно UX нам и интересен в первую очередь, так как даже незначительные изменения в дизайне могут сильно упростить или усложнить жизнь юзеров.
Отслеживание этих шагов уже даст много информации — переделали онбординг, изменили главную страницу, сломали воронку — всё это быстро отслеживается на новой когорте.
В отличии от анализа метрик в динамике, когортный анализ помогает смотреть свежим взглядом на каждую новую версию продукта без привязки к истории. Вот на прошлой неделе всё было хорошо с прохождением каталога, а сейчас плохо — что сделали? Увеличили количество категорий. Окей, это нам не надо, откатываем.
Для полноты картины, в список метрик можно добавить продуктовый набор типа retention, ARPU, LTV или среднй чек.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤2🔥2
Набросал тут небольшую памятку для начинающих изучать SQL. Без совсем уж основных основ, но в целом уровень аналитический, а не инженерный.
Про структуру запроса, порядок его выполнения и простые практики по базовой оптимизации.
🍿
https://telegra.ph/Pamyatka-po-SQL-05-15
Про структуру запроса, порядок его выполнения и простые практики по базовой оптимизации.
https://telegra.ph/Pamyatka-po-SQL-05-15
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Памятка по SQL
Небольшая памятка для начинающих учить SQL. В каком порядке выполняется запрос, как его можно быстро и дёшево оптимизировать и несколько часто используемых полезных практик. §1. Структура SQL-запроса и последовательность выполнения Для начала давай разберёмся…
👍30🔥9
Вопрос может показаться странным, учитывая специфику группы, но всё же) Если представить, что вы можете пойти в любое направление аналитики, куда больше душа лежит?
Anonymous Poll
19%
Аналитика данных
44%
Продуктовая аналитика
5%
Маркетинговая аналитика
8%
BI-аналитика
16%
ML-инженерия и Data science
8%
Дата инженерия
📌 Задача предсказания UX
Если подумать, какая задача в моей карьере была самой популярной и желанной для заказчиков, то сразу вспоминаются попытки предикта поведения юзера. Серьёзно, она была почти во всех командах 🙂
Это просто золотой грааль для компаний. Все мечтают на ранних этапах предсказывать в какой сегмент попадёт юзер (хотя бы на уровне "отвалится или будет платящим"). В идеале сразу при регистрации. Имея эту информацию, можно уже много чего наворотить в UX пользователя, в зависимости от ожиданий.
И мы даже много раз пытались такое провернуть силами продуктовой аналитики (естественно, не всегда удачно). К слову, у нас никогда не было классного ML-спеца, поэтому сильно глубоко мы никогда не копали.
А нет, вру, один раз была команда DS, которая занималась этой задачей основательно, но они начали её делать до моего прихода в компанию, и не закончили когда я ушёл, так что не считается 🙂
😅 Сложно (особенно заказчику) принять факт, что с первого запуска, не имея никаких поведенческих показателей юзера, сложно как-то магическим образом предсказывать его будущее. Ни гео, ни времени суток регистрации, ни даже источника траффика никогда не достаточно. А жаль, конечно.
Это конечно не даёт ответ на вопрос “а что делать-то в первый день с ними, кого активнее пушить а на кого не давить и просто дать время?”, но в целом, иметь какие-никакие прогнозы по юзеру через неделю выглядит всё ещё полезнее, чем не иметь никаких.
Это одна из тех задач, где нет какого-то единого алгоритма решения. На хабре все подходы отличаются диаметрально, т.к. всё ещё и сильно зависит от конкретного бизнеса.
Сталкивались с такими задачами? Как решали? 🙂
Если подумать, какая задача в моей карьере была самой популярной и желанной для заказчиков, то сразу вспоминаются попытки предикта поведения юзера. Серьёзно, она была почти во всех командах 🙂
Это просто золотой грааль для компаний. Все мечтают на ранних этапах предсказывать в какой сегмент попадёт юзер (хотя бы на уровне "отвалится или будет платящим"). В идеале сразу при регистрации. Имея эту информацию, можно уже много чего наворотить в UX пользователя, в зависимости от ожиданий.
И мы даже много раз пытались такое провернуть силами продуктовой аналитики (естественно, не всегда удачно). К слову, у нас никогда не было классного ML-спеца, поэтому сильно глубоко мы никогда не копали.
😅 Сложно (особенно заказчику) принять факт, что с первого запуска, не имея никаких поведенческих показателей юзера, сложно как-то магическим образом предсказывать его будущее. Ни гео, ни времени суток регистрации, ни даже источника траффика никогда не достаточно. А жаль, конечно.
Проблему мы частично решали простым сдвигом точки анализа хотя бы на недельку. Обычно за это время у юзера происходит или ранний отток, или какая-то движуха, по которой можно пытаться планировать его жизнь наперёд. Предикторы типа наличия первого платежа, его суммы, времени на “подумать”, а так же всякие триггеры посещения отдельных разделов — уже раскрывают юзера намного детальнее.
Это конечно не даёт ответ на вопрос “а что делать-то в первый день с ними, кого активнее пушить а на кого не давить и просто дать время?”, но в целом, иметь какие-никакие прогнозы по юзеру через неделю выглядит всё ещё полезнее, чем не иметь никаких.
Это одна из тех задач, где нет какого-то единого алгоритма решения. На хабре все подходы отличаются диаметрально, т.к. всё ещё и сильно зависит от конкретного бизнеса.
Сталкивались с такими задачами? Как решали? 🙂
👍9
📌 Откуда удобно заходить в ПА
В продуктовую аналитику я пришёл веб-студии, в которой занимался много чем, от верстки до дизайна. Но больше времени моим делом было, наверное проектирование интерфейсов.
Эта работа не просто про рисование квадратиков. Проект включает в себя много исследовательских моментов — построение всяких CJM / JTBD, персонажей, воронок, карточных сортировок, проведение интервью, построение карт метрик и иногда даже разметку событий и т.д. Такое углубленное изучение UX / экономики проекта.
Многие вещи оттуда отлично вписываются в продуктовую аналитику.
Из каких ещё сфер можно относительно легко зайти в ПА?
🔵 Маркетинг (web). Как и проектирование, маркетинг сначала досконально изучает пользователей, их привычки, желания, цели и особенности поведения. А ещё бонусом опыт работы с инструментами веб-аналитики и понимание подкапотного устройства сайта на уровне HTML-CSS-JS.
🔵 Социология. Социологи хорошо знакомы со статистикой и умеют изучать людей, проводить исследования и делать выводы. Аналитическое мышление развивается очень хорошо. Знал бы я в универе, что мне эта специальность в будущем подойдёт, забил бы на энергофак не думая 🙂
🔵 Экономика. Как по мне, немного дальше социологии, но всё ещё формирует очень много полезных навыков, особенно для работы с будущей юнит-экономикой проекта.
🔵 Психология. У этих ребят имеется глубокое понимание поведения и мотивации людей, что очень ценно для анализа поведения юзеров и понимания почему юзеры ведут себя именно так.
🔵 Ну и, конечно же, смежная аналитика (например, дата-). Хороший набор хардов, аналитическое мышление и умение работать с данными и делать выводы.
И это только то, что на поверхности 🙂
В продуктовую аналитику я пришёл веб-студии, в которой занимался много чем, от верстки до дизайна. Но больше времени моим делом было, наверное проектирование интерфейсов.
Эта работа не просто про рисование квадратиков. Проект включает в себя много исследовательских моментов — построение всяких CJM / JTBD, персонажей, воронок, карточных сортировок, проведение интервью, построение карт метрик и иногда даже разметку событий и т.д. Такое углубленное изучение UX / экономики проекта.
Многие вещи оттуда отлично вписываются в продуктовую аналитику.
Из каких ещё сфер можно относительно легко зайти в ПА?
И это только то, что на поверхности 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤2