Заскуль питона (Data Science)

Сеньор под прикрытием 😂

Ссылка на пост в LinkedIn

Материалы для прокачки навыков в pandas для начинающих 🐼 [ч. 1]

Хотите прокачаться в pandas, но не знаете, с чего начать? Собрал полезные инструменты, шпаргалки и ресурсы, которые помогут вам разобраться во всем шаг за шагом!

Можно основные операции потыкать на этом сайте (сводные таблицы, join'ы, сортировки и др.)

Есть официальная документация с быстрым стартом (как устроены данные, как создавать чарты, сводники)

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

У Яндекс Образования в курсе по Python: блок по pandas

Шпаргалки по pandas (если нужно освежить быстро в памяти):

1. link1
2. link2
3. в одном PDF, во втором PDF, в третьем PDF

Была ли вам интересна подборка? Какие материалы помогли вам лучше всего разобраться в pandas? Делитесь в комментариях! А если пост соберёт 100 реакций, выложу следующую подборку с практическими задачами 😏

#дляначинающих@zasql_python

UPD:
https://dfedorov.spb.ru/pandas/

Пользуемся продуктом (или собираем фидбек) для генерации новых гипотез

Если ты сам не пользуешься продуктом, многое ускользает. По факту на основе данных мы отвечаем на вопрос: «Что случилось?»

Ты не замечаешь очевидных неудобств, которые мешают пользователям. Ты видишь, что на этапе оплаты большой отток. Анализируешь данные, проверяешь A/B-тесты, но не находишь явной причины. А если бы ты попробовал оплатить заказ сам, то заметил бы, что в мобильной версии кнопка “Оплатить” уходит за границы экрана.

Данные могут показывать проблему, но не её причину. Например, ты понимаешь, что время нахождения на странице сильно меньше, чем ожидается (мы считаем, что просмотр контента этой страницы улучшает бизнес-показатели). Проблема могла быть с тем, что очень много текста, непонятное содержание страницы, техническая ошибка и т.д. Хорошее правило с ошибками: «Если воспроизводится у двух и более людей, значит проблема глобальная».

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

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

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

Ставьте реакции ❤️, если пост понравился, пишите комментарии.

А вы тестируете продукт, который анализируете? Как часто замечаете проблемы, которые не видно в метриках?

Реально на мои апельсинки 🍊 кто-то позарился? Или кто-то пытается их мне втюхать?

Как относитесь к таким пушам? Заставляют ли они вас более активно реагировать на них или вообще все равно?

Топ-10 полезных приемов в SQL от тимлида аналитиков

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

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

Совсем скоро это можно будет сделать на бесплатном мастер-классе от Павла Беляева, тимлида аналитиков в сервисе eLama, где Павел покажет 10 приёмов в работе с SQL, которые использует его команда в реальной практике📊.

Что будет на мастер-классе:
🟠 Проведем проверку на повторяющиеся комбинации в таблице с данными
🟠 Найдем последний элемент в исторических данных
🟠 Сравним разные версии таблиц
🟠 Заполним пропущенные даты во входящих данных
На этом закончим спойлеры, остальное узнаем на мастер-классе!

🕘Встречаемся 12 февраля в 19:00 по мск

Зарегистрироваться на бесплатный мастер-класс

🤩 Увидел, что у телеграма есть фича: отправить "Когда будет в сети" (испытан a-ha момент, поэтому с запозданием + практически никто не показывает, что он в сети, поэтому…).

Интересно, как это работает на тех, кто поставил статус "был(а) недавно".

(никак, на них не влияет)

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

Если это катилось с экспериментом, то какие бы вы предложили метрики для эксперимента? Пишите в комментариях!

😏 А вы уже успели пощупать? Видите ли плюс от этой фичи?

Как стать тимлидом? [статья]

Тут описано со стороны разработки, но с какой-то погрешностью можно переложить на аналитику

У тимлида основные фокусы:

1. Delivery - чтобы все заказчики были довольны и команда закрывала проблемы в бизнесе. Различные исследования, проверка гипотез.

2. Team Development - построение эффективной команды, выстраивание определенной культуры, найм новых сотрудников. Тут может быть и помощь в решении различных вопросов взаимодействия и т.д.

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

Как стать тимлидом в компании?

Автор указывает четыре пункта:

1. Проактивность. Брать на себя больше ответственности, покрывать больше зон в бизнесе. Также это может развитие новых инструментов, генерация гипотез по росту продукта.

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

3. Развитие хардов (тут для разработки). Для аналитики важны софты также. Мы очень часто работаем с бизнесовыми заказчиками, нужно проще объяснять сложные вещи. Не вдаваться в работу алгоритмов, а попытаться объяснить на простых примерах.

4. Обращать внимание на эмпатию. Умение сочувствовать, сопереживать коллегам. Тут блок про мотивацию, делегирование, что нужно чувствовать свою команду, эмоции.

Тут про заблуждения в работе тимлида.

А вы что думаете? Как считаете, сочетание этих пунктов позволят вырасти или есть еще другие составляющие? Пишите в комментариях!

Как считать пенетрацию пользователей в продукте на SQL?

🎮 В сервисе у нас есть чарт, характеризующий количество пользователей в сервисе (MAU / DAU / WAU), мы смотрим за определенный промежуток времени количество пользователей. Этот график интуитивно понятен, есть практически во всех продуктах и является одной из тех метрик, которую отслеживают.

Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!

WITH user_activity AS (
    SELECT 
        user_id, 
        event_date,
        DATE_TRUNC('week', event_date) AS week_start,
        DATE_TRUNC('month', event_date) AS month_start
    FROM user_events
    WHERE event_date BETWEEN '2024-01-01' AND '2024-12-31'
)
SELECT 
    event_date,
    COUNT(DISTINCT user_id) AS DAU,
    COUNT(DISTINCT CASE WHEN event_date = week_start THEN user_id END) AS WAU,
    COUNT(DISTINCT CASE WHEN event_date = month_start THEN user_id END) AS MAU
FROM user_activity
GROUP BY event_date
ORDER BY event_date;

❓ Пенетрация позволяет ответить на вопрос: "Сколько всего пользователей пользуются продуктом в динамике?". В сервисе есть старички, которые регулярно продукт используют и за время мы их учитываем несколько раз (по дням). Мы можем взять весь год и посмотреть сколько всего пользователей использовали фичу X и посчитать статично, найти долю и все. Но хочется понимать как инициативы влияют на абсолютные значения / доли относительно всех пользователей продукта до момента T.

WITH daily_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
    SELECT DISTINCT event_date 
    FROM daily_users
),
cumulative_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_unique_users
    FROM date_series d
    LEFT JOIN daily_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
)
SELECT * FROM cumulative_users;

⬆️ Выше представлен скрипт, который считает накопительно пользователей по дням, теперь мы можем это применить для ответа на вопрос: "Какой процент пользователей когда-либо использовал продукт на момент времени T?". Это нам может быть нужно для отслеживания доли использования от всей аудитории накопительно. Мы можем более явно отслеживать как наша база (в тотале) реагирует по дням, когда мы используем какие-то механики, например, или запускаем новые фичи

WITH daily_feature_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_name = 'feature_x' 
      AND event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
daily_total_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
    SELECT DISTINCT event_date 
    FROM daily_total_users
),
cumulative_feature_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_feature_users
    FROM date_series d
    LEFT JOIN daily_feature_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
),
cumulative_total_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_total_users
    FROM date_series d
    LEFT JOIN daily_total_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
)
SELECT 
    cfu.event_date,
    cfu.cumulative_feature_users,
    ctu.cumulative_total_users,
    ROUND(100.0 * cfu.cumulative_feature_users / (ctu.cumulative_total_users, 0), 2) AS penetration_rate
FROM cumulative_feature_users cfu
JOIN cumulative_total_users ctu ON cfu.event_date = ctu.event_date
ORDER BY cfu.event_date;

⬆️ Выше представлен код, как мы считае долю тех, кто использовал фичу относительно всех пользователей до момента T.

🐖 Используете ли вы пенетрацию для отслеживания доли относительно всех пользователей? Был ли этот пост полезен? Ставьте 100 🐳 и я выложу еще что-нибудь по этой тематике)

Анализ экспериментов с Ratio-метриками

Проводя эксперименты, обычно, мы используем базовые методы: t-test, z-test, bootstrap (если данных не так много). Это для одних метрик, но, предположим, мы работаем с метриками-отношения (представляют из себя деление суммы случайной величины X на сумму случайной величины Y).

В этом случае в группе A и группе B у нас нет дисперсии. В самом деле, рассмотрим средний чек - метрика отношения (сумма GMV / количество заказов), CTR (сумма кликов / количество показов). Получаем некоторую метрику Za и Zb для которой мы знаем значение, но дисперсии метрики не знаем.

Отсюда выход:

а) провести бутстрап, чтобы найти распределение этой метрики и узнать распределение статистики
б) бакетировать (меньше по ресурсам, чем бутстрап).
в) применять другие методы (например, линеаризацию или дельта-метод).
г*) что-то другое...

Бутстрап

Для оценки распределения метрики можем использовать выборочные значения в группе A и группе B и найти разницу, таким образом, мы получим «разницу средних». Из минусов: MDE не рассчитать (при дизайне эксперимента), очень долгий расчет при больших выборках, ресурсов может не хватить.

Расчет для конкретной выборки, можно разницу средних потом посчитать

def bootstrap_ratio(data, nominator, denominator, group_column, group_value, n_iter=10000):

    group_data = data[data[group_column] == group_value]

    boot_ratios = []
    for _ in range(n_iter):
        sample = group_data.sample(len(group_data), replace=True)
        ratio = sample[nominator].sum() / sample[denominator].sum()
        boot_ratios.append(ratio)

    return np.array(boot_ratios)

Бакетизация

Делим также пользователей по бакетам (с их GMV и количеством заказов), распределение метрики будет нормальным, главное, чтобы в бакетах было достаточное количество наблюдений. Мы делаем n-подвыборок (где n - это количество бакетов). Из минусов: сложность работать с маленькими выборками, зависимость от количества бакетов (тонкая настройка).

def bucketize(data, nominator, denominator, n_buckets=50, random_state=42):

    data = data.sample(frac=1, random_state=random_state).reset_index(drop=True)
    buckets = np.array_split(data, n_buckets)
    bucket_ratios = [bucket[nominator].sum() / bucket[denominator].sum() for bucket in buckets]

    return bucket_ratios

Пару слов про дельта-метод и линеаризацию.

В общем-то это об одном и том же. Мы хотим найти дисперсию метрики для того, чтобы применить классические методы (например, t-test). В дельта-методе мы корректируем дисперсию на корреляцию двух случайных величин (числителя и знаменателя). Только есть разница: дельта-метод вычисляет дисперсию на уровне выборки сразу, а линеаризация позволяет Ratio-метрику превратить в поюзерную. Результаты сонаправлены.

Дельта-метод

def calculate_ratio_variance(values_numerator, values_denominator):

    mean_num = np.mean(values_numerator)
    mean_denom = np.mean(values_denominator)
    variance_num = np.var(values_numerator, ddof=1)
    variance_denom = np.var(values_denominator, ddof=1)

    covariance_num_denom = np.cov(values_numerator, values_denominator)[0, 1]

    ratio_variance = (
        (variance_num / mean_denom ** 2)
        - (2 * (mean_num / mean_denom ** 3) * covariance_num_denom)
        + ((mean_num ** 2 / mean_denom ** 4) * variance_denom)
    )

    return ratio_variance

Линеаризация

# ratio_control - ratio-метрика в контрольной группе (для теста также рассчитывается)

def calculate_ratio_control(numerator_control, denominator_control):
      return sum(numerator_control) / sum(denominator_control)

ratio_control = calculate_ratio_control(numerator_control, denominator_control)

def linearization(numerator, denominator, ratio_control):
    return numerator - ratio_control * denominator

Дополнительные материалы для ознакомления: первый, второй, третий, четвертый, пятый

Понравился пост? Давайте наберем 150 🐳🐳🐳, если хотите продолжение, пишите в комментариях, часто ли используете подобные методы?

Заскулил питона at the gym

В 10 классе начал тягать железо в тренажерном зале. Понравилось, хожу до сих пор. (по крайнем мере я стараюсь).

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

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

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

Вечером обычно ходит много людей и тренировка может заканчиваться в 22-23, остается только доехать до дома и ночью(либо в течение дня) находить свободное время для изучения нового

А как вы совмещаете хобби с работой?
Поделитесь своим опытом?

#личнаяжизнь@zasql_python

Карьерный бег по кругу: работа ради зарплаты или ради роста?

Листая LinkedIn, я заметил один интересный тренд: есть ребята, которые меняют работу почти каждый год, но их позиция при этом остается на том же уровне. Задачи и обязанности в лучшем случае расширяются минимально.

Иногда причина понятна: человек хочет сменить вектор и заняться чем-то новым — например, перейти от стандартной аналитики к ML или A/B тестам. Но в реальности ожидания часто не оправдываются: задачи остаются схожими с предыдущим местом, а новых знаний и навыков добавляется немного.

Нередко эти специалисты меняют место работы 4-5 раз подряд с одними и теми же задачами. Да, зарплата при этом растет (возможно, значительно), но общий профессиональный прогресс замедляется или вовсе останавливается.

_______________________

Почему так происходит?

У всех есть свои причины, но чаще всего частые переходы связаны с двумя основными факторами:

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

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

_______________________

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

1. Потолок зарплаты существует у всех позиций.

2. Требования к профессионалам растут, особенно в условиях высокой конкуренции.

_______________________

Что происходит с профессиональным ростом?

Вот несколько моментов, о которых стоит задуматься:

Каждый переход добавляет лишний период адаптации (обычно 3-6 месяцев). Новые процессы, новая команда, другая корпоративная культура — это все требует времени. По сути, несколько месяцев уходит на “разгон”.

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

Глубокая экспертиза требует времени. Частая смена компаний мешает углубляться в продукт или бизнес. А именно глубокая экспертиза делает аналитиков незаменимыми специалистами, на которых хотят равняться другие.

_______________________

Рост внутри компании

Если есть возможность расти профессионально и забирать кусок ответственности за бизнес, лучше воспользоваться этим шансом

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

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

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

_______________________

К чему это всё?

Зарплата важна. Комфорт важен. Но если вы видите возможность профессионального роста в текущей компании, не стоит упускать этот шанс ради краткосрочной выгоды. Рано или поздно важнее становится не просто количество мест работы, а опыт, который дает вам вес на рынке труда.

Как вы думаете, выгодно ли менять работу каждый год, или лучше развиваться в стабильной среде? Делитесь своими мыслями в комментариях!

___________________________

@zasql_python

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

➕ 🟰 Аналитики-калькуляторы - это те, кто выполняет задачи, которые им ставят. Считают данные, строят отчеты, собирают чарты и системы, которые потом менеджмент использует для дальнейшей работы. И это не плохо, потому что без базовой аналитики никуда. Адхоки, регулярные отчеты, которые лежат в основе процессов, - это база. Но проблема в том, что у многих такой подход становится потолком. Они не понимают, зачем их данные нужны бизнесу, что именно решают их чарты или отчеты. Если не задумываться об этом, можно долго работать в таком режиме. Хотя с другой стороны, это может быть отличным временем для прокачки технических навыков и понимания основ.

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

Как вырасти до аналитика-партнера? [мое мнение]

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

2️⃣ Адаптация коммуникации. Мы часто забываем, что общаемся с людьми, которые могут не знать, что такое p-value или зачем ты используешь тот или иной метод. Людям из бизнеса важно понимать результат: как это повлияет на их задачи, принесет ли прибыль или решит проблему. Умение говорить на языке разных команд - аналитиков, маркетинга, продукта - это ключ к тому, чтобы становиться партнером.

3️⃣ Активная позиция и фильтрация задач. Когда задач много, важно понимать, какие из них действительно решают проблему, а какие - просто затыкают дыру в имеющемся процессе. Аналитик-партнер не просто выполняет запланированные таски, а задает вопросы: “А это точно решит проблему?”, “Какое влияние это окажет?”, “Можно ли сделать проще или эффективнее?”. При этом нужно уметь фильтровать входящие запросы. Не все задачи стоит брать в работу, но те, которые ты принимаешь, важно выполнять так, чтобы не пришлось переделывать или добавлять правки. Инициативность здесь тоже играет роль: иногда ты можешь предложить свой вариант решения, который окажется лучше исходного.

4️⃣ Учиться у тех, кто уже разбирается в области. Коллеги, которые давно работают в компании или просто сильнее тебя в каких-то аспектах, – это ценный источник знаний. Если ты не понимаешь, как работает тот или иной процесс, не бойся задавать вопросы. Работать в паре над задачами – это тоже хороший способ быстрее разбираться в сложных темах.

Что думаете, корректно ли делить аналитиков именно так? Конечно, есть те, кто работает исключительно в операционной зоне, и это тоже важная часть. Но здесь речь именно про тех аналитиков, которые могут влиять на развитие бизнеса своими инициативами. Если интересно, ставьте 1️⃣0️⃣0️⃣ реакций (завез еще кастомные), и я разберу что-нибудь ещё - подкаст, статью или, может быть, ваш запрос. А в комментариях будет круто почитать ваши мысли, делитесь!

Как проводите новогодние праздники? Отдыхаете / обучаетесь / работаете?

Планирую в ближайшее время актуализировать роадмап + подкрепить средним временем прохождения пунктов / расписанием того, как все изучать, чтобы вкатиться (и не только вкатышам). Возможно, это будет в Figma / Miro с дальнейшей развилкой в ML, руководящие позиции. Если вам по-прежнему это интересно, накидайте очень много реакций, а я постараюсь сделать так, чтобы вы четко понимали как идет развитие / что нужно дополнительно изучить + рассмотрю варианты как можно качаться внутри команды, чтобы дорасти еще выше.

Как я вижу для себя:

1. Сделать для новичков
2. Сделать для продолжающих (а как можно расти еще быстрее, что нужно делать, чтобы расти)
3. Объединить несколько форматов.

Все зависит от вас! Ставьте много 🐳(200?) и я начну двигаться к разработке данного формата.

Перед новогодними праздниками X5 написали статью про контекстных бандитов и то, как они их применяли в ценообразовании. Здесь рассказывается об основных методах, которые ребята применяли для экспериментов: UCB, Thompson Sampling.

Базово алгоритмы позволяют выбрать лучшую стратегию на основе метрики, например, цены товара, исходя из определенного контекста, изменения среды (данных по пользователю, внешних факторов и др.). В отличие от классических A/B-тестов, контекстные бандиты могут достаточно быстро менять свои решения, адаптируясь к реальным данным. Это значит, что вместо долгих тестов можно сразу получать лучшие результаты.

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

Код обещали выложить в следующей статье, в статье Ozon Tech он уже есть. Байесовская линейная регрессия, Thompson Sampling, СMAB, код тут

😏 Итоги года

🚶‍♂️ х2.2 подписчиков с начала года. Дальше - больше. Ставим таргет на х2 к концу следующего года.

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

🎄 Всем спасибо! Хороший выдался год! Желаю каждому карьерных успехов, интересных задач и сочных офферов

🐳 4.5к реакций за год? Интересно, можем ли сделать +2-3% к этой метрике?

😑 А что интересного случилось у вас за этот год? Пишите в комментариях

Подглядывание в 🆎 тестах. Я ошибся, я могу один раз ошибиться?

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

В чем основная суть?

Предположим, мы запустили эксперимент, который должен идти 14 дней (так мы определили по дизайну). Возьмем для примера базовый t-test для двух выборок.

Вдруг мы решили посмотреть на результаты, видим значимое изменение. По сути (если мы знаем формулу для t-test'а или другого статистического критерия), накопительно на каждый день можем посчитать статистику и увидеть, что, например, в 4 день (ладно-ладно, в 7), мы увидели значимое изменение. Пришла в голову гениальная мысль отрубить тест и экстраполировать выводы, но так, очевидно делать нельзя, и вот почему:

1. Мы рассчитывали сроки эксперимента в зависимости от трафика. Чем меньше пользователей, тем сильнее шум.
2. Доверительный интервал получается весьма широким, мы можем не до конца быть уверенными в эффекте (та же история может случиться и в обратную сторону, p-value от статистики (например, разницы средних) может "отскочить" от промежутка (0, alpha). Если бы мы подсмотрели, мы сделали неправильное решение.
3. На симуляциях мы повышаем ошибку первого рода (FPR) достаточно сильно. Подглядывание даже может имитировать подбрасывание монетки (по факту, мы проверяем несколько гипотез, что за 1, 2, 3, ... n день средние различаются, тем самым мы рискуем ошибиться. Подробнее можно посмотреть тут

Что можно посмотреть по этому поводу?

1. Статья от GoPractice..
2. Видео от Анатолия Карпова.
3. Пост от ProductSense на Facebook

Про это очень много есть статей + давно было интересно покопаться в проблеме подглядывания, например, ребята из Spotify использовали методы последовательного тестирования для досрочного принятия решения (чтобы не держать эксперимент какое-то время). История может быть актуальна, если мы хотим принимать правильные решения как можно чаще, а неправильные - сразу отрубать, чтобы не терять деньги во время теста. Также читал, что советуют обращаться к байесовскому тестированию, но давайте ко всему последовательно).

🐳🐳🐳 100 реакций на пост и разгоняем дальше 🐳🐳🐳

Дизайн 🆎 экспериментов и почему это важно.

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

🎄 При проектировании A/B эксперимента учитывайте сезонность, например, в Новый Год пользователи могут вести себя по-другому

💡 Нужно определиться с гипотезой. Проводя A/B тестирование, мы всегда говорим о постановке различных гипотез, как на языке бизнеса (в понятном для всех формате), так и на языке статистики, когда говорим про нулевые и альтернативные гипотезы. Важно понимать, что от гипотезы зависит многое. По сути, как мы дальше будем интерпретировать различные варианты.

🙅‍♂️ Риски. Какие могут быть риски для компании? Если что-то резонирующее, которое сразу улетит в СМИ - тест можно перезапускать, можем получить при анализе невалидные результаты. Например, если мы просто убираем точку входа или полностью меняем популярное приложение при раскатке 50/50.

🗒 Определение метрик и теста. А на что мы смотрим, когда подводим итоги? Может есть какие-то целевые, по которым мы хотим принимать решения, а может есть какие-то вспомогательные, которые нам нужны для дальнейшего анализа. Если у нас есть своя A/B платформа, проблемой с подсчетов быть не должно. На этом этапе важно также понимать какой тест мы используем для анализа.

☕ Сегменты пользователей. Хотим мы катиться на всех или нет зависит от сетапа эксперимента, возможно, нам нужно брать определенный срез пользователей (старички/новички, пользователи, обладающие каким-то признаком).

🌳 Дерево принятия решений. Если метрик несколько, мы должны определиться с различными вариантами, когда эксперимент катим, а когда нет. Если метрика серая, то..., а если нет, то. Базово должно фиксироваться до проведения эксперимента.

😁 Определение MDE / размера выборки / длительности эксперимента. Мы должны понять на истории, а действительно ли мы сможем прокрасить эксперимент? По сути, тот же MDE нужен нам для определения примерной длительности эксперимента или ответа на вопрос, а эта метрика чувствительна вообще будет на данном срезе или нет?

🥪 Другие слои. А считаем ли мы корректным проводить эксперимент, если слои забиты, а насколько забиты, все ли окей в этом плане?

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

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

✅ Корректное логирование эксперимента. Можно раскатить на себя, посмотреть, собрать различные события в тестовой группе, попробовать посчитать метрики (просмотр, клик по фиче X, которую мы запускаем на тестовую группу).

🚀 Запуск эксперимента

От вас жду 100 🐳 за пост. Далее пройдемся по вопросам, касаемых разметки и ТЗ для команды разработки и я продолжу писать посты из списка.

Всем привет!
Хочу порекомендовать вам канал Start Career in DS - один из самых крупных каналов с материлами по DS и смежным темам

👉 Автор канала Рома Васильев руководит отделом аналитики международного поиска Яндекса, преподаёт на "Karpov.сourses", на ФКН Вышки и в Центральном Университете Т-Банка 👨‍🎓

В канале вы можете найти полезные материалы для изучения и подготовки к собеседованиям:
🦾 Классический ML – база: справочник основных алгоритмов
👨‍🏫 Что ботать, чтобы пройти на стажировку аналитиком в Яндекс?
🤖 Модели перевернувшие NLP: как устроен Transformer
📚Deep Learning: теоретический справочник по базовым концепциям

Подписывайтесь, ребята делают достойный контент 🙂

Заскуль питона (Data Science) pinned «🍪🍪 Понравился формат, когда спрашиваю про то, о чем хотите видеть посты. Давайте постараемся внедрить. О чем пишем на следующей неделе? Выберу среди топа залайканных комментариев. Формат: 💻 Пост про какую-то область в ML, практические кейсы в работе аналитика…»

🍪🍪 Понравился формат, когда спрашиваю про то, о чем хотите видеть посты. Давайте постараемся внедрить. О чем пишем на следующей неделе? Выберу среди топа залайканных комментариев.

Формат:

💻 Пост про какую-то область в ML, практические кейсы в работе аналитика

🆎 Пост про дизайн экспериментов. Про какие-то статьи. Хочу понять, почему так считаем.

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

📝 Если вам нравится формат, могу разбирать различные интересные статьи, только дайте знать.

Можно накидать под этот пост комментариев на несколько недель вперед, возьму в соответствующий спринт 😱

Да, я 🤔

Вы набрали достаточное количество реакций, поэтому привожу 1 кейс - это когортный анализ в SQL.

☕️ Этот подход важен, когда нужно понять, что происходит с пользователями спустя какое-то время после их взаимодействия с продуктом. Например, они пользуются новой фичей или заходят в продукт через 1, 7, 14, 30 дней после регистрации? Когортный анализ помогает ответить на такие вопросы.

🍪🍪 Пример задачи

Допустим, у вас есть продукт, где пользователи регистрируются и совершают действия. Нужно определить, сколько пользователей из каждой когорты (группы, зарегистрированной в один день) возвращаются через разные промежутки времени.

🤔 Что сделаем?

1. Разделим пользователей на когорты по дате регистрации.
2. Посчитаем, сколько пользователей из каждой когорты совершили хотя бы одно действие через 0, 1, 7, 14 и 30 дней.
3. Рассчитаем удержание в процентах относительно размера когорты.

with cohort_base as (
    select
        u.user_id,
        date(u.registration_date) as cohort_date,
        datediff(e.event_date, u.registration_date) as days_since_registration
    from users u
   left join events e
        on u.user_id = e.user_id
    where e.event_date is not null
),
cohort_activity as (
    select
        cohort_date,
        days_since_registration,
        count(distinct user_id) as active_users
    from cohort_base
    where days_since_registration between 0 and 30
    group by cohort_date, days_since_registration
),
cohort_size as (
    select
        date(registration_date) as cohort_date,
        count(distinct user_id) as cohort_size
    from users
    group by cohort_date
)
select
    ca.cohort_date,
    ca.days_since_registration,
    round(ca.active_users * 100.0 / cs.cohort_size, 2) as retention_rate
from cohort_activity ca
join cohort_size cs
    on ca.cohort_date = cs.cohort_date
order by ca.cohort_date, ca.days_since_registration;

😱 Что делает этот запрос?

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

cohort_activity - считаем количество уникальных пользователей, которые были активны через 0, 1, 7, 14 и 30 дней после регистрации, для каждой когорты.

cohort_size - определяем размер каждой когорты — количество пользователей, зарегистрировавшихся в конкретный день.

🐸 Рассчитываем удержание (retention_rate) как процент активных пользователей от общего числа зарегистрированных в когорте.

Можно выявить, как изменения в продукте (новая фича, интерфейс) влияют на удержание пользователей. Если retention сильно падает после первых дней, это сигнал, что пользователи теряют интерес или сталкиваются с трудностями.

Обратная задача рассчитать Churn Rate, нужно просто сделать 1 - Retention Rate

Если наберется 100 🐳, выложу еще пост с практическим применением SQL, есть еще что рассказать 🔥

Вопрос с собеседования в продуктовую команду

🍴 Всем привет! Этот пост будет сочетать в себе две темы: практические продуктовые кейсы + вопрос с собеседования. В компании вы можете столкнуться с тем, что какая-то метрика (возьмем для примера конверсию в покупку) упала (например, увидели в отчетности или посмотрели в данных), вопрос, почему такое может быть? Сформулируйте ряд гипотез, на что бы вы посмотрели в первую очередь?

Давайте попробуем разогнать в комментариях.

Следующий пост (если наберется 100 🐳) - будет решение, как бы я подступился к этой задаче

UPD: Давайте возьмем сервис размещения объявлений для примера

Как доверительные интервалы помогают решать задачи бизнеса?

😏 Всем привет! В этом посте вообще опишу то, с какой ситуацией можно столкнуться, анализируя эксперименты. Представим, что мы задизайнили эксперимент, определили слои, запустили эксперимент, собрали все требования, ожидания, выбрали целевые метрики и вот мы уже подводи итоги эксперимента. Бизнесу важны по большей части деньги и пользовательский опыт. Так вот, смотрим на метрики, видим, что p-value > alpha - уровня значимости, который определили заранее (возможно даже с какими-то поправками), сразу опускаем руки, ведь эффекта не нашли (нет). Как нам ответить на вопрос бизнесу, а что дальше делать с этой информацией?

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

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

import scipy.stats as stats
import numpy as np

control_conversions = 500
control_total = 10000
test_conversions = 555
test_total = 10000 

control_rate = control_conversions / control_total
test_rate = test_conversions / test_total

effect = test_rate - control_rate

se = np.sqrt((control_rate * (1 - control_rate)) / control_total +
             (test_rate * (1 - test_rate)) / test_total)

z_score = effect / se
p_value = 2 * (1 - stats.norm.cdf(abs(z_score)))

ci_low, ci_high = effect - 1.96 * se, effect + 1.96 * se

print('Разница средних, %')
print(np.round(effect, 3) * 100)

print('Доверительный интервал, %')
print([np.round(ci_low, 3) * 100, np.round(ci_high, 3) * 100])

print('p-value')
print(np.round(p_value, 2))

# Разница средних, %
# 0.5
# Доверительный интервал, %
# [-0.1, 1.2]
# p-value
# 0.08

😭 Видим, что p-value низкий, можно даже прокрасить CUPED, стратификацией, но давайте посмотрим более детально. Истинное значение конверсии лежит в промежутке от -0.1% до 1.2%, но что значит для бизнеса?

Предположим, что мы сервис доставки продуктов. ARPPU составляет 1000 рублей => мы можем рассчитать эффект в деньгах, возьмем крайние границы доверительного интервала:

arppu = 1000
low_effect_arppu = ci_low * control_total *  arppu 
high_effect_arppu = ci_high * control_total *  arppu 
print([low_effect_arppu, high_effect_arppu])

# [-6955.767415148702, 116955.76741514866]

😮 Истинное значение эффекта конверсии лежит в диапазоне от -0.1% до 1.2%. Небольшое ухудшение или хорошее улучшение. Это значит, что при текущем дизайне эксперимента мы не можем с уверенностью сказать, что новая фича улучшает метрику. Однако, если перейти на бизнес-язык, мы видим следующий эффект в деньгах.

➖ Потенциальный минус: -7 000 рублей
➕ Потенциальный плюс: +116 955 рублей

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

Если наберется 150 🐳, выложу пост про подборку статей по 🆎

Где практиковать SQL?

😮 Давно не было постов вообще про SQL. Не знаю даже почему, хотя самый важный инструмент в нашей работе. Представьте, что вы прошли какие-то курсы, примерно понимаете как все решать, знаете основные концепции, но хочется потрогать задачи реальных компаний. Помню, когда сам проходил различные курсы (в том числе всем известный sql-ex, который форсили постоянно), не хватало какой-то практической составляющей, возможно задач с собеседований компаний.

Какие платформы я советую?

1. StrataScratch - здесь представлены задачи различных зарубежных компаний по SQL и не только. Различные вариации оконных функций, подзапросы, сложные структуры и все это заправлено под задачи с собеседований. https://www.stratascratch.com

2. LeetCode - по SQL я встречал не так много задач, но тем не менее, были интересные над которыми можно подумать. Есть нетипичные, которые не решить просто оконкой и взять актуальное значение данных, надо реально подумать. https://leetcode.com/

Понятно, что есть какие-то курсы, про которые я писал выше. Хочу отметить, что я смотрел. Есть DataCamp, кому-то нравится, кому-то нет. Для меня проблема, что большая часть практики - это просто дополнение запроса из предыдущего шага (с нуля что-то ты можешь и не писать вовсе).

У меня был пост с роадмапом, где я затрагивал SQL, поэтому если вам интересно, тыкайте сюда

🍪🍪 В скором времени я планирую выкладывать какие-то практические задачи сюда, с которыми реально может столкнуться каждый аналитик, поэтому, если наберется 100 🐳, делаем! Retention, пенетрации, воронки, критерии для A/B тестов и др.

А чем пользовались вы, когда изучали SQL?

Зачем нужен хэш с солью в A/B экспериментах?

😭 Начнем с хэширования. Когда мы запускаем тест, нужно понять, в какую группу попадет пользователь? В контрольную или тестовую? Чтобы сделать это случайным образом, но при этом всегда стабильно, используется хэширование. Берем уникальный идентификатор пользователя, например user_id, пропускаем его через хэш-функцию (чаще MD5), а результат делим по модулю. Например, если результат деления на 2 равен 0, пользователь идет в группу A, если 1, то в группу B. Это гарантирует, что один и тот же пользователь всегда будет попадать в одну и ту же группу.

import hashlib

user_id = "12345"
hash_value = int(hashlib.md5(user_id.encode()).hexdigest(), 16)
group = "A" if hash_value % 2 == 0 else "B"
print(group)

🧂 Теперь про соль. Если пользователь участвует сразу в нескольких тестах, его распределение в группы может повторяться. Например, в тесте кнопки “Купить” он будет в группе A, и в тесте фильтра товаров он тоже будет в группе A. Это создает пересечения экспериментов и искажает результаты (особенно, когда речь идет про разные слои, которые могут с собой конкурировать). Соль решает эту проблему. Это уникальная строка для каждого теста, которую мы добавляем к user_id перед хэшированием. Она изолирует тесты друг от друга, даже если пользователь участвует сразу в нескольких. То есть соль + хэш позволяет перемешать пользователей псевдорандомом, обеспечивая воспроизмодимость сплитования на платформе.

experiment_name = "new_checkout_flow"
salted_id = f"{experiment_name}_{user_id}"
hash_value = int(hashlib.md5(salted_id.encode()).hexdigest(), 16)
group = "A" if hash_value % 2 == 0 else "B"

Таким образом, мы разбили на 2 разные группы. Привязались к идентификатору, конкретному эксперименту и сделали псевдорандомизацию. Можно также генерировать на A/A тестах с изменением соли, обеспечивая рандомизацию пользователей. Это не просто взять и четные значения хэша менять на нечетные и наоборот. Посмотрите, как от соли меняется значение конечного хэша + соли.

print(int(hashlib.md5(f'salt2_{123}'.encode()).hexdigest(), 16)), print(int(hashlib.md5(f'salt9_{123}'.encode()).hexdigest(), 16))

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

И еще один плюс: если вы решите изменить пропорцию распределения, например, сделать 70% пользователей тестовыми, а 30% контрольными, это легко сделать с помощью хэширования. Нужно просто поменять границы.

split_percentage = 70
group = "A" if hash_value % 100 < split_percentage else "B"

Понравился пост? Если соберется 100 🐳, выложу пост про виды хэшей и чем они различаются (ну или про слои в A/B экспериментах)

Так и в реальной жизни 💀

#мемы@zasql_python

😲 Для продуктовых аналитиков нужно находиться на одной волне с продуктом, в котором они работают. Это дизайнеры, продакт-менеджеры, разработчики. Есть бесплатный «онлайн-тренажер» по продуктовому мышлению, на который я натыкался для расширения экспертизы с различными кейсами, подходами к анализу продуктов.

😎 На Хабре есть статья про различные продуктовые кейсы, где можно самому подумать + еще скормить какой-то LLM вариант ответа, тем самым иметь «эталонное решение».

🔋Если вы только вкатываетесь в какое-то направление и не только, советую присмотреться к различным хакатонам, кейс-чемпионатам. По сути расширение экспертизы + практическое применение (по крайнем мере было у меня на последнем хакатоне). Вообще для старта нормально потрогать, я подумал.

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

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

Те, кто любит подкасты, советую Make Sense. Очень разносторонние кейсы + подходы, а также подкасты различных продуктовых команд.

Seeing Statistic Theory

😡 Это то, с чего я начинал, когда начал копать в сторону аналитики данных и статистики в целом, так как понимание статистики и теории вероятностей давалось очень тяжело (начинал с курсов по статистике от Анатолия Карпова). Как понимание с оттачиванием практических примеров - кайф. Только нужно сразу закинуть пару примеров и решать в Python, например, без этого никак.

🤑 Сейчас я советую сразу присмотреться к курсу по статистике и теории вероятностей от ФЭН ВШЭ. Много практики, хорошо для общего понимания академической статистики и тервера. Будет тяжело, но на выходе получите помимо знаний, структуры особенный эффект после обучения.

♟ Если хотите, разберу относительной новый курс по прикладной статистике от ААА, делал анонс второй части тут

Ждём сообщения от заказчиков, смежников, только так. Никаких похвал, только это. Высшая благодарность 👍

#мемы

🤔 Почему важно делать просто в продукте?

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

Вы идете к кому-то из списка выше, договариваетесь, считаете, но тут возникает момент истины, что любые процессы стоят денег / времены для команды. То есть команда будет тратить время на разработку чего-то нового, жертвуя тем, что можно было сделать проще. Например, добавить один виджет / сделать что-то простое и увидеть инкремент на бизнес или посмотреть на исследования других компаний, в т.ч. конкурентов. Тут можно еще затронуть базово концепцию MVP (Minimal Valuable Product), но тут, скорее, вопрос приоритезации и то, что случайно есть риск зарубить хорошие жирные гипотезы (есть же декомпозиция, все дела...)

Помню довольное старое (5 лет назад вышло) видео Ильи Красинского по поводу юнит-экономики, про стоимость гипотез я запомнил оттуда (в целом, тут про юнит-экономику, но все же, будет полезно).

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

❤️ А что вы думаете по этому поводу, сталкивались ли вы с подобным? Если наберется много реакций продолжу дальше писать про продуктовые штуки.

ПОДДЕРЖАТЬ БУСТОМ

🎲 Что такое predict_proba?

💻 Предположим, вы решаете задачу оттока и вам нужно понять с какой вероятностью пользователь будет оттекать из сервиса. Фактический флаг, обычно, это 1 и 0 ничего нам не скажут о том, что пользователи собирают покинуть наш сервис. Для этого вам нужны определенные вероятности отнесения к оттоку (1), далее можно с этим как-то работать, например, изучать распределения, тестировать определенные гипотезы и т.д.

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

🤔 Как работает?

1. Сначала мы вычисляем линейную комбинацию векторов признаков и весов (с определенным байесом).
2. Результат подается в функцию активацию, например, классический вариант, это сигмоида (для бинарной классификации) и softmax (для многоклассовой классификации).
3. Определяем вероятности.

🐍 Пример отрабатывания вручную

 
from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression

X, y = make_classification()
lr = LogisticRegression()

lr.fit(X, y)

z = np.dot(X, lr.coef_.reshape(-1, 1)) + lr.intercept_

model_predict = lr.predict_proba(X)[:5, 1]

naive = 1 / (1 + np.exp(-z)).flatten()[:5]

print(model_predict)
print(naive)

🥰 Как видим, результаты идентичные (для вероятностей). Можно также поставить трешхолды и определить 1 или 0, чтобы замерять качество полученных моделей.

Дополнительные материалы:

1. How to Use Logistic Regression predict_proba Method in scikit-learn
2. CatBoost. Predict Proba
3. Predict_proba examples in MLflow - October 2024

❤️ Понравился пост? Поддержи бустом, пиши комментарии. Если наберется много реакций, выпущу пост про различные функционалы качества, функции ошибки в машинном обучении или про Sequential Testing 🔥

Помните, я выпускал пост про Deep Work и Pomodoro для концентрации на работе?

По большей части - это всё работа со своим временем, возможностью оптимизировать рабочие и жизненные процессы.

В своем LinkedIn я писал по поводу GTD (Getting Things Done) - это механика, при которой все задачи отправлюятся по определенному пайплайну, в конечном итоге мы имеем какую-то понятную картину того, что мы делаем сейчас, что будем делать, предварительно разгружая оперативную память мозга.

Более подробно копая в эту тему, я наткнулся на видео Александра Вотякова по тому, как структурировать все входящие задачи, как их трекать. + были прикольные штуки про привычки, выработки новых. Например, сейчас, я вырабатываю привычку ходить в зал с утра и знаете, это работает). Сейчас активно слежу за обновлениями, очень много всего интересного можно найти

Классные посты, которые я советую глянуть:

❓ Триггер, действие, награда

Жить в хаосе - это выбор слабых. 1 часть, 2 часть

В общем, подписывайтесь 👉🏼 @votyakov_ar_life, а я пойду писать следующие посты...

😵 Выбросы в A/B тестах. Проблема при дизайне, подведении результатов, планировании следующих экспериментов.

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

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

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

Почему?

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

Что можно с этим сделать?

1. Убрать выбросы на предпериоде, топ n пользователей по целевой метрике в тесте

2. Заменить значение выбросов на максимальное значение по квантилям. Пример: пользователь принесу сервису 100 рублей, 99% квантиль - 80. Пользователя мы не убираем, заменяем значением 80. Более подробно про это могу написать, проведем симуляции, посмотрим как ведут себя распределения и др.

Материалы:

Как улучшить ваши A/B-тесты: лайфхаки аналитиков Авито.

АБ тесты и подводные камни при их автоматизации

Хорошая статья на Medium, про попытки исключения различным образом выбросов

Это одна из многих проблем, которая есть при проведении экспериментов.

Используете ли вы трекеры времени для продуктивной работы? Если да, то какие? Сколько примерно вы потратили дней / месяцев / лет, чтобы их внедрить в свою жизнь? Чувствуете ли вы импакт от этого?

🍅 У части людей, например, внедрено для работы Pomodoro. Это когда ты бьешь рабочее время на короткие интервалы для работы и отдыха. Базовый вариант - это когда одна сессия выглядит следующим образом: 25 минут работаешь, 5 отдыхаешь. Требуется больше времени, чтобы быть в фокусе, хотя можно разбить на более длительные сессии. В этой статейке 70 минут работаешь, 20 минут отдыхаешь, 40 минут еще чил. Суммарно 10.5 часов на работу, 3.3 часов на отдых. Итог ~ 14 часов на сессии.

🧠Я склоняюсь в сторону Deep Work - это когда у тебя рабочая сессия длится несколько часов. Фокусированно сидишь над задачей / задачами без отвлечения. На каком-то из часов начинаешь замечать, что делать достаточно. Главное - это подготовить рабочее место, предварительно отключив раздражители, приготовиться к сессии и плотно сидеть и работать, deep work... А еще важнее, на первых этапах, вырабатывая привычку - НЕ ВСТАВАТЬ (очевидно, по каким-то делам / встречкам это делать не получится, но сессию в календаре под это дело забить можно или стремиться к этому). Если брать 4 часа на сессию, а сессий 3, получается 12 часов на сессии.

📖 Дополнительные материальчики для чтения:

🔗LINK 🔗
🔗LINK 🔗

Если вам нравится формат таких постов, ставьте реакции, пишите комментарии

💙 Яндекс Лавка. Что произошло за 6 месяцев?

Всем привет, хочу поделиться тем, что мы успели сделать за последние Q2-Q3 продуктовой командой. Несмотря на то, что я пришел ровно 4 месяца назад, видно, как продукт быстро растет, продуктово прорабатываются куча гипотез, а классные фичи до вас докатываются в самом лучшем виде. Здесь собраны очень сильные ребята из различных направлений, которые помогают вместе делать классный продукт

Теперь к главному:
Мы активно ищем сильных аналитиков, разработчиков, продактов, дизайнеров, чтобы расти быстрее, реализовывать самые бешеные и кайфовые идеи вместе.

Подборку вакансий прикреплю ниже, если появятся вопросы, пишите в личку @m459n9

💙 Вакансии в Лавке 💙

P.S. Следить за новостями Команды продукта Лавки теперь можно в Телеграме: @lavka_product_team. Присоединяйтесь! Давайте знакомиться ближе)

🔍 Causal Inference (ч. 1)

Этот пост нужен для того, чтобы базово вникнуть для чего используется

Итак, Causal Inference - это процесс поиска причинно-следственных связей. Он позволяет нам понять, насколько X влияет на Y. В статье от X5 объясняются основные техники, позволяющие оценить эффект. Как правило, они могут основываться и на простых методах по типу линейной регрессии. Вообще практически все в нашем мире можно объяснить с помощью линейной регрессии (true fact).

Зачем нам это может нужно, если есть A/B тесты?

1) Хочется оценить эффект от фичи, которая работает длительное время. Например, нужно оценить эффект от раскатки нового варианта онбординга на пользователей с момента запуска.

2) Мы не контролируем формирование групп. Это может быть применимо к оффлайн-экспериментам.

3) Не можем провести эксперимент по различным причинам. Например, по техническим или этическим, когда тест нужно держать очень долго

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

🆎 Представляем, что мы хотели провести A/B тест, но по какой-то из причин, этого не сделали. Помните, в чем основная задача? Это определить будет ли значимым эффект при рандомном семплировании определенных групп. Проводя эксперимент в классическом понимании, мы имеем тест, контроль (на кого-то раскатили новый функционал, на кого-то нет), мы применяем. Далее, ссылаясь на то, что наблюдения независимые (или зависимые и мы применяем поправки), сравниваем группы, получаем эффект

В задачах Causal Inference может быть несколько вариантов решения задач.

1. Определить то, как ведет себя метрика на препериоде и оценить то, как после запуска воздействия поменялось поведение метрики (по сравнению с прогнозом). Например, Diff-n-diff или Causal Impact (Counterfactuals analysis)

2. В задачах, где у нас нет контроля, сопоставить пользователей по похожести и оценивать эффект так, как будто мы проводим тест. PSM, Instrumental variables и различные вариации (Квази-эксперименты)

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

Я не забыл, в процессе. Будет пост / посты на следующей неделе. До сих пор ждёте? 😮

Ставьте котика на реакцию 😱

Это же гениально 😂

Ссылка на Reddit

#memes

Градиентный спуск (ч. 1)

😔 Всем привет! Сегодня я бы хотел вам рассказать про то, что такое градиентный спуск и вообще для чего он применяется, в каких направлениях и для чего. Градиент отражает направление скорейшего возрастания функции

💳 Начнем с линейной ргерессии, для тех кто не помнит / не знает, уравнение прямой задается yi = wi * xi, где yi - значение целевого признака. Это конечно замечательно, но истинные значения (если мы живем в непрерывном пространстве будут всегда различаться от предсказанных (какая-то ошибка возникнет).

🍦 Решение задачи - минимизировать ошибки, возникаемые при изучении модели. Но как мы это можем сделать, если у нас xi, yi заданы? Правильно, повлиять как-то на веса признаков. Для линейной регрессии обычно используется такая функция потерь, как MSE, которую мы хотим минимизировать. Градиентный спуск позволяет найти веса модели, при которых ошибка будет минимальна (осторожно, модель может найти локальный / глобальный минимум). Мы хотим понять, при каких значения wi наше значение ошибки будет минимально. Почему берется MSE, могу рассказать в следующих частях

👌 У градиентного спуска есть 3 параметра:
1) начальная точка, в нашем контексте - это вектор весов признаков (выбираются случайно)
2) количество итераций, мы определяем заранее сколько итеративно нам нужно пройтись, чтобы прийти к точке, близкой к минимуму
3) коэффициент скорости обучения (Learning Rate). Если мы будем выбирать слишком маленький шаг, то можем за ограниченное количество итераций не прийти в точку минимума (функции потерь в нашем случае), а если Learning Rate будет слишком большим, то мы можем перепрыгнуть точку минимума.
4*) количество эпох и размер батчей - это используется для стохастического градиентного спуска.

в общем виде:

start_point = i
iterations = n
learning_rate = t

for _ in range(iterations):
    start_point -= t * gradient(x)

start_point, func(start_point)

Это позволит нам найти минимум функции итерационно, в нашем контексте - функции потерь.

Игрушечный пример с градиентным спуском.

import numpy as np

def loss_function(x):
    return x ** 2 * np.sin(x)

def gradient(x):
    return 2 * x * np.sin(x) + x**2 * np.cos(x)

def gradient_descent(starting_point, learning_rate, num_iterations):
    x = starting_point
    for _ in range(num_iterations):
        x -= learning_rate * gradient(x)
    return x

starting_point = 3  # Начальная точка, выбирается случайно
learning_rate = 0.01  # Скорость обучения
num_iterations = 100  # Количество итераций

minimum = gradient_descent(starting_point, learning_rate, num_iterations)

В этом примере minimum = argmin(x), т.е. точка в которой достигается минимум функции, а соответствующее значение можно найти, если подставить значения в loss_function(minimum).

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

Где можно почитать подробней?

Учебник Яндекса (с формулками)
Статья на Хабр
Презентация от Александра Дьяконова

Если хотите больше постов, связанных с ML или около того, ставьте реакции, пишите комментарии!

Авито ищет опытных специалистов в Data Science

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

Присоединяйтесь к сильному комьюнити дата-сайентистов всего в три шага:

1. Подайте заявку до 1 октября
2. Решите тест
3. Пройдите интервью 5-6 октября

Откликайтесь и забирайте оффер!

Всем доброй ночи! Увидел, что у Академии Аналитиков Авито вышла вторая часть курса по прикладной статистике. Кто-то уже успел посмотреть? Первая часть мне зашла, можно посмотреть на одном дыхании под lofi music, я считаю (ну почти). Тут поинтересней темы, интересно что скажут про критерий MW, будет ли что-то про модификации и другое, узнаю, отпишу (честно, не помню как они применяют его, нужны ли какие-то условия для выборки, в демо платформы A/B тестов не увидел)

P.S: Я никуда не ушел, через 3 дня заканчивается испытательный срок, все отпишу 😋

😡 - когда Максим не выпускал пост месяц, а ты ждал мем...

UPD: Если вы не смотрели первую часть, настоятельно рекомендую глянуть.

UPD2: Ссылочка: https://avito.tech/education/statistics (жаль, что на ютабчике, а не на рутубе офк)

22 🎉

Дальше - больше. Всем спасибо, что продолжаете и дальше смотреть за постами, я очень рад этому! Нас уже 3000, блин! С последнего поста про др уже х2 подписчиков 😊

Больше не смогу отправить в красивое время сообщение. Надо было в 11 лет постить…

Выезд клиентской аналитики Яндекс 🍫 Лавки в Сочи

🤗 Всем привет! Этот пост про то, как мы вместе с командой полетели в Сочи. Были продуктовые, маркетинговые аналитики и ресерчеры. В общем, объединили количественные и качественные исследования. Очень классная движуха, поскольку можно с разных сторон посмотреть на то, что происходит в Лавке.

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

🕵️‍♂️ Кстати, по одной из тем меня назначили фасилитатором. Цель - забрифовать людей по теме, дать вкратце понимание того, что происходит в определенном направлении бизнеса.

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

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

😊 А какая была ваша первая командировка? Делитесь об этом в комментариях, ставьте реакции!

💪 Ладно, закину еще сюда. 150 реакций здесь и будет пост про Causal Inference в аналитике!

😴 Давайте в выходные отдыхать, закину вам пару интересных фактов, которые произошли с Яндексом за последнее время

1. Для тех, кто хотел посмотреть на то, как работает Яндекс 🍫 Лавка изнутри, у ❤️ вышел 2 недели назад пост про это, очень интересно было посмотреть

2. У Яндексоидов вышла папка с большим количеством каналов (я там есть, кстати), можно посмотреть изнутри, как кто живет, о чем пишут. Для себя подметил некоторые каналы. Первая картинка была взята отсюда

3. Появилась новая фича у Лавки в виде дозаказа 🤑

4. Недавно была презентация нового тикера YDEX. Уже доступен на Московской бирже

👍 А еще… У меня есть много всего интересного, про что можно рассказать. Ставьте реакции, пишите комментарии, что бы вы хотели видеть в дальнейшем

🆎 Демо платформы A/B тестов в Avito. Интересно реализовано, больше всего кайфанул от загруженности слоев при проведении экспа по разным разбивкам устройств. 5 минут и можно посмотреть, буквально свежая новость, к просмотру вэлком. https://www.youtube.com/watch?v=OppYNmYxCTg

Мое предложение все еще в силе: https://t.me/zasql_python/240

Для чего нужен ML в аналитике?

❓ Сразу же вопрос, можно ли решить продуктово задачу как-то без использования машинного обучения? Что решаете данной задачей? Да-да типичные вопросы "аналитика-душнилы", который постоянно хочет задать вопрос: "Зачем?" (и это правильно).

😩 Раз уж на то пошло, давайте опишу здесь сценарии, в которых ML может применяться (понятно, что их куда больше, рассмотрю те, которые вспомнил). Понятно, что аналитики бывают разные, рассмотрю с призмы продуктовой аналитики. Зачастую используются какие-то ML решения для исследований, а продакшн уже не наше)

😐 Задача классификации. Хотим предсказывать какую-то бинарную величину (или оценивать вероятность). Нам нужно оценить, например, отток пользователей, какие-то дополнительные исследования в эту сторону. Пример ноутбука Kaggle

👍 Временные ряды. Если у нас есть желание построить какой-то прогноз, например, внутренний KPI продаж, это можно сделать как на основе различных факторов, так и используя временные ряды. Туториал на Kaggle.

😤 Causal Inference aka причинно-следственные связи. Внедряем какую-то фичу, хотим честно замерить эффект на пользователей.❗️Про это могу рассказать в следующих постах, если наберется нормальное количество реакций❗️

😎 Матчинг. Поиск из базы наших пользователей тех людей, кто соответствует поставленной задачи. Например, те пользователи, которые имеют определенный паттерн, который нас устраивает и мы хотим найти похожих. Ноутбук Яндекса ❤️

😎 MMM (Marketing Mix Modeling). Это про то, когда нам нужно оценить различные маркетинговые каналы (но это больше к маркетинговой аналитике). Статьи на Хабр. Первая часть, вторая часть

🕺 Сегментация пользователей. Кластеризация какая-нибудь, есть пример тут с гайдом, как это можно сделать.
...
feaure importance ... и так далее.

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

😤 Все зависит от специфики команды, можно и динамическим ценообразоованием заняться, блин

👍 А в каких кейсах вы использовали ML? Если на этом посте наберется 150+ реакций, запилю какой-нибудь гайд с решением продуктовой задачи с помощью ML

Всем привет! Сюда после моего прихода в Яндекс 💙 Лавку присоединилось большое количество человек. Хочу порекомендовать канал @start_ds Ромы Васильева, ранее он занимался коммерческой аналитикой в Лавке. Помню, как смотрел его видео на ютубчике про различные вопросы с собеседований, интервью с различными клевыми ребятами и мне всегда этот формат очень сильно заходил, а также разборы различных ML вопросов с собеседований и не только. По 🆎 есть также хорошие посты со ссылками на источники. Сейчас он перешел в большой Яндекс, но тем не менее, у человека еще есть время выкладывать годные посты, в общем вэлком 😤

🧀 Ранее, когда я изучал разные материалы, связанные с A/B тестами, натыкался на интересный доклад (aka дискуссию) о том, как проводятся A/B тесты про специфику, проблемы.

А. Карпов, А. Сахнов, А. Байрамкулов, А. Хакимов — A/B-тесты. Источники данных и инструменты анализа

😑 Зачем нужно развивать культуру A/B тестов?
Нужны не всем. Например, чтобы увидеть результат в каком-то стартапе можно увидеть эффект практически сразу (если мы говорим о продуктовых изменениях). Микроизменения хочется смотреть крупным игрокам, такие показатели без A/B тестов поймать сложно. Скажу, что в целом достаточно классно, когда продукт мыслит в рамках экспериментов и такими шажками развивается (гипотез много, все сразу в прод не катнешь, а сезонность учитывать хочется).

🐈 В бизнесе решили, что нужен A/B тест. Нужна ли платформа?
Платформа сама по себе достаточно сложная, включает в себя очень много всего. Например, это и связь различных источников и метричница и бэкэнд, короче в общем много всего. Как будто мы должны понять окупится ли платформа (поддержание + внедрение). Можно сказать, что платформа нужна тогда, когда культура A/B тестов начинает прогрессировать и людям важно разделять тесты, например, на различные слои, следить за кучей метрик и т.д.

😱 Как разные сферы влияют на A/B тестирование?
... (думаю про это даже пост катнуть, если интересно, пишите).

🐶 Тут еще упоминалось о различных тестах, которые рассматривались (запись 2023 года). Говорили о разных платформах, в т.ч про Ambrosia. Почитал документацию, будто она не может бить по неравным размерам групп, не нашел correction какой-то по крайнем мере с отношением групп, как в статейке от Ozon. Ладно, еще упомянули Varioqub от ❣️

🆎 Если наберется 100 🐳, напишу про то, как можно оценивать влияние различных фич друг на друга или про возможности A/B платформ разных компаний.

✈️ От гипотезы до инсайтов

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

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

Пример: Если мы внедрим X, то это повлияет на Y с эффектом в Z% в течение T дней.

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

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

Data - метрики / показатели на которые мы хотим появлиять. Например, в контексте A/B тестирования это могут быть целевые метрики (AOV, ARPU, CR, ну вы поняли...)

👍 Insight - выводы, которые мы в дальнейшем можем отдавать в бизнес, либо использовать для дальнейших исследований. Например, при проведении A/B тестирования, мы увидели, как в стенде метрик (если он есть), как прокрасились какие-то метрики, но целевые нет => можно в дальнейшем с полученным знанием формулировать новую гипотезу и тестировать еще раз.

Советы по HADI:

1. Можно формулировать гипотезы по SMART.
2. Приоретизация результата, можно использовать RICE
3. Чем больше гипотез, тем лучше, можно тестировать много всего.

🥰 Если на посте наберется 100 реакций, напишу про стенд метрик более подробно!

✈️ Вдруг кто еще не видел, по ML есть хороший конспектик, красиво оформленный + понятно объясненный. Был бы еще код от руки написан, цены бы не было, а так, хорошо 🙊

Признавайтесь, сколько натапали уже кабанов? ❤️