Какие интересные задачи решал?

Интересные и нестандартные задачи в карьере

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

Задача 1: Предсказание цены сделки через аналитику CRM

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

Проблема: Обычные подходы (средняя цена по отрасли) дают ошибку ±50%. Нужна была точная модель.

Решение:

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

• Размер компании (кол-во сотрудников)
• Бюджет (указан в CRM)
• Длительность sales cycle
• Количество decision makers
• Тип контракта (annual vs monthly)

import pandas as pd
from sklearn.ensemble import RandomForestRegressor
from sklearn.preprocessing import StandardScaler

# Загружаем исторические сделки из CRM
df = pd.read_sql("""SELECT 
    deal_id,
    company_size,
    budget_range,
    sales_cycle_days,
    decision_makers_count,
    contract_type,
    final_deal_amount  -- целевая переменная
FROM crm_deals
WHERE status = 'won' AND final_deal_amount > 0
LIMIT 500
""", conn)

# Подготовка данных
X = df[['company_size', 'budget_range', 'sales_cycle_days', 'decision_makers_count']]
y = df['final_deal_amount']

# Обучение модели
model = RandomForestRegressor(n_estimators=100, max_depth=10, random_state=42)
model.fit(X, y)

# Важность признаков
feature_importance = pd.DataFrame({
    'feature': X.columns,
    'importance': model.feature_importances_
}).sort_values('importance', ascending=False)

print(feature_importance)
# Результат:
# feature                   importance
# company_size              0.42
# budget_range              0.35
# decision_makers_count     0.15
# sales_cycle_days          0.08

# Прогноз для новой сделки
new_deal = pd.DataFrame({
    'company_size': [250],
    'budget_range': [100000],
    'sales_cycle_days': [45],
    'decision_makers_count': [3]
})
predicted_amount = model.predict(new_deal)[0]
print(f"Прогнозный размер сделки: ${predicted_amount:,.0f}")

Результат: Точность модели ±15%. Sales team получила инструмент для прогноза и расстановки приоритетов. Средняя ошибка в прогнозировании выручки упала с 40% до 12%.

Задача 2: Анализ сезонности в продажах и оптимизация inventory

Контекст: E-commerce компания хранила товары на складе, не зная точно, какой спрос будет в каждый месяц. Это приводило к затовариванию (избыток) или дефициту (потери продаж).

Проблема: Просто брать средние продажи неправильно — спрос очень зависит от времени года и дня недели.

Решение: Я разбил спрос на компоненты.

import numpy as np
from scipy.signal import savgol_filter

# Исторические продажи по дням
df_sales = pd.read_sql("""SELECT 
    DATE(created_at) as date,
    SUM(quantity) as daily_sales
FROM orders
WHERE created_at >= '2022-01-01'
GROUP BY DATE(created_at)
ORDER BY date
""", conn)

# Выделяем компоненты: Trend + Seasonality + Random

# 1. Тренд (скользящее среднее)
df_sales['trend'] = df_sales['daily_sales'].rolling(window=30, center=True).mean()

# 2. Деманд без тренда (detrended)
df_sales['detrended'] = df_sales['daily_sales'] / df_sales['trend']

# 3. Сезонность по дням недели
seasonal_by_dow = df_sales.groupby(df_sales['date'].dt.dayofweek)['detrended'].median()
print("Коэффициент сезонности по дням недели:")
for day, coeff in seasonal_by_dow.items():
    days = ['Пн', 'Вт', 'Ср', 'Чт', 'Пт', 'Сб', 'Вс']
    print(f"{days[day]}: {coeff:.2f}x")

# Результат:
# Пн: 0.82x (низкий спрос)
# Вт: 0.91x
# Ср: 1.05x
# Чт: 1.12x (высокий спрос)
# Пт: 1.18x (пиковый спрос)
# Сб: 1.25x
# Вс: 0.95x

# 4. Сезонность по месяцам
seasonal_by_month = df_sales.groupby(df_sales['date'].dt.month)['detrended'].median()
print("\nКоэффициент сезонности по месяцам:")
months = ['Янв', 'Фев', 'Мар', 'Апр', 'Май', 'Июн', 'Июл', 'Авг', 'Сен', 'Окт', 'Ноя', 'Дек']
for month, coeff in seasonal_by_month.items():
    print(f"{months[month-1]}: {coeff:.2f}x")

# Прогноз спроса на апрель
baseline_april = 5000  # средний спрос
seasonal_april = 0.94  # апрель спокойнее
forecasted_april = baseline_april * seasonal_april
print(f"\nПрогноз спроса на апрель: {forecasted_april:,.0f} единиц")

Результат: Благодаря сезонному прогнозу снизили лишний inventory на 23%, а потери из-за дефицита упали на 34%. Это освободило $200K в денежном потоке.

Задача 3: Поиск когортного эффекта (когда старые пользователи вдруг начали вели себя иначе)

Контекст: Заметили, что коэффициент retention упал с 65% до 45%. Но это было не по новым пользователям, а по старым, которые уже год с нами.

Проблема: Нужно было выявить, какой экзогенный фактор это вызвал. Может быть, изменился экономический климат? Или конкуренты?

Анализ:

WITH cohort_retention AS (
    SELECT 
        DATE_TRUNC('month', u.created_at)::date as cohort_month,
        u.id as user_id,
        DATE_TRUNC('month', CURRENT_DATE)::date as current_month,
        EXTRACT(MONTH FROM AGE(CURRENT_DATE, u.created_at)) as months_since_signup,
        MAX(CASE WHEN a.action_at >= CURRENT_DATE - INTERVAL '30 days' THEN 1 ELSE 0 END) as active_last_30d
    FROM users u
    LEFT JOIN actions a ON u.id = a.user_id
    WHERE u.created_at >= '2022-01-01'
    GROUP BY DATE_TRUNC('month', u.created_at), u.id
)
SELECT 
    cohort_month,
    months_since_signup,
    COUNT(DISTINCT user_id) as cohort_size,
    SUM(active_last_30d) as retained_users,
    ROUND(100.0 * SUM(active_last_30d) / NULLIF(COUNT(DISTINCT user_id), 0), 2) as retention_pct
FROM cohort_retention
GROUP BY cohort_month, months_since_signup
ORDER BY cohort_month DESC, months_since_signup;

Обнаружили: Пользователи, которые были с нами 12+ месяцев, вдруг перестали логиниться. Но новые и активные пользователи остались.

Причина: Выяснилось, что произошло изменение в algoritme токена JWT. Старые токены (выданные год назад) переставали работать, и пользователи вынуждены были пересоздавать аккаунты. Это был баг в backend, который никто не заметил.

Решение: Исправили баг, миграция токенов, retention вернулся к норме.

Задача 4: Анализ причинно-следственной связи (причинная инференция)

Контекст: Компания запустила новую рекомендационную систему. Revenue вырос на 12%. Но был ли это результат рекомендаций, или просто обычный рост?

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

Решение: A/B тест с двумя группами

from scipy.stats import ttest_ind

# Группа A: С новой системой рекомендаций
group_a = pd.read_sql("""SELECT order_value FROM orders 
WHERE user_id IN (SELECT user_id FROM test_groups WHERE variant = 'treatment')
AND created_at >= '2024-01-01'
""", conn)

# Группа B: Без системы рекомендаций (контрольная группа)
group_b = pd.read_sql("""SELECT order_value FROM orders 
WHERE user_id IN (SELECT user_id FROM test_groups WHERE variant = 'control')
AND created_at >= '2024-01-01'
""", conn)

# Статистический тест
t_stat, p_value = ttest_ind(group_a['order_value'], group_b['order_value'])

print(f"Средний заказ (Group A с рекомендациями): ${group_a['order_value'].mean():.2f}")
print(f"Средний заказ (Group B контрольная): ${group_b['order_value'].mean():.2f}")
print(f"Разница: ${group_a['order_value'].mean() - group_b['order_value'].mean():.2f}")
print(f"P-value: {p_value:.6f}")

if p_value < 0.05:
    print("✓ Результат статистически значим (p < 0.05)")
else:
    print("✗ Результат НЕ значим, результат может быть из-за случайности")

Результат: Рост был реальным (p-value = 0.004). Это доказано и компания с уверенностью развивала рекомендации дальше.

Задача 5: Сегментация клиентов через machine learning

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

Решение: Кластеризация через K-Means

from sklearn.cluster import KMeans
from sklearn.preprocessing import StandardScaler

# Собираем признаки клиентов
df_customers = pd.read_sql("""SELECT 
    user_id,
    total_purchases,
    total_spent,
    avg_order_value,
    purchase_frequency_monthly,
    days_since_last_purchase,
    product_categories_count,
    customer_lifetime_days
FROM customer_metrics
WHERE total_purchases > 0
""", conn)

# Нормализуем признаки (важно для K-Means)
scaler = StandardScaler()
df_normalized = scaler.fit_transform(df_customers.iloc[:, 1:])

# Кластеризация
kmeans = KMeans(n_clusters=4, random_state=42)
df_customers['cluster'] = kmeans.fit_predict(df_normalized)

# Профили кластеров
for cluster in range(4):
    cluster_data = df_customers[df_customers['cluster'] == cluster]
    print(f"\nКластер {cluster} ({len(cluster_data)} клиентов):")
    print(f"  Средний LTV: ${cluster_data['total_spent'].mean():.0f}")
    print(f"  Кол-во покупок: {cluster_data['total_purchases'].mean():.1f}")
    print(f"  Дни с последней покупки: {cluster_data['days_since_last_purchase'].mean():.0f}")

# Результат:
# Кластер 0 (150 клиентов) — HIGH-VALUE LOYAL
#   Средний LTV: $8,500
#   Кол-во покупок: 28.5
#   Дни с последней покупки: 12

# Кластер 1 (420 клиентов) — ACTIVE
#   Средний LTV: $1,200
#   Кол-во покупок: 4.2
#   Дни с последней покупки: 45

# Кластер 2 (680 клиентов) — AT RISK
#   Средний LTV: $450
#   Кол-во покупок: 1.8
#   Дни с последней покупки: 180

# Кластер 3 (1100 клиентов) — DORMANT
#   Средний LTV: $95
#   Кол-во покупок: 1.0
#   Дни с последней покупки: 400+

Результат: Выявили 4 сегмента с очень разными паттернами. Для каждого разработали отдельную retention-стратегию: для HIGH-VALUE нужен персональный менеджер, для AT-RISK нужны email-напоминания, для DORMANT — win-back кампании. Это увеличило efficiency retention-программы в 3 раза.

Ключевой вывод

Самые интересные задачи — те, где аналитика выходит за рамки простых отчётов и становится инструментом для предсказания, объяснения и оптимизации бизнеса. Это требует сочетания:

• Технических навыков (SQL, Python, статистика)
• Бизнес-понимания (что важно для компании)
• Любопытства (глубокие вопросы "почему")
• Умения коммуницировать (результаты должны быть понятны)