ML-трекинг TTV: измеряем и ускоряем путь клиента к ценности

AI-система отслеживания времени до ценности (Time-to-Value)

Клиент подписал контракт, прошло 30 дней, а он так и не понял, зачем платит. Типичная ситуация. Мы знаем, как измерить и сократить путь к ценности. За 15+ проектов по внедрению TTV-трекинга в B2B SaaS-продукты мы накопили практику, которая гарантирует измеримый результат: среднее сокращение TTV на 25% быстрее, чем при ручном анализе.

Time-to-Value (TTV) — время от подписания контракта до момента, когда клиент впервые получает значимую ценность от продукта Wikipedia. В B2B SaaS это ведущий индикатор долгосрочного удержания: клиенты, достигшие Aha-момента за < 14 дней, имеют retention на 40% выше, чем те, кто не достиг его вовсе. Мы автоматизируем этот трекинг с помощью ML, что позволяет предсказывать риски и вмешиваться до того, как клиент застрянет.

Как определить Aha-момент?

Aha-момент = первое достижение value milestone. Конкретные определения зависят от продукта:

• CRM: первая успешно закрытая сделка через систему
• Аналитическая платформа: первый просмотренный дашборд с реальными данными
• Автоматизация: первый успешно выполненный workflow
• Коммуникации: первые 10 сообщений от команды

Определение milestone через данные:

def identify_aha_moment(product_events, cohort):
    """
    Корреляционный анализ: какое action предсказывает retention лучше всего?
    Метод: найти события, после которых 90-day retention максимален
    """
    event_types = product_events['event_type'].unique()

    correlations = {}
    for event in event_types:
        users_with_event = product_events[product_events['event_type'] == event]['user_id'].unique()
        retention_with = cohort[cohort['user_id'].isin(users_with_event)]['retained_90d'].mean()
        retention_without = cohort[~cohort['user_id'].isin(users_with_event)]['retained_90d'].mean()
        correlations[event] = retention_with - retention_without

    return sorted(correlations.items(), key=lambda x: x[1], reverse=True)[:5]

Как ML предсказывает TTV и выявляет риски?

Раннее предсказание застрявших клиентов. Onboarding journey — последовательность шагов. ML предсказывает вероятность того, что клиент так и не достигнет Aha-момента:

def predict_at_risk_onboarding(account_id, days_since_signup):
    events = get_product_events(account_id, days=days_since_signup)

    features = {
        'setup_completion_pct': events['setup_steps_completed'] / total_setup_steps,
        'integrations_connected': events['integrations_count'],
        'users_invited': events['team_members_invited'],
        'login_frequency': events['unique_login_days'] / days_since_signup,
        'support_tickets_opened': events['support_tickets'],
        'training_modules_completed': events['training_completion'],
        'days_since_signup': days_since_signup,
        'plan_tier': account['plan'],
        'company_size': account['employee_count']
    }

    risk_score = onboarding_risk_model.predict_proba([features])[0][1]
    return risk_score

Временной горизонт: День 3, день 7, день 14 — контрольные точки. Если на день 7 прогноз риска > 0.6 → триггер вмешательства.

Сегментация TTV: таблица средних значений

По use case: Кластеризация клиентов по их цели. Разные onboarding paths для разных кластеров — персонализированные рекомендации следующего шага.

Intervention Engine

Automated vs. Human interventions:

def select_intervention(account, risk_score, bottleneck):
    if risk_score > 0.8:
        # Критический — CSM вмешивается вручную
        return {
            'type': 'human',
            'action': 'schedule_call',
            'owner': assign_csm(account),
            'message_template': 'high_risk_outreach'
        }
    elif risk_score > 0.5 and bottleneck == 'integration':
        # Автоматический — in-app tooltip + email
        return {
            'type': 'automated',
            'channel': ['in_app_tooltip', 'email'],
            'content': 'integration_setup_guide',
            'timing': 'next_login'
        }
    else:
        return {'type': 'monitor', 'next_check': 3}  # дней

A/B тестирование интервенций:

• Контрольная группа vs. группа с nudge
• Метрика: TTV (дней до Aha), 30-day activation rate
• Bayesian A/B тест: останавливаем при posterior probability > 95%

Cohort Analytics

TTV Cohort Chart: Классическая визуализация: по оси X — дни с регистрации, по Y — % клиентов достигших Aha. Сравнение когорт (разные месяцы, разные каналы, планы).

Bottleneck Analysis: Воронка onboarding шагов: где больше всего клиентов застревают? Шаг с наибольшим drop-off — приоритет для UX-улучшения.

def funnel_analysis(onboarding_steps, cohort):
    funnel_rates = {}
    for i, step in enumerate(onboarding_steps):
        users_reached = cohort[cohort['max_step_reached'] >= i]['count']
        users_completed = cohort[cohort['max_step_reached'] >= i+1]['count']
        funnel_rates[step] = users_completed / users_reached
    return funnel_rates

Медианный TTV по сегментам: Еженедельный мониторинг. Рост медианного TTV → проблема в onboarding (регрессия в продукте, изменение ICP).

Сравнение типов интервенций

Что входит в работу

• Документация: model card с описанием фич и метрик, pipeline схемы, архитектура ML-сервиса
• Доступы: дашборды TTV cohort chart и funnel analysis для Product & CSM команд
• Обучение: воркшоп по интерпретации рисков и настройке интервенций
• Поддержка: код-ревью и доработка модели под новые events в течение гарантийного периода

Интеграция

Product Analytics: Amplitude, Mixpanel, Heap — источник events. Warehouse: Snowflake/BigQuery — feature store для модели.

CRM: Salesforce Custom Object "Onboarding Progress" — видимость для CSM. Health Score объединяется с TTV progress.

In-app Messaging: Intercom, Pendo, Appcues — каналы доставки автоматических интервенций на основе ML-триггеров.

Сроки: Aha-moment definition + TTV cohort analytics + базовый risk scoring — 3-4 недели. ML-предсказание at-risk accounts + intervention engine + A/B test framework — 6-8 недель.

Хотите измерить и сократить TTV вашего продукта? Свяжитесь с нами — мы поможем настроить систему трекинга под ваш стек. Закажите аудит текущего onboarding для оценки потенциала сокращения TTV. Получите консультацию по внедрению — расскажем, как интегрировать ML-трекинг в вашу продукт-аналитику.

Какие проблемы прогнозирования временных рядов встречаются чаще всего?

Финансовый директор запрашивает прогнозирование временных рядов продаж на квартал. Аналитик строит SARIMA, добивается MAPE 8.3% на тестовой выборке — и с гордостью деплоит. Через два месяца в production метрика падает до 23%. Причина классическая: модель обучалась на данных до COVID, тестировалась на стабильном периоде, а production попал на промо-акцию и сбой поставок. Data leakage + distribution shift = красивые цифры в ноутбуке и неработающий прогноз в реальности. Мы сталкивались с этим десятки раз. Наш опыт — 5+ лет в прогнозировании временных рядов для ритейла, финтеха и IoT, более 50 завершённых проектов.

Неправильная кросс-валидация. Стандартный train_test_split для временных рядов — ошибка. Случайное разбиение создаёт data leakage: модель видит «будущие» значения в обучении. Правильно — TimeSeriesSplit или walk-forward validation с expanding window.

Множественная сезонность. Почасовые данные потребления электроэнергии имеют три сезонности: суточную (24 ч), недельную (168 ч), годовую (8760 ч). SARIMA справляется только с одной. Prophet обрабатывает несколько, но медленно масштабируется на тысячи рядов.

Пропуски и аномалии в данных. Пропуск в сенсорных данных — это информация (датчик отключился), а не просто NaN. Линейная интерполяция убивает этот сигнал. Правильная обработка зависит от природы пропуска.

Cold start при иерархическом прогнозировании. Новый SKU в ассортименте из 50 000 позиций: исторических данных нет, нужен прогноз. Стандартные подходы тут не работают — нужны cross-learning подходы или feature-based методы.

Какие инструменты и когда применять?

Prophet (Meta) — отличный старт для бизнес-данных с понятной сезонностью и праздниками. Быстро настраивается, интерпретируем, встроенная обработка выбросов и пропусков. Падает в точности при нерегулярных паттернах и не масштабируется на десятки тысяч рядов без параллелизации. Prophet (Facebook) — официальная документация.

Gradient boosting на фичах (LightGBM, XGBoost) — часто недооценённый подход. Создаёте фичи вручную: лаги (t-1, t-7, t-28), скользящие средние, категориальные признаки (день недели, месяц), экзогенные переменные. Модель обучается на всех рядах одновременно — решает cold start через похожие ряды. MAPE на ритейл-прогнозировании часто лучше нейронных сетей при правильной feature engineering.

TFT (Temporal Fusion Transformer) — трансформер, специально разработанный для интерпретируемого прогнозирования с ковариатами. Встроенные механизмы: variable selection (какие признаки важны), temporal self-attention (какие временные точки влияют на прогноз), квантильные предсказания. Доступен в pytorch-forecasting. Требует ~10 000+ записей на ряд для стабильного обучения. Temporal Fusion Transformer — академическая публикация.

PatchTST — трансформер, который делит временной ряд на патчи (аналогично ViT для изображений). Лучше захватывает локальные паттерны, чем классические трансформеры. Хорошо работает для long-horizon forecasting (прогноз на 96–720 шагов). Реализация в neuralforecast от Nixtla.

N-HiTS, N-BEATS — нейронные архитектуры без attention, быстрее TFT, конкурентная точность. N-BEATS выигрывает на M4/M5 benchmark для задач без ковариат.

Как мы разворачиваем TFT в production?

TFT требует тщательной подготовки данных. Типичный пайплайн через pytorch-forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 дней
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 дней
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

Частая ошибка: target_normalizer по умолчанию (StandardScaler) ломает предсказания для рядов с нулевыми значениями (нет продаж в выходные). GroupNormalizer с transformation="softplus" — правильный выбор для count-данных.

Пошаговая инструкция по настройке TFT

1. Сбор и подготовка данных. Обработать пропуски (маркировать NaN, интерполировать только если это технический сбой), агрегировать до нужной частоты, сформировать ковариаты (праздники, промо, цены).
2. Создание TimeSeriesDataSet. Указать group_ids (например, магазин+SKU), временной индекс, горизонт прогноза. Настроить target_normalizer с учётом распределения таргета.
3. Обучение baseline. Сначала Prophet или LightGBM — чтобы понять, насколько сложнее задача.
4. Тренировка TFT. Запустить TemporalFusionTransformer с loss=QuantileLoss(), подобрать learning rate и размеры hidden слоёв. Использовать pytorch_forecasting или neuralforecast.
5. Валидация и интерпретация. Проверить walk-forward, проанализировать variable selection, построить attention heatmap.

Кейс: прогноз спроса в ритейле. Сеть из 120 магазинов, 8000 SKU, горизонт прогноза 28 дней. Исходная система: SARIMA отдельно для каждого ряда, MAPE 18.4%, полный цикл переобучения — 6 часов. TFT на PyTorch + pytorch-forecasting: одна модель на все ряды, MAPE 11.2%, переобучение — 40 мин на A10G. Дополнительный бонус: feature importance через variable selection — выяснилось, что day_before_holiday влияет сильнее, чем сама дата праздника. Средняя экономия бюджета на инференсе для клиента составила 1.5 млн ₽ в год.

Как правильно оценивать качество прогнозов?

Не используйте RMSE как единственную метрику — она сильно штрафует за большие ошибки на больших значениях. Наш набор метрик для ритейл-прогнозирования:

• MAPE — интерпретируема, но нестабильна при значениях близких к нулю
• sMAPE — симметричная версия, избегает деления на маленькие числа
• MASE (Mean Absolute Scaled Error) — нормализован относительно наивного сезонного прогноза, отлично подходит для сравнения между рядами с разными масштабами
• Quantile loss / Pinball loss — для вероятностного прогнозирования, оценка покрытия интервалов

Гарантируем: мы предоставляем model card с этими метриками на валидационной выборке и результаты walk-forward теста на истории не менее 6 месяцев.

Что входит в работу

• Документация по выбранной архитектуре, обоснование выбора гиперпараметров.
• Воспроизводимый пайплайн обучения и инференса (Docker + CI/CD + Airflow/Prefect).
• Код с комментариями и модульными тестами на ключевые компоненты.
• Обучение вашей команды: как переобучать модель, как интерпретировать выходы, как деплоить новые версии.
• Поддержка в течение 3 месяцев после сдачи: консультации, фиксы багов, донастройка.

Процесс работы

Начинаем с EDA: визуализация, тест ADF на стационарность, STL-декомпозиция, анализ пропусков и выбросов. Это 2–3 дня, но часто выявляет системные проблемы данных, которые блокируют прогнозирование.

Затем: baseline (наивный seasonal, Prophet), feature engineering для LGBM, выбор архитектуры нейронной сети если нужно. Walk-forward validation с реалистичным горизонтом. Деплой через API с автоматическим переобучением по расписанию через Airflow или Prefect.

Сроки ориентировочно: MVP-прогноз на одном типе данных — 3–6 недель. Иерархическая система прогнозирования с автоматизацией — 2–5 месяцев. Стоимость рассчитывается индивидуально.

Наша команда — сертифицированные ML-инженеры (AWS ML Specialty, GCP Professional ML Engineer). За 5 лет на рынке реализовали более 50 проектов по прогнозированию. Свяжитесь с нами для бесплатного анализа ваших данных — мы оценим задачу и дадим первые рекомендации за 1–2 дня. Закажите консультацию и убедитесь, что ваши прогнозы работают в production, а не только в ноутбуке.