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.