Учимся создавать «окна» в SQL
В прошлом посте мы узнали, зачем нужны оконные функции. Теперь научимся их объявлять. Все начинается с инструкции OVER() - она и определяет наше «окно».
Ключевые команды внутри OVER():
▪️PARTITION BY - разделяет данные на группы (партиции). Как GROUP BY, но без «схлопывания» строк. Считает функцию внутри каждой группы отдельно.
▪️ORDER BY - сортирует строки внутри окна. Критично для функций нарастающего итога, ранжирования и смещения (LAG/LEAD).
Разберем на примере простой таблички, содержащей дату, канал с которого пришел пользователь и количество конверсий:
Что произойдет?
▪PARTITION BY Date создаст отдельное «окно» для каждой даты. Сумма будет считаться только в рамках одного дня.
▪ORDER BY medium отсортирует каналы внутри каждой даты.
▪SUM(conversions) в паре с ORDER BY рассчитает нарастающий итог конверсий внутри каждого дня. Для первой строки в окне (дне) sum будет равен ее conversions, для второй - сумме первой и второй, и так далее.
⚠️ Важно: ROWS / RANGE управляют диапазоном строк, по которым считается оконная функция. И даже если ничего не указывать, то по умолчанию используется RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.
В результате выполнения запроса мы получим примерно такую табличку:
Основы разобрали! Далее я расскажу как сужать фокус окна до «скользящего» диапазона с помощью ROWS BETWEEN.
#харды #sql
В прошлом посте мы узнали, зачем нужны оконные функции. Теперь научимся их объявлять. Все начинается с инструкции OVER() - она и определяет наше «окно».
Ключевые команды внутри OVER():
▪️PARTITION BY - разделяет данные на группы (партиции). Как GROUP BY, но без «схлопывания» строк. Считает функцию внутри каждой группы отдельно.
▪️ORDER BY - сортирует строки внутри окна. Критично для функций нарастающего итога, ранжирования и смещения (LAG/LEAD).
Разберем на примере простой таблички, содержащей дату, канал с которого пришел пользователь и количество конверсий:
SELECT
date AS dt
, medium AS med
, conversions AS conv
, SUM(conversions) OVER(PARTITION BY date ORDER BY medium) AS sum
FROM orders
Что произойдет?
▪PARTITION BY Date создаст отдельное «окно» для каждой даты. Сумма будет считаться только в рамках одного дня.
▪ORDER BY medium отсортирует каналы внутри каждой даты.
▪SUM(conversions) в паре с ORDER BY рассчитает нарастающий итог конверсий внутри каждого дня. Для первой строки в окне (дне) sum будет равен ее conversions, для второй - сумме первой и второй, и так далее.
⚠️ Важно: ROWS / RANGE управляют диапазоном строк, по которым считается оконная функция. И даже если ничего не указывать, то по умолчанию используется RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.
В результате выполнения запроса мы получим примерно такую табличку:
dt med conv sum
10.05.20 cpa 1 1
10.05.20 cpc 2 3
10.05.20 organic 1 4
11.05.20 cpa 1 1
11.05.20 cpc 3 4
11.05.20 direct 1 5
11.05.20 organic 2 7
12.05.20 cpc 1 1
12.05.20 organic 2 3
Основы разобрали! Далее я расскажу как сужать фокус окна до «скользящего» диапазона с помощью ROWS BETWEEN.
#харды #sql
❤21👍14🤔1💯1
Сегодня поговорим про экосистемные метрики. Или, если слово «экосистема» кажется слишком громким - про мультипродуктовые, сквозные пользовательские метрики.
В России настоящих экосистем не так уж много: Т-Банк, Сбер, Яндекс, МТС. Но чтобы применять экосистемные метрики, не обязательно быть «экосистемой». Достаточно иметь несколько продуктов и общего пользователя.
Сначала давайте разберемся, что же такое «экосистема»?
Когда у компании один продукт, чаще всего все довольно просто и грубо. Обычно считают доходы и расходы. Юнит-экономика, Retention, LTV и CAC приходят позже, когда продуктов становится больше и бизнес усложняется.
И вот здесь часто возникает ошибка: каждый продукт продолжают измерять изолированно, как будто пользователь существует внутри одного сервиса. Но пользователь так не живет. Он может прийти через один продукт, попробовать второй, регулярно пользоваться третьим, а деньги принести в четвертом. Для клиента это один непрерывный опыт, а для аналитики - набор разрозненных витрин.
А что такое «экосистемная метрика»?
Такие метрики нужны не «для красоты». Они используются в дереве метрик, чтобы понимать вклад конкретного продукта во всю систему, а также чтобы корректно оценивать эффекты A/B-тестов, которые почти всегда выходят за рамки одного продукта.
Когда компания начинает смотреть на бизнес через призму «мультипродуктовости», сильно меняется управленческое мышление. Отдельный продукт может быть убыточным или вообще не монетизироваться, но при этом оставаться важной частью всей конструкции - снижать стоимость привлечения, усиливать вовлечение, повышать удержание или раскрывать ценность других продуктов. В продуктовой логике такие сервисы хочется закрыть. В экосистемной - это элементы, из которых собирается эффективная бизнес-модель.
Дополнительно появляется эффект снижения CAC и роста удержания. Пользователей можно вовлекать в новые продукты не только через внешний маркетинг, но и за счет уже существующей базы. А пользователь, который использует несколько продуктов, значительно реже полностью уходит, даже если один из сервисов перестал быть для него ценным.
Какой вывод?
Если у вас несколько продуктов, не живите в логике одного продукта. Не измеряйте бизнес как набор независимых сервисов. Измеряйте пользователя ваших продуктов - именно там находится реальная ценность и реальные управленческие решения.
#харды #метрики
В России настоящих экосистем не так уж много: Т-Банк, Сбер, Яндекс, МТС. Но чтобы применять экосистемные метрики, не обязательно быть «экосистемой». Достаточно иметь несколько продуктов и общего пользователя.
Сначала давайте разберемся, что же такое «экосистема»?
Экосистема - это портфель продуктов, в основе которого лежит платформа единого профиля пользователя и между продуктами которого существует передаточная ценность.
Это система взаимосвязей между продуктами и сервисами, добавляющая им ценность. В определенный момент связи дают больше пользы, чем все составные части экосистемы в сумме.
Когда у компании один продукт, чаще всего все довольно просто и грубо. Обычно считают доходы и расходы. Юнит-экономика, Retention, LTV и CAC приходят позже, когда продуктов становится больше и бизнес усложняется.
И вот здесь часто возникает ошибка: каждый продукт продолжают измерять изолированно, как будто пользователь существует внутри одного сервиса. Но пользователь так не живет. Он может прийти через один продукт, попробовать второй, регулярно пользоваться третьим, а деньги принести в четвертом. Для клиента это один непрерывный опыт, а для аналитики - набор разрозненных витрин.
А что такое «экосистемная метрика»?
Экосистемная метрика - это метрика, описывающая сразу несколько продуктов, а не один конкретный.
Это метрика, которая позволяет перейти от математики продукта к математике пользователя и экосистемы в целом.
Такие метрики нужны не «для красоты». Они используются в дереве метрик, чтобы понимать вклад конкретного продукта во всю систему, а также чтобы корректно оценивать эффекты A/B-тестов, которые почти всегда выходят за рамки одного продукта.
Когда компания начинает смотреть на бизнес через призму «мультипродуктовости», сильно меняется управленческое мышление. Отдельный продукт может быть убыточным или вообще не монетизироваться, но при этом оставаться важной частью всей конструкции - снижать стоимость привлечения, усиливать вовлечение, повышать удержание или раскрывать ценность других продуктов. В продуктовой логике такие сервисы хочется закрыть. В экосистемной - это элементы, из которых собирается эффективная бизнес-модель.
Дополнительно появляется эффект снижения CAC и роста удержания. Пользователей можно вовлекать в новые продукты не только через внешний маркетинг, но и за счет уже существующей базы. А пользователь, который использует несколько продуктов, значительно реже полностью уходит, даже если один из сервисов перестал быть для него ценным.
Какой вывод?
Если у вас несколько продуктов, не живите в логике одного продукта. Не измеряйте бизнес как набор независимых сервисов. Измеряйте пользователя ваших продуктов - именно там находится реальная ценность и реальные управленческие решения.
#харды #метрики
1👍15❤8🤔1
Если вы искали исчерпывающий курс по управлению данными, то он здесь, в одной книге на 800 страниц. Но приготовьтесь - это вам не «Котики».
📚 DAMA-DMBOK: Свод знаний по управлению данными. 2-е издание
The Data Management Association - это международная некоммерческая организация, которая поддерживает и развивает профессиональное сообщество в области управления данными. Она была основана в 1980-х и ранее называлась Data Administration Management Association или сокращенно DAMA. Организация знаменита публикацией ключевого справочника по управлению данными Data Management Body of Knowledge или DMBOK.
Справочник DAMA-DMBOK содержит лучшие практики, методологии и рекомендации по различным аспектам управления данными. Он охватывает 10 ключевых областей, включая архитектуру и проектирование данных, хранилища данных и бизнес-аналитику, управление качеством данных и метаданными. Авторы стремятся стандартизировать процессы работы с данными и улучшить их управление. Поэтому DAMA-DMBOK - стандарт в дата-менеджменте и основное пособие для подготовки к экзамену на Certified Data Management Professional (CDMP). Берем на заметку.
🔗 Первое издание вышло в 2009 году, второе опубликовано в 2017 году. Именно оно переведено на русский язык и продается в бумажном варианте за много денег, например, на OZON. Электронную версию в PDF - качайте по ссылке.
#книга
📚 DAMA-DMBOK: Свод знаний по управлению данными. 2-е издание
The Data Management Association - это международная некоммерческая организация, которая поддерживает и развивает профессиональное сообщество в области управления данными. Она была основана в 1980-х и ранее называлась Data Administration Management Association или сокращенно DAMA. Организация знаменита публикацией ключевого справочника по управлению данными Data Management Body of Knowledge или DMBOK.
Справочник DAMA-DMBOK содержит лучшие практики, методологии и рекомендации по различным аспектам управления данными. Он охватывает 10 ключевых областей, включая архитектуру и проектирование данных, хранилища данных и бизнес-аналитику, управление качеством данных и метаданными. Авторы стремятся стандартизировать процессы работы с данными и улучшить их управление. Поэтому DAMA-DMBOK - стандарт в дата-менеджменте и основное пособие для подготовки к экзамену на Certified Data Management Professional (CDMP). Берем на заметку.
🔗 Первое издание вышло в 2009 году, второе опубликовано в 2017 году. Именно оно переведено на русский язык и продается в бумажном варианте за много денег, например, на OZON. Электронную версию в PDF - качайте по ссылке.
#книга
1❤28🔥6
Как поддерживать форму, будучи руководителем?
Помнишь то чувство, когда ты впервые стал руководителем? Выходишь со встречи, на которой решаются важные вопросы, и понимаешь масштаб новой роли! А какие открываются горизонты…
Но в этой новой реальности есть и обратная сторона - постепенное отдаление от «земли». Как бывший аналитик, я ощутил это на себе: чем глубже погружаешься в менеджмент, тем выше риск потерять харды. Если расслабиться, то однажды можно обнаружить, что опыт больше не подкрепляется актуальными знаниями.
Здесь должен работать принцип, знакомый любому спортсмену: чтобы не потерять форму, нужно постоянно тренироваться. Нельзя уйти только в менеджмент, полностью забросив профессиональные навыки.
Я выработал для себя несколько рабочих практик:
▪️Сознательно оставлять за собой право брать сложные проекты, которые требуют глубокого погружения. Делегировать важно, но иногда нужно и самому «поработать руками», чтобы поддерживать уровень и понимать, с какими реальными вызовами сейчас сталкивается команда.
▪️Системное обучение - обязательно. Это может быть изучение перспективного языка, фреймворка или углубленный курс по новой технологии. Такой подход позволяет расширять кругозор и приносить в команду конкретные, проверенные на себе знания и идеи для внедрения.
▪️Очень эффективной практикой стало ревью задач команды. Берешь задачу, детально разбираешь решение, предлагаешь альтернативы, делишься опытом по оптимизации кода или архитектуры. Для команды - развитие и поддержка, а для меня - лучший способ оставаться в профессиональном тонусе.
Сила руководителя - в синергии. Умение мотивировать, вдохновлять и выстраивать процессы - это фундамент. Но подлинный авторитет и эффективность рождаются там, где этот фундамент подкреплен живой экспертизой и прочной связью с реальной работой.
Тренируйте свои профессиональные «мышцы» так же регулярно, как и управленческие. Именно эта дисциплина отделяет просто начальника от настоящего лидера.
#опыт
Помнишь то чувство, когда ты впервые стал руководителем? Выходишь со встречи, на которой решаются важные вопросы, и понимаешь масштаб новой роли! А какие открываются горизонты…
Но в этой новой реальности есть и обратная сторона - постепенное отдаление от «земли». Как бывший аналитик, я ощутил это на себе: чем глубже погружаешься в менеджмент, тем выше риск потерять харды. Если расслабиться, то однажды можно обнаружить, что опыт больше не подкрепляется актуальными знаниями.
Здесь должен работать принцип, знакомый любому спортсмену: чтобы не потерять форму, нужно постоянно тренироваться. Нельзя уйти только в менеджмент, полностью забросив профессиональные навыки.
Я выработал для себя несколько рабочих практик:
▪️Сознательно оставлять за собой право брать сложные проекты, которые требуют глубокого погружения. Делегировать важно, но иногда нужно и самому «поработать руками», чтобы поддерживать уровень и понимать, с какими реальными вызовами сейчас сталкивается команда.
▪️Системное обучение - обязательно. Это может быть изучение перспективного языка, фреймворка или углубленный курс по новой технологии. Такой подход позволяет расширять кругозор и приносить в команду конкретные, проверенные на себе знания и идеи для внедрения.
▪️Очень эффективной практикой стало ревью задач команды. Берешь задачу, детально разбираешь решение, предлагаешь альтернативы, делишься опытом по оптимизации кода или архитектуры. Для команды - развитие и поддержка, а для меня - лучший способ оставаться в профессиональном тонусе.
Сила руководителя - в синергии. Умение мотивировать, вдохновлять и выстраивать процессы - это фундамент. Но подлинный авторитет и эффективность рождаются там, где этот фундамент подкреплен живой экспертизой и прочной связью с реальной работой.
Тренируйте свои профессиональные «мышцы» так же регулярно, как и управленческие. Именно эта дисциплина отделяет просто начальника от настоящего лидера.
#опыт
❤17🔥10
В рамках ежегодного исследования рынка аналитиков, ребята из NEWHR выпустили первую его часть, а именно ТОП экспертов и каналов.
На лендинге вы найдете рейтинги ТОП-15 экспертов и ТОП-30 Telegram-каналов, интересных аналитикам + полные списки.
Они разделены по специализациям: для продуктовых, маркетинговых, дата-, веб- и BI-аналитиков и отдельно для системных и бизнес-аналитиков.
Также хотел поделиться небольшим списком каналов, которые читаю сам и вам советую:
🔹 Статистика и R в науке и аналитике
🔹 Math for Impact
🔹 JetMetrics
🔹 Data Nature
А что читаете вы? Поделитесь в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Как в SQL настроить фокус окна?
В прошлый раз мы научились делить данные на окна. Но что, если нам нужно посчитать результат не по всей группе, а сумму с соседней строкой?
Когда я осваивал оконные функции, для меня самым сложным было разобраться не с OVER, партициями или самими функциями, а именно с настройками окна.
Инструкция ROWS позволяет ограничить строки в окне, указывая фиксированное количество строк, предшествующих или следующих за текущей.
RANGE, в отличие от ROWS, работает не с физическими строками, а с диапазоном значений ORDER BY. Поэтому несколько строк с одинаковым значением могут попадать в одно окно.
Обе инструкции ROWS и RANGE всегда используются вместе с ORDER BY.
Возьмем наш пример и посчитаем сумму по текущей и следующей строке внутри каждого дня:
Результат выполнения и логику запроса смотрите на картинке.
В выражении для ограничения окна также можно использовать следующие ключевые слова:
▪️UNBOUNDED PRECEDING - указывает, что окно начинается с первой строки группы;
▪️UNBOUNDED FOLLOWING - с помощью данной инструкции можно указать, что окно заканчивается на последней строке группы;
▪️CURRENT ROW - инструкция указывает, что окно начинается или заканчивается на текущей строке;
▪️BETWEEN «граница окна» AND «граница окна» - указывает нижнюю и верхнюю границу;
▪️«Значение» PRECEDING - определяет число строк перед текущей строкой (не допускается в RANGE);
▪️«Значение» FOLLOWING - определяет число строк после текущей строки (не допускается в RANGE).
Комбинируя ключевые слова, вы можете подогнать диапазон работы оконной функции под вашу специфическую задачу.
Далее разберем самые полезные оконные функции.
#харды #sql
В прошлый раз мы научились делить данные на окна. Но что, если нам нужно посчитать результат не по всей группе, а сумму с соседней строкой?
Когда я осваивал оконные функции, для меня самым сложным было разобраться не с OVER, партициями или самими функциями, а именно с настройками окна.
Инструкция ROWS позволяет ограничить строки в окне, указывая фиксированное количество строк, предшествующих или следующих за текущей.
RANGE, в отличие от ROWS, работает не с физическими строками, а с диапазоном значений ORDER BY. Поэтому несколько строк с одинаковым значением могут попадать в одно окно.
Обе инструкции ROWS и RANGE всегда используются вместе с ORDER BY.
Возьмем наш пример и посчитаем сумму по текущей и следующей строке внутри каждого дня:
SELECT
date
, medium
, conversions
, SUM(conversions) OVER(PARTITION BY date ORDER BY medium ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING) AS sum
FROM orders
Результат выполнения и логику запроса смотрите на картинке.
В выражении для ограничения окна также можно использовать следующие ключевые слова:
▪️UNBOUNDED PRECEDING - указывает, что окно начинается с первой строки группы;
▪️UNBOUNDED FOLLOWING - с помощью данной инструкции можно указать, что окно заканчивается на последней строке группы;
▪️CURRENT ROW - инструкция указывает, что окно начинается или заканчивается на текущей строке;
▪️BETWEEN «граница окна» AND «граница окна» - указывает нижнюю и верхнюю границу;
▪️«Значение» PRECEDING - определяет число строк перед текущей строкой (не допускается в RANGE);
▪️«Значение» FOLLOWING - определяет число строк после текущей строки (не допускается в RANGE).
Комбинируя ключевые слова, вы можете подогнать диапазон работы оконной функции под вашу специфическую задачу.
Далее разберем самые полезные оконные функции.
#харды #sql
🔥27❤3
Давно я не писал про пирамиду метрик, а ведь с последнего поста остались неразобранными еще два слоя.
Мы добрались до метрик качества. Как вы помните, чем ниже мы спускаемся по пирамиде, тем сильнее метрики влияют на продукт. Из трех подслоев продуктового уровня именно подслой качества отвечает за надежность продукта, его стабильность и соответствие ожиданиям пользователей.
Здесь хочется вспомнить незатейливый слоган:
Метрики качества – это фундамент доверия и долгосрочного успеха. Без них можно сколько угодно создавать ценность и работать над лояльностью, но один сбой, медленная загрузка или волна ошибок сведут все усилия на нет. Именно качество напрямую влияет на удержание, репутацию и в конечном счете на экономику продукта.
Как это измерить? Я выделяю четыре группы метрик, которые стоит мониторить любой продуктовой и инженерной команде.
1. Метрики надежности
Здесь все просто. Пользователь должен иметь доступ к продукту. Ключевые показатели:
▪️Uptime;
▪️SLA;
▪️Коэффициент ошибок.
Это базовый уровень доверия.
2. Метрики функциональности и стабильности
Продукт не только должен работать, но и работать правильно.
▪️Доля ошибок;
▪️Процент негативных обращений в поддержку;
▪️Доля пользователей, столкнувшихся с проблемами.
Эти цифры показывают, насколько стабилен ваш функционал в реальных условиях, а не в тестовой среде.
3. Метрики производительности
Даже если все работает без ошибок, но медленно – ценность падает.
▪️Время загрузки страниц или экранов;
▪️Время отклика на действия.
Просадки здесь сразу бьют по вовлечению и конверсиям.
4. Метрики контроля качества
Это уже про внутренние процессы:
▪️Бюджет ошибок (сколько проблем мы готовы принять);
▪️Процент успешных тестов;
▪️Количество непредвиденных инцидентов после релиза.
Эти метрики помогают оценить, насколько эффективно мы предупреждаем сбои и управляем рисками.
Пренебрежение любым из этих блоков ведет к просадке качества. А это прямая угроза доверию клиентов, удержанию и репутации. Инвестиции в качество всегда окупаются, потому что предотвращают колоссальные затраты на исправление последствий и возврат ушедших пользователей.
Последний слой пирамиды метрик – самый близкий к пользователю: интерфейс продукта и маркетинг. Но его мы разберем в следующий раз.
#харды #метрики #разбор_метрик
Мы добрались до метрик качества. Как вы помните, чем ниже мы спускаемся по пирамиде, тем сильнее метрики влияют на продукт. Из трех подслоев продуктового уровня именно подслой качества отвечает за надежность продукта, его стабильность и соответствие ожиданиям пользователей.
Здесь хочется вспомнить незатейливый слоган:
Нормально делай – нормально будет.
Метрики качества – это фундамент доверия и долгосрочного успеха. Без них можно сколько угодно создавать ценность и работать над лояльностью, но один сбой, медленная загрузка или волна ошибок сведут все усилия на нет. Именно качество напрямую влияет на удержание, репутацию и в конечном счете на экономику продукта.
Как это измерить? Я выделяю четыре группы метрик, которые стоит мониторить любой продуктовой и инженерной команде.
1. Метрики надежности
Здесь все просто. Пользователь должен иметь доступ к продукту. Ключевые показатели:
▪️Uptime;
▪️SLA;
▪️Коэффициент ошибок.
Это базовый уровень доверия.
2. Метрики функциональности и стабильности
Продукт не только должен работать, но и работать правильно.
▪️Доля ошибок;
▪️Процент негативных обращений в поддержку;
▪️Доля пользователей, столкнувшихся с проблемами.
Эти цифры показывают, насколько стабилен ваш функционал в реальных условиях, а не в тестовой среде.
3. Метрики производительности
Даже если все работает без ошибок, но медленно – ценность падает.
▪️Время загрузки страниц или экранов;
▪️Время отклика на действия.
Просадки здесь сразу бьют по вовлечению и конверсиям.
4. Метрики контроля качества
Это уже про внутренние процессы:
▪️Бюджет ошибок (сколько проблем мы готовы принять);
▪️Процент успешных тестов;
▪️Количество непредвиденных инцидентов после релиза.
Эти метрики помогают оценить, насколько эффективно мы предупреждаем сбои и управляем рисками.
Пренебрежение любым из этих блоков ведет к просадке качества. А это прямая угроза доверию клиентов, удержанию и репутации. Инвестиции в качество всегда окупаются, потому что предотвращают колоссальные затраты на исправление последствий и возврат ушедших пользователей.
Последний слой пирамиды метрик – самый близкий к пользователю: интерфейс продукта и маркетинг. Но его мы разберем в следующий раз.
#харды #метрики #разбор_метрик
❤11🔥3👾1
Решил попробовать написать серию постов про машинное обучение.
Но так как люблю копать глубоко, начать захотелось с истории - понять, откуда вообще все это выросло и почему мы оказались именно в текущей точке. Так сказать, пройтись по основным вехам.
В какой-то момент стало понятно, что это уже не пост для Telegram. Текст разросся, плюс захотелось добавить фоток и немного контекста.
➡️ Поэтому вынес его в блог.
Приятного чтения и поделитесь фидбеком!
#харды #ml
Но так как люблю копать глубоко, начать захотелось с истории - понять, откуда вообще все это выросло и почему мы оказались именно в текущей точке. Так сказать, пройтись по основным вехам.
В какой-то момент стало понятно, что это уже не пост для Telegram. Текст разросся, плюс захотелось добавить фоток и немного контекста.
➡️ Поэтому вынес его в блог.
Приятного чтения и поделитесь фидбеком!
#харды #ml
Все про аналитику от This is Data -
Машинное обучение от философии к инженерии - Все про аналитику от This is Data
Я решил попробовать написать серию постов про машинное обучение. Начать хочется с истории, чтобы понять, откуда вообще все это выросло и почему мы оказались именно в текущей точке. Когда сегодня говорят про ИИ, создается ощущение внезапного прорыва. Как будто…
1🔥20🥱3
Как перестать хвататься за все сразу
Часто вижу людей, которых на работе заваливает проектами. Десятки писем и чатов, параллельные инициативы, стратегические задачи вперемешку с операционкой. В итоге расфокус и постоянное ощущение, что ты что-то не успеваешь😕
Если вы себя узнали, хочется кинуть вам спасательный круг.
Я давно использую приоритизацию Must - Should - Nice to Have. Это упрощенная версия метода MoSCoW, разработанного Даем Клеггом в компании Oracle в 1994 году. Метод простой, но действенный. Благодаря ему я всегда понимаю, что именно делать и зачем.
Шаг 1. Соберите полный список проектов
Выпишите все проекты и крупные задачи. Именно все. Не только KPI, но и побочные активности.
Например: запуск нового продукта, развитие дерева метрик, ведение корпоративного блога, организация мероприятия, менторинг стажеров.
Даже сам список уже многое проясняет. Часто кажется, что делаешь мало, но когда видишь 10-15 проектов одновременно, становится понятно, куда уходит время.
Шаг 2. Расставьте приоритеты
Теперь распределите проекты по трем категориям.
▪Must. То, что кровь из носу нужно сделать. Иначе - срыв обязательств, провал цели или потеря доверия.
▪Should. Важно, но можно перенести. Это развитие, улучшения, стратегические заделы.
▪Nice to Have. Было бы классно сделать, но если не сделаете, ничего критичного не произойдет.
Важно! В Must не должно быть половины списка. Если все критично, значит вы не сделали выбор.
Шаг 3. Разложите по неделям
Создайте таблицу в строках которой - проекты из Must и Should, в столбцах недели. Лучше всего делать это упражнение в начале месяца.
На пересечении проекта и недели пишите конкретный результат. Не «заняться», а «подготовить концепт», «согласовать», «запустить пилот».
После этого неделя перестает быть абстрактной. Появляется понятный план действий.
Перегруженность чаще возникает не из-за количества задач, а из-за отсутствия фокуса. Когда приоритет зафиксирован, работать становится проще и спокойнее😌
#опыт
Часто вижу людей, которых на работе заваливает проектами. Десятки писем и чатов, параллельные инициативы, стратегические задачи вперемешку с операционкой. В итоге расфокус и постоянное ощущение, что ты что-то не успеваешь
Если вы себя узнали, хочется кинуть вам спасательный круг.
Я давно использую приоритизацию Must - Should - Nice to Have. Это упрощенная версия метода MoSCoW, разработанного Даем Клеггом в компании Oracle в 1994 году. Метод простой, но действенный. Благодаря ему я всегда понимаю, что именно делать и зачем.
Шаг 1. Соберите полный список проектов
Выпишите все проекты и крупные задачи. Именно все. Не только KPI, но и побочные активности.
Например: запуск нового продукта, развитие дерева метрик, ведение корпоративного блога, организация мероприятия, менторинг стажеров.
Даже сам список уже многое проясняет. Часто кажется, что делаешь мало, но когда видишь 10-15 проектов одновременно, становится понятно, куда уходит время.
Шаг 2. Расставьте приоритеты
Теперь распределите проекты по трем категориям.
▪Must. То, что кровь из носу нужно сделать. Иначе - срыв обязательств, провал цели или потеря доверия.
▪Should. Важно, но можно перенести. Это развитие, улучшения, стратегические заделы.
▪Nice to Have. Было бы классно сделать, но если не сделаете, ничего критичного не произойдет.
Важно! В Must не должно быть половины списка. Если все критично, значит вы не сделали выбор.
Шаг 3. Разложите по неделям
Создайте таблицу в строках которой - проекты из Must и Should, в столбцах недели. Лучше всего делать это упражнение в начале месяца.
На пересечении проекта и недели пишите конкретный результат. Не «заняться», а «подготовить концепт», «согласовать», «запустить пилот».
После этого неделя перестает быть абстрактной. Появляется понятный план действий.
Перегруженность чаще возникает не из-за количества задач, а из-за отсутствия фокуса. Когда приоритет зафиксирован, работать становится проще и спокойнее
#опыт
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥15❤2👍1
В АБ-тестах самая частая ошибка не расчет p-value, а неправильный выбор статистического теста.
▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?
От этого зависит правильность ваших выводов.
Я сделал простую схему-шпаргалку по выбору тестов. Минимальный старт, чтобы не выбирать метод наугад.
Но важно понимать, что схема не заменяет понимание.
Перед применением теста стоит:
✔️проверить однородность выборок;
✔️посмотреть на распределения;
✔️оценить выбросы;
✔️убедиться в независимости наблюдений;
✔️проверить предпосылки конкретного теста.
И только после этого принимать решение.
Для первого шага такой карты достаточно. Дальше все равно придется углубляться: читать, разбирать кейсы, ошибаться и нарабатывать практику.
Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.
У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.
Сейчас как раз стартует новый поток, и следующий будет только осенью.
#харды #аб
▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?
От этого зависит правильность ваших выводов.
Я сделал простую схему-шпаргалку по выбору тестов. Минимальный старт, чтобы не выбирать метод наугад.
Но важно понимать, что схема не заменяет понимание.
Перед применением теста стоит:
✔️проверить однородность выборок;
✔️посмотреть на распределения;
✔️оценить выбросы;
✔️убедиться в независимости наблюдений;
✔️проверить предпосылки конкретного теста.
И только после этого принимать решение.
Для первого шага такой карты достаточно. Дальше все равно придется углубляться: читать, разбирать кейсы, ошибаться и нарабатывать практику.
Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.
У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.
Сейчас как раз стартует новый поток, и следующий будет только осенью.
#харды #аб
1🔥11👎6❤3🤔3👍2🤯1
Почему оконные функции могут тормозить запрос?
Я написал уже целую серию постов про оконки (раз, два, три) и там все выглядело красиво - добавил OVER() и получил профит. Но в комментах справедливо подметили, что оконные функции - это часто один из самых тяжелых видов запросов, который сильно жрет ресурсы.
Главный виновник тут обычно не сама функция, а сортировка. Сортировать много строк - дорогая операция на больших объемах данных, и ее лучше избегать везде, где она не нужна. Ниже 4 прикладных совета по оптимизации.
1⃣ Убери ORDER BY из окна, если порядок не влияет на смысл
Частая ошибка - писать ORDER BY внутри OVER() «на всякий случай». Как только он появляется, базе нужно обеспечить порядок строк, а это почти всегда дорого.
Если тебе нужен просто итог по группе (например, общий доход за день для каждой строки), а не накопительная сумма или скользящее окно - ORDER BY внутри окна не нужен.
2⃣ Чем меньше строк, тем быстрее
Оконки «проходят» по всем строкам, часто упорядочивают их, а иногда еще и держат большие куски данных в памяти. Поэтому самый простой ускоритель - сократить объем данных ДО оконки:
✔ Отфильтруй период (например, последние 30/90 дней);
✔ Не тащи лишние колонки («SELECT *» - плохо);
✔ Если можно, то сначала агрегируй данные до нужной гранулярности, а окно считай уже на агрегате.
3⃣ Несколько разных окон = несколько сортировок
Если в одном запросе несколько окон с разным ORDER BY, база может быть вынуждена упорядочивать данные несколько раз. И как итог: больше времени и памяти.
Если можешь, унифицируй порядок в окнах. Если не можешь, то иногда лучше разнести расчеты на 2 шага, чем собирать все в одном SELECT.
4⃣ Используй план выполнения запроса
EXPLAIN - это команда, которая показывает план выполнения запроса: какие шаги база собирается сделать и где она потратит ресурсы. А EXPLAIN ANALYZE еще и выполняет запрос добавляя фактические цифры: сколько строк прошло через каждый шаг и сколько времени заняло.
Далее я разберу, как именно читать EXPLAIN и использовать эту команду для оптимизации.
#харды #sql
Я написал уже целую серию постов про оконки (раз, два, три) и там все выглядело красиво - добавил OVER() и получил профит. Но в комментах справедливо подметили, что оконные функции - это часто один из самых тяжелых видов запросов, который сильно жрет ресурсы.
Главный виновник тут обычно не сама функция, а сортировка. Сортировать много строк - дорогая операция на больших объемах данных, и ее лучше избегать везде, где она не нужна. Ниже 4 прикладных совета по оптимизации.
1⃣ Убери ORDER BY из окна, если порядок не влияет на смысл
Частая ошибка - писать ORDER BY внутри OVER() «на всякий случай». Как только он появляется, базе нужно обеспечить порядок строк, а это почти всегда дорого.
Если тебе нужен просто итог по группе (например, общий доход за день для каждой строки), а не накопительная сумма или скользящее окно - ORDER BY внутри окна не нужен.
-- Накопительная сумма (дороже)
SUM(revenue) OVER (PARTITION BY date ORDER BY created_at)
-- Просто итог по дню (дешевле)
SUM(revenue) OVER (PARTITION BY date)
2⃣ Чем меньше строк, тем быстрее
Оконки «проходят» по всем строкам, часто упорядочивают их, а иногда еще и держат большие куски данных в памяти. Поэтому самый простой ускоритель - сократить объем данных ДО оконки:
✔ Отфильтруй период (например, последние 30/90 дней);
✔ Не тащи лишние колонки («SELECT *» - плохо);
✔ Если можно, то сначала агрегируй данные до нужной гранулярности, а окно считай уже на агрегате.
3⃣ Несколько разных окон = несколько сортировок
Если в одном запросе несколько окон с разным ORDER BY, база может быть вынуждена упорядочивать данные несколько раз. И как итог: больше времени и памяти.
SUM(x) OVER (PARTITION BY a ORDER BY b) AS s1,
AVG(x) OVER (PARTITION BY a ORDER BY c) AS s2
Если можешь, унифицируй порядок в окнах. Если не можешь, то иногда лучше разнести расчеты на 2 шага, чем собирать все в одном SELECT.
4⃣ Используй план выполнения запроса
EXPLAIN - это команда, которая показывает план выполнения запроса: какие шаги база собирается сделать и где она потратит ресурсы. А EXPLAIN ANALYZE еще и выполняет запрос добавляя фактические цифры: сколько строк прошло через каждый шаг и сколько времени заняло.
Далее я разберу, как именно читать EXPLAIN и использовать эту команду для оптимизации.
#харды #sql
👍22❤2🥱1