AI-система персонализированных retention-предложений

Проектируем и внедряем системы искусственного интеллекта: от прототипа до production-ready решения. Наша команда объединяет экспертизу в машинном обучении, дата-инжиниринге и MLOps, чтобы AI работал не в лаборатории, а в реальном бизнесе.
Показано 1 из 1Все 1564 услуг
AI-система персонализированных retention-предложений
Средний
~1-2 недели
Часто задаваемые вопросы

Направления AI-разработки

Этапы разработки AI-решения

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    949
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1183
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    921

Потеря клиентов — одна из самых болезненных метрик в SaaS. Каждый процент оттока напрямую снижает LTV и заставляет тратить больше на привлечение. Но стандартная скидка 10% всем, кто не покупал 30 дней, сливает маржу и не возвращает тех, кто ушёл по другим причинам. Мы разрабатываем AI-системы, которые анализируют поведение каждого клиента, предсказывают риск оттока и генерируют персонализированные retention-предложения. Результат: конверсия в возврат в 4-6 раз выше, чем при массовых рассылках, а retention-бюджет расходуется только на тех, кому это действительно нужно. Наш опыт в ML-решениях — более 5 лет, мы реализовали 15+ проектов по удержанию клиентов в SaaS и e-commerce.

Как AI определяет риск оттока?

Модель на основе Gradient Boosting (n_estimators=200, learning_rate=0.05, max_depth=5) обучается на 6+ месяцах истории. Признаки: частота покупок, средний чек, количество обращений в поддержку, глубина использования функций, время с последнего визита. Для объяснения причин используем SHAP — это позволяет не только сказать «клиент уйдёт», но и понять почему: цена, функционал, качество сервиса или конкуренты. Gradient Boosting — популярный ансамблевый метод, устойчивый к выбросам.

import pandas as pd
import numpy as np
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.multioutput import MultiOutputClassifier
from anthropic import Anthropic
import shap

class ChurnRiskModel:
    def __init__(self):
        self.churn_model = GradientBoostingClassifier(
            n_estimators=200, learning_rate=0.05,
            max_depth=5, random_state=42
        )
        # Многоклассовая модель причин оттока
        self.reason_model = MultiOutputClassifier(
            GradientBoostingClassifier(n_estimators=100, random_state=42)
        )
        self.llm = Anthropic()
        self.explainer = None

    def fit(self, users_df: pd.DataFrame, labels: pd.Series,
             churn_reasons: pd.DataFrame = None):
        """
        users_df: поведенческие и транзакционные признаки
        labels: 1=churned, 0=retained
        churn_reasons: multi-label для причин (price, features, competitor, quality, support)
        """
        X = users_df.fillna(0)
        self.churn_model.fit(X, labels)
        self.explainer = shap.TreeExplainer(self.churn_model)
        self.feature_names = users_df.columns.tolist()

        if churn_reasons is not None:
            self.reason_model.fit(X, churn_reasons)

    def predict_churn_risk(self, user_features: dict) -> dict:
        """Риск оттока + причины + SHAP объяснение"""
        X = pd.DataFrame([user_features])[self.feature_names].fillna(0)
        churn_prob = self.churn_model.predict_proba(X)[0][1]

        # SHAP values для объяснения
        shap_values = self.explainer.shap_values(X)
        if isinstance(shap_values, list):
            shap_vals = shap_values[1][0]
        else:
            shap_vals = shap_values[0]

        # Топ факторы риска
        top_factors = sorted(
            zip(self.feature_names, shap_vals),
            key=lambda x: abs(x[1]), reverse=True
        )[:5]

        return {
            'churn_probability': float(churn_prob),
            'risk_level': 'high' if churn_prob > 0.7 else 'medium' if churn_prob > 0.35 else 'low',
            'top_risk_factors': [
                {'feature': name, 'impact': float(impact), 'direction': 'increase' if impact > 0 else 'decrease'}
                for name, impact in top_factors
            ]
        }


class RetentionOfferEngine:
    """Выбор оптимального предложения для удержания"""

    def __init__(self, churn_model: ChurnRiskModel):
        self.churn_model = churn_model
        self.llm = Anthropic()
        self.offers = {
            'discount_10': {'type': 'discount', 'value': 10, 'cost': 0.1, 'segment': 'price_sensitive'},
            'discount_20': {'type': 'discount', 'value': 20, 'cost': 0.2, 'segment': 'high_risk'},
            'feature_unlock': {'type': 'feature', 'duration_days': 30, 'cost': 0.05, 'segment': 'power_users'},
            'personal_manager': {'type': 'service', 'cost': 0.15, 'segment': 'enterprise'},
            'loyalty_bonus': {'type': 'points', 'value': 500, 'cost': 0.03, 'segment': 'loyal'},
            'winback_survey': {'type': 'survey', 'cost': 0.01, 'segment': 'churned'},
        }

    def select_offer(self, user: dict, churn_risk: dict) -> dict:
        """Персонализированный выбор предложения"""
        risk_factors = {f['feature']: f['impact'] for f in churn_risk['top_risk_factors']}

        # Определение причины риска
        if risk_factors.get('days_since_last_purchase', 0) > 0 and \
           risk_factors.get('avg_order_value', 0) < 0:
            # Снижение среднего чека = ценовая чувствительность
            offer_key = 'discount_10' if churn_risk['churn_probability'] < 0.6 else 'discount_20'

        elif risk_factors.get('support_tickets_last_30d', 0) > 0:
            # Проблемы с сервисом
            offer_key = 'personal_manager'

        elif risk_factors.get('feature_usage_depth', 0) < 0:
            # Не использует продукт
            offer_key = 'feature_unlock'

        elif user.get('total_orders', 0) > 20:
            # Лояльный клиент
            offer_key = 'loyalty_bonus'

        else:
            offer_key = 'discount_10'

        offer = self.offers[offer_key].copy()
        offer['offer_id'] = offer_key

        # Персонализированное сообщение
        offer['message'] = self._personalize_message(user, offer, churn_risk)

        return offer

    def _personalize_message(self, user: dict, offer: dict, risk: dict) -> str:
        risk_factors_str = ", ".join([
            f['feature'] for f in risk['top_risk_factors'][:3]
        ])

        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=100,
            messages=[{
                "role": "user",
                "content": f"""Write a personalized retention message (2 sentences max, warm tone).

User: {user.get('first_name', 'Customer')}, {user.get('tenure_months', 0)} months with us
Offer: {offer['type']} - {offer.get('value', '')}
Risk signals: {risk_factors_str}

Be specific, not generic. Don't mention risk/churn directly."""
            }]
        )
        return response.content[0].text

Почему персонализированные предложения эффективнее массовых?

Параметр Массовая рассылка Наше AI-решение
Конверсия 2-4% 12-18%
Расход бюджета на всех клиентов только на группу риска
Учет причины оттока нет да (SHAP + LLM)
Время отправки фиксированное оптимальное (за 7-14 дней до ухода)

Модель, обученная на 6 месяцах истории, предсказывает отток с AUC 0.82-0.88. Precision @30% threshold (высокий риск): 65-75%. Оптимальный момент для предложения — когда пользователь ещё активен, но уже демонстрирует признаки ухода. Наш опыт показывает, что экономия retention-бюджета достигает 30% без потери эффективности. Например, в одном проекте мы сократили расходы на retention на значительную часть бюджета, перенаправив его только на клиентов с высоким риском.

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

  • Аналитика: сбор и подготовка данных (минимум 6 месяцев истории, метки оттока и причины).
  • Проектирование: выбор архитектуры модели (Gradient Boosting + MultiOutput для причин), настройка пайплайна.
  • Разработка: реализация ChurnRiskModel и RetentionOfferEngine, интеграция с CRM через API.
  • Тестирование: A/B тест на 10% трафика, сравнение конверсии и LTV.
  • Деплой: развертывание на SageMaker или Kubernetes, мониторинг дрейфа данных.
  • Документация и обучение: передача модели, дашборда с SHAP-объяснениями, обучение команды.

Как интегрировать AI-систему с существующей CRM?

Интеграция происходит через REST API или прямое подключение к базе данных. Мы предоставляем Docker-образ с моделью, который разворачивается в вашей инфраструктуре. API принимает JSON с признаками пользователя и возвращает риск оттока и рекомендованный оффер. Для CRM на базе Salesforce, HubSpot или AmoCRM есть готовые коннекторы. Время интеграции — от 1 до 3 дней после поставки модели.

Как мы это делаем: реальный кейс

Для одного SaaS-продукта мы обучили модель на данных за 8 месяцев. Gradient Boosting с SHAP выявил, что 40% оттока связано с неиспользованием ключевой функции «автоотчеты». Мы сформировали персонализированное предложение: бесплатный месяц доступа к этой функции. Конверсия составила 22% — в 5 раз выше, чем предыдущая массовая скидка 15%. Суммарная экономия на retention-бюджете за квартал — существенная сумма.

Этапы внедрения

Этап Длительность Результат
Аналитика и сбор данных 1-2 недели Подготовленный датасет с признаками
Проектирование и прототип 1 неделя Архитектура модели и пайплайн
Разработка и обучение модели 2-3 недели Рабочая модель с метриками
Интеграция и тестирование 1-2 недели API-интеграция с CRM, A/B тест
Деплой и мониторинг 1 неделя Продуктивная среда, дашборд

Сроки и гарантии

Ориентировочные сроки — от 4 до 8 недель в зависимости от сложности интеграции. Мы гарантируем повышение конверсии retention-кампаний минимум в 3 раза по сравнению с массовыми рассылками. Свяжитесь с нами для консультации — мы подберем оптимальную архитектуру под ваш стек и данные. Закажите пилотный проект, чтобы убедиться в эффективности на ваших данных.

Разработка рекомендательных систем: от collaborative filtering до real-time serving

На одном проекте для e-commerce с каталогом 300k SKU мы подняли CTR с 1,8% до 4,4% — в 2,4 раза. Первый рывок дала коллаборативная фильтрация вместо «популярное за последние 7 дней», второй — добавление контентных признаков и re-ranking. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная. Ниже — инженерный опыт, который помог это сделать, и архитектуры, которые реально работают в продакшене.

Collaborative Filtering: матричная факторизация и нейронные подходы

Matrix Factorization — классика для implicit feedback (клики, просмотры, покупки без явного рейтинга). ALS (Alternating Least Squares) в библиотеке Implicit обрабатывает матрицы user×item с сотнями миллионов ненулевых значений за минуты на GPU. Latent factors 64–256, регуляризация λ=0.01–0.1 — стартовые параметры. Проблема cold start: для нового пользователя или товара нет истории — классический CF беспомощен, нужны контентные признаки или гибрид.

Neural Collaborative Filtering (NCF) заменяет скалярное произведение на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст, категория, время суток). Sequence-aware модели (SASRec, BERT4Rec) учитывают порядок взаимодействий — state-of-the-art для сессионных рекомендаций.

Как выбрать архитектуру рекомендательной системы?

Ответ зависит от данных, нагрузки и требований к холодному старту. Ниже — три основных подхода с критериями выбора.

Критерий Collaborative Filtering Content-Based Filtering Гибридный (two-stage)
Данные для старта История взаимодействий Признаки объектов и пользователей И то, и другое
Cold start Провальный Работает для новых items Частично решён
Diversity (long-tail) Низкий, popularity bias Высокий Средний–высокий
Latency serving <5 ms (precomputed) <10 ms (FAISS) 20–50 ms
Сложность внедрения Низкая Средняя Высокая

Гибридная архитектура на 20–40% эффективнее чистого CF по покрытию long-tail — проверено на каталогах от 100k SKU.

Content-Based Filtering: когда истории взаимодействий мало

Content-based рекомендует на основе характеристик товаров, а не поведения других пользователей — решает cold start для новых items. Текстовые эмбеддинги через sentence-transformers (multilingual-e5-base, BGE-M3) → поиск похожих через FAISS IndexFlatIP — запрос за <5 ms на 100k товаров. Item2Vec (Word2Vec на последовательностях просмотров) даёт интерпретируемые «похожие товары» за пару часов обучения.

Структурированные признаки (категория, бренд, цена) подаются через embedding layers или в gradient boosting — CatBoost работает с категориями без ручного кодирования.

Почему гибридные модели работают лучше?

Production-системы почти всегда двухуровневые. Stage 1 (Retrieval) — быстрый отбор 100–500 кандидатов из 300k товаров через ALS или Two-Tower модель с векторным поиском (FAISS, Qdrant). Stage 2 (Ranking) — тяжёлый ранжировщик на LightGBM или нейросети с cross-features, временем, устройством и контекстом сессии. LightFM — хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры. Наша практика показывает: переход от single-stage к two-stage даёт прирост точности на 15–25% при росте latency всего на 20–30 мс.

Real-Time Serving: архитектура под нагрузку

Latency SLA — 50–100 ms при тысячах запросов в секунду. Base-рекомендации precompute (batch job раз в час) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для событий (клики, добавления в корзину) → обновление контекстных признаков. Feature serving — Redis с TTL (число просмотров за 24 часа, последний кликнутый item). При нагрузке 10k req/s ставим Redis Cluster с репликацией.

A/B тестирование — единственный достоверный способ оценить улучшения. Офлайн-метрики коррелируют с онлайн не всегда. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обязательное чтение для команды. Тест с 5–10% трафика, мониторинг CTR, конверсии, revenue per session. Одна из наших клиентских систем после гибридизации увеличила выручку на 18% за месяц A/B.

Сроки разработки рекомендательной системы

Этапы и типичные временные затраты — в таблице ниже. Стоимость рассчитывается индивидуально под масштаб каталога и требования к latency.

Этап Длительность Результат
Аудит данных и baseline 1–2 недели Отчёт с плотностью матрицы, cold start‑зонами, метриками «популярного»
Прототип (offline validation) 2–3 недели Работающая модель с офлайн-метриками (Recall@k, NDCG)
Production-система (two-stage, A/B) 1.5–2.5 месяца Low-latency сервис с мониторингом и A/B-инфраструктурой
Обучение команды и документация 1–2 недели Model card, runbook по деплою, сессия по дообучению

Что входит в разработку под ключ

  1. Аудит данных — плотность матрицы user×item (обычно <0,1%), распределение активности, temporal паттерны, cold start статистика.
  2. Baseline — «популярное» как простой порог, который часто трудно обогнать.
  3. Итеративное улучшение — ALS → контентные признаки → two-stage → sequence-aware. Каждый шаг с A/B.
  4. Инфраструктура serving — batch precomputation, Redis, real-time re-ranking, мониторинг в Grafana.
  5. Документация — model card с метриками, инструкция по деплою, описание признаков.
  6. Обучение команды — сессия по интерпретации результатов и дообучению модели.
  7. Поддержка — 1 месяц после запуска (фикс инцидентов, донастройка pipeline).

Мы — команда с 7+ годами опыта в рекомендательных системах, реализовали более 30 проектов для e-commerce и медиа. Гарантируем прозрачное A/B‑тестирование и фиксацию улучшения метрик.

Хотите оценить потенциал роста вашего каталога? Свяжитесь с нами для бесплатного аудита данных. Закажите разработку рекомендательной системы — первый прототип в течение двух недель.

Пример конфига ALS для implicit feedback
from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Больше о математике рекомендательных систем — в Wikipedia.