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

📈 Что относится к продуктовому росту

Входит:

— Задачи, которые напрямую влияют на метрики продукта: CR, Retention, активацию, LTV
— Оптимизация UX, фичи с прикладной пользой (да, те самые “циничные”)
— CRM и триггерные коммуникации
— Работа с офферами, подписками, монетизацией
— A/B тесты и проверка гипотез

Не входит:

— Фичи для имиджа и роста NPS без понятного влияния на поведение
— Внешний маркетинг и рекламные кампании (включая перфоманс)

Три направления продуктового роста + ключевые механики

1️⃣ Привлечение и активация
🤩 Задача: помочь новичку быстро получить первую ценность

🟣Персонализированный онбординг

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

🟣Aha-момент за 30 секунд

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

🟣Прогресс-бар

пользователь прошёл часть пути — и он с большей вероятностью завершит начатое. Прогресс-бары особенно эффективны в регистрации, настройке профиля, подборе интересов.

🟣Онбординг-напоминалки

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

Цель: удержать пользователя, чтобы он понял ценность.

2️⃣ Удержание и возвращение
🐸 Задача: сделать так, чтобы пользователь возвращался и не отваливался

🔵Daily rewards и челленджи — причины зайти каждый день (Например, это реализовано у Duolingo или Yazio).

🔵Персональные рекомендации — показываем релевантный контент или товары (Сейчас в это идут все сервисы, больше персонализации)

🔵Семейные подписки — люди остаются ради общего опыта и экономии (Кинопоиск с возможонстью просмотра для всей семьи)

🔵Winback-офферы — пуш/письмо с персональным предложением тем, кто ушёл (Коммуникация на отточников).

🔵Заморозка подписки — альтернатива отмене, снижает отток (Например, Duolingo или приложения с игровой механикой).

Цель: дать ощущение пользы и повода вернуться

3️⃣ Монетизация и LTV
🤑 Задача: зарабатывать больше с каждого пользователя

🟡Freemium + пробный доступ — вовлечь сначала, продать потом

обычно пользователям предоставляют 7-30 дней для пользования плюшками продукта

🟡Апгрейд через ценность — дать попробовать premium, чтобы захотелось остаться

работает как часть freemium или отдельно: пользователю предлагают временный апгрейд до премиум-версии без ограничений)

🟡Кросс-продажи — показать сопутствующие товары/фичи

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

🟡Лёгкие подписки / микроплатежи — сниженный порог входа

механика снижения болевого порога: вместо годовой подписки за X можно предложить месячную за X / k

😍 Цель: увеличить выручку не только количеством, но и качеством

Yango Play:
Первый год — привлечение
Второй год — активация
Третий год — удержание и выручка

Примеры продуктового роста других компаний

🔵Dropbox — рост через рефералку
🟣Проблема: дорогая реклама
🟡Решение: двухсторонняя реферальная система (бонус за приглашение)
🟢Результат: +60% регистраций, кратное снижение CAC

🔵Superhuman — элитность через waitlist
🟣Проблема: конкуренция с Gmail
🟡Решение: доступ только по инвайту, индивидуальный онбординг
🟢Результат: высокий LTV, искусственный дефицит → рост

🔵ConvertKit — рост через авторов
🟣Проблема: конкуренция с Mailchimp
🟡Решение: ниша блогеров + «значок» в email-подписи
🟢Результат: органический рост, лояльная аудитория

🔵Calendly — вирусность через встречи
🟣Проблема: как вовлечь новых пользователей
🟡Решение: бесплатные встречи + брендинг в ссылке
🟢Результат: каждая встреча — новая точка роста

А какие подходы применяете вы в продукте? Ставьте 🔥 и буду дальше писать про продуктовые штуки!

⚡️Анализируем продажи на Wildberries с помощью Python

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

Андрон Алексанян - эксперт по аналитике с 8 летним опытом и по совместительству CEO Simulative в прямом эфире проанализирует продажи на Wildberries с помощью Python.

Что будет на вебинаре:

🟠Напишем скрипт на Python, который каждый час собирает статистику о ранжировании карточки на WB по ключевым запросам;
🟠Построим наглядные визуализации для отслеживания динамики ранжирования.

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

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

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

Недавно наткнулся на воркшоп с разбором реальных продуктовых кейсов — практичная штука (там есть ответы + годные мысли).

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

1️⃣ Кейс

Вы продакт, который отвечает за корзину и метрики корзины.

Одна из ваших метрик — это доля выкупа заказанных вещей, т.е. те вещи, которые выкупил пользователь, которые заказал.

🍪🍪 Например, человек может заказать 10 вещей, но выкупить 4 штуки, а 6 уедет обратно.

Представим, что показатель процента невыкупленных товаров находится на уровне 10% — это означает, что 10 процентов пользователей не выкупают товар который заказал.

⬆️ Наступил май, и данный показатель стал аккуратно расти 12-15-20-25 процентов.

😨 В течение 2 недель дорос до 30 процентов.

И нужно разобраться куда копать и что смотреть, чтобы понять?

Какие гипотезы могут быть и повлияли на текущую ситуацию?

Если скажешь про A/B-тест. Не уверен в гипотезе, но готов тратить деньги. Важно проерить гипотезу без разработки, а на что можно посмотреть уже сейчас

Давайте проведем исследования, опрос, A/B тестирование выглядит странно, нужно обращаться к прокси-метрикам

2️⃣ Кейс

Вы продакт одного из классифайдов, отвечаете за звонки/контакты.

🤪 Основная задача: сделать так, чтобы эти метрики росли и не падали.

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

🆎 Другая команда по честному провела A/B тест, и получилось так, что A/B Тест уменьшил количество контактов на 30%.

🔽Ваша целевая метрика (контакты) упала.

Что делать с A/B-Тестом и на основе чего принять решение?

3️⃣ Кейс

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

У вас есть несколько сильных конкурентов, и вы не один на рынке, ваши услуги стоят достаточно дорого, дороже чем у других = вы самые дорогие.

📰 Основной способ заработка, это публикация объявления и дополнительное продвижение.

Публикация объявления, составляет около 80% всей прибыли сервиса.

Значительная часть ежегодного прироста выручки обеспечивается за счет повышения цен 2 раза в год.

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

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

Если пост соберёт 100 🔥, расскажу, как я сам проходил собеседования с продуктовыми кейсами — какие были вопросы, как готовился и что помогло.

Отладка SQL-запросов

⌛️ Большую часть времени аналитики пишут скрипты в определённой СУБД: достают оттуда данные для моделей, отчётности, выгрузок, продуктовых исследований и прочих задач. Предположим, ты начал строить большую витрину, которая должна покрывать бизнес-потребности.

Всё идёт нормально, но вдруг:

1. Нет записей, хотя должны быть / записей стало меньше

2. Данные задвоились

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

____

Этот пост - про быструю и понятную отладку SQL-запросов, особенно если он уже раздулся на тысячи строк.

1️⃣ Начало с верхнеуровневой структуры

Если в коде есть подзапросы, лучше переписать их на CTE / временные таблицы. Так код легче читать и отлаживать по шагам.

Простой подзапрос:


select ...
from (
select ...
from orders
where ...
) t
join ...


CTE:


with filtered_orders AS (
select ...
from orders
where ...
)
select ...
from filtered_orders
join ...

Стало чуточку проще читать + можно проверить, что в filtered_orders, следующий шаг про это

2️⃣ Проверка CTE или временных таблиц

Здесь мы проверяем количество строк / уникальных сущностей по типу order_id / user_id, проверяем на пустые значения


select count(*) as total_rows,
count(distinct user_id) as unique_users
from filtered_orders;


3️⃣ Спускаемся глубже, смотрим с какого момента началась проблема (идем внутрь запроса)

Что нас ждет внутри? Джойны / оконные функции / группировки.

Хорошая практика - это посмотреть, задублировались ли ключи, по которым будет в дальнейшем JOIN


select o.order_id, count(*) as cnt
from orders o
join transactions t on o.order_id = t.order_id
group by o.order_id
having count(*) > 1;

Если дублируется, то надо ответить на вопрос: ожидаемое это поведение или нет? Если проблема, то следующий шаг.

4️⃣ Контроль за дублями

Базовая проблема: в одной таблице ключ уникален, в другом нет (можно, например, предагрегировать, используя row_number() / distinct / group by


with transaction_agg as (
select order_id, sum(amount) as total_amount
from transactions
group by order_id
)
select o.order_id, t.total_amount
from orders o
left join transaction_agg as t ON o.order_id = t.order_id;

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

5️⃣Хорошая и простая практика: посмотреть глазами

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


select *
from orders o
join transactions t on o.order_id = t.order_id
where o.order_id = 'abc123';


6️⃣Последнее

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

Бывают разные сущности, но хочется понимать как мы закрываем бизнес-задачу, используя именно ЭТИ данные (тут про смысл аналитического мышления / бизнес-смысла и смысла данных

Понравился формат поста? Ставьте 🔥, пишите комментарии, какие пункты еще стоит добавить

🚀 Держите руку на пульсе IT-индустрии! 🚀

Часто возникает вопрос: как быть в курсе последних трендов и возможностей для профессионального роста в IT?

Конечно, не пропускать встречи с экспертами крупных компаний и своим профессиональным коммьюнити.

Канал @conference_ru это:

📅 Актуальная информация о предстоящих IT-конференциях и митапах по всей России: даты, места проведения, спикеры

💰 Скидки и промокоды на участие: экономьте деньги и получайте максимум от посещения мероприятий

🗣️ Записи прошедших конференций в открытом доступе

🤝 Возможность углубить свой опыт и завести полезные знакомства

📰 Свежие новости и аналитика из мира IT: будьте в курсе главных событий и трендов

Расширяйте свой потенциал вместе с  @conference_ru

Реклама: ИП Беляев Арсений Игоревич, ИНН: 590322038514, Erid: 2VtzquqrPGe

🚨 SRM в A/B тестах: когда не совпадают доли, и что с этим делать

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

Sample Ratio Mismatch (SRM) — несоответствие фактических долей заданным.

😢 Пример:


Ожидание:

control — 50%
test — 50%

Реальность:

control — 62%
test — 38%

🧐 Почему так могло произойти?

1. Что-то не то со сплитованием в A/B-шнице (последнее на что можно подумать, если платформа не только что разработана). Могут быть проблемы со сплитовалкой на уровне разработки, но также маловероятный сценарий.
2. Логи определения групп пользователей настроены некорректно. Вероятный сценарий. Могли определить неправильно веса групп, выкатить только на определенные девайсы, неправильно настроено определение групп (в тест / контроль попадают пользователи с разным распределением метрики при верной H0).

😎 Как это можно быстро проверить?

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

SQL


SELECT
variant,
COUNT(DISTINCT user_id) AS users
FROM
experiment_assignments
WHERE
experiment_name = 'new_checkout_flow'
AND assignment_time BETWEEN '2025-04-01' AND '2025-04-10'
GROUP BY
variant;


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

Возьмем пример из начала на 10 000 наблюдений с фактическим разбросом.


from scipy.stats import chisquare

observed = [6200, 3800]
total = sum(observed)
expected = [total / 2, total / 2]

_, p_value = chisquare(f_obs=observed, f_exp=expected)

if p_value < 0.05:
print("SRM")
else:
print("NO SRM")

Вообще на каждом эксперименте можно поставить автоматическую проверку (на предмет валидности расчетов). Ожидаемое vs Фактическое.

Немного про проверку гипотез при Chi-Square


H0: Распределение пользователей между вариантами эксперимента соответствует ожидаемым долям (например, 50 / 50).
H1: Распределение пользователей отличается от ожидаемого.

Если p-value < 0.05, мы отвергаем H0 => SRM есть.
Если p-value >= 0.05, оснований отвергать H0 нет => распределилось все как и ожидалось.

😘 Всегда проверяйте SRM до метрик. Это простая проверка, которая спасёт ваш эксперимент.

Ставьте реакции если:

🐳 — пост понравился!

🤡 — пойдет)

🚀 Почему пользователи платят $30 за простой конвертер картинок? Давайте разберемся.

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

Как он это сделал:
1️⃣ Анализ спроса: через поисковые запросы он увидел, что много людей ищут конвертацию «HEIC to JPG».
2️⃣ Фокус на главном: удалил всё лишнее, оставив только функцию конвертации в один клик.
3️⃣ Скорость внедрения: за 30 дней сделал запуск без перфекционизма.

Посты про конвертер (ч.1, ч.2)

Что из этого получилось:
— Доход $500 в месяц с тенденцией роста.
— Более $10K заработано на конвертере.
— $0 на рекламу, всего $40 в месяц на сервер.

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

Наши успехи:
— Более 400 запусков по этой методике.
— Некоторые продукты уже набрали от 50К до 100К+ пользователей.

👉 Присоединяйтесь к @its_capitan— следите за процессом разработки, продвижения и узнайте, сколько можно заработать на таких микро-продуктах.

Реклама: ИП Зуев Игорь Владимирович, ИНН: 360408359441, Erid: 2VtzqvvPyTg

Что такое Retriever и зачем он нужен?

На схеме изображен классический вариант RAG (Retrieval Augmented Generation). Retrieved contexts получен с помощью Retriever поверх Vector Store.

Предобученная LLM (например, ChatGPT) знает уже много — она обучалась на огромном корпусе данных: сайты, книги, коды, форумы, всё подряд. Но у такой модели есть одна большая проблема: Она не знает ничего про внутренний контекст компании: как у тебя считаются метрики, какие A/B тесты были, как устроены ключевые таблицы. Чтобы LLM могла использовать знания из своей компании — ей нужно их передавать.

Retriever — это компонент, который вытаскивает только релевантную информацию, может быть интегрирован с собственной базой знаний (PDF, CSV, SQL, Confluence и др.), и может работать с LLM на основе релевантного контекста. На сайте LangChain можно посмотреть более подробно про основные концепции Retrievers + вот тут посмотреть какие вообще реализованы у LangChain

Пайплайн работы с Retriever

1. Загрузка документов (файлы, базы, статьи). Все, что мы считаем нужным для решения задачи. От черновиков дло
2. Разбиваем их на части (чанки) для индексации
3. Преобразуем текст в векторное представление (через эмбеддинги)
4. Сохраняем в векторную базу (Vector Store) — например, в FAISS или Chroma
5. По запросу — находим ближайшие куски текста, которые помогут модели ответить

Retriever делает семантический поиск по смыслу, а не просто по словам.

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


from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import CharacterTextSplitter
from langchain.chains import RetrievalQA, ConversationalRetrievalChain

loader = TextLoader("text_for_gpt.txt")
documents = loader.load()

text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
texts = text_splitter.split_documents(documents)

embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(texts, embeddings)
retriever = vectorstore.as_retriever()

llm = ChatOpenAI(model="gpt-3.5-turbo")
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
response = qa_chain.invoke({"query": 'О чем статья? Расскажи вкратце'})

print(response["result"])


Выше реализован single-shot RAG (одна проходка и ответ из базы). В дальнейшем напишу про виды RAG и чем они отличаются)

Какие бывают типы Retrieval? [статья с хабра]

1. Sparse Retrieval — классический полнотекстовый поиск
Примеры: TF‑IDF, BM25
Базы: PostgreSQL (GIN), Apache Solr, Whoosh

2. Dense Retrieval — семантический поиск через нейросети
Примеры: BERT, word2vec, e5-multilingual, OpenAI
Базы: ChromaDB, FAISS, Pinecone, Qdrant, Milvus

3. Hybrid Retrieval — комбинация sparse + dense
Примеры: ElasticSearch с плагином, Qdrant, PostgreSQL с pgvector

4. Graph Retrieval — поиск по графам знаний (use case: связи между объектами)
Примеры: Neo4j, Weaviate, ArangoDB, TigerGraph.

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

🤖 — Да, интересно читать про LLM, давай дальше!
🦜 — Давай лучше про A/B тесты (это бежит попугайчик LangChain)

Глобальный контроль — кто это вообще и зачем он нужен?

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

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

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

🙅‍♂️ Зачем это нужно?

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

А у вас в компании есть глобальный контроль? Анализировали долгосрочный эффект от внедрения фичей в нашем направлении? Делитесь в комментариях кейсами)

⏰ Последний шанс зарегистрироваться: Big Data в реальном бизнесе! 🚀

📊 Big Data больше не абстракция — это основа стратегических решений, которые меняют бизнес-процессы в самых разных сферах: от медицины до финтеха.

Хотите разобраться в управлении большими данными и услышать инсайты от важных лиц индустрии? Тогда Data Fusion 2025 — событие, которое нельзя пропустить.

🎙️ Например, отдельным треком пройдет серия сессий на тему «ML + наука» – о том, как машинное обучение влияет на отрасли бизнеса и науки.

🎙️ На профильных кейс-сессиях о RAG, CV, RL, Embodied AI, NLP будут представлены доклады о лучших практиках машинного обучения в ведущих компаниях рынка.

🎙️ По традиции на полях конференции можно будет послушать Science Note – доклады ключевых российских ученых в сфере работы с данными и машинным обучением, в том числе – Ивана Оселедца, Константина Воронцова, Андрея Райгородского.

Конференция и экспертиза, которые нельзя пропустить!

⚡ Регистрация скоро закроется! Чтобы получить доступ, заполните онлайн-форму на официальном сайте: https://data-fusion.ru/


–
*Big Data — большие данные
*RAG — генерация с подключением к поиску (Retrieval-Augmented Generation)
*Embodied AI — ИИ, взаимодействующий с физической средой
*CV — компьютерное зрение (Computer Vision)
*RL — обучение с подкреплением (Reinforcement Learning)
*NLP — методы обработки естественного языка

💰 ARPU и ARPPU на пальцах: считаем, понимаем, используем в SQL

☕️ Как это выглядит на данных?

Предположим, у нас есть таблица с заказами и пользовательскими событиями (по последнему мы получаем данные по DAU / WAU / MAU, например).

1) orders:


user_id | order_id | gmv | date

user_id - id пользователя
order_id - id заказа
gmv - стоимость заказа (для пользователя)
date - дата оплаты заказа


2) actions:


user_id | action_name | date

user_id - id пользователя
action_name - обычно таблица с событиями (сюда льются любые заходы пользователя в приложении)
date - дата экшна


💃 ARPU = total GMV / АКТИВНЫЕ пользователи
💃 ARPPU = total GMV / ПЛАТЯЩИЕ пользователи

😈 Пример запроса ниже. Рассчитаем ARPU / ARPPU за март 2025 года

-- Считаем ARPU и ARPPU за март 2025 года

WITH
-- Количество уникальных активных пользователей (по действиям)
active_users AS (
SELECT COUNT(DISTINCT user_id) AS active_user_count
FROM actions
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),

-- Количество уникальных платящих пользователей (по заказам)
paying_users AS (
SELECT COUNT(DISTINCT user_id) AS paying_user_count
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),

-- Общая выручка за период
total_revenue AS (
SELECT SUM(gmv) AS gmv_total
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
)

-- Финальный расчёт метрик ARPU и ARPPU
SELECT
ROUND(gmv_total * 1.0 / active_user_count, 2) AS arpu, -- Средняя выручка на активного пользователя
ROUND(gmv_total * 1.0 / paying_user_count, 2) AS arppu -- Средняя выручка на платящего пользователя
FROM total_revenue
CROSS JOIN active_users
CROSS JOIN paying_users;


Например, ARPU = 100 ₽, ARPPU = 500 ₽ => платит только каждый 5-й.

❓ ARPU отвечает на вопрос: сколько в среднем приносит один пользователь среди всех активных. Это полезно при расчёте юнит-экономики: можно быстро оценить выручку на пользователя, не углубляясь в поведение платящих отдельно. Также ARPU часто используется как proxy для оценки LTV в первые периоды жизни пользователя, особенно при когортном анализе.

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

Если рассматривать их в связке, можно понять за счёт чего растёт выручка: за счёт увеличения числа платящих (растёт ARPU, ARPPU на месте) или за счёт того, что каждый платящий стал платить больше (растут оба).

Обычно, при проведении экспериментов смотрят за ARPU (так как принимается решения по внедрению фичи не на срезе платящих, а не срезе всего приложения).

ARPU чувствительнее к изменениям в конверсии в оплату, а ARPPU — к изменениям в поведении уже платящих.

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

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

Model Context Protocol – незаменимый инструмент для ML-соревнований, где нужно использовать всю мощь LLM. С помощью нового стандарта подключения AI-ассистентов к бизнес-приложениям от Anthropic ты сможешь интегрировать ИИ в свой проект – идеальное решение для хакатона, где время ограничено.

В новой статье разбираемся, как устроен протокол, как поднять собственный MCP-сервер и использовать его в IT-соревнованиях. Ты узнаешь про:
🔤 Архитектуру Model Context Protocol.
🔤 Основные возможности стандарта.
🔤 Примеры реализации: от простых к сложным.

Сосредоточься на создании уникального AI-ассистента. Как это сделать? Ответ в статье: https://cnrlink.com/mcpitonecupzasqlpy

А проверить всю мощь MCP можно на IT_ONE Cup. ML Challenge. Зарегистрируйся, выбери один из трех треков и раздели призовой фонд в 1 500 000 рублей.

MCP станет одним из важных инструментов для разработки ИИ-помощников в задачах соревнования:
🔤 Динамические контекстные подсказки для системного аналитика.
🔤 AI-генератор дизайн-макетов по описанию требований.
🔤 Система визуализации BPMN-диаграмм.

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

Регистрация открыта до 11 апреля включительно: https://cnrlink.com/itonecupmlzasqlpymcp

LLM-агенты [https://huggingface.co/blog/open-source-llms-as-agents#what-are-agents] [ч.1]

LLM-агенты — это все системы, которые используют LLM в качестве своего механизма и могут выполнять действия в окружающей среде на основе наблюдений. Они могут использовать несколько итераций цикла «Восприятие ⇒ Рефлексия ⇒ Действие» для выполнения своей задачи и часто дополняются системами планирования или управления знаниями для повышения своей эффективности.

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

1. input


Here is a question: "How many seconds are in 1:23:45?"
You have access to these tools:
- convert_time: converts a time given in hours:minutes:seconds into seconds.

You should first reflect with ‘Thought: {your_thoughts}’, then you either:
- call a tool with the proper JSON formatting,
- or your print your final answer starting with the prefix ‘Final Answer:’

2. LLM размышляет


Thought: I need to convert the time string into seconds.


3. LLM вызывает инструмент


Action:
{
"action": "convert_time",
"action_input": {
"time": "1:23:45"
}
}

4. Инструмент возвращает результат


Thought: I now have the information needed to answer the question.
Final Answer: There are 5025 seconds in 1:23:45.

Решение базовых проблем

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

Вместо угадываний LLM будет учиться выполнять задачи пошагово и подход в дальнейшем можно масштабировать). В этой статье представлен еще код того, как можно интегрировать библиотеки Hugging Face для создания агентов через LangChain.

Понравился такой формат поста? Ставьте реакции! Продолжу дальше писать про LLM и агентов, сейчас небольшое погружение

⚡️Какой основной инструмент работы у аналитика?

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

Это можно долго и тяжело делать с помощью Excel, чуть легче с помощью SQL. А в Pandas, да и в целом в Python, это можно сделать за несколько строк кода. Простой пример - иногда для фильтрации строк по какому-то агрегированному признаку в SQL нужно написать 3 подзапроса, а в Pandas это можно сделать за 2 строки.

Pandas - инструмент, который делает жизнь аналитика проще и приятней, а работу - эффективней.

Научиться работать с Pandas на реальных задачах бизнеса можно на бесплатном курсе от Simulative.

За неделю обучения вы:
🟠Освоите Pandas с нуля до продвинутых функций: сложная агрегация, оконные функции и т.д.
🟠Научитесь решать реальные аналитические задачи: проводить многомерный ABC-анализ, XYZ-анализ, рассчитывать динамику продаж.
🟠Сделаете собственный проект, который сможете добавить в портфолио: реальный кейс автоматизации обработки финансовой отчетности от крупной региональной аптечной сети

🕗 Обучение проходит на платформе школы

😶Начать учиться Pandas

Используете ли вы LLM в аналитике? (или просто для продакшн-решений)

🗯 Многие уже применяют их в повседневной работе: ускоряют написание кода, SQL, помогают с формулировками гипотез, объясняют пайплайны, адаптируют текст под бизнес — это, кажется, уже стало базовым инструментом. Иногда, сталкиваемся с такими крайностями, как vibe code, когда просто копируются и вставляются ошибки с готово решения под разные модели GPT.

💭 Интересен другой кейс, как по мне. Задачи, где модель помогала не только вам, но и влиянию на сам процесс? Например, сбор ассистента, который отвечает за какой-то контекст бизнеса на основе скормленной документации / правил, или автоматизация аналитических выводов из отзывов пользователей / на основе имеющихся данных. Это может быть не просто базовый чат-бот, но и инструмент с возможностью разметки, решения задач на основе различных агентов (DeepSeek, OpenAI и др.).

Первый вариант понятен, этим пользуются почти все (поправить что-то, сделать под себя). Но во втором случае интересно: доводили ли вы такие проекты до MVP или продакшена? Или, может, делали ресёрч, который показал потенциал, но не стал продуктом?

🐳Если тема зайдёт, хочу собрать отдельный пост с кейсами: где и как можно использовать LLM в аналитике, какие проекты реально работают. Возможно, даже попробую собрать простой продакшн-пример — и описать, где он может быть уместен.

Что такое RFM-анализ и как он помогает сегментировать пользователей

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

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

В данном посте мы рассмотрим RFM-анализ.

Если вкратце мы разбиваем пользователей на сегменты на основе:

⌛️ R (Recency) - давности последней покупки (например, в днях)

🥳 F (Frequency) - общее количество покупок покупок.

🤑 M (Monetary) - сумма денег, потраченная пользователей.

Про присваиваемость сегментов:

1. Выбираем период анализа, например, последние 90 дней.

2. Определяется количество сегментов (обычно от 3 до 5 по одному из пунктов). Максимум X³ комбинаций, если делим каждую метрику на X частей.

Пояснение к п.2: Если у нас Monetary от 0 до 3000, а сегментов планируется 3, то трешхолды для определения сегментов: 1 - (0, 1000], 2 - (1000, 2000], 3 - (2000, 3000]. Аналогично и для других.

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

3. По трешхолдам равномерно разбитым определяем сегменты

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

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

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

1. link1
2. link2
3. link3

А вы применяете RFM-анализ? Как относитесь к данному методу сегментации?

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

CEO Simulative и эксперт с большим опытом в аналитике, Андрон Алексанян организовал бесплатный интенсив, где вы будете решать реальные задачи, с которыми аналитики сталкиваются на работе

На прямых эфирах вы сделаете:
🟠Анализ активности пользователей с помощью SQL
🟠Анализ маркетинговых активностей с помощью Python
🟠ABC анализ ассортиментной матрицы в Excel (уже прошел, но вам будет доступна запись)

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

❗️Знать Python и SQL не обязательно — все будем разбирать с нуля

🕗 Встречаемся на новом эфире уже сегодня, 20 марта в 19:00 по мск

😶Участвовать в бесплатном интенсиве

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

Ребята регулярно выкладывают крутой контент, рекомендую подписаться и следить за ними :)

Что можно почитать из последнего:
- 🎯 Как вкатиться в NLP: подборка основных RoadMaps
- 🔥 Сборники тестовых заданий и видео разборы реальных тестовых
- Что такое Git и зачем он нужен Data Scientist'у
- 🔗 Базовая теория по DL, которую должен знать каждый

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

Материалы для прокачки навыков в Polars для начинающих

Написал я пост про Pandas, теперь напишу про Polars, чтобы было логическое продолжение

🐼 Если вы работаете с большими данными и устали ждать, пока Pandas обработает ваш запрос, стоит попробовать Polars.

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

❓ С чего начать?

1. Официальная документация – базовые концепции и API docs.pola.rs

2. Подробный гайд по Polars с примерами – разбор синтаксиса и возможностей Polars Book (GitHub)

3. Работа со строками в Polars – как делать обработку текстов, разбирать email-адреса, чистить данные и т.д. Статья на Towards Data Science

4. Шпаргалка в Jupyter Notebook – можно сразу потыкать основные команды Cheat Sheet

5. Шпаргалка в PDF (с визуализацией для лучшего усвоения) - PDF Cheat Sheet

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

❤️‍🔥 Наберем 100 реакций, выложу такую же подборку по PySpark

Используете ли вы Polars? Пишите в комментариях

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

Приглашаем на конференцию Data Fusion 2025: ведущие специалисты в сфере науки, бизнеса и государства поделятся прикладными кейсами применения ML и DS и своим взглядом на будущее сферы на 70+ сессиях.

📌 Что в программе?
— Новые подходы в ML
— Кейс-стади от специалистов из различных индустрий: финтех, медицина, промышленность
— Data Science для бизнеса — как применять ИИ для роста прибыли
— Кейс-сессии и детальный разбор неочевидных проблем в ML

📅 Дата: 16-17 апреля 2025
📍 Место: Москва, технологический кластер «Ломоносов»

🚀 Бесплатная регистрация уже открыта: https://data-fusion.ru/

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

—
*ML — машинное обучение
*Data science — наука о методах анализа данных

[пост с линкедин]

Нашел на линкедине пост, посвященный уничтожению чемпиона в своей команде. Сталкивались ли с этим в команде? Что думаете? Пишите в комментариях

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

CEO Simulative и эксперт с большим опытом в аналитике, Андрон Алексанян организовал бесплатный интенсив, где в течение 3 недель вы будете решать реальные задачи, с которыми аналитики сталкиваются на работе

На прямых эфирах вы сделаете:
🟠Анализ активности пользователей с помощью SQL
🟠Анализ маркетинговых активностей с помощью Python
🟠ABC анализ ассортиментной матрицы в Excel (уже прошел, но вам будет доступна запись)

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

❗️Знать Python и SQL не обязательно — все будем разбирать с нуля

🕗Встречаемся на новом эфире уже завтра, 13 марта в 19:00 по мск

Участвовать в бесплатном интенсиве

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

💰 Запускаем новый продукт — кажется, что все идет отлично. Начинаются покупки, растет выручка. Но спустя время бизнес замечает странную вещь: общая выручка не изменилась, а иногда даже начала падать 😢


🤔 Что случилось?

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

🤔 Почему это проблема?

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

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

3. Если новый продукт не оправдал ожидания, пользователь может уйти вообще из обоих продуктов 🌟

Пример:
У вас был премиум-тариф, который приносил высокий доход, а вы запустили дешевый вариант (дискаунтер). Клиенты ушли в новый продукт, выручка просела.

Как найти каннибализацию? 🍪🍪

Смотрим, как изменилось поведение пользователей после запуска нового продукта.

👩‍💻 SQL-запрос ниже


WITH old_product AS (
SELECT
user_id,
COUNT(order_id) AS old_orders,
SUM(revenue) AS old_revenue
FROM orders
WHERE product_id = 'old_product'
AND order_date < '2024-01-01'
GROUP BY user_id
),

new_product AS (
SELECT
user_id,
COUNT(order_id) AS new_orders,
SUM(revenue) AS new_revenue
FROM orders
WHERE product_id = 'new_product'
AND order_date >= '2024-01-01'
GROUP BY user_id
)

SELECT
o.user_id,
o.old_orders,
n.new_orders,
o.old_revenue,
n.new_revenue,
CASE
WHEN o.old_orders > 0 AND n.new_orders > 0 AND n.new_revenue < o.old_revenue
THEN 'Перешли, но платят меньше'
WHEN o.old_orders > 0 AND n.new_orders > 0 AND n.new_revenue >= o.old_revenue
THEN 'Перешли, но выручка сохранилась'
WHEN o.old_orders > 0 AND n.new_orders = 0
THEN 'Остались на старом'
WHEN o.old_orders = 0 AND n.new_orders > 0
THEN 'Новый клиент'
ELSE 'Нет активности'
END AS user_behavior
FROM old_product o
LEFT JOIN new_product n ON o.user_id = n.user_id;


❓ Что значит результат?

1. Перешли, но платят меньше → Упали чеки, возможно, продукт слишком дешевый или не дает ценности. Нужно тестировать upsell, дополнительные возможности для продажи товаров / услуг, рост GMV, маржинальности 😵

2. Остались на старом → Им новый продукт не нужен? Разбираемся, что именно их удерживает. Возможно, просто пользователи привыкли к другому продукту, а пересаживаться не видят смысла 🪑

3. Мало новых клиентов → Новый продукт не привлекает новую аудиторию. Возможно, нужно менять маркетинг, коммуникацию с пользователями. Доносить понятные смыслы 🖼

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

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

😊 Наберется 100 реакций, сделаю еще пост с практическим применением SQL на реальных задачах

UPD: для оценки каннибализации честнее всего запустить 🆎

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

Андрей — Data Scientist в США, который знает, как искать работу так, чтобы выбирать из лучших предложений. Он сам прошёл путь от начинающего специалиста до международного уровня, увеличив свою зарплату в 15 раз. Работал в России, Германии, Канаде и США, а его система поиска работы стабильно приносит офферы на 30-50% выше рынка. И это не только у него — Андрей уже помог 300+ IT-специалистам выйти на новый уровень карьеры.

Теперь он делится этой системой в курсе "От 0 до Оффера", где за 5 недель ты прокачаешь своё резюме, LinkedIn, узнаешь, где и как искать работу, и научишься выбивать лучшие офферы.

Что ты получишь:
✅ Резюме, которое выделяется на фоне тысяч откликов и проходит скрининг на глобальном рынке. Конверсия в собеседования у выпускников растёт в 2,5 раза.
✅ Прокачанный LinkedIn с входящими предложениями от иностранных компаний.
✅ Понимание, как вести переговоры о зарплате и увеличивать её уже на этапе оффера.
✅ Подготовку к сложным интервью в западные компании, включая поведенческие вопросы.

Примеры реальных результатов участников:
💬 Вадим: "Зп +100к в месяц просто из-за LinkedIn, даже искать ничего не пришлось — сами нашли!"
💬 Артем: "Оффер в Европе с х2 к прошлой зарплате. Спасибо за систему!"
💬 Александр: "Зарплата выросла с $3,000 до $5,000 после курса. Через полтора года нашёл новую работу за $6,000."

Курс стартует уже завтра, 11 марта. Если хочешь не просто искать, а находить — присоединяйся! Это лучшее вложение в карьеру, которое работает всю жизнь.

Регистрируйся по ссылке 🔗

Bayessian vs Frequient A/B testing [презентация]

Видео на Youtube: Александр Сахнов — Почему вам не стоит использовать байесовское A/B-тестирование

Нашел вначале шикарную презентацию от X5 по сравнению байесовского и частотного подхода к применению A/B тестов, потом нашел само видео)

Есть код на Python, можно сравнить методы на данных и посмотреть, как использовать.

Опровергаются различные мифы по поводу байесовского тестирования (про Peeking Problem, большую чувствительность, множественное тестирование)

В начале идет описание частотного A/B тестирования и пайплайн проведения:

1. Фиксирование допустимых вероятностей ошибок первого и второго рода
2. Фиксирование ожидаемого результата
3. Оцениваем по истории дисперсии
4. Оцениваем необходимый размер групп
5. Проводим эксперимент
6. Собираем данные и вычисляем p-value
7. Оцениваем результат

Говорится о сложности интерпретации p-value. Вводится статистика, у которого какое-то предельное распределение. По реализации выборки мы считаем реализацию статистики и смотрим куда попала. Про это я писал у себя в посте. Бизнесу нужно принять бинарное решение (внедряем / не внедряем).

Затем описывается пайплайн байесовского A/B тестирования:

1. Определение априорных распределений (для неизвестных для нас параметров). Далее мы переходим к апостериорному распределению с помощью правдоподобий и теоремы Байеса
2. Определение размера групп. Размер групп можем взять из частотного метода
3. Проведение эксперимента
4. Собираем данные и что-то вычисляем
5. Оцениваем результат

Частотный подход: Какая вероятность получить такое или более экстремальное значение статистики при верности H0?
Байесовский подход: Какая вероятность, что среднее уменьшилось / увеличилось по совместному апостериорному распределению?

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

В частотном A/B-тесте у всех одни и те же результаты, но в Байесе все зависит от априорных знаний. Если два аналитика зададут разные априоры, они могут получить разные выводы по одному и тому же тесту! Представьте, что в A/B платформе такое внедряется — один продакт видит значимый эффект, а другой — нет. Как принимать решения?

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

🐳 Наберется 100 реакций, в следующем посте буду писать про байесовское тестирование более подробно

А вы используете байесовские методы? Если да, то какие? Пишите в комментариях.

Типы задач продуктового аналитика

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

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

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

3. работа с архитектурой данных. Здесь речь и про разработку витрин (не только для отчетности), но и для решения других задач. Сюда можно включить и разметку для пользовательского приложения (в зависимости от внердяемой фичи) и занесения метрик в абшницу и feature store для ML расчетов (вариаций куча).

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

5*. прогнозирование. Тут речь про построение планов на основе различных методов прогнозирования (временные ряды), не грубая прикидка, а хороший прогноз (etna, arima, sarimax, prophet etc)

6. выгрузки / адхоки. Включает в себя разные вопросы, которые могут решаться за 1 этап (просто выгрузка из БД без каких-то фокусов). Сегменты пользователей для рассылки / коммуникации, ответ на вопрос, одна чиселка в ответе, передать инфу другим аналитикам / командам и др.

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

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

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

Что-то забыл? Делитесь в комментариях! Какую задачу вам приходится решать чаще всего?

Хотите научиться автоматизировать процессы обработки данных как в Бигтехе?

Чтобы проанализировать большой массив данных, его нужно обработать. Обычно это происходит в три этапа: извлечение, трансформация и загрузка (или ETL). Но чем больше становится данных, тем труднее управлять этим процессом вручную — автоматизировать его можно с помощью Airflow.

Чтобы научиться работать с Airflow, приходите на бесплатный вебинар, где Антон Шишков, опытный Software Engineer из бигтех-компании, — поделится с вами своими знаниями и лучшими практиками работы с Airflow на примере автоматизации сбора данных.

Что мы будем делать на вебинаре:
🟠 Познакомимся с Airflow: узнаем, как он может упростить работу и повысить эффективность;
🟠 Узнаем об операторах и сенсорах: как использовать для создания гибких и надежных конвейеров данных;
🟠 Напишем базовые и продвинутые DAG'и, чтобы вы могли применить их на практике;
🟠 Разберем, как использовать Docker, FastAPI, Postgres, Clickhouse и Minio для автоматизации ETL-процессов.

🕗Встречаемся 4 марта в 19:30 по мск

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

🤔 картинка для привлечения внимания

о чем пишем на следующей неделе? пишите в комментариях

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

а так, любые предложения приветствуются

Что влияет на метрику X

В нашей работе может достаточно часто возникать задача в следующей формулировке: "А что влияет на метрику X?". Метрика X может быть произвольна. В дальнейшем бизнес может сделать упор над тем, а что можно улучшить, на что стоит обратить внимание. Для решения этой задачи можно подступиться следующим способом:

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

💻 Собрать таблицу с фичами, которые экспертно могут быть выбраны для обучения модели машинного обучения.

Что здесь можно придумать?

📊 Линейная регрессия. Все мы любим линейную регрессию за ее простую интерпретируемость, но есть существенный минус: между фичой и таргетом должна быть линейная зависимость. Коэффициенты, которые мы получаем при обучении (coef_), по сути коэффициенты при которых минимизируется функция потерь. Кроме того, важно следить за мультиколлинеарностью, чтобы важность фичей не перераспределялась между различными признаками (для этого нужно определить насколько сильно они коррелируют друг с другом). doc


from sklearn.linear_model import LinearRegression
from sklearn.datasets import make_regression
import pandas as pd

X, y = make_regression(n_samples=1000, n_features=10, noise=10, random_state=42)
feature_names = [f"feature_{i}" for i in range(X.shape[1])]

model = LinearRegression()
model.fit(X, y)

importance = pd.Series(model.coef_, index=feature_names).sort_values(ascending=False)


🌲 Деревья решений и градиентный бустинг. Когда мы работаем с нелинейными зависимостями, линейная регрессия уже не даёт нам полной картины. В таких случаях можно использовать деревья решений и градиентный бустинг. Эти модели оценивают важность признаков по тому, насколько они помогают уменьшать неопределённость (снижать критерий ошибки, например, Gini или MSE) при разбиениях. catboost doc

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


from catboost import CatBoostRegressor

model = CatBoostRegressor(iterations=200, verbose=False)
model.fit(X, y)

feature_importance = pd.Series(model.get_feature_importance(), index=feature_names)


🤨 Permutation Importance. Метод, который отвечает на вопрос: "Что будет, если убрать этот признак?". doc

Шаги:

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


from sklearn.ensemble import RandomForestRegressor
from sklearn.inspection import permutation_importance
from sklearn.model_selection import train_test_split

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

model = RandomForestRegressor(n_estimators=100)
model.fit(X_train, y_train)

perm_importance = permutation_importance(model, X_test, y_test, scoring="r2")
importance = pd.Series(perm_importance.importances_mean, index=feature_names)


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


🙄 SHAP. Когда важно не просто узнать, какие признаки важны, но и как именно они влияют. doc


import shap

explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)

shap.summary_plot(shap_values, X_test, feature_names=feature_names)


Линейная регрессия подходит для простых зависимостей, деревья и бустинг – для сложных, Permutation Importance – когда нужна честная оценка вклада признаков, а SHAP – для объяснения модели

🤔 Наберется 100 реакций, напишу более подробно про SHAP. А вы применяете эти методы или какие-то другие?

😢 когда-нибудь закончится гонка с самим собой и захочется спокойной жизни

Освойте основной инструмент работы аналитика

Аналитику часто приходится обрабатывать огромные массивы информации, чтобы реально что-то «увидеть» в данных.

Это можно долго и тяжело делать с помощью Excel, чуть легче с помощью SQL. А в Pandas это можно сделать за несколько строк кода.

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

Научиться работать с Pandas на реальных задачах бизнеса можно на бесплатном курсе от Simulative.

За неделю обучения вы:
🟠 Освоите Pandas с нуля до продвинутых функций: сложная агрегация, оконные функции и т.д.

🟠 Научитесь решать реальные аналитические задачи: проводить многомерный ABC-анализ, XYZ-анализ, рассчитывать динамику продаж и т.д.

🟠 Сделаете собственный проект, который сможете добавить в портфолио: реальный кейс автоматизации обработки финансовой отчетности от крупной региональной аптечной сети

Начать учиться Pandas

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

1️⃣ Работа в долгосрок

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

If it helps in the short-term, but hurts Duolingo in the long-term, it’s not right


2️⃣ Культура экспериментов: быстрые A/B тесты вместо долгих споров

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

When we disagree, we test ideas and let the metrics decide.


3️⃣ Минимизация промежутков между действиями (Clock Speed)

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

Duolingo сокращает все простои

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

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

4️⃣ Простота в продукте и фокус на миссии

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

Learners need to get utility out of whatever we’ve built. Otherwise, we’ve made something that adds more complexity to the app and distracts learners from what they’re here to do.

Every feature we ship must be intuitive, delightful, useful, and polished.

If a feature or screen requires explanation or additional context, it’s not right.


5️⃣ Радикальные идеи приветствуются — «99 Bad Ideas»

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

Some of our best features and campaigns have come from asking ridiculous, unlikely questions


6️⃣ Меньше говорить, больше делать

> TL;DR-культура — вместо долгих обсуждений краткое выжимка из сути проблемы и решения.
> Говорить меньше — показывать больше (на примере прототипов).
> Когда в компании нет лишнего шума, решения принимаются быстрее.

Talking about ideas is rarely as effective as building them


7️⃣ Высокие планка: от команды до продукта

Duolingo строит культуру превосходства. Здесь ожидают, что сотрудники будут делать лучшую работу в своей карьере. Они не боятся ошибок, но главное правило — не обвинять, а разбираться в причинах:

We don’t chase blame. We dig in and figure out what happened. This is how we continuously raise the bar—not by being perfect, but by being a little bit better each day.


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

Темп + ориентация на долгосрок + простой UI = <3

🐳🐳🐳 А вы что думаете? Пишите в комментариях, ставьте реакции!

Я нашел канал Андрея Noukash еще два года назад, и именно с него начинал свой путь в аналитике. Было ничего не понятно, но видосы и посты Андрея помогли разобраться - что учить и как вообще строить карьеру. Так что, если ты сейчас в поиске работы или хочешь выйти на новый уровень — это точно стоит твоего времени.

💡 27 февраля в 20:00 (Мск) Андрей проведет бесплатный стрим
👉 “Алгоритм получения оффера в 2025”

Андрей – Data Scientist в США, чья зарплата с начала карьеры выросла в 15 раз. Он выстроил систему поиска работы, которая позволяет получать офферы на 30-50% выше рынка в любой стране.

🔍 Что будет на стриме:
1. Ошибки, из-за которых не зовут на следующий этап
2. Как написать резюме, которое пройдет 9 из 10 скринингов
3. Что важно для нанимающего менеджера (спойлер: не только hard skills)
4. Как правильно отвечать на вопросы рекрутера (даже если ты не понял вопрос)
5. Лайфхаки переговоров – как уверенно просить больше денег

🎁 Бонус всем, кто зарегистрируется – чек-лист “Какие вопросы задавать работодателю”, чтобы сразу понять, стоит ли там работать.

📌 Регистрация в боте (ссылка) – участие бесплатное.

Не пропусти — это может быть лучшим карьерным решением в 2025 году. 🚀

Формирование пользовательской привычки: почему одни продукты входят в повседневность, а другие нет?

Недавно наткнулся на интересную концепцию из книги Hooked от Нира Эяля.

Суть в том, что привычные продукты формируются на пересечении двух факторов:

1. Частоты использования – чем чаще мы совершаем действие, тем быстрее оно закрепляется
2. Воспринимаемой ценности – насколько полезным это кажется пользователю

🔍 Google – высокая частота использования, люди ищут информацию каждый день, поэтому привычка сформирована
🚔 Amazon – покупки совершаются реже, но воспринимаемая ценность высокая, поэтому пользователи возвращаются

Что здесь важно понимать?

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

Если продукт используется нечасто, но его воспринимаемая ценность огромна (например, Airbnb), пользователи всё равно возвращаются
Не всегда можно просто "увеличить частоту" – если пользователю не нужна ежедневная покупка товаров, пытаться формировать привычку через увеличение касаний может быть бесполезно

Как это применимо к продуктам и аналитике?

Если стоит задача увеличить вовлечённость, важно понимать, в какой зоне на графике находится продукт.

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

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

😏 Понравился пост? Наберется 100 рекций, продолжу дальше обозревать концепции из книг. А какие книги по продукту или аналитике читали вы? Какие концепции показались вам полезными?

Авито нанимает!

Ускоренный отбор за выходные и возможность попасть в одну из пяти DS-команд: автомодерация, монетизация, поисковое ранжирование, AI Lab и вертикальные команды DS.

Вас ждет:
➡️ конкурентная зарплата и удаленка по всей России;
➡️ реальные задачи на большом масштабе — разработка алгоритмов для проверки объявлений, внедрение ML-моделей, оптимизация процессов и DS-поддержка;
➡️ участие в разработке новых продуктов — предлагаем для этого мощное железо и бюджет на обучение;
➡️ сильное IT-комьюнити, которое любит опенсорс.

Регистрируйтесь по ссылке до 27 февраля и развивайте крупнейший в мире сервис объявлений.

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

Ссылка на пост в 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/

Устроиться аналитиком в Яндекс за выходные

1–2 марта проводим Weekend Offer Analytics. До 24 февраля оставьте заявку на участие, 1 марта пройдите технические собеседования, а 2 марта познакомьтесь с командами и получите офер.

В мероприятии участвует 11 команд: Большие данные, Алиса, Ecom-сценарии Поиска, Автономный транспорт, Поиск с Нейро, Карты, Рекламные технологии, Коммерческий департамент, Международные проекты Поиска в Турции и Казахстане, Crowd, Приложение «Яндекс с Алисой». Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.

Узнать подробности и зарегистрироваться можно здесь.

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

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

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

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

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

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

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

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

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

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

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

🔥 Ухудшающие A/B-тесты: зачем ломать продукт ради роста?

В мире продуктовой аналитики A/B-тесты обычно ассоциируются с улучшением продукта (или его неухудшением). Однако существует менее очевидный, но крайне полезный метод — ухудшающие A/B-тесты. Давайте разберём, что это такое, зачем их проводят и какие преимущества они дают.

________________________

Что такое ухудшающие A/B-тесты?

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

____________________

🤔 Зачем компании проводят ухудшающие A/B-тесты?

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

Экономия ресурсов. Прежде чем инвестировать в улучшение определённой функции, стоит понять, насколько она влияет на метрики. Если ухудшение не приводит к значимым изменениям, возможно, улучшение не принесёт ожидаемой отдачи. За внедрение фичи отвечают 4 лица: менеджер, дизайнер, аналитик и разработчик.

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

____________________

😡 Пример применения

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

Гипотеза: Замедление работы приложения негативно повлияет на метрики.

Эксперимент: Создаются несколько тестовых групп с разной степенью замедления приложения.

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

____________________

🤬 Почему не использовать глобальный контроль?

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

Про пользу ухудшающих тестов в статье Авито

Метрики перформанса могут влиять и на продуктовые показатели. К такому выводу мы пришли после проведения ухудшающих тестов.

Про ухудшающие A/B тесты

📺 link1, link2
🔗 link3

А вы проводили ухудшающий эксперимент? Что проверяли? Наберется 100 🐳, выложу посты про стенды метрик, используемые при анализе результатов A/B экспериментов

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда дашборд превращается в хаос

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

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

___________________________

Как сделать дашборд, который реально нужен бизнесу?

Частая ошибка: не уточнить контекст задачи. Получил запрос, построил отчёт, принёс и тут начинаются уточнения:

“А это для выгрузок или для ежедневного контроля?”
“Нам вообще-то важен срез по регионам, почему его нет? А по приложениям? Точкам входа в продукт?”
“А где сравнение с прошлым месяцем?”
"А нам еще важно следить за этим, сделаешь парочку графиков?
"Смежникам важно смотреть на это, а давай еще сделаем так: на одной вкладке будет общая информация, а на второй возможность для финансов грепнуть

(вопросов может быть много)

1. Почему так произошло?

Не зафиксировали цель дашборда. Какую проблему позволяет решить данный дашборд?

Не проверили, а покрывает ли эту задачу существующая отчётность?

Не уточнили, какие срезы реально важны. Заказчик сам может не знать, пока не увидит готовый отчёт.

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

2. Как избежать переделок?

1️⃣ Сначала обсуждать контекст задачи. Зачем решили делать этот отчёт именно сейчас?

2️⃣ Формулировать основные показатели заранее. Бизнесу нужна конкретика, а не “что-нибудь полезное”.

3️⃣ Закладывать время на доработки, но минимизировать их за счёт хорошего брифинга на старте. Каждую отчетность важно документировать и подсветить основным пользователям за что он отвечает и почему он выглядит именно так.

4️⃣ Понять, кто будет пользоваться дашбордом. Одним важно смотреть верхнеуровнево, другим необходима детализация

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

Было у вас такое, что делали сложный отчёт, а потом оказалось, что его никто не смотрит или вы постоянно вносили в него правки? Делитесь в комментариях!
Понравился формат? Ставьте 🐳, буду рассказывать подробнее с чем сталкивался и чего бы я не хотел допускать в будущем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата-инженеры — самые ценные игроки любой DS-команды

Данные — это база, без навыков их обработки и организации хранения не получится построить никакой аналитики.

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

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

Обучение охватывает весь стек, который нужен многорукому-многоногу: SQL, Python, Metabase, Linux, Docker, Airflow, Clickhouse, Hadoop и Spark. А также готовит к любому собеседованию – в курс включены тестовые задания, технические и HR-собеседования и многое другое.

Уже совсем скоро стартует новый поток
Оставляйте заявку, чтобы узнать все подробности
А по промокоду ZASQL дарят еще скидку 10%

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

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

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

❓ Пенетрация позволяет ответить на вопрос: "Сколько всего пользователей пользуются продуктом в динамике?". В сервисе есть старички, которые регулярно продукт используют и за время мы их учитываем несколько раз (по дням). Мы можем взять весь год и посмотреть сколько всего пользователей использовали фичу 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 🐳🐳🐳, если хотите продолжение, пишите в комментариях, часто ли используете подобные методы?

Как построить витрину данных, как в крупной IT-компании?

Объединение данных из разных источников — то, с чем в какой-то момент сталкиватся каждый аналитик или дата-инженер.

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

Как строить витрину данных разберём в прямом эфире нашего бесплатного вебинара в режиме решения реальной рабочей задачи📊. Спикер вебинара — Айгуль Сибгатуллина, Data Engineer в Сбер.

Что будет на вебинаре:
• Построим воркфлоу от этапа получения ТЗ до создания полноценной витрины;
• Разберемся с методологией на разных диалектах;
• Узучим Spark в работе дата-инженера: преобразования, оптимизации, планы запросов;
• Используем AI для ускорения процессов.

🕗Встречаемся 28 января 19:00 по мск

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