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

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

Это интересная задача. Метрика «счастья» должна быть простой, но отражать реальность. Дам структурированный подход.

Шаг 1: Определение «счастья» в контексте поисковых подсказок

Что делает пользователя счастливым при использовании поисковых подсказок?

1. Релевантность — подсказка правильная (я ищу именно это)
2. Скорость — подсказка появилась быстро
3. Использование — я действительно нажимаю на подсказку (не игнорирую)
4. Точность — подсказка привела к нужному результату
5. Разнообразие — есть выбор, не одно и то же

Шаг 2: Выбор метрик для каждого компонента

Компонент 1: Click-through Rate (CTR) — Релевантность + Использование

CTR = (Clicks on suggestion) / (Times suggestion shown)

Почему это важно:

• Если подсказка хорошая, пользователь кликнет
• CTR выше = пользователи доверяют подсказкам
• Базовое значение: 15-25% для хороших подсказок

SQL:

SELECT 
    suggestion_id,
    COUNT(CASE WHEN event = 'suggestion_shown' THEN 1 END) as impressions,
    COUNT(CASE WHEN event = 'suggestion_clicked' THEN 1 END) as clicks,
    COUNT(CASE WHEN event = 'suggestion_clicked' THEN 1 END) * 100.0 / 
        COUNT(CASE WHEN event = 'suggestion_shown' THEN 1 END) as ctr_pct
FROM search_events
GROUP BY suggestion_id;

Компонент 2: Conversion Rate (пользователь нашел, что искал)

Conversion = (Sessions with purchase/action after clicking suggestion) / (Total clicks)

Почему это важно:

• CTR высокий, но если пользователь не конвертит — это значит подсказка была неправильной
• Это отражает точность предсказания системы
• Базовое значение: 5-10% в e-commerce

SQL:

SELECT 
    COUNT(DISTINCT CASE WHEN converted = true THEN session_id END) as converting_sessions,
    COUNT(DISTINCT session_id) as total_sessions,
    COUNT(DISTINCT CASE WHEN converted = true THEN session_id END) * 100.0 / 
        COUNT(DISTINCT session_id) as conversion_rate
FROM (
    SELECT 
        session_id,
        MAX(CASE WHEN event = 'purchase' THEN 1 ELSE 0 END) as converted
    FROM search_events s
    WHERE EXISTS (
        SELECT 1 FROM search_events s2 
        WHERE s2.session_id = s.session_id 
        AND s2.event = 'suggestion_clicked'
    )
    GROUP BY session_id
) conversions;

Компонент 3: Latency (Скорость появления подсказок)

Latency = Average time from keystroke to suggestion shown

Почему это важно:

• Если подсказка появится через 2 секунды — пользователь может уже уйти
• Быстрые подсказки = счастливые пользователи
• Базовое значение: <200ms (хорошее), <500ms (приемлемо)

SQL:

SELECT 
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY suggestion_latency_ms) as p50_latency,
    PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY suggestion_latency_ms) as p95_latency,
    AVG(suggestion_latency_ms) as avg_latency
FROM search_events
WHERE event = 'suggestion_shown';

Компонент 4: Satisfaction Score (прямой опрос)

Метод: Каждые N кликов показываем микро-опрос: "Была ли подсказка полезна?"

• Да (5 баллов)
• Отчасти (3 балла)
• Нет (1 балл)

SELECT 
    AVG(satisfaction_score) as avg_satisfaction
FROM suggestion_feedback
WHERE feedback_date > NOW() - INTERVAL '7 days';

Шаг 3: Нормализация метрик

Все компоненты в разных единицах:

• CTR: 0-100%
• Conversion: 0-100%
• Latency: 0-1000ms
• Satisfaction: 1-5 баллов

Нормализуем в шкалу 0-1 (или 0-100%):

def normalize_metrics(ctr, conversion, latency_ms, satisfaction):
    # CTR: 0-30% → 0-1 (выше 30% = 1.0)
    norm_ctr = min(ctr / 30, 1.0)
    
    # Conversion: 0-15% → 0-1 (выше 15% = 1.0)
    norm_conversion = min(conversion / 15, 1.0)
    
    # Latency: 0-500ms → 0-1 (500ms = 0, 100ms = 1.0)
    norm_latency = max(1 - (latency_ms / 500), 0)
    
    # Satisfaction: 1-5 → 0-1 (5 = 1.0, 1 = 0.0)
    norm_satisfaction = (satisfaction - 1) / 4
    
    return {
        'norm_ctr': norm_ctr,
        'norm_conversion': norm_conversion,
        'norm_latency': norm_latency,
        'norm_satisfaction': norm_satisfaction
    }

Шаг 4: Взвешивание компонентов

Вопрос: Какой компонент важнее?

Мой выбор весов (обоснованный):

1. CTR: 30% вес — это первый сигнал, что подсказка хорошая
2. Conversion: 30% вес — но если нет конверсии, подсказка была плохой
3. Satisfaction: 25% вес — прямой сигнал от пользователя
4. Latency: 15% вес — важно, но не критично (даже при 500ms пользователи используют)

Рациональное обоснование:

• CTR и Conversion одинаково важны (они дополняют друг друга)
• Satisfaction — это «ground truth» от пользователя
• Latency — это гигиена, но не основной драйвер счастья

Шаг 5: Формула интегральной метрики

Suggest Happiness Score (SHS) = 
    0.30 × CTR_normalized + 
    0.30 × Conversion_normalized + 
    0.25 × Satisfaction_normalized + 
    0.15 × Latency_normalized

Шкала: 0-1 (или 0-100%)
Интерпретация:
- 0.00-0.30: Плохо (пользователи не счастливы)
- 0.30-0.60: Среднее (есть проблемы)
- 0.60-0.80: Хорошо (пользователи довольны)
- 0.80-1.00: Отлично (пользователи очень довольны)

Шаг 6: SQL для расчета SHS

WITH metrics_daily AS (
    -- CTR
    SELECT 
        DATE_TRUNC('day', event_date) as day,
        COUNT(CASE WHEN event = 'suggestion_clicked' THEN 1 END) * 100.0 / 
            COUNT(CASE WHEN event = 'suggestion_shown' THEN 1 END) as ctr_pct,
        
        -- Conversion (в том же дне)
        COUNT(DISTINCT CASE 
            WHEN event = 'purchase' AND 
                 EXISTS (SELECT 1 FROM search_events se2 
                         WHERE se2.session_id = search_events.session_id 
                         AND se2.event = 'suggestion_clicked'
                         AND se2.event_date = search_events.event_date)
            THEN session_id 
        END) * 100.0 / 
        NULLIF(COUNT(CASE WHEN event = 'suggestion_clicked' THEN 1 END), 0) as conversion_pct,
        
        -- Latency
        AVG(CASE WHEN event = 'suggestion_shown' THEN suggestion_latency_ms END) as latency_ms,
        
        -- Satisfaction
        (SELECT AVG(score) FROM suggestion_feedback 
         WHERE DATE_TRUNC('day', feedback_date) = DATE_TRUNC('day', search_events.event_date)) as satisfaction_score
    FROM search_events
    GROUP BY 1
),
normalized AS (
    SELECT 
        day,
        LEAST(ctr_pct / 30.0, 1.0) as norm_ctr,
        LEAST(conversion_pct / 15.0, 1.0) as norm_conversion,
        GREATEST(1 - (latency_ms / 500.0), 0) as norm_latency,
        COALESCE((satisfaction_score - 1) / 4, 0.5) as norm_satisfaction
    FROM metrics_daily
)
SELECT 
    day,
    ROUND((
        0.30 * norm_ctr +
        0.30 * norm_conversion +
        0.25 * norm_satisfaction +
        0.15 * norm_latency
    ) * 100, 1) as suggest_happiness_score
FROM normalized
ORDER BY day DESC;

Шаг 7: Дополнительные метрики для анализа

Сегментированные метрики (срезы):

-- По типу поиска
SELECT 
    search_category,
    suggest_happiness_score
FROM shs_daily
ORDER BY suggest_happiness_score DESC;

-- По устройству
SELECT 
    device_type,
    suggest_happiness_score
FROM shs_daily
ORDER BY suggest_happiness_score DESC;

-- По географии
SELECT 
    country,
    suggest_happiness_score
FROM shs_daily
ORDER BY suggest_happiness_score DESC;

Шаг 8: Мониторинг и алерты

-- Проверить если SHS упал на 10% за день
WITH daily_shs AS (
    SELECT 
        day,
        suggest_happiness_score,
        LAG(suggest_happiness_score) OVER (ORDER BY day) as prev_day_shs
    FROM shs_daily
)
SELECT 
    day,
    suggest_happiness_score,
    prev_day_shs,
    ((suggest_happiness_score - prev_day_shs) / prev_day_shs * 100) as pct_change
FROM daily_shs
WHERE ABS((suggest_happiness_score - prev_day_shs) / prev_day_shs) > 0.10
ORDER BY day DESC;

Пример расчета

День 1:

• CTR: 20% → normalized: 0.67
• Conversion: 8% → normalized: 0.53
• Satisfaction: 4.2/5 → normalized: 0.80
• Latency: 150ms → normalized: 0.70

SHS = 0.30×0.67 + 0.30×0.53 + 0.25×0.80 + 0.15×0.70 = 0.201 + 0.159 + 0.200 + 0.105 = **0.665 (66.5%)**

Интерпретация: Хорошо, но есть место для улучшения.

Почему эта метрика хорошая

1. Комплексная — учитывает несколько аспектов счастья
2. Действенная — можно улучшать каждый компонент
3. Объективная — не зависит от мнений
4. Сравнимая — можно сравнивать дни/недели/версии
5. Пригодная для мониторинга — легко заметить падение
6. Бизнес-связанная — высокий SHS = больше пользователей вернётся

Альтернативные веса (если другие приоритеты)

Если приоритет — скорость: 0.25 × CTR + 0.25 × Conversion + 0.20 × Satisfaction + 0.30 × Latency

Если приоритет — точность предсказаний: 0.20 × CTR + 0.40 × Conversion + 0.30 × Satisfaction + 0.10 × Latency

Итог

Интегральная метрика Suggest Happiness Score (SHS) = 0.30×CTR + 0.30×Conversion + 0.25×Satisfaction + 0.15×Latency объединяет все аспекты счастья пользователя в одно простое число (0-100%), которое легко мониторить и улучшать.