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

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

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

❌ Особенно актуально это на тех местах работы, где проводится мало исследований или A/B-тестов, и аналитик постепенно превращается в сборщика витрин — на входе требования, на выходе дашборд.

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

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

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

-> дальше идет поддержание функционала, алерты. ТОЛЬКО продакты / проджекты генерировали новые задачи (аналитика не двигала бизнес).

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

Например.

1. На срезе X видно падение конверсии в поиск -> рождается гипотеза.
2. Общее падение заказов -> копаем в способы оплаты -> видно падение СБП.
3. Новички хуже проходят онбординг -> видно в глубине событий за первую сессию.

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

15 минут в день и спина болеть не будет

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

🔥 Ставьте реакции, если пост был полезным, и делитесь своими кейсами в работе с дашбордами

Внезапные влеты

Привет, мир! Я вернулся после сдачи экзаменов. Тема поста - влеты.

Что такое влет? Сидишь такой, решаешь свои задачки и тут бац, срочная задача, которая должна быть сделана еще вчера

Например

📊 Просела метрика, давайте поймем, почему так.

🧑‍💻 CEO нужно показать отчет, для этого нужно предоставить те данные, которая не покрывает отчетность (через час, разумеется).

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

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

🟢 Плюсы

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

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

Ну и ещё - это шанс выделиться. Быстро собрать информацию, выдать решение, спасти день и стать тем аналитиком, которому доверяют.

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

🔴 Минусы

1. Внезапный стресс. Сложно может быть понимать контекст, резко смещать фокус в рамках спринта.
2. Местами может обесценивать твою работу (твои ресурсы, планирование и др.)
3. Нарушение границ. Если отвечать постоянно ДА, то высока вероятность, что следующий влет упадет в тебя, ну а затем выгорание)

🤷‍♂️ Что можно с этим сделать?

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

2. Если можно решить задачу на коленке грубо, можно предоставить вариант / MVP решения того, как можно закрыть проблему.

3. Делать выводы по влетам. А почему вообще возник? С чем связан? Является ли он критичным для бизнеса?

😖 Влеты раздражают, напрягают и сбивают с ритма.
Но и это точка, где аналитик становится не просто исполнителем, а партнёром: где ты думаешь не только про задачи, но и про приоритеты, коммуникацию, стабильность.
Главное - не брать всё на себя, фильтровать, проговаривать ожидания, и не бояться говорить с заказчиками.

Ставьте 🔥, если пост понравился! Делитесь с миром.
Как часто у вас бывают влеты на работе? Что с ними делаете? Пишите в комментариях

UX пользователей: кейсы крупных компаний

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

🔗 Так вот, ссылочка тут

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

Интересные кейсы

🟣 Audible: Build seamless purchase experiences
Рассматривается, как Audible улучшает UX при оформлении подписки, минимизируя фрикции и повышая конверсию.

🍔 McDonald’s: The Psychology Behind McDonald’s $2 Billion Self-Serve Kiosks
Анализируется, как дизайн киосков влияет на поведение клиентов и способствует увеличению продаж.

🟢 Grammarly: How to Craft Onboarding Surveys Users Love: 5 Do’s and Don’ts
Показано, как правильно сформулированные вопросы при регистрации повышают вовлеченность пользователей.

🎵 Spotify Wrapped: Spotify Wrapped: 6 psychology principles that make it go viral every year.
Разбирается, какие психологические принципы делают ежегодный отчет Spotify таким популярным и ожидаемым.

🟡 Temu: The psychology of Temu’s casino-like shopping UX
Исследуется, как элементы геймификации и случайных вознаграждений стимулируют покупки.

Всего представлено 64 кейса, которые можно посмотреть и рассмотреть с уклоном в психологию пользователей

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

Годный ресурс, советую каждому ознакомиться с ним.

Если пост понравился, поставьте 🔥, пишите комментарии, нужно ли делать подборку по таким ресурсам!