С какими проблемами сталкивался на работе

Question

claude-haiku-4.5 · Accepted Answer

## Реальные проблемы аналитика на работе и как я их решал

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

### 1. Грязные и неполные данные

**Проблема**: В CRM системе 40% записей о клиентах содержали ошибки:
- Пустые email поля
- Дубликаты (один клиент в базе дважды)
- Несовместимые форматы (телефоны: "+7...", "8...", без страны)
- Устаревшие данные (люди, которые удалили аккаунт 2 года назад, остались в базе)

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

**Решение**:

```python
import pandas as pd
import numpy as np
from fuzzywuzzy import fuzz

# 1. Нормализация телефонов
def normalize_phone(phone):
    if pd.isna(phone):
        return None
    phone = ''.join(filter(str.isdigit, str(phone)))
    if len(phone) == 10:
        phone = '7' + phone  # Россия
    return phone if len(phone) == 11 else None

df['phone_normalized'] = df['phone'].apply(normalize_phone)

# 2. Выявление дубликатов
def find_duplicates(df, threshold=85):
    duplicates = []
    for i in range(len(df)):
        for j in range(i+1, len(df)):
            # Сравниваем по email и имени
            email_match = fuzz.ratio(df.iloc[i]['email'], df.iloc[j]['email'])
            name_match = fuzz.ratio(df.iloc[i]['full_name'], df.iloc[j]['full_name'])
            
            if email_match > threshold or (email_match > 80 and name_match > 80):
                duplicates.append({
                    'customer_id_1': df.iloc[i]['id'],
                    'customer_id_2': df.iloc[j]['id'],
                    'confidence': max(email_match, name_match)
                })
    return pd.DataFrame(duplicates)

# 3. Удаление неживых клиентов
df['is_active'] = ~(
    (df['last_login'].isna()) & 
    (df['last_purchase_date'] < pd.Timestamp.now() - pd.Timedelta(days=365))
)
```

**Результат**: очистили БД, выявили 15K дубликатов (объединили в 7.5K клиентов), исправили 60% телефонов → анализ LTV стал достоверным

### 2. Конфликт между метриками и бизнес-целями

**Проблема**: Метрика MAU (Monthly Active Users) растет, но выручка падает.

Продакт-менеджер настаивал, что MAU — главное. Но я заметил: пользователи, которые растят MAU, это low-value пользователи (используют бесплатный функционал, никогда не платят).

**Конфликт**: 
- PM хочет расти по MAU
- CFO хочет расти по выручке
- Я в середине, объясняя, что это противоречит друг другу

**Решение**:

```sql
-- Анализ когорт по типам пользователей
WITH user_cohorts AS (
    SELECT 
        DATE_TRUNC('month', signup_date) as cohort_month,
        user_id,
        SUM(revenue_30d) as paid_30d,
        COUNT(CASE WHEN activity_score > 0.5 THEN 1 END) as active_days
    FROM users u
    LEFT JOIN purchases p ON u.id = p.user_id
    GROUP BY DATE_TRUNC('month', signup_date), u.id
)
SELECT 
    cohort_month,
    COUNT(DISTINCT user_id) as mau,
    COUNT(DISTINCT CASE WHEN paid_30d > 0 THEN user_id END) as paying_users,
    ROUND(100.0 * COUNT(DISTINCT CASE WHEN paid_30d > 0 THEN user_id END) / COUNT(DISTINCT user_id), 2) as conversion_rate,
    SUM(paid_30d) as total_revenue,
    ROUND(AVG(paid_30d), 2) as arpu
FROM user_cohorts
GROUP BY cohort_month;
```

**Вывод**: MAU рос на 15%, но ARPU падал с $12 до $8, потому что платящая база оставалась неизменной, а бесплатная база росла.

**Решение**: предложил вместо MAU смотреть на DAU платящих пользователей + Net Revenue Retention → KPI изменился, стратегия переориентировалась

### 3. Недостаточная мощность инструментов

**Проблема**: У компании были 500 млн строк в таблице transactions. Попытка запустить простый GROUP BY занимала 15 минут, а запросы часто падали по timeout.

BigQuery в облаке = дорого. Внутренняя PostgreSQL падала при больших данных.

```sql
-- Этот запрос был разумный логически, но вешал БД:
SELECT 
    user_id,
    DATE_TRUNC('day', created_at) as day,
    COUNT(*) as transaction_count,
    SUM(amount) as daily_volume
FROM transactions
WHERE created_at >= NOW() - INTERVAL '365 days'
GROUP BY user_id, DATE_TRUNC('day', created_at)
ORDER BY daily_volume DESC;
-- Время выполнения: 18 минут (на 500M строк это много)
```

**Решение**: внедрили Clickhouse (column-oriented БД):

```sql
-- Тот же запрос в Clickhouse выполняется за 0.3 секунды!
SELECT 
    user_id,
    toDate(created_at) as day,
    count() as transaction_count,
    sum(amount) as daily_volume
FROM transactions
WHERE toDate(created_at) >= today() - 365
GROUP BY user_id, toDate(created_at)
ORDER BY daily_volume DESC
LIMIT 1000;
```

Также:
- Добавили партиционирование таблиц по месяцам
- Создали pre-aggregated таблицы для часто используемых метрик
- Внедрили дневные batch-снимки вместо запросов на лету

**Результат**: аналитики сначала ждали результатов часами, теперь ждут минутами

### 4. Отсутствие доверия к данным

**Проблема**: Генерируешь отчет о доходе за месяц, отправляешь CFO, а через час говорит: "Это не совпадает с цифрами в1С". Ты начинаешь искать ошибку в своем SQL запросе.

Происходило это часто. Когда расхождения, люди не верят аналитике.

**Причины**:
- Different definition of revenue (gross vs net? with taxes?)
- Timing issues (деньги пришли, но счет выставлен в другой день)
- Разные источники данных (1С, Stripe, кассовая система)

**Решение**: создал "Golden Source" (единый источник истины):

```python
# Reconciliation script
revenue_from_stripe = get_revenue_from_stripe()  # API
revenue_from_1c = get_revenue_from_1c()          # ERP
revenue_from_db = get_revenue_from_internal_db() # Our DB

reconciliation_report = pd.DataFrame({
    'source': ['Stripe', '1C', 'Internal DB'],
    'revenue': [revenue_from_stripe, revenue_from_1c, revenue_from_db],
    'currency': ['RUB', 'RUB', 'RUB']
})

# Выявляем расхождения
if not (revenue_from_stripe == revenue_from_1c == revenue_from_db):
    # Детальный анализ различий
    missing_in_1c = [tx for tx in internal_db if tx not in c_1]
    # ...
    log_discrepancy_report()
```

**Результат**: Каждое утро в Slack отправляется reconciliation отчет. Если есть расхождения, видно, откуда они — это создало доверие

### 5. Неправильная интерпретация статистики

**Проблема**: Запустили A/B тест. Конверсия в группе B выше на 2%. Я рапортую: "B лучше!" Запускаем в продакшн. А потом... ничего не изменилось. В продакшене лифт не проявился.

Почему? Потому что с моей выборкой и сроками, разница была на границе значимости (p-value = 0.048, почти не значима).

```python
from scipy import stats

# Данные из теста
group_a = [0, 1, 0, 0, 1, 1, 0, 1, 0, 0]  # 4 конверсии из 10 = 40%
group_b = [1, 0, 1, 0, 1, 1, 0, 1, 1, 0]  # 6 конверсий из 10 = 60%

t_stat, p_value = stats.ttest_ind(group_a, group_b)
print(f"p-value: {p_value:.4f}")  # Высокий p-value = низкая значимость

# Правильный подход: считать требуемый размер выборки ДО теста
from statsmodels.stats.power import tt_ind_solve_power

# Если я хочу поймать эффект 15% с силой 80% и alpha=0.05
required_sample_size = tt_ind_solve_power(
    effect_size=0.15,
    alpha=0.05,
    power=0.80,
    ratio=1.0  # равные группы
)
print(f"Требуется {int(required_sample_size)} участников в каждой группе")
```

**Решение**: внедрил protocol для A/B тестирования:
1. **Pre-registration**: описываем тест, метрику, размер выборки ДО запуска
2. **Minimum sample size**: НИКОГДА не глядим на результаты, пока не достигнемы N участников
3. **False positive rate control**: используем Bonferroni correction если много метрик

**Результат**: перестали запускать false positive тесты, экономия на бесполезных фичах

### Главный вывод

Эти проблемы научили меня, что хороший аналитик — это не просто тот, кто пишет SQL. Это:

**1. Data steward** — отвечает за качество и достоверность
**2. Communicator** — объясняет данные нетехническим людям
**3. Engineer** — решает проблемы производительности и архитектуры
**4. Statistician** — не просто отчеты, а scientific approach
**5. Problem solver** — видит суть проблемы за метриками

Именно такой holistic подход к аналитике я хочу применять в вашей компании.

С какими проблемами сталкивался на работе

Комментарии (1)

Реальные проблемы аналитика на работе и как я их решал

1. Грязные и неполные данные

2. Конфликт между метриками и бизнес-целями

3. Недостаточная мощность инструментов

4. Отсутствие доверия к данным

5. Неправильная интерпретация статистики

Главный вывод