📌 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
📌 Беттинг, гэмблин, порно, ч.1
Мы здесь уже обсуждали этичность сфер, но сегодня в одном чате была похожая дискуссия.
Давайте, я, как человек, поработавший в этих сферах, побуду “адвокатом дьявола” 😈
Так получилось, что компании этих сфер пишут мне чаще остальных. Может их просто много, а может мой ценник в резюме не смущает только их 🙂
1️⃣ И это первая особенность таких компаний — у них всегда большие бюджеты. Как посмотришь на синьорские вилки “экологичных” команд с HH, так грустно становится. Да, это, конечно, во многом связано и с тем, что они рублёвые, а нормальная гэмбла в РФ не приживается, но какая мне разница, если я удалёнщик и не в РФ?
Моя первая компания этой категории разрабатывала адалтный дейтинг. Я тогда работал в “обычном” продукте и ещё у меня была параллельная компания а-ля фриланс, где мне платили по часам (кстати, это тоже был какой-то австралийский адалтный видео хостинг, но его не считаем ). Так вот этот дейтинг послушал мою историю и просто предложил перекрыть все мои доходы и ещё сверху накинуть, чтобы обидно не было. Уважаемо.
2️⃣ Второй момент — это почти полная свобода действий. Во всех, назовём их “сомнительными”, сферах, где я работал, у аналитиков полно свободы. Даже тот проект из вчерашнего поста, который мы пилили пол года, был исключительно нашей инициативой, а не задачей продукта, за которой стояла вертикаль менеджеров. Мы просто презентовали его, когда он был готов. И мы не делали его в “свободное от работы” время. Да, у тебя конечно есть задачи от команды, но там в основном отчётность, которая легко автоматизируется. Вся магия происходит вокруг новых идей.
Мы здесь уже обсуждали этичность сфер, но сегодня в одном чате была похожая дискуссия.
Давайте, я, как человек, поработавший в этих сферах, побуду “адвокатом дьявола” 😈
Так получилось, что компании этих сфер пишут мне чаще остальных. Может их просто много, а может мой ценник в резюме не смущает только их 🙂
Моя первая компания этой категории разрабатывала адалтный дейтинг. Я тогда работал в “обычном” продукте и ещё у меня была параллельная компания а-ля фриланс, где мне платили по часам (
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16
📌 Беттинг, гэмблин, порно, ч.2
3️⃣ Технологии. Третий крутой момент. Начиная от гибкости в выборе комфортного софта (любая цена компенсируется по умолчанию, без обсуждений), до поощрения любых экспериментов с методами и технологиями работы. Ты всегда можешь попробовать какую-то новую штуку просто по приколу, если понравится — пожалуйста, внедряй. Не понравится — ну и хрен с ней, не попробовал бы — не узнал. Никто слова не скажет про потраченное время и деньги. И это, опять же, в рабочее время.
И напоследок, когда я искал работу, общался с ребятами из крупного сербского беттинга. Просто оцените их условия:
👌 ЗП по договоренности, вилка от 5к$, верхнего порога нет;
👌 ЗП на карту, наличкой или криптой. Как тебе удобно;
👌 Своё 5-этажное фисное здание в центре Белграда, с парковкой и террасами с барбекю зоной на каждом этаже. В офис можно приезжать по желанию, можно только на шалыки;
👌 Релок пакет и предоставление ВНЖ на 3 года;
👌 Рабочий день 6 часов, с возможностью эти часы раскидать как удобно, лишь бы быть доступным для команды, когда это необходимо;
👌 Пятница — сокращённый “тусовый” день с барбекю и пивом, по желанию.
Лично для меня, работать в таких командах более этично и интересно, чем в том же ВК.
И напоследок, когда я искал работу, общался с ребятами из крупного сербского беттинга. Просто оцените их условия:
Лично для меня, работать в таких командах более этично и интересно, чем в том же ВК.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32
📌 Про необычную организацию рабочих инструментов
Я много где успел поработать и посмотреть как у кого устроена система инструментов. В основном это, конечно, гибкие истории. Обычно это Jira + Confluence, парочка баз данных, гугл диск, BI, ну и какой-то легаси кусок который и нести тяжело, и бросить жалко.
Но была у меня одна команда, для которой инструменты были не просто инструментами, а чуть ли не культом. У них это называлось как-то пафосно, типа “Принцип трёх”, “Правило трёх”,“Триединая святая Русь”. Не помню. Это была первая страница онбординга, обязательная к ознакомлению.
А смысл был в использовании командой только 3-х инструментов:
1️⃣ Notion — Основной инструмент для документации всего. Тут и описание данных, и инфа по всяким ивентам компании, и реквизиты и онбординг. Вообще всё, что может понадобиться. Я большой фанат Notion Labs, даже перевёл календарь на их новый продукт, поэтому был в восторге. По мне, так он сильно удобнее базового Confluence.
2️⃣ Miro — Сервис для досок. Тут хранились все идеи, схемы и наброски. Утверждённые идеи из Miro перетекали в Notion.
3️⃣ Chartio — BI-система. Основной инструмент работы аналитиков. Все мало-мальски значимые разработки заводились мини-проектами. Даже рисёрчи хранились тут в формате блоков с текстом, совмещёнными с графиками по ходу. Не так удобно как блокноты R или Python, но там глубина задач не предполагала уходить дальше SQL.
Было ещё 2, которые в эту систему не вписывались, но они и не столько про саму “работу”:
💭 Slack — тут понятно, без него просто никуда.
💭 OraPM — Таск-трекер, он же тайм-трекер. Не вписан в эту систему 3-х инструментов, идёт сбоку. Взял таску, врубил таймер, поехал. Отвратительно, конечно, но уж такой формат был. Сама по себе Ora, кстати, классная. Не Jira по функционалу, конечно, но для аналитиков хватало.
Вообще, это редкая история, когда инструментарий настолько жёстко закреплён, но в этом что-то есть. Из очевидных плюсов — ты не теряешься в файлах и документах, всё чётко на своих местах.
Как вам такой подход?
Я много где успел поработать и посмотреть как у кого устроена система инструментов. В основном это, конечно, гибкие истории. Обычно это Jira + Confluence, парочка баз данных, гугл диск, BI, ну и какой-то легаси кусок который и нести тяжело, и бросить жалко.
Но была у меня одна команда, для которой инструменты были не просто инструментами, а чуть ли не культом. У них это называлось как-то пафосно, типа “Принцип трёх”, “Правило трёх”,
А смысл был в использовании командой только 3-х инструментов:
Было ещё 2, которые в эту систему не вписывались, но они и не столько про саму “работу”:
Вообще, это редкая история, когда инструментарий настолько жёстко закреплён, но в этом что-то есть. Из очевидных плюсов — ты не теряешься в файлах и документах, всё чётко на своих местах.
Как вам такой подход?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
Приветики, хотите вам задачку сгенерю на продуктовое мышление? Там надо будет датасет покрутить ответить на простой вопрос «и чё теперь?» 🙂
Мини-тренажёр по оценке ситуации и умению мыслить от продукта без регистрации и смс!
Мини-тренажёр по оценке ситуации и умению мыслить от продукта без регистрации и смс!
👍35🔥15
📌 Задачка на продуктовое мышление
Вводная: Вы — продуктовый аналитик в букинг-сервисе (бронирование отелей и хостелов на короткие сроки).
Когда-то давно команда выкатила такую фичу: на странице выбора отеля есть кнопка “Сравнить”, при нажатии кнопки, система ищет доступные варианты в таком же стиле, в этом же районе на эти же даты. Фичу сделали, но никто её не анализировал, она живёт там сама по себе. Задача — понять всё ли там ок, или надо что-то менять.
Есть обзорная выгрузка логов юзеров, где:
🔵 time — время события, без даты. Для синтетического датасета даты тут не важны, а время просто для сортировки порядка ивентов;
🔵 event — событие: open_hotel (открыл страницу отеля), open_compare (открыл фичу сравнения), book (успешное бронирование);
🔵 sum_usd — списание за бронирование;
🔵 n_days — период бронирования;
Остальные поля, надеюсь, понятны 🙂
Задача: Проанализировать логи и принять решение что делаем дальше.
Правильного ответа нет, свои варианты или логику можно кидать в комменты⬇️
Вводная: Вы — продуктовый аналитик в букинг-сервисе (бронирование отелей и хостелов на короткие сроки).
Когда-то давно команда выкатила такую фичу: на странице выбора отеля есть кнопка “Сравнить”, при нажатии кнопки, система ищет доступные варианты в таком же стиле, в этом же районе на эти же даты. Фичу сделали, но никто её не анализировал, она живёт там сама по себе. Задача — понять всё ли там ок, или надо что-то менять.
Есть обзорная выгрузка логов юзеров, где:
Остальные поля, надеюсь, понятны 🙂
Задача: Проанализировать логи и принять решение что делаем дальше.
Правильного ответа нет, свои варианты или логику можно кидать в комменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍3❤2
booking_logs.csv
6.6 MB
Выгрузка к задаче. Она синтетическая, поэтому там могут встречаться артефакты в виде странной логики поведения, но в жизни тоже система аналитики легко может не довезти какую-то часть, так что реализм +100
📌 Метрика Adoption Rate
В продуктовой аналитике есть такая внегласная область User Interaction, это про взаимодействие юзера с продуктом через интерфейс. Так вот там есть “свой” набор метрик. Это те же самые продуктовые метрики, но с щепоткой контекста. Т.е. используются более узко, в рамках конкретной фичи.
‼️ И вот одна из главных метрик в UI-аналитике это Adoption Rate. AR показывает “заметность” фичи для пользователя И/ИЛИ соответствие ожидания-реальности при её использовании. Считается как
Поясню. Любая фича в продукте может быть более или менее значимой. В зависимости от этого, мы хотим её показать всем, или спрятать, чтобы нашли только те, кому она нужна. Поэтому у каждой фичи мы ожидаем своё "нормальное" значение. AR какой-нибудь тонкой настройки в профиле всегда будет ниже чем у кор-фичи.
А что про ожидание? Это скорее вопрос интуитивности. Возьмём для примера задачку из прошлого поста. Никого не смутило поведение функции “Сравнения”? Любой, кто хоть раз покупал что-то в магазине, может задаться вопросом “а что я буду сравнивать, с чем, и по каким характеристикам? А зачем мне это вообще надо?” Хотя нажми он кнопку, получил бы классную подборку вариантов не хуже, а может и дешевле.
Низкий AR при хороших прочих показателях фичи, задизайненной под большинство, почти всегда КРИЧИТ о проблемах в восприятии юзерами. Или триггер старта сценария фичи слишком спрятан, или не очевидна его ценность, или он просто затирается “баннерной слепотой”.
В продуктовой аналитике есть такая внегласная область User Interaction, это про взаимодействие юзера с продуктом через интерфейс. Так вот там есть “свой” набор метрик. Это те же самые продуктовые метрики, но с щепоткой контекста. Т.е. используются более узко, в рамках конкретной фичи.
Например, Retention rate. В классическом понимании RR показывает насколько часто юзер возвращается, хороший показатель метрики намекает, что юзера всё устраивает и он продолжает пользоваться продуктом.
В анализе конкретной фичи RR похожа, но говорит об удовлетворённости пользователя не всем продуктом, а конкретной фичей. Нравится ли она ему настолько, что он вписывает её в свой повседневный флоу взаимодействия с продуктом. Т.е. RR тут может быть высоким, в то время как основной продуктовый RR низким. И наоборот.
количество юзеров фичи / всех активных юзеров.Поясню. Любая фича в продукте может быть более или менее значимой. В зависимости от этого, мы хотим её показать всем, или спрятать, чтобы нашли только те, кому она нужна. Поэтому у каждой фичи мы ожидаем своё "нормальное" значение. AR какой-нибудь тонкой настройки в профиле всегда будет ниже чем у кор-фичи.
А что про ожидание? Это скорее вопрос интуитивности. Возьмём для примера задачку из прошлого поста. Никого не смутило поведение функции “Сравнения”? Любой, кто хоть раз покупал что-то в магазине, может задаться вопросом “а что я буду сравнивать, с чем, и по каким характеристикам? А зачем мне это вообще надо?” Хотя нажми он кнопку, получил бы классную подборку вариантов не хуже, а может и дешевле.
Низкий AR при хороших прочих показателях фичи, задизайненной под большинство, почти всегда КРИЧИТ о проблемах в восприятии юзерами. Или триггер старта сценария фичи слишком спрятан, или не очевидна его ценность, или он просто затирается “баннерной слепотой”.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍5🔥2
Приветики, хочу спойлернуть вам мини проект, который, планирую релизнуть на выходных. С кодом на гитхабе, с описанием на хабре, вот это вот всё.
Кароч,3Д-экшон суть такова как-то у меня был проект рабочий, где нужно было выпилить часть фичей из продукта, которые не выгодно обслуживать. Какие — не уточнялось, но что-нибудь надо снести. Чтобы вычислить аутсайдеров, логично сравнить все фичи между собой. Это понятно. Не понятно как сравнить и по каким критериям. Потому что начиная в этом всём копаться, осознаёшь что у каждой части свои приколы и как будто стандартизировать шкалу оценок нельзя. И так то оно так, но немножко, всё таки, можно.
В той задаче была другая цель, но сама по себе идея прикладного фича-анализатора мне нравилась.
В итоге это должна быть некая system, в которую ты грузишь свой датасет, а она раскидывает это всё красиво, чтоб ты обзорно понимал характер фичей и их импакт. А потом уже, с этой инфой шёл рыть те, которые выглядят перспективнее.
Сейчас я уже вывел набор из 5-ти параметров-метрик, которые относительно равномерно ложатся в большинство интерфейсных фичей и глобально покрывают и UX и экономику. Закончил тесты на разные типы фичей, чтобы убедиться что всё ложится равномерненько. Пока не придумал как оптимизировать структуру данных на вход, чтобы это была не таблица на 146 млн строк, но и чтобы запрос был не на 5 листов формата а4, и чтобы всё это было применимо к разным проектам, естественно.
В идеале ещё сделать автоматическое распознавание фичей и их ключевых точек. Но тут пока ноль идей, в какой-нибудь другой версии потом может придумаю.
Кароч,
В той задаче была другая цель, но сама по себе идея прикладного фича-анализатора мне нравилась.
В итоге это должна быть некая system, в которую ты грузишь свой датасет, а она раскидывает это всё красиво, чтоб ты обзорно понимал характер фичей и их импакт. А потом уже, с этой инфой шёл рыть те, которые выглядят перспективнее.
Сейчас я уже вывел набор из 5-ти параметров-метрик, которые относительно равномерно ложатся в большинство интерфейсных фичей и глобально покрывают и UX и экономику. Закончил тесты на разные типы фичей, чтобы убедиться что всё ложится равномерненько. Пока не придумал как оптимизировать структуру данных на вход, чтобы это была не таблица на 146 млн строк, но и чтобы запрос был не на 5 листов формата а4, и чтобы всё это было применимо к разным проектам, естественно.
В идеале ещё сделать автоматическое распознавание фичей и их ключевых точек. Но тут пока ноль идей, в какой-нибудь другой версии потом может придумаю.
👍16🔥6
📌 Про DataLore и DataSpell
Почти неделю ничего не писал, а теперь врываюсь сразу с рекламой. Ладно, это просто рекомендация классных штук 🙂
Как-то кто-то мне с воодушевлением рассказывал про новый продукт JetBrains, который DataSpell, я послушал, покивал и благополучно забил. А на днях у меня появилось желание завести Jupyter в облаке под R. С юпитером я не работал толком, когда-то давно под это дело ставил Anaconda, потом немножко смотрел на блокноты через VSCode и PyCharm, но мне не понравилось.
А тут ради интереса пошёл посмотреть на DataSpell. Там я конечно вообще не понял как работать с блокнотами в R, но это и не важно стало потом 🙂
Когда я его ставил, JB любезно предложили мне попробовать ещё их облачный сервис DataLore. И вот это уже оказалось офигенно. Это простое корпоративное облако, к которому можно затянуть предустановленные коннекторы к базам данных (выбор по джетбрейновски огромный) или накидать файлами в проекты. Проект там это блокнот Jupyter с поддержкой R в том числе, все базовые приколы типа обновлений по расписанию и репортов — в наличии. А ещё блокнот можно компилировать в отчёт для не-аналитиков, скрыв код. За это отвечает отдельный интерфейс а-ля конструктор отчётов.
Секьюрность настраивается гибко. По дефолту в домене компании, но можно и раздавать отдельно на конкретных юзеров. В общем — моё почтение.
Как инструмент синхронизации аналитических артефактов — пока видится мне единственным завершённым на рынке, с удобным хранением скриптов R/Python/SQL и документации, например к тестам. Единственный минус для меня — не умеет запускать реактивные приложения Shiny. Но это было бы уже совсем круто 🙂
Кароч выглядит как конкурент Google Collab, только убивает последнего за счет гибкости.
А DataSpell, с которого всё началось, в целом выглядит как удобная комбинация DataGrip + PyCharm + R Studio + DBT. Всё в одном месте, всё удобно и красиво. Но я пока не готов переходить на него, R Studio всё-таки имеет много мелких приколов, от которых я не готов отказаться пока.
#инструменты
Почти неделю ничего не писал, а теперь врываюсь сразу с рекламой. Ладно, это просто рекомендация классных штук 🙂
Как-то кто-то мне с воодушевлением рассказывал про новый продукт JetBrains, который DataSpell, я послушал, покивал и благополучно забил. А на днях у меня появилось желание завести Jupyter в облаке под R. С юпитером я не работал толком, когда-то давно под это дело ставил Anaconda, потом немножко смотрел на блокноты через VSCode и PyCharm, но мне не понравилось.
А тут ради интереса пошёл посмотреть на DataSpell. Там я конечно вообще не понял как работать с блокнотами в R, но это и не важно стало потом 🙂
Когда я его ставил, JB любезно предложили мне попробовать ещё их облачный сервис DataLore. И вот это уже оказалось офигенно. Это простое корпоративное облако, к которому можно затянуть предустановленные коннекторы к базам данных (выбор по джетбрейновски огромный) или накидать файлами в проекты. Проект там это блокнот Jupyter с поддержкой R в том числе, все базовые приколы типа обновлений по расписанию и репортов — в наличии. А ещё блокнот можно компилировать в отчёт для не-аналитиков, скрыв код. За это отвечает отдельный интерфейс а-ля конструктор отчётов.
Секьюрность настраивается гибко. По дефолту в домене компании, но можно и раздавать отдельно на конкретных юзеров. В общем — моё почтение.
Как инструмент синхронизации аналитических артефактов — пока видится мне единственным завершённым на рынке, с удобным хранением скриптов R/Python/SQL и документации, например к тестам. Единственный минус для меня — не умеет запускать реактивные приложения Shiny. Но это было бы уже совсем круто 🙂
Кароч выглядит как конкурент Google Collab, только убивает последнего за счет гибкости.
А DataSpell, с которого всё началось, в целом выглядит как удобная комбинация DataGrip + PyCharm + R Studio + DBT. Всё в одном месте, всё удобно и красиво. Но я пока не готов переходить на него, R Studio всё-таки имеет много мелких приколов, от которых я не готов отказаться пока.
#инструменты
👍6🔥3🤔2❤1
📌 Аналитическая система с единорогами и пони
Мне довелось поработать со многими командами, и у каждой была какая-то своя система хранения и работы с данными. Тут я не про принципы, а про инфраструктуру. И вот чёт недавно я задумался об идеальной, на мой взгляд, системе.
Почти всё я выбрал исключительно потому что нравится 🙂 Я не дата-инженер, поэтому что-то может быть не оптимально, но это мой комфортный стек работы со стороны ПА.
Получился вот такой наборчик:
🔵 Данные с бэка, про платежи, регистрации, данные юзеров и вот это вот всё я бы хранил в Postgre. Потому что надёжная и неубиваемая система. Как та самая нокия. А для бэка это главный критерий, на мой взгляд, т.к. тут самые чувствительные данные.
🔵 Фронтовый трекер для событий — вот тут хз, раньше был крутой опенсорсный Segment. Весил мало, загрузку не импрувил, user-based. Не умел ничего кроме трека ивентов, но с этой задачей справлялся прекрасно. Вот какой-то такой аналог бы. Может в сторону своей разработки бы смотрел. Ключевой параметр — легкость.
🔵 ETL-процессинг исключительно самописный, потому что это не дорого (в масштабах остального) и всегда можно тонко настроить. А для внезапных витринок сюда же прикручиваем DBT.
🔵 Кликстрим по фронту складывал бы в колоночную бд, т.к. в запросе обычно нужно мало полей на много строк, а не наоборот. Тут бы зашёл Clickhouse или Vertica. Работал с кликстримом в строковых бд, запрос на >5 млн строк вообще не реально выгрузить. Но вроде как CH на масштабах проигрывает Вертике (но это не точно, слышал такое где-то).
🔵 По BI тут два инструмента. В качестве основы для постоянных бордов Shiny (жестко, но стабильно, быстро и функционал ограничен только твоей фантазией). А для временных бордов и черновиков Redash (простой, быстрый, гибкости для времянок достаточно).
🔵 Как working-area / хранилище артефактов, рисерчей, результатов экспериментов и т.д. для аналитиков поднял бы DataLore.
Интересно, насколько это вообще жизнеспособная схема со стороны инженерии, но работать аналитику в такой — одно удовольствие 🙂
Мне довелось поработать со многими командами, и у каждой была какая-то своя система хранения и работы с данными. Тут я не про принципы, а про инфраструктуру. И вот чёт недавно я задумался об идеальной, на мой взгляд, системе.
Почти всё я выбрал исключительно потому что нравится 🙂 Я не дата-инженер, поэтому что-то может быть не оптимально, но это мой комфортный стек работы со стороны ПА.
Получился вот такой наборчик:
Интересно, насколько это вообще жизнеспособная схема со стороны инженерии, но работать аналитику в такой — одно удовольствие 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥1
Интересно, зайдут тут SQL-сниппеты, или не нужны никому, потестим 🙂
Вот довольно популярный сниппет, когда нужно найти что-то наиболее частое, например с каких девайсов обычно сидит юзер, или какой язык использует чаще и т.д.
Я это делаю через подсчёт строк и отбора топ-1 по каждому юзеру. Для примера, нужно найти самый популярный девайс юзера:
Логика простая, сначала выстраиваем поюзерный список девайсов с сортировкой по бОльшему количеству чего-нибудь, нумеруем строки, а потом отрезаем все строки, что не 1.
Тут весь прикол в
#сниппеты
Вот довольно популярный сниппет, когда нужно найти что-то наиболее частое, например с каких девайсов обычно сидит юзер, или какой язык использует чаще и т.д.
Я это делаю через подсчёт строк и отбора топ-1 по каждому юзеру. Для примера, нужно найти самый популярный девайс юзера:
select user_id,
device as most_used_device
from (select user_id,
device,
row_number() as over(partition by user_id order by user_id, count(*) desc) as rn
from database
group by 1, 2) as t1
where rn = 1
Логика простая, сначала выстраиваем поюзерный список девайсов с сортировкой по бОльшему количеству чего-нибудь, нумеруем строки, а потом отрезаем все строки, что не 1.
Тут весь прикол в
count(*), сюда засовывать нужно то, что логически подойдёт, если это ивенты, то лучше их на дни попилить, чтобы мы не девайсы по количеству ивентов тащили 🙂#сниппеты
❤24🔥8👍4