Триггерные сценарии — механизм, который превращает клиентские данные в действия: событие в CDP порождает правило, правило порождает коммуникацию. В enterprise-контуре, где данные не покидают периметр, это единственный способ автоматизировать коммуникации без выноса профилей во внешний SaaS. Для компаний с базой от 50 тысяч клиентов триггерные сценарии — не опция, а базовая инфраструктура: без них данные в CDP остаются «мёртвым» активом. В этом гайде — архитектура триггерных сценариев внутри on-prem контура, типы триггеров, паттерн outbox для событийной модели, интеграция с каналами коммуникации и практические примеры для retail, банков и телекома. Подробнее о платформе — в разделе On-prem CDP для enterprise.
Что такое триггерные сценарии в CDP
Триггерный сценарий — это автоматическое правило вида «если произошло событие X для сегмента Y — выполнить действие Z». В контексте CDP триггерные сценарии работают поверх единого профиля клиента: платформа собирает события из всех источников, обогащает профиль и в реальном времени проверяет, попадает ли клиент под условия сценария.
В отличие от массовых рассылок, которые отправляются «всем из списка» по расписанию, триггерные коммуникации реагируют на конкретное действие конкретного клиента. Поэтому средний показатель open rate триггерных писем — 45-50%, тогда как у массовых рассылок — 15-20%. Причина проста: сообщение приходит в момент, когда клиент уже в контексте.
Для enterprise-компаний триггерные сценарии внутри контура решают две задачи одновременно. Во-первых, автоматизация коммуникаций без ручного вмешательства маркетолога. Во-вторых, данные не покидают периметр — правила исполняются на тех же серверах, где хранятся профили. Это критично для компаний, которые не могут использовать внешний SaaS из-за требований ИБ или 152-ФЗ.
Триггерный сценарий vs ручная кампания
| Параметр | Массовая кампания | Триггерный сценарий |
|---|---|---|
| Инициатор | Маркетолог вручную | Событие в системе |
| Аудитория | Статический список | Динамический сегмент |
| Момент отправки | Фиксированное расписание | В реальном времени (событие) |
| Open rate (среднее) | 15-20% | 45-50% |
| Масштабирование | Линейно от команды | Автоматическое |
| Контроль данных | Часто через внешний ESP | Внутри контура |
Триггерные сценарии — это мост между единым профилем клиента и реальной коммуникацией. Данные без действий — стоимость хранения. Действия без данных — спам. Триггерный сценарий соединяет одно с другим.
Архитектура триггерного пайплайна: событие — правило — действие
Триггерный пайплайн внутри on-prem CDP состоит из трёх компонентов, каждый из которых выполняет строго определённую функцию. Понимание этой архитектуры позволяет CTO и enterprise-архитектору оценить, насколько платформа готова к production-нагрузкам.
Компонент 1: сбор событий (Event Ingestion)
Клиентские события поступают из множества источников: веб-аналитика, мобильное приложение, POS-система, контакт-центр, биллинг. Каждое событие содержит три обязательных атрибута: идентификатор клиента, тип события, временная метка. Дополнительно — payload с параметрами (сумма покупки, ID товара, канал обращения).
В lean-архитектуре события записываются напрямую в PostgreSQL — через REST API или пакетный импорт. При высоких нагрузках (свыше 1000 событий в секунду) подключается NATS как событийная шина. Однако для 80% enterprise-инсталляций PostgreSQL с правильной схемой партиционирования достаточно.
Компонент 2: Rules Engine (движок правил)
Rules engine — ядро триггерной логики. Компонент непрерывно мониторит поток событий и сопоставляет каждое событие с набором активных правил. Правило определяет:
- Триггер — какое событие запускает сценарий (покупка, вход на сайт, отсутствие активности N дней)
- Условие — фильтр по атрибутам профиля и сегменту (VIP-клиент, регион Москва, LTV > 50 000 ₽)
- Задержка — пауза перед действием (немедленно, через 30 минут, через 24 часа)
- Действие — конкретная операция (отправить email, создать задачу, вызвать webhook)
- Ограничения — frequency cap (не более 1 сообщения в сутки), канал, тихие часы
В монолитной Go-архитектуре Rules Engine работает как горутина внутри основного бинаря. Это устраняет сетевые задержки между компонентами и упрощает деплой — один процесс вместо россыпи микросервисов.
Компонент 3: Action Executor (исполнитель действий)
После срабатывания правила Action Executor формирует конкретное действие. Для email — рендерит шаблон с подстановкой данных из профиля. Для webhook — формирует JSON-payload и отправляет HTTP-запрос. Для внутренней задачи — создаёт запись в системе задач с привязкой к клиенту.
Критически важно: Action Executor работает асинхронно. Сбой отправки email не блокирует обработку следующего события. Каждое действие записывается в лог с результатом (отправлено, ошибка, повтор) — таким образом, аудит-трейл покрывает не только действия пользователей, но и все автоматические коммуникации.
Схема потока данных
| Этап | Компонент | Вход | Выход |
|---|---|---|---|
| 1. Приём | Event Ingestion | HTTP / batch / webhook | Событие в БД + обновление профиля |
| 2. Оценка | Rules Engine | Событие + профиль + правила | Список действий к исполнению |
| 3. Исполнение | Action Executor | Действие + шаблон + данные профиля | Email / SMS / webhook / задача |
| 4. Логирование | Audit Log | Результат действия | Запись в audit trail |
Типы триггеров: поведенческие, временные, lifecycle
Триггерные сценарии классифицируются по типу инициирующего события. Каждый тип решает свою задачу, и при проектировании сценариев важно понимать, какие триггеры применимы на каком этапе жизненного цикла клиента.
Поведенческие триггеры (Behavioral)
Реагируют на конкретное действие клиента в реальном времени. Это самый распространённый тип — по статистике, 60-70% триггерных сценариев в enterprise-инсталляциях относятся именно к поведенческим.
| Событие | Сценарий | Задержка | Канал |
|---|---|---|---|
| Брошенная корзина | Напоминание о незавершённом заказе | 30-60 мин | Email / push |
| Просмотр товара 3+ раза | Персональная скидка на товар | 2-4 часа | Email / SMS |
| Первая покупка | Welcome-серия из 3 писем | Немедленно | |
| Обращение в контакт-центр | NPS-опрос после закрытия тикета | 24 часа | SMS / email |
| Повторная покупка | Благодарность + бонус на следующую | Немедленно | Push / email |
Поведенческие триггеры требуют минимальной задержки между событием и реакцией. В lean on-prem архитектуре латентность составляет 100-500 мс от момента записи события до срабатывания правила — вся обработка происходит в одном процессе без сетевых хопов.
Временные триггеры (Time-Based)
Срабатывают по расписанию или после истечения определённого периода. Используются для реактивации, напоминаний и периодических коммуникаций.
- Отсутствие активности N дней — реактивация через 30, 60, 90 дней неактивности
- Дата в профиле — день рождения клиента, годовщина первой покупки, окончание подписки
- Периодические — ежемесячный дайджест для VIP-сегмента, еженедельный отчёт по расходам
- Расписание кампании — отправка в 10:00 по часовому поясу клиента
Временные триггеры реализуются через планировщик внутри бэкенда. Каждую минуту scheduler проверяет: есть ли клиенты, для которых наступило время срабатывания. Поэтому гранулярность — 1 минута, что достаточно для 99% enterprise-сценариев.
Lifecycle-триггеры (жизненный цикл клиента)
Реагируют на переход клиента между стадиями жизненного цикла. В отличие от поведенческих, которые привязаны к одному событию, lifecycle-триггеры оценивают совокупность атрибутов и действий.
- Переход из сегмента «Потенциальный» в «Новый» — welcome-серия, онбординг
- Переход из «Активный» в «Спящий» — реактивационная цепочка
- Рост LTV выше порога — перевод в VIP-программу
- Снижение частоты покупок — предупреждение менеджеру, спец. оффер
- Churn-предиктор — автоматическая скидка или персональный звонок
Lifecycle-триггеры — самые ценные для бизнеса, поскольку они работают проактивно. Вместо реакции на событие (клиент ушёл) они реагируют на тренд (клиент начинает уходить). Для этого Rules Engine должен уметь вычислять производные метрики: частоту покупок за последние 90 дней, тренд среднего чека, количество дней без активности.
Сравнение типов триггеров
| Характеристика | Поведенческий | Временной | Lifecycle |
|---|---|---|---|
| Инициатор | Событие клиента | Таймер / расписание | Смена сегмента / метрики |
| Латентность | Секунды | Минуты | Минуты — часы |
| Сложность логики | Простая (1 событие) | Простая (дата) | Высокая (совокупность) |
| Доля в production | 60-70% | 15-20% | 10-15% |
| Бизнес-ценность | Высокая (конверсия) | Средняя (вовлечение) | Максимальная (retention) |
Outbox pattern: событийная модель без Kafka
Enterprise-архитекторы часто спрашивают: «Как обеспечить гарантированную доставку триггерных коммуникаций без Kafka?» Вопрос обоснованный — потеря события означает потерю коммуникации, а потеря коммуникации означает потерю дохода. Однако Kafka в on-prem контуре создаёт архитектурную нагрузку: минимум 3 брокера, ZooKeeper (или KRaft), мониторинг, отдельная команда эксплуатации.
Outbox pattern решает задачу гарантированной доставки без дополнительной инфраструктуры. Принцип: событие и команда на действие записываются в одну транзакцию в PostgreSQL. Фоновый worker читает таблицу outbox и исполняет действия. После успешного исполнения — помечает запись как обработанную.
Как работает outbox в триггерном пайплайне
- Транзакция: клиентское событие записывается в таблицу events, профиль обновляется, Rules Engine вычисляет действие и записывает его в таблицу outbox — всё в одной PostgreSQL-транзакции
- Гарантия: если транзакция прошла — действие гарантированно окажется в outbox. Если упала — ни событие, ни действие не записаны. Нет промежуточного состояния
- Worker: фоновый процесс (горутина в Go) каждые 100-500 мс опрашивает outbox, забирает необработанные записи и исполняет действия
- Retry: при ошибке отправки (email-провайдер недоступен) запись остаётся в outbox с инкрементом retry_count и экспоненциальной задержкой
- Dead letter: после N неудачных попыток (по умолчанию — 5) запись перемещается в dead_letter_queue для ручного разбора
Outbox vs Kafka: архитектурное сравнение
| Критерий | Outbox (PostgreSQL) | Kafka |
|---|---|---|
| Инфраструктура | 0 дополнительных узлов | 3-5 узлов (брокеры + ZooKeeper) |
| Гарантия доставки | At-least-once (транзакционная) | At-least-once (настраиваемая) |
| Пропускная способность | До 5 000 событий/сек | До 100 000+ событий/сек |
| Латентность | 100-500 мс | 10-50 мс |
| Сложность эксплуатации | Нулевая (PostgreSQL уже есть) | Высокая (отдельная компетенция) |
| Порог целесообразности | До 700 тыс. профилей | Свыше 1 млн профилей |
Для 80% enterprise-инсталляций с базой до 700 тысяч клиентов outbox pattern закрывает требования к гарантированной доставке. При этом переход на NATS или Kafka — модульный: достаточно заменить transport layer, не переписывая бизнес-логику Rules Engine. Подробнее об архитектуре — в разделе Внедрение и развёртывание CDP.
Интеграция с каналами коммуникации
On-prem CDP — не конечный канал, а orchestrator. Платформа решает, кому и когда отправить, но не владеет каналом доставки. Интеграция с downstream-каналами строится через три механизма: встроенные коннекторы, webhook engine и API-вызовы.
Поддерживаемые каналы
| Канал | Механизм интеграции | Данные из CDP | Типичная задержка |
|---|---|---|---|
| SMTP / API email-провайдера | Имя, сегмент, история покупок, персональный оффер | 1-5 сек | |
| SMS | API SMS-шлюза | Телефон, шаблон, переменные из профиля | 3-10 сек |
| Push-уведомления | Firebase / HMS / собственный push-сервер | Device token, заголовок, тело, deeplink | 1-3 сек |
| Webhook | HTTP POST на произвольный URL | JSON-payload с данными профиля и события | 100-500 мс |
| Внутренняя задача | Создание записи в системе задач CDP | Клиент, тип задачи, приоритет, ответственный | Мгновенно |
| Мессенджеры | API Telegram / WhatsApp Business | Chat ID, шаблон, переменные | 1-5 сек |
Webhook engine как универсальный интеграционный слой
Webhook engine — ключевой механизм расширения. Вместо того чтобы строить коннектор к каждой внешней системе, CDP отправляет HTTP POST с JSON-payload на URL, который укажет администратор. Это позволяет интегрироваться с любой системой, принимающей HTTP-запросы: внутренней CRM, системой лояльности, корпоративным порталом, самописным сервисом рассылок.
Каждый webhook-вызов логируется: URL, payload (с маскированием PII), HTTP-статус ответа, время ответа. Тем самым инженеры ИБ могут аудировать все исходящие интеграции без дополнительных инструментов.
Принцип канальной нейтральности
Триггерный сценарий не привязан к конкретному каналу. Правило определяет «что отправить» и «кому», а канал выбирается на этапе исполнения — на основе предпочтений клиента, доступности канала и приоритетов. Например, если клиент отписался от email — Action Executor переключается на push. Если push-токен отсутствует — создаёт внутреннюю задачу для менеджера.
Канальная нейтральность означает, что при подключении нового канала (например, мессенджера) не нужно менять существующие сценарии — достаточно добавить канал в приоритеты исполнения.
Триггерные сценарии по отраслям: retail, банки, телеком
Триггерные сценарии отличаются от отрасли к отрасли — по типу событий, каналам доставки и регуляторным ограничениям. Ниже — конкретные примеры, которые реализуются внутри on-prem CDP без выноса данных.
Retail и e-commerce
В ритейле триггерные сценарии приносят измеримый результат: по данным отраслевых исследований, брошенная корзина с триггерным напоминанием конвертируется в покупку в 8-12% случаев. Для сети с 200 тысячами активных клиентов это может означать дополнительные 5-15 млн рублей ежемесячной выручки.
| Сценарий | Триггер | Условие | Действие | Метрика |
|---|---|---|---|---|
| Брошенная корзина | Добавление в корзину без покупки | Прошло 45 мин, сумма > 1 000 ₽ | Email + push через 2 часа | Conversion rate: 8-12% |
| Повторная покупка | Покупка в категории | Расходный товар, средний цикл 30 дней | Напоминание на 25-й день | Repeat purchase rate: +15% |
| Реактивация | Отсутствие покупок 60 дней | LTV > 5 000 ₽, был активен ранее | Персональный промокод 10% | Win-back rate: 5-8% |
| Welcome-серия | Первая покупка | Новый клиент | 3 письма за 7 дней: бренд → ассортимент → бонус | 2nd purchase rate: +25% |
| VIP-апгрейд | LTV пересекает порог | Накопленный чек > 50 000 ₽ | Уведомление + бонус + задача менеджеру | VIP retention: 92% |
Банки и финсервисы
В финансовом секторе триггерные коммуникации ограничены регуляторикой. Каждое сообщение клиенту проходит через consent check — согласие на конкретный канал и тип коммуникации. Однако в рамках согласия триггерные сценарии повышают кросс-продажи на 20-30%.
- Одобрение кредитного лимита — триггер: скоринг завершён, результат «одобрен». Действие: SMS + push с предложением, задача менеджеру
- Аномальная транзакция — триггер: сумма превышает 3 стандартных отклонения от среднего. Действие: push-уведомление клиенту, алерт в антифрод-систему
- Окончание вклада — триггер: 14 дней до истечения срока. Действие: персональное предложение пролонгации с индивидуальной ставкой
- Онбординг нового клиента — триггер: открытие счёта. Действие: серия из 5 сообщений за 30 дней (активация мобильного банка, подключение автоплатежей, настройка уведомлений)
Для банков критично, что триггерный пайплайн работает внутри контура — без передачи данных о транзакциях во внешний SaaS. При этом аудит-трейл покрывает каждое автоматическое сообщение.
Телеком
Телеком-операторы с абонентской базой от 500 тысяч до нескольких миллионов — классический пример, где триггерные сценарии работают в масштабе.
- Снижение потребления — триггер: ARPU абонента упал на 20% за последние 3 месяца. Действие: предложение перехода на подходящий тариф
- Churn-предупреждение — триггер: абонент звонил в контакт-центр с жалобой + снизил потребление. Действие: удержание — промо-пакет или персональный звонок
- Upsell дополнительных услуг — триггер: абонент исчерпал 80% трафика. Действие: push с предложением пакета дополнительных ГБ
- Welcome для нового абонента — триггер: активация SIM. Действие: серия сообщений: подключение приложения, настройка автооплаты, бонус за рекомендацию
В телекоме нагрузка на триггерный пайплайн может достигать 2000-5000 событий в секунду. Для таких объёмов outbox pattern масштабируется через партиционирование таблицы outbox по дате и подключение NATS как промежуточного транспорта.
Как проектировать триггерную логику
Самая частая ошибка — начинать с каналов. «Нам нужны триггерные email-рассылки» — неправильная постановка задачи. Правильная: «Какие клиентские события влияют на retention, и как на них реагировать?»
Методология проектирования (5 шагов)
- Инвентаризация событий. Составить полный список клиентских событий, доступных в CDP: покупки, визиты, обращения, платежи, смена атрибутов. Для enterprise-инсталляции типично 15-40 типов событий
- Маппинг на бизнес-метрики. Для каждого события определить: какую бизнес-метрику оно влияет? Покупка — LTV. Обращение в поддержку — CSAT. Отсутствие активности — churn rate. Без этой привязки сценарии превращаются в спам
- Определение сегментов. Триггерный сценарий без сегментации — массовая рассылка. Каждое правило должно содержать условие по сегменту: VIP / новый / спящий, регион, LTV, продуктовый портфель
- Проектирование цепочек. Одиночный триггер — редко эффективен. Цепочка из 3-5 шагов с разными задержками и эскалацией даёт на 40-60% лучший результат. Например: push через 1 час → email через 24 часа → задача менеджеру через 72 часа
- Определение frequency cap. Максимальное количество коммуникаций клиенту за период. Рекомендация: не более 3 триггерных сообщений в неделю, не более 1 в сутки по одному каналу
Чек-лист правила перед запуском
| Проверка | Вопрос | Красный флаг |
|---|---|---|
| Размер аудитории | Сколько клиентов попадут под правило? | > 50% базы (это уже массовая рассылка) |
| Частота срабатывания | Сколько раз в день сработает? | > 10 000/день без frequency cap |
| Канал согласия | Есть ли consent клиента на этот канал? | Нет проверки consent перед отправкой |
| Бизнес-метрика | Какую метрику улучшает сценарий? | «Просто хотим напомнить о себе» |
| Exit condition | Когда сценарий прекращается? | Нет условия остановки (бесконечный цикл) |
| Тестирование | Протестировано на контрольной группе? | Запуск на всю базу без A/B теста |
Когда триггерные сценарии не подходят
Не каждая коммуникация должна быть триггерной. Есть ситуации, когда ручная кампания эффективнее:
- Сезонные акции — массовая коммуникация по фиксированной дате (Чёрная пятница, Новый год). Триггер не нужен — нужен scheduler с точным временем
- Кризисные уведомления — изменение условий обслуживания, смена тарифа. Отправляются всем, без фильтрации по сегменту
- Имиджевые кампании — рассылки без привязки к событию клиента. Низкий отклик, но нужны для brand awareness
Мы рекомендуем начинать с 5-7 триггерных сценариев и расширять по мере накопления данных об эффективности, а не запускать 30 сценариев одновременно. Причина: каждый сценарий требует мониторинга, A/B тестирования и периодической ревизии — на это нужны ресурсы команды.
Типичные ошибки и ограничения
Enterprise-инсталляция триггерных сценариев — это не только архитектура, но и операционная дисциплина. Ниже — ошибки, которые мы наблюдаем в production-контурах, и рекомендации по их предотвращению.
Ошибка 1: триггерный шторм
Если правило не содержит frequency cap — одно событие может породить десятки коммуникаций. Клиент просматривает 15 товаров за сессию → 15 триггеров «просмотр товара» → 15 писем. Решение: frequency cap на уровне клиента (не более 1 сообщения в час по одному каналу) и дедупликация по event_type + customer_id за окно.
Ошибка 2: отсутствие exit condition
Реактивационная цепочка без условия остановки продолжает отправлять сообщения клиенту, который уже вернулся. Решение: каждый сценарий должен содержать exit condition — событие, после которого клиент выходит из цепочки. Для реактивации — это любая покупка или визит.
Ошибка 3: игнорирование тихих часов
Push-уведомление в 3:00 ночи — гарантированная отписка. Даже если триггер сработал в 2:47 — Action Executor должен отложить исполнение до 9:00 утра по часовому поясу клиента. Тихие часы (22:00-09:00) — обязательный параметр для push и SMS.
Ошибка 4: тестирование на production-базе
Новый сценарий, запущенный сразу на всю базу, может отправить 100 тысяч нерелевантных сообщений за час. Рекомендация: первый запуск — на контрольной группе (1-5% базы). Мониторинг 48 часов. Анализ метрик. Масштабирование на полную базу.
Архитектурные ограничения lean-контура
Outbox pattern на PostgreSQL — не бесконечно масштабируемое решение. При нагрузке свыше 5000 событий в секунду на одном узле рекомендуется переход на NATS. При этом стоит учитывать, что 5000 событий/сек — это уровень крупного ритейла с базой 500-700 тысяч активных клиентов. Для 90% enterprise-инсталляций в Москве этого порога достаточно.
FAQ о триггерных сценариях
Сколько стоит запуск триггерных сценариев внутри on-prem контура в Москве?
Триггерные сценарии входят в базовую функциональность платформы. Для профиля Minimum (1 узел, до 150 тыс. клиентов) — совокупный старт от 2,1 млн рублей (лицензия + внедрение) плюс от 60 тыс. рублей ежемесячно за сопровождение. Настройка первых 5-7 сценариев входит в этап внедрения. Дополнительная плата за количество сценариев или объём коммуникаций отсутствует — стоимость не зависит от MAU.
Сколько триггерных сценариев можно запустить одновременно?
Архитектурного ограничения на количество активных правил нет. В production-инсталляциях работают от 10 до 200 одновременных сценариев. Ограничивающий фактор — не платформа, а операционная ёмкость команды: каждый сценарий требует мониторинга, A/B тестирования и ревизии. Рекомендуем начинать с 5-7 и наращивать по мере накопления данных об эффективности.
Какие каналы поддерживают триггерные коммуникации?
Из коробки — email (SMTP), SMS (через API шлюза), push-уведомления (Firebase, HMS), webhook на произвольный URL и внутренние задачи. Webhook engine позволяет подключить любой канал, принимающий HTTP-запросы: Telegram, WhatsApp Business, корпоративный мессенджер, систему лояльности. Подключение нового канала — конфигурация, а не доработка кода.
Нужна ли Kafka для триггерных сценариев в on-prem CDP?
Для базы до 700 тысяч клиентов — нет. Outbox pattern на PostgreSQL обеспечивает гарантированную доставку с пропускной способностью до 5000 событий в секунду. Kafka целесообразна при базе свыше 1 млн профилей или при нагрузке свыше 10 000 событий/сек. Архитектура модульная — переход на NATS или Kafka не требует переписывания сценариев.
Как on-prem триггерные сценарии обеспечивают соответствие 152-ФЗ?
Все данные — профили, события, правила, история коммуникаций — хранятся на серверах заказчика на территории РФ. Триггерный пайплайн работает внутри контура, персональные данные не передаются во внешние системы. Каждая коммуникация фиксируется в аудит-логе с привязкой к клиенту, каналу и времени. Consent check — обязательный шаг перед отправкой.
Какова типичная задержка от события до отправки триггерной коммуникации?
Для поведенческих триггеров — от 100 мс до 5 секунд от момента записи события до передачи в канал доставки. Далее зависит от канала: email — 1-5 сек, push — 1-3 сек, SMS — 3-10 сек. Итого от события до получения клиентом — в среднем 5-15 секунд. Для временных триггеров гранулярность планировщика — 1 минута.
Можно ли запустить триггерные сценарии на этапе пилота?
Да. На профиле Minimum (1 узел) триггерные сценарии работают в полном объёме. Типичный пилот: импорт 10-30 тысяч профилей, настройка 3-5 базовых сценариев (welcome, брошенная корзина, реактивация), запуск на контрольной группе. Срок пилота — 2-4 недели. При подтверждении результатов — масштабирование на полную базу.
Запустите триггерные сценарии внутри вашего контура
Триггерные коммуникации — ключевой механизм, который превращает клиентские данные в измеримый бизнес-результат. Если ваша команда рассматривает on-prem CDP и хочет оценить, какие триггерные сценарии принесут максимальный эффект именно для вашей отрасли и базы — запросите архитектурную консультацию. Разберём ваши текущие сценарии, спроектируем первые 5-7 правил и покажем работу пайплайна на демо-стенде с реальными данными.