Что влияет на метрику 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. А вы применяете эти методы или какие-то другие?

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

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

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

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

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

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


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

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

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

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: для оценки каннибализации честнее всего запустить 🆎

Материалы для прокачки навыков в 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

Что такое 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-анализ? Как относитесь к данному методу сегментации?

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

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

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

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

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

💰 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

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

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

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

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

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

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

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

Что такое 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)

🚨 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 до метрик. Это простая проверка, которая спасёт ваш эксперимент.

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

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

🤡 — пойдет)

Отладка 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️⃣Последнее

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

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

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

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

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

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

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 🔥, расскажу, как я сам проходил собеседования с продуктовыми кейсами — какие были вопросы, как готовился и что помогло.

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

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

Входит:

— Задачи, которые напрямую влияют на метрики продукта: 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 — вирусность через встречи
🟣Проблема: как вовлечь новых пользователей
🟡Решение: бесплатные встречи + брендинг в ссылке
🟢Результат: каждая встреча — новая точка роста

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

Поиск роста для аналитика в компании через освоение нового

Сидишь на одном месте, думаешь, что развитие вышло на плато и не знаешь, что делать.

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

Это может касаться разных сторон того, что хочется прокачать.

👍 Сюда можно отнести:

🟢Работу с новыми инструментами. Например, хочешь освоить Kafka, Hadoop, Airflow.
🟡Новые подходы. Например, применение A/B тестов, ML, Deep Learning, GPT в бизнес-процессах.
🟣Бизнес аспекты. Хочешь развиваться в e-com, e-grocery дальше, но не понимаешь почему вообще возникают те или иные задачи, общий контекст не складывается в голове
...
список можно дополнять в зависимости от своих интересов.

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

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

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

Тут есть 2 варианта:

1️⃣ В компании есть наработки, а в команде нет. Нужно изучить существующие наработки в компании, понять, как их можно адаптировать под задачи своей команды, и предложить первый тестовый кейс на знакомой бизнес-проблеме. Возможно, применение ML поможет быстрее находить инсайты, а A/B тесты — честно замерять эффекты.

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

Бывало ли у вас ощущение, что развитие застопорилось?

Поставьте 🔥, если тема откликается! Делитесь в комментариях своими кейсами поиска роста 🙏

💡 Хочу собрать продуктовые кейсы и в дальнейшем разобрать тут

Очень часто аналитиков учат SQL, Python, визуализации. Но почти не учат думать о продукте и бизнесе: зачем метрика выросла, как устроен флоу решений, почему фича провалилась.

📊 Поэтому я собираю продуктовые кейсы — из разных компаний, команд и контекстов. Чтобы потом разобрать их и сделать нормальную базу практики.

Примеры задач, которые подходят:

1. продуктовая задача с собеседований
2. запуск фичи или её провал
3. борьба с оттоком, рост CR / LTV / GMV
4. нестандартный A/B
5. онбординг, ретеншен
6. или просто интересная продуктовая задача, с которой вы бились

👉 Форма на 3 минуты

Если получится классная история — сделаю по ней разбор.
Подключайтесь, будет интересно.

Про базовые метрики в задачах классификации в машинном обучении

Классификация — это про то, как определяется класс объекта. Например: фродер или нет, показать товар или не показать, дать кредит или отказать.

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

Когда обучается модель, необходимо понять, насколько хорошо она работает.

Обычно начинают с accuracy — самой простой и часто вводящей в заблуждение метрики.

1️⃣ Accuracy (доля верных предсказаний)

Представим задачу разметки клиентов как фродеров или нет.

В выборке всего 5% настоящих фродеров.

Если модель просто будет отвечать, что все не фродеры, она окажется права в 95% случаев. Accuracy = 95%.

На первый взгляд — отличный результат.

🚫 Но такой результат можно получить, не делая ничего. В задачах с перекосом классов accuracy — почти бесполезна.

Accuracy = (TP + TN) / (TP + FP + FN + TN)

2️⃣ Precision (точность)

Отражает долю корректных среди всех предсказанных как положительные.

В нашем случае отражает долю реальных фродеров среди всех, кого модель определила как фродеров

Если модель указывает на пользователей как фродеров, а по факту из 10 таких пользователей 6 действительно фродеры, а 4 — нет, то:

Precision = 6 / (6 + 4) = 0.6

👍 Иначе говоря — насколько обоснованно модель выдала положительный класс.

При низком precision модель тревожит нормальных пользователей — что критично для антифрода, медицины, рекомендаций.

Precision = TP / (TP + FP)

3️⃣ Recall (полнота)

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

Если в выборке 20 настоящих фродеров, и модель нашла 6 из них, то:

Recall = 6 / (6 + 14) = 0.3

😱 Это означает, что 70% фродеров модель пропустила.

Проще говоря — если модель кого-то не заметила, это может дорого обойтись.

Recall = TP / (TP + FN)

🤔 Про TP, FP, FN, TN в этой задаче классификации

TP — модель предсказала фрод и это правда
FP — модель предсказала фрод, но это ошибка
FN — модель сказала не фрод, но на самом деле это фрод
TN — не фрод и модель это правильно предсказала

4️⃣ Трейд-офф между Precision и Recall

🙂 При высоком пороге модель выдает положительный класс только при большой уверенности. Precision возрастает, но recall снижается — модель пропускает многих.

🪫 При низком пороге модель ловит почти всех фродеров — recall высокий, но увеличивается число ошибок (FP), и precision падает. Поэтому часто используют F1-score — гармоническое среднее между precision и recall.

F1 = 2 * (Precision * Recall) / (Precision + Recall)

Статьи:

[ссылка_1], [ссылка_2], [ссылка_3], [ссылка_4]

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