🔗 Разметка событий
Обещал написать про разметку событий, ловите. Надеюсь там не слишком запутанно, старался сделать пошагово.
Приятного прочтения 🍿
https://telegra.ph/Razmetka-01-03
Обещал написать про разметку событий, ловите. Надеюсь там не слишком запутанно, старался сделать пошагово.
Приятного прочтения 🍿
https://telegra.ph/Razmetka-01-03
Telegraph
Разметка событий
Понятная разметка — лучший друг любого продуктового аналитика. То, как собираются данные, какие есть события и какие у них свойства, во многом определяет сколько боли будет в вашей работе. По важности — одна из топовых задач. Осложняет дело ещё и тот факт…
👍14🔥10❤1🤔1
Я тут задумал небольшой пет-проект по поднятию простой системы аналитики только под веб пока. Суть в чем, нужно скрафтить небольшой сайт, на него повесить трекер ивентов, оттуда по API стянуть данные для ETL и сложить в БД, потом её натянуть на какой-то BI. Всё просто, но я таким не занимался никогда чтобы прям с нуля 🙂
План пока такой:
1. Взять трекер типа GA или Segment
2. Даги написать на Airflow
3. Как БД поднять Clickhouse
4. Ну с базовым BI там всё просто, тот же Redash залетит
Есть тут инженеры, насколько такой выбор оптимален? Затрат там пока видится максимум на 120$ за КХ на минимальном тарифе. Или имеет смысл хранить данные отдельно в каком-нибудь Redshift? В идеале потом ещё трекер сменить на самописный, но его сначала надо написать 😅
План пока такой:
1. Взять трекер типа GA или Segment
2. Даги написать на Airflow
3. Как БД поднять Clickhouse
4. Ну с базовым BI там всё просто, тот же Redash залетит
Есть тут инженеры, насколько такой выбор оптимален? Затрат там пока видится максимум на 120$ за КХ на минимальном тарифе. Или имеет смысл хранить данные отдельно в каком-нибудь Redshift? В идеале потом ещё трекер сменить на самописный, но его сначала надо написать 😅
👍4🔥2🤯2🤔1
📌 Что значит “знать SQL”?
В одном чатике возник такой вопрос. Спектр ответов был от “знать оконки” до “писать трехэтажные запросы”.
Давай разбираться 🧐
В русскоязычном комьюнити очень сильно смещён фокус на хард скилы. Но что такое SQL по сути? Это прикладной навык, инструмент, с помощью которого ты решаешь часть задачи. Точнее — всего лишь добываешь данные для анализа.
В работе тебе никто не говорит: “достань мне из базы вот такие данные по таким колонкам и чтобы запрос был пожирнее”.
Говорят: “мы выкатили фичу, и она, кажется, не работает”.
Твоя задача намного, намного глубже — нужно определиться с критериями, что вообще значит “не работает”? А как понять что работает? Есть ли у неё перспектива? Надо ли переделывать? Тут намного больше тонкостей в аналитическом мышлении.
Все эти вопросы нужно переводить на язык данных. “Посчитаем, значит вот это, это и вон то” — можешь достать эти данные из базы, не потратив на это неделю? Поздравляю, у тебя нормальный рабочий уровень SQL 🥳
Да, некоторые вещи используются чаще — например подзапросы или CTE, джоины и оконки. Некоторые реже — какой-нибудь локальный мэппинг, lead/lag и т.д. Но это ты со временем сам обнаружишь.
Все функции наизусть никто не знает, и это нормально. Да что там знать, большей частью функций из документации ты никогда не воспользуешься даже. А если вдруг и понадобится что-то хитрое — есть гугл.
В одном чатике возник такой вопрос. Спектр ответов был от “знать оконки” до “писать трехэтажные запросы”.
Давай разбираться 🧐
В русскоязычном комьюнити очень сильно смещён фокус на хард скилы. Но что такое SQL по сути? Это прикладной навык, инструмент, с помощью которого ты решаешь часть задачи. Точнее — всего лишь добываешь данные для анализа.
Разгоним музыкальную метафору. Вот есть барабанщик. Его задача играть ритм в композиции. Для этого он использует палочки, которыми стучит по сету. Эти палочки и есть его SQL. Он может понять как их держать и как извлекать звук, а потом перейти, собственно, к музыке. А может годами оттачивать трюки, подкидывать их, крутить и т.д., к музыке так и не приступив. И когда он приходит в группу с таким крутым скиллом — его не берут. Потому что группе надо ритм держать, а не палочками выпендриваться.
В работе тебе никто не говорит: “достань мне из базы вот такие данные по таким колонкам и чтобы запрос был пожирнее”.
Говорят: “мы выкатили фичу, и она, кажется, не работает”.
Твоя задача намного, намного глубже — нужно определиться с критериями, что вообще значит “не работает”? А как понять что работает? Есть ли у неё перспектива? Надо ли переделывать? Тут намного больше тонкостей в аналитическом мышлении.
Все эти вопросы нужно переводить на язык данных. “Посчитаем, значит вот это, это и вон то” — можешь достать эти данные из базы, не потратив на это неделю? Поздравляю, у тебя нормальный рабочий уровень SQL 🥳
Да, некоторые вещи используются чаще — например подзапросы или CTE, джоины и оконки. Некоторые реже — какой-нибудь локальный мэппинг, lead/lag и т.д. Но это ты со временем сам обнаружишь.
Все функции наизусть никто не знает, и это нормально. Да что там знать, большей частью функций из документации ты никогда не воспользуешься даже. А если вдруг и понадобится что-то хитрое — есть гугл.
🔥14👍7❤2
📌 Аналитические кейсы на собесах, 1
Листал линк недавно, много жалоб на собесы. Правда в основном DA, но у этих всегда какое-то мясо творится, даже лезть страшно. Давай порассуждаем про собесы продуктовых аналитиков.
Обычно тех интервью состоит из части по SQL, Питону и решению кейсов.
Вообще, если бы я писал сценарий собеса, я бы вырезал первые 2 части из интервью — SQL легко проверить даже на скрининге с HR, а Питон проще отдать на мини-тестовое по решению кейса, на час-два.
💭 Хоть я и не люблю тестовые, по ним легко проверить умение пользоваться языком. Даже если там всё написано будет через GPT — главное что написано, и как решено. Если не знать что вообще делать, GPT не поможет. А в работе-то пожалуйста, используй.
Другое дело — решение кейсов. Эта штука самая простая и самая сложная одновременно. А если вам нужен аналитик для решения задач — ещё и самая полезная.
Суть кейсов в следующем: интервьюер даёт какие-то вводные, описывает проблему, с которой столкнулся бизнес, а кандидат должен порассуждать как бы он эту проблему решал.
Я обожаю кейсы💛 . Чаще всего пока интервьюер рассказывает задачу, у меня в голове уже всплывает реальная похожая ситуация из практики, и я просто рассказываю как делал в тот раз. И это не потому что я динозавр и всё застал, а потому что кейсы редко оригинальные или далекие от реальности. Чаще всего это типичные рабочие ситуации — “ты приходишь на работу в понедельник и видишь что за выходные мы сильно просели по деньгам. Как найти проблему?”
Кейсы сложно обмануть. Ты можешь хоть 40 лет накрутить 🐺 — спалишься на них моментально. Зато они прекрасно проверяют аналитическое мышление. Даже если SQL пройден кое-как, хороший результат на кейсах — всё ещё причина задуматься о найме.
Листал линк недавно, много жалоб на собесы. Правда в основном DA, но у этих всегда какое-то мясо творится, даже лезть страшно. Давай порассуждаем про собесы продуктовых аналитиков.
Обычно тех интервью состоит из части по SQL, Питону и решению кейсов.
Вообще, если бы я писал сценарий собеса, я бы вырезал первые 2 части из интервью — SQL легко проверить даже на скрининге с HR, а Питон проще отдать на мини-тестовое по решению кейса, на час-два.
💭 Хоть я и не люблю тестовые, по ним легко проверить умение пользоваться языком. Даже если там всё написано будет через GPT — главное что написано, и как решено. Если не знать что вообще делать, GPT не поможет. А в работе-то пожалуйста, используй.
Другое дело — решение кейсов. Эта штука самая простая и самая сложная одновременно. А если вам нужен аналитик для решения задач — ещё и самая полезная.
Суть кейсов в следующем: интервьюер даёт какие-то вводные, описывает проблему, с которой столкнулся бизнес, а кандидат должен порассуждать как бы он эту проблему решал.
Я обожаю кейсы
Реже — более креативные, у меня один раз был такой: “В высотном здании есть 2 лифта, которые движутся по разным алгоритмам. Первый — строго в том порядке, в каком нажаты кнопки. Второй — в порядке следования по этажам, останавливаясь там, где кнопка была нажата. Какой алгоритм удобнее?”
Кейсы сложно обмануть. Ты можешь хоть 40 лет накрутить 🐺 — спалишься на них моментально. Зато они прекрасно проверяют аналитическое мышление. Даже если SQL пройден кое-как, хороший результат на кейсах — всё ещё причина задуматься о найме.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
📌 Аналитические кейсы на собесах, 2
Так чего интервьюер ждёт от таких задач?
Они абстрактные, здесь не выдают конкретику, а хотят просто посмотреть на твоё мышление.
Возьмём, для примера, предыдущий кейс про падение доходов, и попробуем поразмышлять.
🌀 Во-первых, нужно понять было ли вообще падение, или это простое колебание в рамках допустимого? А если и было, то насколько критичное. Для детектирования аномалии можно использовать плавающие дов. интервалы, в нашем случае окно в 7 дней хорошо подойдёт. Покажи, что умеешь отличать колебания от аномалий.
Дальше варианты — упало в 0 или просто резко снизилось? Если в 0, то скорее всего это технические проблемы — от сломанной кнопки “купить” до полного падения серверов.
🌀 Допустим, падение резкое, но не полное. Тут начинается блок про экономику. Для начала нужно разложить доход на метрики поменьше. Из чего он состоит? В зависимости от бизнеса, конечно, но глобально это количество денег от юзеров. Нужно рассмотреть эти составляющие отдельно.
🌀 Первое направление — траффик. Может быть такое, что в эти выходные было падение траффика, тогда при неизменных чеках и конверсиях мы увидим падение дохода. Бывает, что траффик падает по внешним причинам, например в стране, где у нас больше всего юзеров — выборы. Но внешние причины редко сильно влияют. Чаще это изменения в маркетинге.
Если объёмы в норме, стоит посмотреть на состав траффика — может он изменился со старичков, которые платят много, на новичков, при этом количество юзеров особо не поменялось.
🌀 Если с траффиком и его составом всё ок, стоит глянуть на средние показатели по юзерам — изменился ли чек? А может было несколько источников дохода (например, подписка и доп. продажи) и изменился какой-то из них? А может что-то произошло не везде, а в каком-то сегменте, например, на вебе или в Испании?
🌀 Если средние метрики в норме, стоит изучить конверсии. Можно зайти с воронок, возможно проблема появилась на каком-то определённом шаге.
И т.д. Можно ещё долго разгонять, в этом суть таких задач.
#собесы
Так чего интервьюер ждёт от таких задач?
Они абстрактные, здесь не выдают конкретику, а хотят просто посмотреть на твоё мышление.
Возьмём, для примера, предыдущий кейс про падение доходов, и попробуем поразмышлять.
Дальше варианты — упало в 0 или просто резко снизилось? Если в 0, то скорее всего это технические проблемы — от сломанной кнопки “купить” до полного падения серверов.
Если объёмы в норме, стоит посмотреть на состав траффика — может он изменился со старичков, которые платят много, на новичков, при этом количество юзеров особо не поменялось.
И т.д. Можно ещё долго разгонять, в этом суть таких задач.
#собесы
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16👍7😎2
📌 Что делать со “срочными” задачами?
Однажды я работал в одной там компании, ничего особенного, кроме CDO. Очень крутой мужик был, многому меня научил. И вот мы как-то сидели с ним на созвоне, обсуждали всякое, и зашёл вопрос о срочности задач.
У любого заказчика, как правило, своя задача самая важная. И хорошо когда у тебя заказчик один, он хотя бы для себя может приоритизировать свои задачи. А если их, скажем 5, то тут начинается хаос. Всем всё нужно вчера, без конкретно этой задачи отдел не функционирует!
И вот тогда тот мой CDO научил меня как это правильно организовать — ответ убил: да забей просто. “Интересная мысль от CDO” — тогда подумал я 🙂
Но смысл там, конечно, не совсем прямой. Он говорит: “я как делаю обычно — прилетает мне задача уровня важности 10/10. И я её отправляю мариноваться на пару дней. Если за эти пару дней заказчик не пришёл уточнить как там дела — значит не очень-то и надо было, и теперь её можно спокойно запланировать в график. А если каждый день приходит, то, видимо, и правда срочно, можно отложить остальные дела.”
Такая, вроде бы, простая мысль, но как же она снизила уровень стресса в моей работе, а за счёт осознанного отказа прыгать туда-сюда и концентрироваться на текущей задаче, неплохо так повышается продуктивность.
И почти ушли ситуации, когда нужно что-то завтра, ты всё бросаешь, делаешь, а послезавтра спрашиваешь “ну как там?” и получаешь ответ “да я чёт ещё не посмотрел” 🤨 (лайк если бесит)
Однажды я работал в одной там компании, ничего особенного, кроме CDO. Очень крутой мужик был, многому меня научил. И вот мы как-то сидели с ним на созвоне, обсуждали всякое, и зашёл вопрос о срочности задач.
У любого заказчика, как правило, своя задача самая важная. И хорошо когда у тебя заказчик один, он хотя бы для себя может приоритизировать свои задачи. А если их, скажем 5, то тут начинается хаос. Всем всё нужно вчера, без конкретно этой задачи отдел не функционирует!
И вот тогда тот мой CDO научил меня как это правильно организовать — ответ убил: да забей просто. “Интересная мысль от CDO” — тогда подумал я 🙂
Но смысл там, конечно, не совсем прямой. Он говорит: “я как делаю обычно — прилетает мне задача уровня важности 10/10. И я её отправляю мариноваться на пару дней. Если за эти пару дней заказчик не пришёл уточнить как там дела — значит не очень-то и надо было, и теперь её можно спокойно запланировать в график. А если каждый день приходит, то, видимо, и правда срочно, можно отложить остальные дела.”
Такая, вроде бы, простая мысль, но как же она снизила уровень стресса в моей работе, а за счёт осознанного отказа прыгать туда-сюда и концентрироваться на текущей задаче, неплохо так повышается продуктивность.
И почти ушли ситуации, когда нужно что-то завтра, ты всё бросаешь, делаешь, а послезавтра спрашиваешь “ну как там?” и получаешь ответ “да я чёт ещё не посмотрел” 🤨 (лайк если бесит)
👍23❤6🔥5
📦 Мои любимые книги
Курсы это конечно хорошо, но они, как правило, только задают вектор развития, не вдаваясь глубоко в темы.
А вот покопаться детальнее отлично помогают книги.
Хочу поделиться с тобой моим любимым списком книг, некоторые из которых вообще настольные, к которым можно возвращаться постоянно:
📎 По АБ-тестам не так давно вышла книга “Доверительное А/В-тестирование” от Рона Кохави, Дианы Тан и Я Сюй. Думаю многие уже читали её, но если ещё не, рекомендую. Не то чтобы закроет прям все вопросы, но очень многое точно прояснит.
📎 “Работа с данными в любой сфере” от Кирилла Еременко — отличная книга после курсов, когда ты впитал тонну информации, эта небольшая книжка помогает уложить всё по полочкам. Особенно хорошо раскрывается тема исследований. Полезна как новичкам, так и при первых симптомах выгорания 🙂
📎 Ещё одна суперпопулярная книга “Графики, которые убеждают всех” от Александра Богачева, про тонкости визуализаций. Если ты много работаешь с BI и не читал эту книгу, то ты где-то свернул не туда.
📎 “Big Data” от Анналина Ына — очень маленький обзорный справочник по алгоритмам ML, они не разбираются детально с точки зрения реализации, но там очень доходчиво описано зачем какой алгоритм нужен, какие задачи он решает и как ты можешь применять их своей практике. Алгоритмы там не супер сложные, все хорошо ложатся в практику продуктовой аналитики.
📎 “Практическая статистика для специалистов Data Science” от Питера и Эндрю Брюсов. Шикарная книга по статистике на практике, в которой разбираются 50 важнейших понятий на R и Python, от EDA до ML. Но она чуть сложнее в понимании, требует небольшой базы.
📎 “Аналитическая культура” Карла Андерсона — наверное, одна из моих любимых. Почти пошаговая инструкция как сделать из компании, которая знать не знала про аналитику — показательную data-driven компанию. От нюансов организации сбора данных до найма и бизнес-результатов.
Здесь я не стал писать про книги по языкам, но они тоже крайне полезны. Это скорее для общего развития.
Закидывайте своих фаворитов 🙂
Курсы это конечно хорошо, но они, как правило, только задают вектор развития, не вдаваясь глубоко в темы.
А вот покопаться детальнее отлично помогают книги.
Хочу поделиться с тобой моим любимым списком книг, некоторые из которых вообще настольные, к которым можно возвращаться постоянно:
Здесь я не стал писать про книги по языкам, но они тоже крайне полезны. Это скорее для общего развития.
Закидывайте своих фаворитов 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍22❤11🔥7
📦 Книги не про аналитику (но это не точно)
Продолжу тему книг, но на этот раз не про аналитику (на первый взгляд).
Продуктовая аналитика, в отличие от какой-нибудь чистой дата-, лежит на стыке классического анализа, продуктового менеджмента и дизайна. На первый взгляд там задействовано меньше хардов (на самом деле нет), а на практике хороший продуктовый подход требует намного большего понимания смежных сфер.
На курсах эти темы редко затрагиваются, но их более глубокое понимание часто очень сильно помогает в работе.
С чего можно начать?
📎 “Интерфейсы” от Алана Купера — пожалуй лучшая книга по проектированию интерфейсов, Купер вообще один из отцов-основателей подхода к проектированию через UX. Книга огромная, но без воды. Крайне рекомендую, если у тебя проблемы с генерацией гипотез на тему “почему эта фича не взлетела”.
📎 “Психбольница в руках пациентов” Алана Купера — ещё одна книга Купера про UX в интерфейсах. Отлично дополняет его же “Интерфейсы”.
📎 “Дизайн. Книга для недизайнеров” от Робина Уильямса — небольшая книга про восприятие дизайна мозгом. Автор называет себя “нейродизайнером”, и в процессе чтения ты начинаешь понимать почему. Очень много полезных фишечек, да и сама по себе книга очень интересная. Мы же поведение юзеров в продукте исследуем, а оно очень сильно зависит и от дизайна.
📎 “Разработка требований к програмному обеспечению” Карла Виггерса. Как-то я состоял (да и сейчас вроде не выписан) в тайном обществе небезызвестного Лёхи Бородкина, и вот эта книга там была чуть ли не местной библией. И не зря. Для системных аналитиков и проектировщиков вообще обязательна, а для продуктовых там тоже много полезной информации на тему как эта ваша разработка вообще устроена и почему именно так.
Продолжу тему книг, но на этот раз не про аналитику (на первый взгляд).
Продуктовая аналитика, в отличие от какой-нибудь чистой дата-, лежит на стыке классического анализа, продуктового менеджмента и дизайна. На первый взгляд там задействовано меньше хардов (на самом деле нет), а на практике хороший продуктовый подход требует намного большего понимания смежных сфер.
На курсах эти темы редко затрагиваются, но их более глубокое понимание часто очень сильно помогает в работе.
С чего можно начать?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍7❤1
🔗 Шаблон резюме
Когда я уходил с прошлого места работа, там бонусом была такая штука как оценка резюме штатными HR-ами. Я закинул им своё, и они там не поправили ничего, сказали вообще не трогать 🙂
Я его подпилил, чтобы получился базовый шаблон и добавил комментарии. Можете брать на вооружение.
Примерно в таком же стиле (но в местном формате) у меня HH и линк.
Ссылка здесь
Когда я уходил с прошлого места работа, там бонусом была такая штука как оценка резюме штатными HR-ами. Я закинул им своё, и они там не поправили ничего, сказали вообще не трогать 🙂
Я его подпилил, чтобы получился базовый шаблон и добавил комментарии. Можете брать на вооружение.
Примерно в таком же стиле (но в местном формате) у меня HH и линк.
Ссылка здесь
❤20👍6🔥5
📌 Популярные инструменты, БД
Я довольно много с кем общаюсь в сфере на тему стека, и собрал некоторую статистику по популярности инструментов в разных компаниях (за исключением всяких там бигтехов). Ну как статистику, скорее сформировал мнение 🙂
Давай разберём, опыт работы с чем именно наиболее вероятно пойдёт в плюс на собесах, по моим субъективным ощущениям, конечно:
Базы данных.
Понятно, что классический SQL везде плюс-минус одинаковый, а если ты не работал с базой, то пару вечеров почитай документацию и нет проблем, но в целом по пулярности я бы поставил так.
1️⃣ Clickhouse — в РФ, наверное, самая популярная БД для продуктовой аналитики. Она колоночная, за счёт чего быстро работает с большим объёмом данных. Моё любимое это возможность дописать -if в любую агрегацию, вместо расписывания кейсов. Но там вообще полно удобных функций, тот же маппинг или ретеншн.
2️⃣ BigQuery — в последние пару лет прям частое явление, раньше встречал очень редко. Гибкая, легко ставится, приятный набор функций. Но геморная в масштабировании. Ещё и платная по запросам, поэтому с BQ не очень удобно работать через внешние окружения.
3️⃣ Vertica — к минусам я бы отнёс довольно скудный набор функций и цену, а к плюсам скорость на больших объёмах.
4️⃣ MS SQL — я лично ни разу не работал с ним, так что особо ничего не прокомментирую, но в последнее время часто натыкаюсь на ребят с этой базой в качестве основной для ПА.
Как ни странно, но за последние года 2 ни разу не слышал чтобы кто-то использовал (именно как основную в ПА) Postgress или MySQL (хотя они во всех рейтингах в топе по поулярности) и всего по разу Spark, Maria и Mongo 🙂
Я довольно много с кем общаюсь в сфере на тему стека, и собрал некоторую статистику по популярности инструментов в разных компаниях (за исключением всяких там бигтехов). Ну как статистику, скорее сформировал мнение 🙂
Сначала думал всё в один пост засунуть, но чёт начал комментировать и обломался по символам. Так что тут пока только про БД.
Давай разберём, опыт работы с чем именно наиболее вероятно пойдёт в плюс на собесах, по моим субъективным ощущениям, конечно:
Базы данных.
Понятно, что классический SQL везде плюс-минус одинаковый, а если ты не работал с базой, то пару вечеров почитай документацию и нет проблем, но в целом по пулярности я бы поставил так.
Как ни странно, но за последние года 2 ни разу не слышал чтобы кто-то использовал (именно как основную в ПА) Postgress или MySQL (хотя они во всех рейтингах в топе по поулярности) и всего по разу Spark, Maria и Mongo 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🤔5🔥3❤1
Последние пару дней часто натыкаюсь на вопросы про выбор курсов, и споры что лучше: заплатить и получить всё сразу, или не платить и гуглить всю инфу (которой в интернете вообще-то дофига).
Вроде как все сходятся в преимуществах платных курсов в виде возможности задавать вопросы кураторам и цельной системе, которая тебя за ручку ведёт.
С кураторами я вам не помогу, а вот с системой можно что-нибудь придумать.
Как-то давно одна моя подруга хотела попробовать что это за профессия такая, я ей тогда составил что-то типа роадмапа, что почитать сначала, где попрактиковаться потом и т.д. Главное — чтобы всё было бесплатно, или, хотя бы, не за 100к+. Потому что это был не вопрос прям смены сферы, а скорее пощупать.
В общем у меня возникла идея, поправить тот роадмап с учётом новых появившихся ресурсов. Такой пошаговый план, как бы я сам сейчас учил базу с нуля. Система, последовательность, рекомендации, вот это всё.
Было бы интересно?
Вроде как все сходятся в преимуществах платных курсов в виде возможности задавать вопросы кураторам и цельной системе, которая тебя за ручку ведёт.
С кураторами я вам не помогу, а вот с системой можно что-нибудь придумать.
Как-то давно одна моя подруга хотела попробовать что это за профессия такая, я ей тогда составил что-то типа роадмапа, что почитать сначала, где попрактиковаться потом и т.д. Главное — чтобы всё было бесплатно, или, хотя бы, не за 100к+. Потому что это был не вопрос прям смены сферы, а скорее пощупать.
В общем у меня возникла идея, поправить тот роадмап с учётом новых появившихся ресурсов. Такой пошаговый план, как бы я сам сейчас учил базу с нуля. Система, последовательность, рекомендации, вот это всё.
Было бы интересно?
👍68🔥21
📌 BI в аналитике
Внимание, пост, ради которого я вообще группу создавал, из категории ныть или рассуждать 🧐
Мне очень нравится тенденция последних лет — выносить BI в отдельное направление аналитики. Когда я только начинал, такого не было и все задачи по BI лежали на штатном аналитике.
Справедливости ради, тогда не было особой разницы даже между ДА и ПА, все делали одно и то же, в попытках понять что вообще происходит в продукте.
Когда я искал работу, общался с одной геймдев-студией, и вот они мне задали стандартный вопрос про любимые и не любимые типы задач. К любимым я причислил рисерчи, а BI отнёс ко вторым. Они спросили почему так с BI, на что я ответил типа хороший BI очень сложный, чтобы всё стабильно работало, нужно много времени уделять поддержке зоопарка дашбордов. Плюс монструозные проекты крашатся стабильно раз в день. То данные не долетели, то расчёты подозрительно себя ведут, то ещё что. Не говоря уже о том, что собрать такую махину это задачка не 5 минут, а иногда и не 5 недель.
Просто не будет времени делать что-то другое.
И тут у тимлида аж глаза загорелись, оказывается, он уже давно пушит идею взять отдельного BI-аналитика как раз по этим причинам. И мне даже как-то полегчало от осознания того, что уже почти все к этой мысли пришли, и мне не придётся учить DAX 😀
Я уже года 3 наверное не работал с BI, не считая SQL-based систем типа Redash или Superset (я называл SS лайтовым😄 ), которые ты используешь больше как блокнот, чем как BI.
Внимание, пост, ради которого я вообще группу создавал, из категории ныть или рассуждать 🧐
Мне очень нравится тенденция последних лет — выносить BI в отдельное направление аналитики. Когда я только начинал, такого не было и все задачи по BI лежали на штатном аналитике.
Справедливости ради, тогда не было особой разницы даже между ДА и ПА, все делали одно и то же, в попытках понять что вообще происходит в продукте.
Когда я искал работу, общался с одной геймдев-студией, и вот они мне задали стандартный вопрос про любимые и не любимые типы задач. К любимым я причислил рисерчи, а BI отнёс ко вторым. Они спросили почему так с BI, на что я ответил типа хороший BI очень сложный, чтобы всё стабильно работало, нужно много времени уделять поддержке зоопарка дашбордов. Плюс монструозные проекты крашатся стабильно раз в день. То данные не долетели, то расчёты подозрительно себя ведут, то ещё что. Не говоря уже о том, что собрать такую махину это задачка не 5 минут, а иногда и не 5 недель.
Просто не будет времени делать что-то другое.
И тут у тимлида аж глаза загорелись, оказывается, он уже давно пушит идею взять отдельного BI-аналитика как раз по этим причинам. И мне даже как-то полегчало от осознания того, что уже почти все к этой мысли пришли, и мне не придётся учить DAX 😀
Я уже года 3 наверное не работал с BI, не считая SQL-based систем типа Redash или Superset (я называл SS лайтовым
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🤔1😎1
This media is not supported in your browser
VIEW IN TELEGRAM
В SQL с регулярками тоже очень типичная история 😀
(сорс: https://twitter.com/rita_codes)
(сорс: https://twitter.com/rita_codes)
😁24👍1
Привет, слушайте, вопрос такой к активно изучающим Python. Я тут расписываю схемку для вот этого, и было бы классно туда блок про Python засунуть.
Но т.к. я не питонист и в своё время его как-то не системно учил, порекомендуйте плз куда сейчас за ним ходят? Только чтобы бесплатно или около того, и желательно разных уровней, спасибо 🙂
Но т.к. я не питонист и в своё время его как-то не системно учил, порекомендуйте плз куда сейчас за ним ходят? Только чтобы бесплатно или около того, и желательно разных уровней, спасибо 🙂
🔗 План самообразования в ПА
Приветики, допилил план по самообразованию в продуктовой аналитике, как бы я сам учился. На самом деле, я почти так и учился, но порядок был другой, за счёт чего я много страдал 🙂 Тут постарался расположить всё по логическому, на мой взгляд, плану.
Запасайтесь попкорном и приятного чтения 🍿
https://telegra.ph/Plan-samoobrazovaniya-po-professii-produktovogo-analitika-02-04
Приветики, допилил план по самообразованию в продуктовой аналитике, как бы я сам учился. На самом деле, я почти так и учился, но порядок был другой, за счёт чего я много страдал 🙂 Тут постарался расположить всё по логическому, на мой взгляд, плану.
Запасайтесь попкорном и приятного чтения 🍿
https://telegra.ph/Plan-samoobrazovaniya-po-professii-produktovogo-analitika-02-04
Telegraph
План самообразования по профессии продуктового аналитика
Привет, я работаю в сфере уже около 10 лет, преимущественно по специальности чистой продуктовой аналитики. Иногда я оглядываюсь назад и думаю — с текущим пониманием что и как устроено в работе, как бы я выстраивал свой процесс обучения с нуля? Эта статья…
🔥65👍13❤8🤔1
Обновил пост в закрепе, вынес туда навигацию. Чтобы новоприбывшим было проще сориентироваться что тут вообще у нас происходит 🙂
👍15❤3
📌 Перспективы развития из ПА
В последнее время часто вижу вопросы из серии “куда дальше расти аналитику?” Аналитики бывают разные и с разным бэкграундом, поэтому давай расскажу куда можно развиться именно из продуктового.
Глобально тут две ветки, на выбор — назовём их горизонтальная и вертикальная.
🔖 Вертикальная подразумевает усиление своих хард-скиллов. У позиции ПА, как и у почти у любой в IT, есть три основных грейда (джун-миддл-синьор). Развитие внутри одной позиции внутри грейдов — уже вариант. Если тебе нравится работать “руками”, всегда можно комфортно расти по ЗП просто за счёт усиления скиллов.
Если нравится менеджерить, и нет проблем с софт-скиллами — хорошим шагом будет целиться в тимлиды. Там будет меньше времени на чисто продуктовые задачи, но больше взаимодействия с командой и вовлечённости в процессы и архитектуру всей аналитической системы компании.
Есть ещё путь в руководители направлений, в ПА это чаще отдел АБ.
✨ Дальше идёт уже C-level. В вертикали это CDO (Chief Data Officer). Обычно в CDO охотнее берут с бэкграундом дата-инженера, но чётких правил нет. Я видел CDO из ПА, из ДА и даже из маркетинговой аналитики. И все прекрасно справлялись. CDO занимается выстраиванием архитектуры и культуры аналитики в компании. C-level часто получает прибавку в виде дивидендов от прибыли компании.
🔖 Вторая ветка развития — горизонтальная. В отличии от остальных типов аналитиков, ПА наиболее приближены к будням продукта, поэтому путь в продакт-менеджеры тут особенно популярный. За счёт глубокой вовлеченности в продукт, такие переходы обычно происходят без даунгрейдов по деньгам, а часто ещё и с апгрейдом.
✨ Из продакта тоже можно дойти до C-level’а — CPO (Chief Product Officer), иногда их называют Product Owner’ами. У кого как. Они занимаются развитием продукта в целом — стратегией, конкурентоспособностью, выходом на рынок и т.д.
В целом, если надоест аналитика, есть куда пойти 🙂
В последнее время часто вижу вопросы из серии “куда дальше расти аналитику?” Аналитики бывают разные и с разным бэкграундом, поэтому давай расскажу куда можно развиться именно из продуктового.
Глобально тут две ветки, на выбор — назовём их горизонтальная и вертикальная.
Если нравится менеджерить, и нет проблем с софт-скиллами — хорошим шагом будет целиться в тимлиды. Там будет меньше времени на чисто продуктовые задачи, но больше взаимодействия с командой и вовлечённости в процессы и архитектуру всей аналитической системы компании.
Есть ещё путь в руководители направлений, в ПА это чаще отдел АБ.
В целом, если надоест аналитика, есть куда пойти 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20
У агентства NewHR от Киры Кузьменко выкатился список 500 популярных ресурсов, которые читают аналитики. ТГ каналов там 253 из которых 83 про аналитику.
Я думаю, там учитывались вообще все упоминания (методологию они не раскрывали), но всё равно приятно быть в списке с @borzilo_y. Тем более что данные за 23-й год, когда каналу был месяц всего. Это ж кто-то из вас был, спасибо 🙂
Я думаю, там учитывались вообще все упоминания (методологию они не раскрывали), но всё равно приятно быть в списке с @borzilo_y. Тем более что данные за 23-й год, когда каналу был месяц всего. Это ж кто-то из вас был, спасибо 🙂
🎉19🔥6😁1🤯1
📌 Про Макса
Хочу рассказать вам историю про самого значимого, в моей карьере, менеджера.
Работал я тогда ещё не очень много, но кое-что уже умел и был на позиции миддла классической ПА (метрики, рисерчи, тесты). Был я, значит, в одном из продуктов компании единственным аналитиком. Сам по себе дата-отдел был не большой, человек может 5.
Мой проект был тестовый, никто особо на него не ставил. В дальнейшем он и не взлетел — какие-то деньги, конечно, приносил, но с точки зрения бизнеса был не очень интересен. Но у нас была классная команда продукта, поэтому после решения о сворачивании, нас перекинули в другие проекты компании.
Всех, кроме меня. У меня были хорошие отзывы, всем всё нравилось, поэтому просто отпускать меня никто не хотел, но и закрепить в новый проект не могли — тупо не было куда. Я стал таким “подвешенным” продуктовым аналитиком без продукта (но с зарплатой).
А потом пришёл Макс, менеджер из какого-то мутного отдела (я даже сейчас не уверен чем они занимались), и говорит, а гоу наши задачки делать. “Ну, мне-то всё равно, гоу” — тогда подумал я, не подозревая как это перевенёт мой будущий подход в работе.
Первым же проектом, после пары вводных задач, была разработка, внимание, “искусственного байера”. Деталей не помню, но в плане Макса было классифицировать качество траффика катбустом, а потом эта модель ложилась в алгоритм бандитов. На входе мы давали этому боту денег и список сорсов, а он в риалтайме должен был перераспределять деньги на лучший, по его предиктам, траф.
Напомню, я тогда был прям олдскульный ПА, и про эти ваши алгоритмы разве что слышал краем уха. Говорю ему: “я чёт не уверен что вообще понимаю хотя бы половину из того что ты сейчас сказал”. И тут, к моему удивлению, он просто начал мне всё объяснять. Показал как вообще этот ваш DS устроен, познакомил с SHAP (в сердечке) и ещё всякой магией.
Оказалось, Макс не просто менеджер, а чел, глубоко увлекающийся анализом в целом и DS в частности. И в менеджмент он пришёл как раз из этой сферы.
Проект мы в итоге реализовали где-то за пол года. Не скажу что он получился прорывной, но по всем показателям не уступал реальным людям. Не лучше, но и не хуже. И зарплату не просил.
Зато после этой истории я всерьёз заинтересовался ML, много читал и смотрел, и в итоге стал использовать алгоритмы довольно часто в своей работе.
#кулстори
Хочу рассказать вам историю про самого значимого, в моей карьере, менеджера.
Работал я тогда ещё не очень много, но кое-что уже умел и был на позиции миддла классической ПА (метрики, рисерчи, тесты). Был я, значит, в одном из продуктов компании единственным аналитиком. Сам по себе дата-отдел был не большой, человек может 5.
Мой проект был тестовый, никто особо на него не ставил. В дальнейшем он и не взлетел — какие-то деньги, конечно, приносил, но с точки зрения бизнеса был не очень интересен. Но у нас была классная команда продукта, поэтому после решения о сворачивании, нас перекинули в другие проекты компании.
Всех, кроме меня. У меня были хорошие отзывы, всем всё нравилось, поэтому просто отпускать меня никто не хотел, но и закрепить в новый проект не могли — тупо не было куда. Я стал таким “подвешенным” продуктовым аналитиком без продукта (но с зарплатой).
А потом пришёл Макс, менеджер из какого-то мутного отдела (я даже сейчас не уверен чем они занимались), и говорит, а гоу наши задачки делать. “Ну, мне-то всё равно, гоу” — тогда подумал я, не подозревая как это перевенёт мой будущий подход в работе.
Первым же проектом, после пары вводных задач, была разработка, внимание, “искусственного байера”. Деталей не помню, но в плане Макса было классифицировать качество траффика катбустом, а потом эта модель ложилась в алгоритм бандитов. На входе мы давали этому боту денег и список сорсов, а он в риалтайме должен был перераспределять деньги на лучший, по его предиктам, траф.
Напомню, я тогда был прям олдскульный ПА, и про эти ваши алгоритмы разве что слышал краем уха. Говорю ему: “я чёт не уверен что вообще понимаю хотя бы половину из того что ты сейчас сказал”. И тут, к моему удивлению, он просто начал мне всё объяснять. Показал как вообще этот ваш DS устроен, познакомил с SHAP (в сердечке) и ещё всякой магией.
Оказалось, Макс не просто менеджер, а чел, глубоко увлекающийся анализом в целом и DS в частности. И в менеджмент он пришёл как раз из этой сферы.
Проект мы в итоге реализовали где-то за пол года. Не скажу что он получился прорывной, но по всем показателям не уступал реальным людям. Не лучше, но и не хуже. И зарплату не просил.
Зато после этой истории я всерьёз заинтересовался ML, много читал и смотрел, и в итоге стал использовать алгоритмы довольно часто в своей работе.
#кулстори
🔥24👍8