High Standard Deviation vs Low Standard Deviaton.

(?) without CUPED vs with CUPED. Variance reduction, yes. P-hacking…

📚 Материалы по методам снижения дисперсии
(увеличиваем чувствительность A/B эксперимента и уменьшаем его длительность):

1. VWE (Variance Weighted Estimator)
2. CUPED / CUPED Multiple Covariates
3. CUNOPAC / CUPAC / CUMPED etc.
4. Стратификация / Постстратификация
5. Outlier Capping / Winsorizing
6. ... список могу продолжить еще

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

107 или 115? Кто вы сегодня?

А про то, зачем это нужно, ныряйте в комментарии 🔽

📺 [Youtube] Создаем AI-агентов на LangChain/LangGraph от идеи до MVP за 20 минут!

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

Агент работает как граф: каждая функция - это узел (нода), а данные переходят по рёбрам.

🤔 Логика такая:

1️⃣ Генерация подтем

2️⃣ Утверждение от пользователя (принимаем или нет)

3️⃣ Поиск релевантных документов

4️⃣ Анализ пробелов в знаниях

5️⃣ Формирование отчёта

💻 В процессе используются LangChain, LangGraph и LangSmith - для построения цепочек, логики переходов и визуализации.

💙 Делитесь постом, если он был полезен!

«Авито Тех» выкупает права на IT-платформу для продуктовой аналитики EXPF Sigma.

Статья

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

Что думаете? Неплохой выход для Trisigma? 😱

Фреймворк HEART

Фреймворк помогает оценивать пользовательский опыт по 5 направлениям:
Happiness, Engagement, Adoption, Retention, Task Success

📺 Видео на Youtube

❤️ Happiness. Удовлетворённость
🎯 Цель: Пользователям должно быть легко, полезно и приятно пользоваться приложением.

Сигналы:
1. Оставляют отзывы в сторах
2. Делятся мнением в опросах

Метрики:
1. TPS/NPS (готовность рекомендовать)
2. Доля 5-звёздочных оценок
3. Оценка обратной связи

😱 Engagement. Вовлечённость
🎯 Цель: Пользователи регулярно потребляют контент и взаимодействуют с продуктом.

Сигналы: Время, проведённое в приложении, растёт

Метрики:
1. Среднее время сессии на пользователя
2. Конверсия в целевое действие
3. Кол-во визитов на пользователя

🚀 Adoption. Принятие
🎯 Цель: Новые пользователи начинают находить ценность в продукте.

Сигналы:
1. Рост установок
2. Рост регистраций
3. Рост логинов

Метрики:
1. Доля установок
2. % новых пользователей
3. Кол-во логинов / DAU

🔄 Retention. Удержание
🎯 Цель: Пользователи возвращаются в продукт, чтобы снова достигать свои цели.

Сигналы:
1. Растёт число активных пользователей
2. Растёт доля повторных визитов

Метрики:
1. % повторных пользователей
2. DAU, WAU, MAU
3* Retention 7D / 14D / 30D

✅ Task Success — Успешность действий
🎯 Цель: Пользователь с лёгкостью достигает того, зачем пришёл.

Сигналы: Увеличивается число успешно завершённых задач

Метрики:
1. % ошибок
2. % прерываний (drop-off)
3. % ANR (приложение не отвечает)

В целом, HEART — это как проверочный список: что именно важно для вашего UX прямо сейчас?
А ещё классно использовать его не в одиночку, а с продактом, дизайнерами и ресёчерами — чтобы не тянуть UX в одну сторону, а двигаться вместе.

Понравился пост? Ставьте 🐳, пишите в комментарии, что разобрать дальше!

❌ Красная карточка

Меня дисквалифицировали из университета.

Вот прошли мои 4 (5?) лет в РАНХиГсе, теперь я дипломированный специалист… (менеджер)

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

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

А через две недели я выхожу на новое место работы после ❤️

🐳 Если наберется много-много реакций и комментариев, расскажу про это более подробно в следующих постах!

Встречи или работа: где найти золотую середину аналитика?

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

Все это очень классно, но давайте посмотрим на то, как это действительно может быть.

Раньше, когда я работал аналитиком данных, у меня были командные синки и 1-2 встречи с основными стейкхолдерами.

И все!
Никаких больше встреч.
Сиди и работай.
Крути запросы, настраивай ETL, делай дашборды и исследования, приноси импакт продукту.

Далее, когда я перешел в продуктовую аналитику, встреч стало намного больше раза в 3 или даже больше. Причем самое интересное, что встречи, которые якобы являлись ВАЖНЫМИ проходили следующим образом:

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

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

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

Action Points:

1. 2-3 дня в неделю ставить БЕЗ ВСТРЕЧ в календаре. Deep Work наше все).
2. Появляться только на важных встречах для вас, как чувствуете. Понятно, что если встреча с руководителем, то скорее всего, ее не нужно пропускать :3
3. Если пошло на то, что на встрече точно НУЖНО быть, тогда смотрим адженду, чтобы четко понимать как можно быстро решить вопросы / проблемы.

Встреч меньше не становится, но держать фокус — реально

А как вы справляетесь с потоком встреч? Получается ли выделять дни под фокус? Что работает у вас?

Ставьте 🐳, если такие посты заходят)

@zasql_python

📺 [YouTube] Денис Теплов. Как использовать дофаминовые петли в развитии продукта

Доклад от CPO Лиги Ставок, в котором говорится о продуктовых механиках, которые, кстати, связаны с формированием привычек.

Стимул -> Желание -> Реакция -> Вознаграждение.

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

🟣Прогресс как источник мотивации🟣

1. Прогресс-бар в регистрации. Просто добавили баннер с прогресс-баром — результат: +0.9 п.п. конверсии в активацию, +3.8% оборот новичков.
2. Уровни в программе лояльности. Чем выше уровень, тем больше бонус — +2.7 п.п. Retention Rate второго месяца, +9.8% оборот.
3. Примеры Apple Watch, Duolingo. Регулярная фиксация и награда за закрытые цели усиливают вовлечённость. Работает безотказно.

🟢Поощрение целевых действий🟢

1. Кейс: Лига Ставок (Тамагочи). Виртуальный зверёк, который растёт за активность, просто меняется настроение. Эффект: +1.3% депозитов, +0.7% GMV.
2. Выигрыш пари. Моментальная обратная связь (что-то из разряда: ты молодец, все топчик, так держать). Эффект: +0.2% количество ставок.

🔵Поощрение нецелевых действий🔵

1. Награда за промежуточные шаги. Ввод карты или выбор адреса — поощрение даже на этапе онбординга даёт +2.8 п.п. к активации, +11.9% оборот новичков.
2. Чтение книги. Привычка формируется через награду за смежные действия. Само действие - это подготовка к целевому сценарию.

🟣Неожиданные награды🟣

Суть: постоянные предсказуемые бонусы быстро перестают работать. Неожиданные - цепляют.

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

1. Spotify: переменные награды (итоги года) - формируют ожидание и интерес.
2. LinkedIn: триггер на статус (ты в топ-50% публикаций) — вовлекает в активность.
3. Лига Ставок: подсветка легендарных коэффициентов — +0.3 п.п. к количеству ставок.
4. Лига Ставок: Социальное подтверждение: фраза "ещё 1000 человек повторили за тобой".

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

Понравился пост? Поставьте 🐳, пишите комментарии

Всех с понедельником!
Не отвлекаемся!
Работаем 😓

😏 @ds_memes

📺 Мок интервью для Продакт Менеджера | Кейсы из Яндекса

🎯 Формат: 2 кейса, реальные задачи с собеседований на продакт-менеджеров. Обсуждение кандидатами по ~15–20 минут, далее фидбек и обсуждение с продакт-менеджерами.

🧺 Кейс 1: Стиральная машина в Средневековой Европе

❓ Задача: Разработать MVP стиральной машины для условий средневековья (нет электричества, нет водопровода, другие социальные условия).

💡 Ключевые аспекты решения:

1. Целевая аудитория: прачки, служанки, крестьянские семьи.
2. Боли: тяжёлый труд, холодная вода, отсутствие времени, неудобство.
3. Конкуренты: ручная стирка, природные решения (водяные колёса).
4. Идея MVP: механическое устройство на водяной мельнице, стирающее сразу несколько вещей.
5. Метрики: количество отстиранного белья, удовлетворённость, сокращение времени.
6. Маркетинг: гонцы, слухи, ярмарки, церкви.
7. Ограничения: отсутствие технологий, нужны простые материалы (дерево, канаты).
8. Модели распространения: аренда, прачечные, версии для феодалов.

🤌 Обратная связь:

1. Плюсы: структура, работа с аудиторией.
2. Минусы: мало конкретики, не все гипотезы протестированы, нужны вопросы к нанимающему менеджеру (например: эпоха, регион, цели).

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

🫙 Кейс 2: Подписка в Яндекс Банке

❓ Задача: Разработать и обосновать подписочную модель для Яндекс Банка по аналогии с Тинькофф.

💡 Ключевые аспекты решения:

1. Анализ конкурентов: Тинькофф, Сбер, Альфа -> кэшбэк, статус, бонусы.
2. Цели Яндекса: рост LTV, удержание, рост выручки.
3. Гипотеза: пользователи хотят кэшбэк и статус.
4. ЦА: частые пользователи Яндекс-сервисов, миллениалы, городские жители.
5. Фичи: доп. кэшбэк в экосистеме, приоритетная поддержка, лимит на переводы.
6. Тестирование: MVP за 2 (4?) недели, A/B-тесты, тест на разных ЦА.
7. Метрики: конверсия в подписку, выручка, удержание, NPS, ARPU.
8. Запуск: бесплатный пробный период, ретаргетинг, промо-кампании.
9. Юнит-экономика: оценка затрат, возврата, LT/CPA.
10. Приоритизация: фичи, которые решают боли, легко объясняются и измеримы.

🤌 Обратная связь:

* Сильная сторона - рыночный анализ и работа с метриками.
* Рекомендация: больше вопросов к контексту, чётче проработка бизнес-целей.

🧠 Чему учат эти кейсы:

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

Умение задать правильные вопросы нанимающему менеджеру - ключ к успешному решению.

Понравился пост? Ставьте 🐳, пишите комментарии!

Новая поляна

Всем привет! Недавно я обещал рассказать о том, куда я ухожу после Яндекса. Думаю, время настало, так как я успел отработать 5 дней 🥳

Я ушел Sr продуктовым аналитиком в рекламную платформу в WB 🛒.

По первым впечатлениям, все заходит и стек похож очень сильно на 💙, чему я очень сильно рад. Мне интересно написать будет про оптимизацию запросов, различные технологии (ближе к DE), планирую опубликовать пилотный пост, если зайдет, то в эту сторону тоже будем двигать!

По стеку: ClickHouse, Trino, SuperSet, Spark, HDFS, JupyterHub, GitLab.

Задач, которые можно тут сделать большое количество (как и везде в принципе, всегда найдется время что-то поделать): от базовой отчетности и исследований до реализации методологии A/B тестирования. Делать есть что и есть где развернуться 💻

По процессам, команде, проектам пока что все нравится, будем смотреть дальше как пойдет.

Сейчас я поступаю в магистратуру. Предварительно сдал большее количество вступительных испытаний (5+, без учета конкурсов портфолио). Если отдельно интересна эта тема, ставьте реакции (🐳 киты важно!). Скажу, как выбирал, почему рассматривал.

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

💫 Spark для аналитика (ч. 1)

Раньше в 💙 я работал немного со Spark, большая часть задач спокойно решалась внутри одной БД или выгрузкой в pandas.

Сейчас для моих задач Spark - это необходимость, чтобы не падал JupyterHub по оперативной памяти: все вычисления выполняются распределённо на кластере с большим объёмом ресурсов. Но это не волшебная таблетка, т.к. важно следить за тем, как используются ресурсы, грамотно настраивать Spark-приложения и оптимизировать запросы. На самом деле подход к работе с ресурсами здесь другой, и есть ряд ограничений, о которых расскажу в следующих постах 🙃

🥳 Как я использую сейчас

1. Собираю данные из разных источников
В реальных задачах часто нужно объединять сразу несколько источников: выгрузки из разных баз, parquet и тд. Пока всё влезает в pandas - норм, но когда данных слишком много, pandas начинает падать. Spark позволяет легко подтянуть все необходимые источники и собрать их в одну большую таблицу, не заботясь об ограничениях памяти.

2. Выполняю тяжёлые вычисления и агрегации
После того как все данные собраны, начинаются подсчеты метрик по большим объёмам данных. Здесь Spark выигрывает за счёт распределённых вычислений: вся тяжёлая работа идёт на кластере, а не на ноутбуке. Как только нужные агрегаты посчитаны, можно забрать результат и уже дальше анализировать, строить графики и т.д.

😍 Spark реально может работать дольше, чем pandas, если данных немного. Всё из-за архитектуры: Spark каждый раз поднимает распределённую систему, разбивает задачи на части, отправляет их на кластер и только потом собирает результат. Pandas же считает всё в оперативке и на небольших данных это быстрее почти всегда.

🔽Ниже прикрепляю основные функции для работы в Spark, которые я использую для решения задач аналитики

from pyspark.sql import SparkSession
from pyspark.sql.functions import avg, count

# запускаем Spark-сессию, тут еще можно закопаться в настройки приложения (если будет много 🐳, выложу) 

spark = SparkSession.builder.appName("zasql_python").getOrCreate()  # название приложения может быть произвольным

# читаем csv и кучу источников

df_csv = spark.read.csv("file.csv", header=True, inferSchema=True)
df_parquet = spark.read.parquet("file.parquet")
df_json = spark.read.json("file.json")

# джойним таблицы между собой

df_joined = df_csv.join(df_parquet, on="user_id", how="inner")

# фильтруем данные

df_filtered = df_joined.filter(df_joined["is_active"] == 1)

# применяем агрегирующие функции, считаем сумму строчек, среднее значение по заказам

df_grouped = (
    df_filtered
    .groupBy("country")
    .agg(
        count("*").alias("users_count"),
        avg("order_sum").alias("avg_order_sum")
    )
)

df_pandas = df_grouped.toPandas()

🐼 Очень похоже на pandas + можно в любой момент пересесть на spark.sql и писать в sql-формате любой запрос.

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("zasql_python_sql").getOrCreate() # произвольное название приложения, должно быть другим, если запускаем параллельно

df_orders = spark.read.parquet("orders.parquet")  # читаем в Spark DataFrame первый источник источник
df_users = spark.read.csv("users.csv", header=True, inferSchema=True) # читаем в Spark DataFrame второй источник

df_orders.createOrReplaceTempView("orders") # создаем темповые таблицы заказов
df_users.createOrReplaceTempView("users") # создаем темповые таблицы юзеров

# теперь читаем тут в sql-формате

query = """
    SELECT 
        u.country,
        COUNT(DISTINCT o.user_id) AS active_users,
        AVG(o.order_sum) AS avg_order_sum
    FROM orders o
    JOIN users u ON o.user_id = u.user_id
    WHERE o.is_active = 1
    GROUP BY u.country
    ORDER BY avg_order_sum DESC
"""

result = spark.sql(query) # читаем в spark.sql, результат тот же получаем, но в SQL-формате
result.show() # показать значения, но можно перевести и в pandas, но ресурсов много сожрет

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

Ставьте 🐳, если хотите продолжение истории про Spark 💫

😋 Когда задачи кочуют из спринта в спринт

Всем привет! У кого в трекере задач был таск, который существовал бесконечно (по крайнем мере вам так кажется)?

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

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

❓ Как это выглядит на практике
1. Встречи проходят, а таска осталась на месте, никаких апдейтов не произошло.
2. Заказчик на вопрос "актуально ли?" отвечает что-то типа "ну, наверное, да…", но сам не уверен. Обычно вот тут нужно остановиться и спросить более конкретно про задачу, которую покрывает инструмент.
3. На стендапах появляется лёгкая неловкость (или часть людей в принципе не интересуются): все понимают, что задача висит, но почему - никто не знает. Было такое, что задача у смежного направления могла висеть и по 2-3 месяца, хотя по сути нужно было декомпозировать до более мелких задач и прокачивать видимость выполнения работы)
4. В голове включается голос (от тебя): "Может, со мной что-то не так?" — и начинается самокопание. Расслабься, попробуй посмотреть с холодной головой, что ты действительно сделал и почему вообще это было нужно.

😋 Что делать?
1. Декомпозировать. Разбиваю задачу на мелкие шаги. Вообще это может выглядеть вот так, если, например, задача - это собрать классный дашборд!

а) поговорить с заказчиком
б) собрать сырые данные
в) проверить метрики
г) собрать прототип
д) выкатить первую версию.
е) поддержка.

2. Фиксировать всё письменно. Заказчик сказал устно - завтра забудет. И да, спустя время это спасает, когда возвращаемся к болям, тут важно ее закрыть и все будет топчик.
3. Не бояться возвращать задачу. Если ТЗ меняется - переоткрываю и честно спрашиваю: "А что реально нужно?" Часто оказывается, что половину уже не надо или приоритеты поменялись.

В следующих постах вернемся к техническим аспектам, ну а пока все!

Ставьте мои любимые реакции 🐳🐬, делитесь постом и пишите в комментариях были ли такие ситуации у вас!

Аналитика мемов

😏 Возможно вы уже заметили подозрительную активность с каналом @ds_memes

😐 Рад поделиться с вами своим новым проектом. Хочу сделать его максимально прозрачным и раскрыть все карты.

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

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

Тематика: контент подобран только на определенную тему IT / работа / офис 💻

Ничего лишнего: никакой тяжелой теории и смыслов - только мемы.

Если вам интересно следить за развитием такого продукта, ставьте реакции - расскажу как полностью автоматизировал процесс публикации и подбора контента. Ставьте 🐳🐬, если интересно. Ссылочку продублирую тут.

И пусть у вас всегда будет под рукой база мемов для чата с коллегами 😎

💫 Spark для аналитика (ч.2.)

Собралось много реакций на предыдущем посте про Spark, делаю еще один!

Repartition в Spark. Зачем это вообще нужно?

В pandas не задумываешься про куски данных: читаете DataFrame и сразу работаешь с ним целиком. В Spark всё иначе: данные делятся на партиции (шарды), которые обрабатываются разными воркерами. Repartition позволяет управлять тем, как и насколько равномерно эти куски разбросаны по кластеру.

❓ Зачем?

⚖️ Баланс нагрузки на кластер. Spark работает быстрее, если данные распределены по всем воркерам более-менее равномерно. Если партиций мало, часть узлов простаивает, остальные тянут всё на себе и теряется весь смысл распределённых вычислений.

🚤 Ускоряет джойны и агрегации. Самая частая боль в Spark - это медленные джойны или группировки. Причина часто в том, что данные по ключу раскиданы неравномерно. Если сделать .repartition("key") перед джойном Spark сможет склеить нужные куски локально, а не гонять данные по всему кластеру.

📝 Экономит память и снижает риск падений приложений. Иногда Spark после фильтрации или select делает ОЧЕНЬ перекошенные партиции: на одной куча данных, на другой почти ничего. Это может привести к OutOfMemory именно на одном воркере, при том что на других куча свободной памяти. Repartition выравнивает данные и размазывает нагрузку.

🗃️ Контроль количества файлов на выходе. Когда записываешь данные в parquet/csv, Spark по дефолту делает столько файлов, сколько партиций в DataFrame.
Если хочешь один файл — обязательно делайте .repartition(1) перед записью, иначе получишь кучу маленьких частей.

📝 Как это выглядит на практике

🔗 Джойны (делаем repartition по ключу объединения таблиц, так проще собрать ключи, разбросанные по кластеру)

df_left = df_left.repartition("user_id")
df_right = df_right.repartition("user_id")
df_joined = df_left.join(df_right, on="user_id", how="inner")

✍️ Запись (в примере ниже указано то, что на выходе мы получаем один файл).

df_result.repartition(1).write.parquet("result.parquet")

☝️ Изменяем количество партиций вручную.

df = df.repartition(50)  # вручную задаём 50 партиций

Обычно количество партиций автоматически подтягивается из конфига приложения, возможно, при настройке видели параметр spark.sql.shuffle.partitions

⚠ Самое важное в этом посте, что нужно искать размен между количеством партиций и размером задач на воркеры.

1️⃣

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

2️⃣

Слишком мало партиций. Неэффективно, Spark теряет свою распределённость, одна нода делает всю работу.

Вообще в DA / DS / ML / DE мы всегда работаем с разменом (трейд-оффами) и все упирается в задачи, которые мы решаем)

Пишем дальше про Spark или нет?
🐳 — Пишем, давай еще, очень интересно
🤝 — Давай уже про что-то другое!