Джуны не нужны?

Периодически в Linkedin натыкаюсь на мнения, что вкатываться в ИТ сейчас бессмысленно - джунов никто не берет. Особенно после появления ChatGPT и различных ИИ-инструментов. Не берусь говорить про весь рынок в целом, но добавлю свои 5 копеек про рынок аналитики данных.

Согласно исследованию Я.Практикума за 2024г: джунов без опыта ищут меньше всего - всего 8.2% от общего числа вакансий. Большинство компаний предпочитают junior+ (54%) с опытом 1-3 года и middle (34.5%). Что интересно, вакансий на Senior-позиции всего 3.3%.

Кроме того, и в Додо, и в Яндексе мы не нанимали джунов.
Почему так?

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

Во-вторых, качество работы. Джуниор не понимает бизнес-контекст и может потратить неделю на анализ чего угодно, только не того, что нужно. “Дали задачу посчитать конверсию воронки - получили презентацию на 10-20 слайдов с графиками не по теме" - достаточно типичная ситуация.

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

Появление ИИ только ухудшило ситуацию. Раньше джуниор мог заниматься простыми задачами: строить базовые дашборды, делать срезы данных, считать простую статистику. Теперь многое из этого умеют делать LLM или специализированные инструменты. Планка входа поднялась - от джуниора сразу ждут более сложной работы.

Так что же - джуны и правда не нужны?

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

Спрос на аналитику данных продолжает расти. Объем мирового рынка инструментов Big Data достиг $348,21 млрд с ростом на 13,2%. Каждая новая компания, выходящая в цифру, каждый интернет-магазин, каждый стартап - все они рано или поздно приходят к необходимости анализировать данные. Растет количество данных, растет ценность персонализации, растут требования к качеству аналитики.

Откуда возьмутся middle и senior специалисты, чтобы поддерживать все это, если никто не растит джунов? Люди не рождаются с готовыми навыками работы в Tableau и знанием SQL.

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

Джуны никуда не пропадут, но к ним точно вырастут требования. Если раньше можно было устроиться джуном, зная только Excel и базовый SQL, то теперь нужно:
- Понимать основы машинного обучения (потому что ИИ не заменит, а дополнит аналитика)
- Уметь работать с современными инструментами BI
- Понимать основы программирования на Python
- Иметь портфолио реальных проектов и хакатонов, а не только сертификаты курсов

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

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

Но возможности все еще есть - просто планка стала выше.

Что такое разница-разниц и как она помогает с оценкой акций?

Ранее я писал про способы оценки экспериментов при отсутствии контрольной групппы.
Теперь вот решил написать серию постов с более развернутым разбором каждого из методов.
Этот пост будет первым и будет он про метод разницы-разниц (Difference-in-Difference).

Представьте, что ваши коллеги провели акцию в Москве и просят вас оценить ее влияние на выручку. Акция проводилась на весь город и выделить контрольную группу никто не удосужился.

Что делать?

В целом вы можете развернуть заказчика и отправить на все 4 стороны (и даже будете правы), но можете и попытаться ему помочь.

Как?
Как раз с помощью метода выше.

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

Кроме того, у нас могут быть данные и по другим городам. Например, данные по выручке в Санкт-Петербурге до/ после акции.

Этих данных в целом достаточно для данного метода.

В чем его суть?
Логика метода включает всего четыре составляющие:

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

2. Тестовая группа после воздействия - уровень показателя в той же группе после вмешательства. (Выручка в Москве после акции)

3. Контрольная группа до воздействия - исходный уровень в группе, которая не подвергается вмешательству. (Выручка в Санкт-Петербурге до акции)

4. Контрольная группа после воздействия - уровень в контрольной группе в тот же период времени. (Выручка в Санкт-Петербурге после акции)

Эффект вмешательства рассчитывается по формуле:

DiD = (После - До)₍эксперимент₎ - (После - До)₍контроль₎

Если представить формулу визуально, то DID - это разница между синий линией (фактический результат тестовой группы) и оранжевой пунктирной линией (контр-фактический результат тестовой группы). Контр-фактический результат - это предполагаемое поведение метрики в тестовой группе в случае отсутствия воздействия.

Метод кажется очень простым, однако он применим не всегда.
Для корректного применения метода необходимо соблюдать некоторые условия:

1. Параллельные тренды.
Без вмешательства целевые метрики в тесте и контроле должны иметь параллельные тренды. Эту предпосылку невозможно проверить напрямую, но можно оценить, изучив предшествующие периоды.

2. Отсутствие композиционных изменений.
Состав групп не должен существенно изменяться в период наблюдения.

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

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

С этим тоже можно работать, например, используя метод DiD с контролем за ковариатами (Conditional DiD) или метод Синтетического контроля (про них я напишу в отдельных постах), но иногда хватает и стандартного DiD.

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

​Есть ложь, есть наглая ложь, а есть статистика

Нас нанимают за точность и объективность данных. Мы привыкли доверять цифрам - они кажутся беспристрастными. На их основе мы делаем выбор и принимаем решения.
Но могут ли цифры врать?

Даррел Хафф в книге "Как лгать с помощью статистики" систематизировал способы обмана - от простых визуальных трюков до сложных манипуляций с методологией.

Можно выделить несколько видов статистических манипуляций:
- Визуальные манипуляции
- Манипуляции с выборкой
- Корреляция как причинность
- Статистическая значимость vs важность
- Эффект выживших
- Селективная отчетность
- Комбинированные манипуляции

Визуальные манипуляции
Самый простой способ - исказить восприятие через графики. Рост с 98% до 99% выглядит драматично, если ось начинается с 97%. Корпорации используют объемные диаграммы: если показатель вырос вдвое, площадь квадрата увеличится в 4 раза, а объем куба - в 8 раз. Визуальный эффект ошеломляющий при том же 100% росте.

Манипуляции с выборкой
Классический провал произошел в 1936 году, когда Literary Digest опросил 2,4 млн избирателей и предсказал победу Лэндона с результатом 57%. Реальный результат получился обратеый: Рузвельт победил 61% против 37% у Лэндона.

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

Современные компании повторяют ошибку. Стартап заявляет, что "78% пользователей предпочитают новый интерфейс", тестируя только тех, кто сам обновил приложение.

Корреляция как причинность
Например, в США количество разводов коррелирует с потреблением маргарина. Логичный вывод: маргарин разрушает семьи!

На самом деле оба показателя росли параллельно с урбанизацией - классический пример ложной корреляции.

Статистическая значимость vs важность
Фармкомпании мастерски используют подмену понятий. Препарат показал "статистически значимое снижение смертности на 22% среди 18,000 пациентов”. Звучит революционно! Абсолютные цифры: 23 смерти против 29 в контрольной группе. Снижение с 0.13% до 0.16% - на жалкие 0.03 процентного пункта.

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

Статистик Абрахам Вальд возразил: самолеты с пробоинами в двигателе и кабине пилота просто не вернулись. Усиливать надо именно критические зоны.

Бизнес-школы используют тот же принцип: "94% MBA-выпускников получают оффер за 3 месяца".

Из статистики исчезли отчисленные, сменившие специализацию, основавшие стартапы без зарплаты.

Селективная отчетность
Хафф приводит пример с зубной пастой: реклама утверждала, что "две трети стоматологов рекомендуют нашу пасту". Звучит убедительно! На деле опросили всего 12 стоматологов, причем вопрос звучал как "какие пасты вы иногда рекомендуете пациентам?" Можно было выбрать несколько вариантов. Восемь врачей среди прочих назвали и эту пасту.

Табачные компании довели селективность до совершенства. Philip Morris финансировала тысячи исследований о курении в 1970-90х, но в открытом доступе оказались менее 10% - те, что не показали связь с раком.

Комбинированные манипуляции
Наиболее коварны случаи, когда несколько техник используются одновременно. Исследование "доказало" безопасность продукта, исключив из анализа всех участников с побочными эффектами (манипуляция с выборкой), показав только относительные, а не абсолютные риски (подмена понятий), и опубликовав только успешные испытания из серии (селективная отчетность).

В эпоху больших данных проблема усугубилась - из петабайтов можно выкроить любую желаемую картину. Хафф предупреждал об этом 70 лет назад, но его уроки актуальны до сих пор.

Что и где учить, если решил стать аналитиком данных

С момента, как только я задумался о переходе в аналитику данных по настоящее время, я прошел довольно много платных и бесплатных курсов по аналитике данных. Решил систематизировать эти знания и поделиться с вами.

Начну с того, что я выделяю 3 разных уровня знания хард-скиллов, которые могут быть у аналитика данных:

1. Необходимый минимум🖥: SQL + Python + BI.
Это база, необходимая каждому аналитику. Зная ее вы можете претендовать на стартовые роли и далее обрастать более профильными знаниями. Какими конкретно - зависит от вашей роли аналитика. Подробнее о ролях аналитика здесь

2. Базовый уровень🔫: SQL + Python + BI + Статистика + базовый A/B.
Тот стандарт, на который ориентируются большинство компаний.
На этом уровне вы справитесь с 80% задач аналитика данных (% оценил по личному опыту), что в целом достаточно для роли мидла в большинстве компаний.

3. Продвинутый 😎: SQL + Python + BI + Статистика + продвинутый A/B + ML.
Умеете все, что необходимо и даже больше. Справитесь с любыми техническими задачами. Рекрутеры будут гоняться за вами с предложениями пособеситься. Есть личное наблюдение, что этот уровень по-немногу становится базовым в большинстве компаний, т.к. уровень аналитики везде развивается.

Кроме того очень важно качать аналитическое мышление. Про это я также писал отдельный пост.

Теперь перейдем непосредственно к навыкам и где их изучать.

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

Если планируете развиваться дальше в дата-инженера, то придется копать глубже.

1. Интерактивный тренажер SQL
2. Симулятор SQL

>>> Python >>>
Я бы проходил оба курса (для практики), но можно выбрать и один из них. Они дают одинаковую базу.

Как только почувствуете себя уверенными в задачках можно идти решать хэндбук от Яндекса - он посложнее и содержит меньше теории или продвиные курсы "Поколение Python"
1. Поколение Python
2. Karpov Courses - Основы Python
3. Хэндбук Яндекса

[Опционально: Алгоритмы]
Иногда задачки на алгоритмы любят давать на собесах. Но я лично считаю, что этот навык не требуется аналитику, поэтому ставлю этот навык опциональным.

Обычно спрашивают задачки уровня easy.
К ним можно подготовиться по материалам ниже:
1. Пройдя хэндбук Яндекса
2. Решая задачки уровня easy на leetcode

>>> BI >>>
BI систем на рынке очень много и на первый взгляд может показаться, что надо знать и все.

На самом деле это не так. Достаточно освоить один инструмент, т.к. концептуально они все одинаковые.

Самые популярные BI-системы в РФ на текущий момент: Yandex Datalens и Apache Superset. Поэтому лучше пройти курсы по ним:
1. Курс по Datalens от Яндекса
2. По суперсету бесплатных курсов нет, поэтому предлагаю ознакомиться с документацией и учиться делать дашборды на практике. Благо обе BI выше бесплатные.

Освоив навыки выше вы уже можете откликаться на первые вакансии в аналитике данных. Если хотите повысить свои шансы на оффер (и зп), то осваивайте навыки ниже

>>> Статистика >>>
Обычно я рекомендую 2 материала:
1. Курсы по статистике Анатолия Карпова
2. Книга Сары Бослаф - "Статистика для Всех"

>>> A/B >>>
Когда я начинал изучать A/B, в открытом доступе не было материалов с хорошей практикой, поэтому я опирался на теорию из материалов ниже и нарабатывал опыт на тестовых заданиях.

1. Лекции Глеба Михайлова по A/B
2. Книга Рона Кохави "Доверительное A/B Тестирование"

В комментах подсказали курс Яндекса по A/B. Кто проходил - поделитесь впечатлениями.

Что касается продвинутых методов A/B тестирования (методы снижения дисперсии, Causal Inference методы, SPRT и пр.) то в интернете довольно много статей на эту тему. Можете почиать Habr или профильные тг-каналы (например, у меня можно почитать про Causal Inference методы)

>>> ML >>>
Из бесплатных самый норм это курс ФКН ВШЭ.
В нем есть как теория в виде лекций на ютубе, так и практика.

!!Важно!!
Чем больше практики -> тем лучше результат.
Решайте как можно больше задач и будет вам счастье🌞

Оценка эффектов без A/B: разбираем Interrupted Time-Series Analysis

Продолжаю серию постов про методы оценки экспериментов при отсутствии контрольной группы. В прошлый раз разбирали Difference-in-Difference, сегодня поговорим про Interrupted Time-Series Analysis (ITSA) - метод анализа временных рядов.

Представьте ситуацию: ваша компания запустила новую программу лояльности для всех клиентов одновременно. Никакой контрольной группы нет - все получили изменения. Через месяц менеджмент спрашивает: “Сработала ли программа? Сколько выручки она принесла?”

Что делать?

Можно, конечно, просто сравнить средние показатели до и после. Но это примитивный подход - он не учитывает естественные тренды, сезонность и другие факторы. А можно применить ITSA.

В чем суть метода?

ITSA анализирует изменение временного ряда в момент вмешательства (intervention). Метод позволяет отделить эффект воздействия от естественной динамики показателя.

Ключевая идея: мы строим модель поведения метрики ДО вмешательства, а затем смотрим, насколько фактические значения ПОСЛЕ отклоняются от прогноза этой модели.

Метод оценивает два типа эффектов:

1. Немедленное изменение уровня (level change) - мгновенный скачок метрики сразу после вмешательства. Например, выручка выросла на 15% в первый же день после запуска программы.

2. Изменение тренда (slope change) - изменение скорости роста метрики. Например, до программы выручка росла на 2% в месяц, а после стала расти на 5% в месяц.

Базовая модель ITSA выглядит так:

Y = β0 + β1 * Время + β2 * Воздействие + β3 * Время_после + e

Где:
- β0 - тренд до вмешательства
- β2 - немедленное изменение уровня
- β3 - изменение тренда после вмешательства
- Воздействие - бинарная переменная (0 до, 1 после)
- Время_после - количество периодов после вмешательства

Пример

Допустим, вы в компании запустили реферальную программу. У вас есть данные по количеству регистраций за 30 недель до запуска и 20 недель после.

До запуска регистрации росли линейно на ~50 пользователей в неделю. После запуска:
- Немедленный скачок: +300 регистраций в первую неделю (β₂)
- Изменение тренда: рост ускорился до +80 пользователей в неделю (β₃)

Модель показала статистически значимые изменения обоих параметров (p < 0.05), что подтвердило эффективность программы.

Условия применения метода

ITSA не универсален. Для корректного применения важно соблюдать несколько условий:

1. Достаточная длина временного ряда
Минимум 8-10 наблюдений до вмешательства и желательно столько же после. Чем больше данных - тем надежнее оценка.

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

3. Отсутствие других вмешательств
Критично важно: в момент "разрыва" не должно происходить других значимых событий. Если вы запустили программу лояльности 1 декабря, а это еще и начало новогодней распродажи - метод не сможет разделить эффекты.

4. Отсутствие автокорреляции остатков
Последовательные наблюдения не должны быть сильно коррелированы.

Когда ITSA работает лучше других методов?

Метод особенно полезен, когда:
- У вас нет возможности выделить контрольную группу
- Вмешательство применяется ко всей популяции одновременно
- Есть длинная история наблюдений до события
- Важно понять не только факт эффекта, но и его динамику

Ограничения метода

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

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

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

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

О работе в бигтехе и небольших компаниях 🏢

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

Инфраструктура: мощь🖥 vs гибкость 🛠

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

Нужен анализ сегмента? Пишешь запрос к витрине - готово. В небольших компаниях все иначе. Витрины содержат только базовую информацию. Портрет пользователя собираешь из CRM, данных о заказах, мобильного приложения. На тот же анализ уходит в разы больше времени.

Но есть плюс: ты сам строишь инфраструктуру. Видишь проблему - предлагаешь решение и внедряешь. Никаких согласований с тремя командами и архитекторами данных.

Процессы: хаос🔥 и структура 📋

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

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

Главное различие - в требованиях к результату. В бигтехе каждый анализ должен приводить к конкретному результату: рост метрик или экономия бюджета. "Просто посмотреть на данные" недостаточно - нужен actionable инсайт.

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

Карьерные перспективы: винтик⚙️ или архитектор 🏗

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

Но есть обратная сторона: огромное количество направлений. Устал анализировать конверсию в e-commerce? Переходи в команду монетизации контента. Надоела продуктовая аналитика? Иди в маркетинговую. Внутренняя мобильность дает возможность расти горизонтально.

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

Но новых направлений открывается меньше. Если хочешь сменить фокус с продуктовой аналитики на что-то радикально другое - скорее всего, придется менять компанию.

Скорость🚀 и бюрократия 📝

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

Разница в другом. В бигтехе бюрократия возникает на этапе доступа к данным. Нужны данные из смежной системы? Подавай заявку, обоснуй, жди апрува. В небольших компаниях меньше формальностей, но больше хаоса. Данные лежат где попало, документации мало.

Что выбрать? 🤔

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

Если ты опытный специалист и хочешь влиять на продукт - в небольших компаниях больше свободы и ответственности. Но потребуется больше времени на техническую работу.

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

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

Нас 100!

Спасибо всем, что читаете мой канал🙏

Чтобы продолжать радовать вас еще более интересным контентом, давайте немного познакомимся.

Удаленка vs неудаленка

Я встаю без будильника. И считаю это одним из тех благ, за которые надо ценить работу в IT - гибкий график.

Но вот че-то уже вторую неделю собираюсь в офис и никак до него не дойду. Каждый вечер думаю: “Ну вот завтра точно поеду” А потом просыпаюсь в 9:30, и понимаю - ехать уже нет смысла. Час в одну сторону, час обратно. Это ж два часа продуктивного времени.

Дома достаточно легко погрузиться на 3-4 часа в задачу, особенно, если нет созвонов среди дня. Плюс можно поработать вечером, если есть вдохновение. Вчера как раз был такой случай.

И вроде понятно, почему все так топят за удаленку. НО!

После 2+ недель дома в таком режиме я начинаю себя чувствовать то ли отшельником, то ли затворником, застрявшем в вечном дне сурка: кровать -> монитор -> кровать (ну и плюс прогулки до магазина и зала в промежутках).

В офисе как-то легче переключаться между режимами работа/ дом, т.к. обычно после того, как ты закрыл ноут в офисе, дома ты его уже не открываешь. Плюс неформальное общение помогает разгрузить голову между задачами. Дома с этим сложнее.

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

У вас как с этим?

Навигатор по постам

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

Causal Inference методы
- Как оценивать эффекты, когда нет контрольной группы
- Difference-in-Differences (DiD) или Разница Разниц
- Interrupted Time-Series Analysis (ITSA)
- Propensity Score Matching (PSM)

Метрики
- Что такое иерархия метрик
- Как работать с метриками
- LTV и CAC

Кейсы с собесов
- Аномальная доля возвратов
- Выпуск промокода
- Падение метрики

Карьера
- Виды аналитиков
- Что учить, если решил стать аналитиком данных
- Как уровень вовлеченности в бизнес влияет на карьеру аналитика
- Мой опыт работы в Бигтехе и индустрии
- Мой опыт собеседований в зарубежные компании
- О необходимости джунов
- Заменит ли нас ИИ

Общее
- Есть ложь, есть наглая ложь, а есть статистика
- Про многозадачность
- Как статистика помогает не сдаваться
- Сколько знакомств надо совершить, чтобы найти идеального партнера?
- Интернет умер

[Со временем этот навигатор будет разрастаться, так что не теряйте его]

Как писать оптимальные SQL-запросы 🔍

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

Обычно, разница кроется не в каких-то сложных техниках оптимизации, а в базовых принципах написания запросов.

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

1. Продумывайте план запроса заранее 🗺

Перед написанием кода ответьте себе:
- Какие таблицы нужны?
- В каком порядке их джойнить?
- Какие фильтры применить?
- Какие колонки нужны в результате?

Не начинайте писать код сразу. Нарисуйте схему: берем таблицу A, фильтруем по X, джойним с B, агрегируем.

2. Прикидывайте объемы данных 🧮

Всегда держите в голове размеры таблиц:
- Сколько строк в таблице? (1000? 1 млн? 100 млн?)
- Сколько останется после фильтра?
- Сколько получится после JOIN?

Пример: таблица заказов - 10 млн строк, пользователей - 1 млн. Джойним без фильтров - база пытается соединить 10 млн х 1 млн. С фильтром по месяцу: 300 тыс х 50 тыс - уже реально.

Если ожидаете 1000 строк, а получается 10 млн - где-то ошибка.

3. Выбирайте только нужные столбцы 📋

SELECT * вытягивает все столбцы, включая тяжелые поля. Всегда указывайте конкретные:

SELECT order_id, user_id, created_at, amount FROM orders

Это особенно критично пр использовании CTE - лишние колонки тащатся через весь запрос.

4. Не дублируйте расчеты - выносите в CTE 🔄

Плохой пример:

SELECT
(SELECT COUNT(*) FROM orders WHERE user_id = u.id),
(SELECT SUM(amount) FROM orders WHERE user_id = u.id)
FROM users u

База дважды обращается к orders.

Хороший пример:

WITH user_orders AS (
SELECT user_id, COUNT(*) as cnt, SUM(amount) as total
FROM orders GROUP BY user_id
)
SELECT u.*, uo.cnt, uo.total
FROM users u JOIN user_orders uo ON u.id = uo.user_id

5. Фильтруйте данные ДО JOIN🔍

Плохой пример:

SELECT * FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.created_at >= '2024-01-01'

Хороший пример:

WITH recent_orders AS (
SELECT * FROM orders WHERE created_at >= '2024-01-01'
)
SELECT * FROM recent_orders o
JOIN users u ON o.user_id = u.id

Простое правило: сначала фильтруем, потом джойним.

6. Понимайте сложность операций:

От быстрых к медленным:
1. Фильтрация WHERE - быстро (особенно с индексом)
2. Сортировка ORDER BY - умеренно (зависит от объема)
3. JOIN - дорого на больших таблицах
4. DISTINCT - дорого (сканирует все строки)
5. GROUP BY - дорого (чем меньше групп, тем быстрее)
6. Оконные функции - самые дорогие

Оконные функции (ROW_NUMBER, RANK, LAG) удобны, но требуют сортировки. Используйте только когда нужен рейтинг или сравнение с предыдущими значениями. Если можно обойтись GROUP BY - обходитесь.

7. Минимизируйте агрегации 📊

Плохой пример: Агрегируем -> Джойним -> Снова агрегируем

Хороший пример: Джойним -> Один раз агрегируем в конце

Каждая агрегация дорогая. Одна аггрегация в конце будет быстрее трех промежуточных.

8. Не применяйте функции в WHERE 🚫

Плохой пример:

WHERE DATE(created_at) = '2024-01-01'

Хороший пример:

WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'

9. Не забывайте тестировать запрос на ограниченных выборках

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

Финальный чек-лист ✅
Ответьте на эти вопросы
1. Продуман план запроса?
2. Прикинули объемы данных?
3. Выбраны только нужные колонки?
4. Расчеты не дублируются?
5. Фильтры используются ДО JOIN?
6. Оконные функции только там, где нужно?
7. Минимум агрегаций?
8. Протестировали запрос на маленьких выборках?

Ставьте ✍, если этот пост оказался вам полезен

Магия формулы Бернулли: почему важно не сдаваться 🎲

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

Почти все из нас думают что-то поменять в своей жизни: сменить профессию, найти любовь, запустить бизнес. Некоторые пробуют сделать первую попытку. И у них не получается. Возможно делают вторую - и опять не получается.

Особенно грустно становится, когда слышишь, как везде говорят: “90% стартапов проваливаются в первые три года”, “только 1% книг становятся бестселлерами”, “50% браков разрушается” и тд.

Хочется опустить руки и ничего не делать.

Но стоит ли?

Ответить на этот вопрос может помочь теория вероятности, а точнее формула Бернулли. Она описывает вероятность хотя бы одного успеха (а больше нам и не надо) и выглядит так:

P(успех) = 1 - (1 - p)^n

где p - вероятность успеха в одной попытке, n - количество попыток.


Как это работает на практике?
Представьте, что вы ищете работу аналитиком. Допустим, вы знаете, что средний шанс получить оффер после одного собеседования - около 5% (p = 0.05). Звучит уныло.

Но посмотрим на математику:
- 1 собеседование: шанс = 5%
- 5 собеседований: шанс = 23%
- 10 собеседований: шанс = 40%
- 20 собеседований: шанс = 64%

Даже, если допустить, что вы не стали лучше как специалист, а просто продолжали пытаться, ваш шанс устроиться на работу после 20 собеседований вырос в 13 раз! На самом деле с каждым следующим собесом вероятность p тоже выросла, т.к. ваши навыки прохождения собеседований тоже подросли.

Другой пример - нетворкинг. Допустим, шанс завести полезное знакомство с одним человеком на конференции - 5%. После знакомства с 50 людьми ваш шанс найти кого-то полезного = 92%. Просто ВАУ.😱

Что это значит?

Формула Бернулли показывает простую вещь: упорство - это не просто красивые слова мотивационных спикеров. Это математическая закономерность.

Когда вы слышите истории успеха, вы видите результат. Но не видите количество попыток. Человек с оффером в топовую компанию, возможно, прошел 30 собеседований. Успешный предприниматель запустил 5-10 неуспешных проектов до того единственного проекта, который взлетел.

Разница между теми, кто достигает целей, и теми, кто нет - часто просто в количестве попыток. Не в таланте. Не в удаче. В попытках.

Важный нюанс

Формула работает, если вероятность успеха p больше нуля. Если вы делаете что-то с нулевым шансом - количество попыток не поможет.

Поэтому важно:
- Убедиться, что движетесь в правильном направлении (p > 0)
- Извлекать уроки из неудач (увеличивать p с каждой попыткой)
- Не сдаваться (увеличивать n)

Если ваш шанс успеха хотя бы 5%, то после 50 попыток вы достигнете результата с вероятностью 92%. Математика на вашей стороне.

Применимо ли это в аналитике?

Еще как. В нашей профессии это работает постоянно:

Ищете инсайт в данных? Чем больше гипотез проверите, тем выше шанс найти значимое. Пытаетесь объяснить аномалию? Перебор версий приведет к ответу. Учите новый инструмент? Количество практики решает.

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

Итого

В следующий раз, когда столкнетесь с неудачей, вспомните формулу Бернулли. Вы не провалились - вы просто уменьшили (1-p)^n еще на один шаг.

Главное - не останавливаться. Математика докажет, что вы были правы.

P.S. Это не призыв биться головой об стену. Если после 20 попыток ничего не меняется - возможно, стоит пересмотреть подход и увеличить p, а не только n😁

Сори, не могу не выложить.

Купили зеркало.
Кошка в шоке

Propensity Score Matching: когда A/B тест невозможен

Давненько не было постов про Causal Inference методы. Напомню, что ранее я уже писал про DiD и ITS.

Сегодня поговорим про один метод, который на первый взгляд может показаться ультимативным, но на самом деле он, как и прочие методы, применим не везде - Propensity Score Matching.

В чем суть метода?

Представьте ситуацию: вы запустили новую фичу, но не для всех пользователей случайно, а только для тех, кто сам ее активировал. Классический A/B тест не сработает - группы изначально разные. Активные пользователи включили фичу, пассивные - нет.

Вопрос: как понять, влияет ли фича на метрики, или разница только из-за того, что группы изначально были разными?

PSM решает эту проблему. Метод позволяет найти для каждого пользователя из тестовой группы похожего "близнеца" из контрольной группы. Похожего по всем важным характеристикам: траты, активность, история покупок и тд.

Вот краткий алгоритм:

- Шаг 1: Строим модель, которая предсказывает вероятность попадания в тестовую группу

Берем характеристики пользователей (возраст, город, количество заказов, средний чек) и строим логистическую регрессию. Она предсказывает вероятность попадания в тестовую группу - это и есть Propensity Score.

- Шаг 2: Матчим пользователей по Propensity Score

Для каждого пользователя из тестовой группы ищем пользователя из контрольной с максимально близким Propensity Score.

- Шаг 3: Сравниваем метрики

У нас есть две сбалансированные группы - можем сравнить средние значения целевой метрики.

Когда PSM работает хорошо?

1. Есть много признаков, которыми можно описать пользователей
Больше данных -> точнее модель -> лучше матчинг.

2. Группы пересекаются по характеристикам
Если в тестовой группе только VIP-клиенты, а в контроле их нет - матчинг не сработает. Нужно, чтобы для каждого пользователя из теста нашелся похожий в контроле.

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

Как проверить, что матчинг работает?

Недостаточно просто проверить баланс групп по характеристикам. Нужна валидация на историческом периоде.

Примените PSM к данным ДО воздействия. Например, фичу запустили 1 июня - сделайте PSM на данных за май. Если хорошо подобранные фичи показывают "эффект" там, где его быть не может - проблема в скрытых факторах, плохом матчинге или в сверхвысокой чувствительности.

Так, на выборках 100k+ пользователей возникает проблема: любая мизерная разница становится статистически значимой. P-value < 0.05 при разнице в 0.01% - технически значимо, но практически шум.

Решение: не использовать всю выборку.
Можно определить MDE (минимальный детектируемый эффект, например +2%), расчитать нужный размер выборки под этот MDE и ограничить выборку до этого размера - т.е. взять случайные 50k вместо всех 500k.

Так вы не будете детектить шум как значимый эффект.

На что еще стоит обратить внимание

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

2. Работайте с выбросами
Перед построением модели сглаживайте или убирайте выбросы. Экстремальные значения могут исказить Propensity Score и ухудшить матчинг.

3. Используйте Caliper Matching
Не матчите пользователей, если разница в Propensity Score больше порога (например, 0.01). Лучше потерять часть данных, чем получить плохие пары.

4. Всегда проверяйте качество матчинга на историческом периоде
Это единственный способ убедиться, что метод матчит без смещения.

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

Ставьте реакции, если пост оказался полезным.
Будет много реакций - будет больше постов про Causal Inference)