Розробка системи Next Best Action: як підвищити ROAS у 4–8 разів

Як Next Best Action змінює маркетинг?

Ви запускаєте email-кампанію, дивитеся в дашборд — а конверсія падає, відтік зростає. Класичні rule-based сегменти вже не працюють: клієнти втомилися від спаму, а бюджет тане на неефективних дотиках. Ми будуємо AI-систему Next Best Action (NBA), яка вирішує, що робити з кожним клієнтом прямо зараз — надіслати код на знижку, підключити менеджера або не робити нічого. Спираємося на Reinforcement Learning і бізнес-обмеження в реальному часі.

У результаті A/B-тестування ми фіксуємо зростання LTV на 20–40% і зниження churn на 20–30%. В одному з проектів економія виявилася значною за рахунок скорочення неефективних комунікацій. ML-модель дій навчається на історичних даних для персоналізації комунікацій та оптимізації маркетингу. Система видає real-time recommendation для кожного клієнта.

Проблеми, які вирішує NBA

Надмірна комунікація. Без NBA ви бомбардуєте всіх однаковими листами. Клієнт, який щойно купив, отримує пропозицію знижки — роздратування, churn. Ми впроваджуємо penalty за частоту: після 2 дотиків за 7 днів ймовірність дії знижується в 0.4 рази.

Неправильний канал. Push-сповіщення дешеві, але для B2B-клієнта вони марні — потрібен дзвінок менеджера. А для мас-маркету дзвінок у 50 рублів нерентабельний. NBA ранжує дії за очікуваним ROI, враховуючи вартість каналу.

Статика. Правила "якщо LTV > 1000 — зателефонувати" застарівають через місяць. NBA донавчається на свіжих даних — reward функції прив'язані до реальної виручки.

Як ми будуємо NBA: контекстуальний бандит з RL

Ядро — контекстуальний бандит. Для кожної дії навчається окрема модель LogisticRegression, яка передбачає ймовірність високого reward (LTV delta) при даному контексті. Кілька дій можуть бути кандидатами, вибирається та, що дає макс. очікуваний ROI.

import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler
import pandas as pd

class NextBestActionEngine:
    """Контекстуальний бандит для вибору наступної дії"""

    def __init__(self):
        self.actions = {
            'email_discount': {'cost': 10, 'type': 'outbound'},
            'push_notification': {'cost': 1, 'type': 'outbound'},
            'call_outbound': {'cost': 50, 'type': 'outbound'},
            'show_banner': {'cost': 0.5, 'type': 'inbound'},
            'offer_upgrade': {'cost': 0, 'type': 'inbound'},
            'no_action': {'cost': 0, 'type': 'none'}
        }
        self.action_models = {}  # Окрема модель для кожної дії
        self.scaler = StandardScaler()

    def train(self, history: pd.DataFrame):
        """
        history: user_id, context_features..., action_taken, reward (LTV delta)
        """
        X = self.scaler.fit_transform(
            history.drop(columns=['user_id', 'action_taken', 'reward']).fillna(0)
        )

        for action in self.actions:
            mask = history['action_taken'] == action
            if mask.sum() < 50:
                continue

            # Модель: при якому контексті дія приносить високий reward
            action_rewards = history.loc[mask, 'reward']
            y = (action_rewards > action_rewards.median()).astype(int)

            model = LogisticRegression(C=1.0, max_iter=200)
            model.fit(X[mask], y)
            self.action_models[action] = model

    def recommend_action(self, user: dict,
                          business_constraints: dict = None) -> dict:
        """Вибір оптимальної дії"""
        context_features = self._extract_context(user)
        X = self.scaler.transform([context_features])

        action_scores = {}

        for action, meta in self.actions.items():
            # Застосовуємо бізнес-обмеження
            if business_constraints:
                if meta['cost'] > business_constraints.get('max_action_cost', 1000):
                    continue
                if (action in business_constraints.get('blocked_actions', [])):
                    continue

            # Передбачення винагороди
            if action in self.action_models:
                reward_prob = self.action_models[action].predict_proba(X)[0][1]
            else:
                reward_prob = 0.3  # Prior для ненавчених дій

            # Очікуваний ROI = очікувана виручка - вартість
            expected_revenue = reward_prob * user.get('expected_clv', 100)
            expected_roi = expected_revenue - meta['cost']

            # Врахування втоми від комунікацій
            if meta['type'] == 'outbound':
                communications_7d = user.get('communications_7d', 0)
                fatigue_penalty = max(0, 1 - 0.3 * communications_7d)
                expected_roi *= fatigue_penalty

            action_scores[action] = {
                'expected_roi': expected_roi,
                'reward_probability': reward_prob,
                'cost': meta['cost']
            }

        # Вибір дії з максимальним ROI
        best_action = max(action_scores, key=lambda x: action_scores[x]['expected_roi'])

        return {
            'recommended_action': best_action,
            'expected_roi': action_scores[best_action]['expected_roi'],
            'reward_probability': action_scores[best_action]['reward_probability'],
            'all_scores': action_scores
        }

    def _extract_context(self, user: dict) -> list:
        return [
            user.get('days_since_last_purchase', 30),
            user.get('total_orders', 0),
            user.get('ltv', 0),
            user.get('churn_probability', 0.5),
            user.get('email_open_rate', 0.2),
            user.get('age_months', 12),
            user.get('avg_order_value', 100),
            user.get('support_tickets_30d', 0),
            user.get('website_visits_7d', 0),
            user.get('communications_7d', 0)
        ]

Як оркеструвати NBA в реальному часі?

NBA ефективна тільки коли реагує миттєво. Клієнт залишив кошик — через 5 хвилин йому приходить push з персональною пропозицією. Для цього ми будуємо подієвий пайплайн: Kafka ловить події (перегляд, кошик, тікет), збагачує профіль, викликає recommend_action і відправляє команду у виконавець.

class NBAOrchestrator:
    """Real-time оркестрація дій"""

    def __init__(self, nba_engine: NextBestActionEngine):
        self.engine = nba_engine
        self.action_executors = {}

    def process_customer_event(self, event_type: str,
                                user: dict) -> dict:
        """Тригерна обробка подій"""
        # Контекст події впливає на NBA
        event_modifiers = {
            'cart_abandoned': {'churn_probability': +0.2, 'urgency': 'high'},
            'product_viewed_3x': {'intent_score': 0.8},
            'price_page_viewed': {'price_sensitivity': +0.3},
            'support_ticket_opened': {'satisfaction': -0.5}
        }

        enriched_user = {**user}
        if event_type in event_modifiers:
            for key, delta in event_modifiers[event_type].items():
                if isinstance(delta, (int, float)):
                    enriched_user[key] = enriched_user.get(key, 0) + delta
                else:
                    enriched_user[key] = delta

        # Обмеження на основі події
        constraints = {}
        if event_type == 'cart_abandoned':
            constraints['allowed_actions'] = ['email_discount', 'push_notification', 'show_banner']

        decision = self.engine.recommend_action(enriched_user, constraints)

        # Логування для навчання
        self._log_decision(user['user_id'], event_type, decision)

        return decision

    def _log_decision(self, user_id: str, event: str, decision: dict):
        """Запис рішення для offline навчання"""
        import json
        import datetime
        log_entry = {
            'timestamp': datetime.datetime.now().isoformat(),
            'user_id': user_id,
            'trigger_event': event,
            'action_taken': decision['recommended_action'],
            'expected_roi': decision['expected_roi']
        }
        # У реальності: запис у Kafka/DB
        print(f"NBA: {json.dumps(log_entry)}")

Чому NBA на RL краща за правила?

Різниця — у три рази по ROAS. І ключовий інсайт: для 30-40% клієнтів найкраща дія — нічого. Це не помилка; це економія бюджету та зниження churn.

Як NBA підвищує ROAS у 4-8 разів?

Система навчається на історичних даних, виявляючи патерни: при якому контексті яка дія приносить максимальний ROI. Reward функція штрафує за надмірні комунікації та заохочує дії, що ведуть до покупки. A/B-тести показують стабільний приріст ROAS відносно правил.

Типові помилки при впровадженні NBA

• Ігнорування cost per action — призводить до вибору дорогих каналів без огляду на бюджет.
• Відсутність сигналу "нічого не робити" — модель буде спамити завжди, збільшуючи churn.
• Недостатній обсяг історії для навчання — <100k записів дають високу variance.

Терміни впровадження

Базовий MVP з 5-6 діями та контекстуальним бандитом — від 4 до 8 тижнів. Повноцінна система з RL та оркестрацією на подіях — 10–16 тижнів. Вартість розраховується індивідуально під ваш обсяг даних та кількість каналів.

Що входить в роботу (deliverables)

• Аудит поточних маркетингових даних та каналів.
• Проектування моделі дій (до 10 дій).
• Навчання контекстуального бандита на історичних даних.
• Розробка оркестратора подій (Kafka/PubSub).
• Інтеграція з CRM, ESP, push-сервісами.
• A/B-тестування vs rule-based сегментів.
• Документація та навчання команди.
• Гарантія якості: пробний запуск на 1 місяць з моніторингом метрик.

Ми володіємо багаторічним досвідом розробки AI-рішень для маркетингу. Наші інженери — автори open-source бібліотек з RL. Надаємо гарантію на коректність моделей протягом 3 місяців після запуску.

Отримайте консультацію прямо зараз. Зв'яжіться з нами для безкоштовного аудиту ваших даних. Замовте розробку NBA під ключ і отримайте перші результати через 4 тижні.

Розробка рекомендаційних систем: від 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 для сесійних рекомендацій.

Як вибрати архітектуру рекомендаційної системи?

Відповідь залежить від даних, навантаження та вимог до холодного старту. Нижче — три основні підходи з критеріями вибору.

Гібридна архітектура на 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.

Що входить у розробку під ключ

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-тестування та фіксацію покращення метрик.

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

from implicit.als import AlternatingLeastSquares

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

Більше про математику рекомендаційних систем — у Wikipedia.