Use MongoDB Atlas Stream Processing y IA para prevenir la rotación de clientes. Detectar las dudas del cliente en tiempo real y activar la siguiente mejor acción.
caso de uso: Inteligencia Artificial, Personalización
Industrias: Comercio minorista
Productos: MongoDB Voyage IA, MongoDB Atlas, MongoDB Atlas Stream Processing, MongoDB Vector Search
emparejar: Amazon Bedrock
Descripción general de la solución
La retención de clientes se refiere a la capacidad de una organización para mantener a los clientes comprando sus productos y evitar que se cambien a otros proveedores. Mejorar la retención para impulsar el éxito a largo plazo en la venta minorista. Aumentar la retención en 5% puede aumentar las ganancias en un 25% a un 95%. Retener a los clientes cuesta mucho menos que conseguir nuevos clientes. Las plataformas de comercio modernas generan grandes volúmenes de datos de comportamiento. Los clientes crean estos datos a través de búsquedas, vistas de productos, acciones en el carrito y actividades de navegación.
La mayoría de los minoristas almacenan estos datos en Sistemas de Registro y los analizan posteriormente a través de pipelines por lotes. Por eso, sólo reaccionan después de que termina la sesión. Horas después, ellas:
Envía emails de carritos abandonados.
Comenzá campañas de retargeting.
Revisar tableros.
Para entonces, el cliente ya se ha ido y se pierde la oportunidad de influir en la compra. Responder mientras el cliente esté aún activo. Pase de un Sistema de registro a un Sistema de acción. Detecta señales de comportamiento durante la sesión y React en tiempo real.
Figura 1. Procesamiento por lotes vs. Stream Processing: datos almacenados analizados posteriormente frente a eventos analizados en tiempo real.
Utiliza MongoDB Atlas y Atlas Stream Processing para crear pipelines de comportamiento en tiempo real. Estas pipelines procesan eventos de clickstream a medida que ocurren y convierten eventos sin procesar en contexto procesable. Con estas herramientas, puedes:
Crea una memoria de sesión en vivo que capture el contexto de comportamiento actual.
Detect tiny behavioral signals from near en tiempo real interaction patterns.
Activar Agente Siguientes Mejores Acciones (NBA) que guían al cliente hacia la conversión.
React a las señales de comportamiento a través de MongoDB Change Streams.
Combina la memoria de la sesión, los datos de los clientes y las políticas empresariales en una capa de datos inteligentes unificada de MongoDB.
Al utilizar Atlas Stream Processing, con el conocido MongoDB Query API (MQL) y el Aggregation Framework en la misma plataforma, evitas la rigidez del procesamiento de flujo basado en SQL. Al utilizar el flexible modelo orientado a documentos de MongoDB, puedes representar el contexto de sesión en evolución. Un documento de sesión único captura el comportamiento histórico y la última snapshot de actividad, lo que permite un análisis del comportamiento casi en tiempo real.
Simplifica tu arquitectura al procesar flujos directamente en MongoDB, en lugar de gestionar una infraestructura de transmisión por secuencias independiente, y entrega aplicaciones impulsadas por eventos más rápido.
Figura 2. Consiga estos tres principios básicos con Atlas Stream Processing
Se pueden detectar patrones de comportamiento en tiempo real para mejorar la retención de clientes, tales como:
Intención de compra
Fricción de búsqueda
Riesgo de abandono
Responde inmediatamente cuando aparezcan estas señales. Activar acciones dirigidas como:
Recomendaciones de productos personalizadas
Notificaciones contextuales de prueba social
Ofertas relacionadas con el envío
Figura 3. Desencadena las siguientes mejores acciones en tiempo real basadas en el comportamiento en vivo del usuario que aumenten la probabilidad de conversión.
Actúa mientras la sesión del cliente esté activa para:
Aumentar las tasas de conversión.
Mejora el valor de por vida del cliente.
Fomentar la lealtad a largo plazo.
Cree un sistema de retención de clientes en tiempo real impulsado por MongoDB Atlas.
Arquitecturas de Referencia
Resumen general de la arquitectura para retención de clientes con Atlas Stream Processing y MongoDB Atlas
Para implementar esta solución, deberás comprender el flujo de datos, las etapas de procesamiento de eventos y los componentes clave de arquitectura:
Figura 4. Motor de retención de clientes, impulsado por MongoDB Atlas
Capa de Ingesta de Eventos
En tu aplicación de comercio electrónico, las interacciones con los clientes generan un flujo de eventos en tiempo real. Puedes utilizar esta aplicación para:
Emitir un evento de latido cada 10 segundos para señalar que la sesión del cliente permanece activa.
Capture las acciones de los clientes, como búsquedas, visualizaciones de productos, agregar al carrito y salida mediante hover.
En esta solución de demostración, transmites eventos a una colección de MongoDB. Change Streams expone cada documento como un nuevo evento, creando una fuente de eventos en tiempo real que alimenta la capa de Stream Processing.
También puede ingerir estos flujos de plataformas como Apache Kafka, Google Cloud Pub/Sub, Azure Event Hubs o AWS Kinesis como fuente para Atlas Stream Processing sin almacenar los eventos en MongoDB Atlas.
Atlas Stream Processing
Atlas Stream Processing se utiliza para procesar los datos a medida que llegan. Esto le permite:
Conéctese al flujo de datos utilizando el
$sourceoperador.Utiliza múltiples procesadores de flujo para diferentes tareas, como construir el estado de sesión y detectar patrones de señales de comportamiento.
Genera señales de comportamiento como alta intención de compra, fricción en la búsqueda y riesgo de salida.
Depósitos de datos
El operador
$mergese utiliza para enviar datos procesados a un destino. En esta solución:Los procesadores de flujos guardan el estado de la sesión en MongoDB para que actúe como una memoria de sesión en tiempo real para la capa de decisión agente.
Atlas Stream Processing escribe señales de comportamiento derivadas de eventos procesados en MongoDB.
MongoDB Change Streams expone estas señales para activar la capa Agentic NBA cuando aparecen señales clave de retención de clientes.
El operador
$mergetambién puede enviar resultados a Apache Kafka, AWS S3 o funciones externas.agente
Implementa un agente de IA para leer señales de comportamiento y calcular un NBA como:
Recomendaciones de productos personalizadas
Notificaciones contextuales de prueba social
Ofertas relacionadas con el envío
El agente actúa como la capa de decisión. Puede implementarse como un agente simple o avanzado. Esta solución utiliza un agente determinista que combina el Protocolo de Contexto de Modelo (MCP), búsqueda vectorial, modelos de embedding de Voyage IA y grandes modelos de lenguaje (LLMs). Estas herramientas evalúan el contexto y generan la NBA óptima para mantener comprometidos a los compradores activos.
MongoDB Atlas
Utiliza MongoDB Atlas como la capa de contexto de comercio y cliente. El agente lee los datos operativos y el historial del cliente de Atlas para obtener contexto. El agente evalúa estos datos y escribe el NBA en una colección de MongoDB.
Atlas simplifica la integración de datos en todo el ecosistema del agente con seguridad y a escala. Esto permite que los datos operativos se almacenen junto con embeddings para el catálogo, las preferencias de los clientes y otros casos de uso de búsqueda vectorial.
Experiencia en tiempo real
Mostrar la NBA en la pantalla del cliente en tiempo real. La aplicación de comercio electrónico utiliza Change Streams para supervisar la colección NBA. Luego, la aplicación muestra notificaciones dirigidas al comprador activo. Ejemplos incluyen:
Íconos de fuego en productos estratégicos
Mensajes de prueba social como notificaciones o en la lista del carrito
Recomendaciones Flash o notificaciones de descuentos como ventanas emergentes
Detección de señales de comportamiento con Atlas Stream Processing
Cada vista de producto, búsqueda o acción del carrito contiene una pista de intención, aunque los eventos en bruto suelen ser ruidosos. Utiliza Atlas Stream Processing para transformar estos eventos en un contexto de sesión claro.
Mantenga este contexto actualizado en tiempo real. Utilízalo para rastrear el comportamiento durante la sesión y detectar patrones importantes. Proporcionar a la capa de decisión un acceso rápido a este contexto en un formato que sea fácil de query, explicar y actuar. En esta arquitectura, Atlas Stream Processing desempeña ese rol.
Figura 5. Detección de señales de comportamiento con Atlas Stream Processing
ASP #1 transforma continuamente el clickstream (1) (2) en un único documento session_state por sesión activa, combinando la memoria de la sesión con la última snapshot conductual de 10segundos (4). ASP #2 lee esa nueva fuente de eventos (5) para detectar señales de comportamiento de alto nivel y "hundirlas" en session_signals (7). Ambos almacenan datos procesados en MongoDB, mientras que los eventos no válidos se enrutan a las colecciones DLQ (3) (6) para depuración y solución de problemas.
Atlas Stream Processing Nº1: compilar un estado de sesión en directo
Compila un estado de sesión en vivo para cada sesión de cliente. Utiliza este estado de sesión para dos propósitos:
Compila la memoria de sesión: Crea la memoria de sesión que los sistemas posteriores requieren. Mantén un documento procesado por sesión y actualízalo cada 10 segundos. Almacena el contexto de sesión esencial, como la primera actividad, la última actividad, los recuentos de interacciones, el comportamiento reciente y el historial de búsqueda.
Interpretar intención: Go más allá de almacenar la actividad interpretándola mediante un modelo de intención adaptado a su dominio.
En esta demostración, agrupe los eventos recientes de los clientes cada 10 segundos para crear una vista estructurada del comportamiento. Utiliza esta vista para rastrear dónde el cliente pone la atención y cómo cambia esa atención a lo largo del tiempo.
Define el modelo de intención con tres conceptos:
Dimensión: La perspectiva conductual para cada interacción. Un evento de producto identifica tanto un producto específico como un contexto más amplio, como
articleTypeybrand.Esto te permite interpretar la intención a múltiples niveles para cada evento. Un cliente podría explorar varios productos manteniéndose enfocado en el mismo tipo de 'dimensión', como un articleType.Peso: La fuerza de la señal de interacción. No todas las acciones tienen la misma importancia.
En esta demostración, los pesos son:
ver producto = 3
añadir al carrito = 7
Para cada elemento de una dimensión, calculo el peso de la siguiente manera:
Peso(elemento) = suma de los pesos de evento para ese ítem en la ventana de 10segundos
Ejemplo:
Si el cliente ve un producto “X” (
P1) dos veces y agrega P1 al carrito una vez, y el articleType es “shoes”, entonces:Peso(P1) = 3 + 3 + 7 = 13
Peso(zapatos) = 3 + 3 + 7 = 13
Este cálculo indica un gran interés tanto en el producto específico como en los “zapatos” en general.
Concentración: usa este parámetro para medir cuánto se concentra la atención del cliente en una determinada dimensión.
Para cada elemento en una dimensión, se debe calcular:
Enfoque(ítem) = Peso(ítem) / Peso total de esa dimensión en la misma ventana
Ejemplo:
Si P1 es el único producto con el que el cliente interactúa en esa ventana, entonces:
Focus(P1) = 13 / 13 = 1.0
Esto significa que el cliente está totalmente enfocado en un producto.
Si el cliente interactúa con dos productos en la misma ventana, y cada producto pertenece a un tipo de artículo diferente, entonces:
visualiza producto P1, donde articleType = Shampoo → Weight(Shampoo) = 3
ve el producto P2 y añade el producto P2 al carrito, en donde articleType = Acondicionador → Weight(Acondicionador) = 3+7 = 10
Entonces:
Peso total(tipo de artículo) = 3 + 10 = 13
So:
Focus(Champú) = 3 / 13 = 0.23
Enfoque (Condición) = 10 / 13 = 0.77
Esto significa que la atención del cliente se distribuye en varios artículos en la dimensión tipoArticulo, pero con un enfoque más fuerte en el Acondicionador.
Utiliza este modelo para rastrear estas variables a lo largo del tiempo. Cada 10segundos de snapshot se convierte en una entrada de comportamiento estructurada para Atlas Stream Processing N.º 2, que evalúa patrones de nivel superior a lo largo del tiempo. Esto ayuda a determinar si el cliente es:
Se centra en un artículo, categoría o marca específica
Explorando ampliamente
Mostrar intención clara o incierta
Construye este estado de sesión con nativas Atlas Stream Processing capacidades:
Utiliza $source para leer eventos de
events_ingesty preservar la hora del evento para la creación de ventanas.Utiliza $validate para aplicar el contrato de evento y enviar los eventos no válidos a
events_ingest_dlq.Utiliza $tumblingWindow con un intervalo de 10segundos de tiempo de evento para crear un marco de procesamiento estable por sesión.
Utiliza $group para agrupar múltiples eventos sin procesar en una sola snapshot por sesión para cada ventana.
Utilice $addFields y $switch para asignar un peso a cada interacción.
Use $function to calculate the intent model of weight and focus for each dimension. Procesas los eventos en cada ventana deslizable con lógica de JavaScript, utilizando contadores y aritmética para generar un snapshot estructurado del comportamiento de sesión cada 10 segundos. Esto crea un nuevo conjunto de datos que Atlas Stream Processing No. 2 consume en la siguiente etapa.
Utiliza $merge para realizar la inserción del resultado en
session_statey mantener un documento activo por sesión con tanto la última snapshot como la memoria de sesión acumulada.
Atlas Stream Processing Núm. 2: Detectar patrones de comportamiento con el tiempo
Lea las instantáneas estructuradas de la sesión de session_state en lugar de los eventos sin procesar del clickstream. Esto proporciona una capa conductual procesada y consciente del tiempo para la evaluación.
En esta demostración, Atlas Stream Processing No.2 usa tres procesadores de streams. Cada procesador detecta un tipo de señal:
high-intentsearch-frictionexit-risk
Los tres procesadores siguen el mismo patrón:
leer instantáneas de sesiones de
session_stateevaluar el comportamiento a lo largo de ventanas de 30segundos
guardar documentos de señal de solo inserción en
session_signals
Este diseño mantiene la pipeline simple y modular. Cada procesador utiliza el mismo patrón de fuente y sumidero, pero aplica diferentes reglas para detectar señales conductuales.Utiliza estas señales como puntos de control conductuales. Cada uno captura cambios significativos en el comportamiento de la sesión, tales como:
Convergencia de productos
Exploración sin resolver
Intención de dejar.
Mantenga las señales dispersas, acotadas en el tiempo y explicables. Esto permite que la capa de toma de decisiones reaccione sólo cuando ocurre algo relevante, en lugar del procesamiento de cada evento bruto.
Atlas Stream Processing N.º 2 no decide la siguiente acción. Construye la capa de señales de comportamiento que utiliza el sistema de decisiones para razonar y actuar en tiempo real.
Figura 6. Creando una capa unificada de datos de inteligencia para agentes de IA
El agente de la siguiente mejor acción funciona sobre una capa unificada de datos de inteligencia en MongoDB. Responde a señales de comportamiento (1) a través de Change Streams, toma el contexto en vivo de session_state (2.a), y lo combina con el contexto empresarial y semántico almacenado en MongoDB, como el perfil de usuario, catálogo, promociones, reglas, embeddings y MongoDB Vector Search (2.b). El agente calcula y almacena la siguiente mejor acción en tiempo real (3), que la aplicación de comercio electrónico luego consume a través de Change Streams y muestra durante la sesión en vivo para fines de retención de clientes (4).
Al almacenar el estado de la sesión, señales de comportamiento y resultados de decisiones en MongoDB, se proporciona al agente una capa unificada de datos de inteligencia. El agente puede leer el contexto de comportamiento fresco y las señales históricas de esa sesión. Luego, combina estos datos con el perfil, el catálogo, las promociones y las reglas de negocio para volver a guardar la NBA en la misma plataforma operativa. Esto mantiene la arquitectura simple, reduce el movimiento de datos y estota el agente acceso rápido al contexto que necesita para actuar en tiempo real de manera segura y escalable.
Enfoque de modelo de datos
MongoDB proporciona un modelo orientado a documentos flexible para arquitecturas en tiempo real. Almacene eventos de clientes diversos con diferentes esquemas en una sola colección. Actualiza tu esquema a medida que evoluciona la lógica empresarial.
El modelo orientado a documentos gestiona estructuras complejas como arreglos y subdocumentos. Utiliza estas estructuras para compilar una memoria de sesión compacta y consultable. Este diseño proporciona un contexto inmediato para los agentes de IA sin la necesidad de uniones de bases de datos. Utiliza índices Time-to-live (TTL) para eliminar los scripts manuales de limpieza de datos.
Esta solución utiliza cuatro colecciones principales:
events_ingest: Almacena eventos de datos sin procesar y de corta duración. Actúa como fuente primaria para las pipelines de transmisión.
session_state: almacena el contexto operativo en vivo por sesión y se actualiza aproximadamente cada 10 segundos.
session_signals: almacena señales de comportamiento interpretables. Atlas Stream Processing genera un documento por cada señal detectada.
next_best_actions: almacena el contrato de acción final para la interfaz de comercio electrónico.
Ingesta de eventos sin procesar (events_ingest)
La aplicación de comercio electrónico envía eventos sin procesar a la colección
events_ingest. Cada evento sigue una estructura común que contiene marca de tiempo, etiquetas y metadatos. El campo del evento identifica el tipo de evento, mientras que la sección de metadatos almacena atributos específicos del evento. Este diseño polimórfico permite que diferentes tipos de eventos coexistan en la misma colección sin aplicar un esquema rígido. Utiliza un índice TTL corto para gestionar estos datos efímeros.{ "timestamp": "2026-01-05T14:55:12.321Z", "tags": { "sessionId": "1767624420027", "userId": "66fe219d625d93a100528224", "event": "search" }, "metadata": { // Event-specific fields } } Estado de sesión materializado (session_state)
El documento de estado de la sesión representa una única fuente de verdad en tiempo real por sesión. Atlas Stream Processing No. 1 actualiza este documento cada 10 segundos. Esto crea un contexto compacto que sirve como fuente para el Atlas Stream Processing No. 2 y como contexto en vivo y a corto plazo para la toma de decisiones del agente dentro de la sesión activa.
El documento separa la actividad acumulada (
sessionTotals) de la actividad reciente de la microventana (last10s). Rastrea el recuento de eventos, búsquedas recientes y actualizaciones del carrito. Calcula los puntajes de preferencia de los artículos usando un modelo de interacción ponderado. Este modelo mide la intensidad del interés y la dirección del enfoque.{ "_id": { "$oid": "69c16dd2f2145b31c07b1beb" }, "firstSeen": { "$date": "2026-03-23T16:43:59.013Z" }, "lastEvent": { "event": "view-product", "ts": { "$date": "2026-03-23T16:49:29.849Z" } }, "lastSeen": { "$date": "2026-03-23T16:49:29.849Z" }, "sessionId": "d73477b8-3879-4749-a402-321a526cdc33", "userId": "671ff2451ec726b417352703", "last10s": { "intent": { "products": [ { "productId": "67192b4264d161905fbe8342", "searchCount": 0, "viewCount": 0, "addToCartCount": 1, "weight": 7, "focus": 0.4375 }, { "productId": "67192b4264d161905fbe8245", "searchCount": 0, "viewCount": 1, "addToCartCount": 0, "weight": 3, "focus": 0.1875 }, { "productId": "67192b4264d161905fbe82a1", "searchCount": 0, "viewCount": 1, "addToCartCount": 0, "weight": 3, "focus": 0.1875 }, { "productId": "67192b3f64d161905fbe77af", "searchCount": 0, "viewCount": 1, "addToCartCount": 0, "weight": 3, "focus": 0.1875 } ], "articleTypes": [ { "articleType": "SHOES", "searchCount": 0, "viewCount": 2, "addToCartCount": 1, "weight": 13, "focus": 0.8125 }, { "articleType": "CARGO_STRAP", "searchCount": 0, "viewCount": 1, "addToCartCount": 0, "weight": 3, "focus": 0.1875 } ], "subCategories": [ { "subCategory": "Shoes", "searchCount": 0, "viewCount": 2, "addToCartCount": 1, "weight": 13, "focus": 0.8125 }, { "subCategory": "Hardware", "searchCount": 0, "viewCount": 1, "addToCartCount": 0, "weight": 3, "focus": 0.1875 } ], "dimensionTotals": { "productWeightTotal": 16, "articleTypeWeightTotal": 16, "subCategoryWeightTotal": 16 } }, "lastEvent": { "event": "view-product", "ts": { "$date": "2026-03-23T16:49:29.849Z" } }, "window": { "start": { "$date": "2026-03-23T16:49:20.000Z" }, "end": { "$date": "2026-03-23T16:49:30.000Z" } } }, "sessionTotals": { "eventCounts": { "heartbeat": 30, "search": 2, "view-product": 21, "add-to-cart": 13, "exit-risk": 14 }, "windowCount": 30 }, "searchHistory": [ "shoes", "running shoes" ] } Diagnóstico Accionable (session_signals)
Atlas Stream Processing N°2 evalúa el estado de la sesión cada 30 segundos, identifica patrones de comportamiento y genera señales. Usa un documento por señal en lugar de un arreglo de señales dentro del documento de la sesión. Este enfoque de inserción única evita la amplificación de la escritura y previene documentos calientes durante los picos de tráfico de venta minorista.
La solución se centra en tres señales básicas de comportamiento que representan momentos de retención de alto impacto en la mayoría de los procesos de ecommerce.
Alta intención: El cliente está considerando activamente realizar una compra y muestra señales claras de intención (como un enfoque repetido en el producto, progreso en el carrito, interés concentrado). Este es el momento ideal para reducir la duda y acelerar la conversión mediante la tranquilidad, la orientación sobre el producto y la claridad en la disponibilidad y la entrega.
Riesgo de Salida: Es probable que el cliente abandone el proceso sin convertir, a menudo después de una interacción significativa o actividad en el carrito. Esta es la última oportunidad para retener la sesión, recuperar el carrito, conservar la intención o brindar asistencia inmediata.
Fricción de búsqueda: El cliente está buscando y navegando repetidamente sin progresar, lo que sugiere que tiene dificultad para encontrar una coincidencia o que se está acumulando frustración. Esta es una de las oportunidades de mayor valor para intervenir de manera temprana, antes de que el cliente abandone la sesión debido al cansancio o la frustración.
A continuación se muestra un documento de ejemplo sobre una señal de fricción en la búsqueda:
{ "_id": "69c172667348bc2e9b60ee7b", "evidence": "Explored a considerable number of products in the last 30 seconds, while articleType focus remained predominant on 'PET_SUPPLIES'. The absence of add-to-cart suggests stable topic-level intent combined with choice overload at the product level", "severity": "medium", "sid": "d73477b8-3879-4749-a402-321a526cdc33", "signal": "search-friction", "topic": { "dimension": "articleType", "value": "PET_SUPPLIES" }, "ts": "2026-03-23T17:03:20.000Z", "uid": "671ff2451ec726b417352703" }
Compilar la solución
Para reproducir esta demostración en tu propio entorno, siga estos pasos.
Configurar los requisitos previos
Cree una cuenta de MongoDB Atlas.
Precargar una base de datos con productos. Usa los archivos de vaciado proporcionados para restaurar los datos.
Implementa la aplicación principal de Leafy Pop-Up Store. Esta aplicación incluye la interfaz y el sistema de flujo de eventos.
Python 3.12 o posterior
Credenciales de AWS para el acceso a Bedrock.
Voyage AI API key.
Configura Atlas Stream Processing
Crear un espacio de trabajo de Stream Processing
Crea un espacio de trabajo en tu cuenta de Atlas con esta configuración:
ConfiguraciónValorRazónNombre del espacio de trabajo
venta minorista-retention-demo
Propiedad y propósito claros; fácil de identificar más tarde.
Nivel
SP10
Suficiente para pipeline a escala de demostración (~2k sesiones) mientras se mantienen los costos bajos.
Proveedor / Región
AWS / us-east-1 (EE. Virginia)
Debe coincidir con la región de tu clúster Atlas para reducir la latencia y evitar tráfico entre regiones.
Tamaño máximo del nivel (opcional)
Dejar en el valor por defecto o configurar en SP30
Permite escalar rápidamente si es necesario sin habilitar el escalado automático.
Registrar la conexión a la base de datos
Abre tu espacio de trabajo de Stream Processing y configura estos ajustes de conexión:
Tipo de conexiónAtlas DatabaseNombre de la conexión
retail_customer_retention
Atlas Cluster
Seleccione el clúster que contiene la base de datos leafy_popup_store
Ejecutar como
Leer y guardar en cualquier base de datos
Crea los procesadores de flujo
Cree cuatro procesadores Atlas Stream en su espacio de trabajo. Siga estos pasos para el primer procesador. Replique el proceso para los tres procesadores restantes.
Crear Atlas Stream Processing n.º 1: Generador de estado de sesión
Abre tu espacio de trabajo de Stream Processing.
Haga clic en Crear procesador.
Introduce asp1_session_state_builder como nombre del procesador.
Abrir el archivo asp1_session_state_builder_.js en el repositorio.
Copie la definición de la pipeline.
Pega el pipeline en el editor de Definición del Procesador.
Haga clic en Crear procesador.
Haz clic en Comenzar.
Replica los pasos anteriores para crear estos tres procesadores:
Nombre del procesadorpipelineasp2_exit_riskasp2_high_intentasp2_search_friction
Configurar capa de decisión de NBA
Clona el repositorio.
git clone https://github.com/mongodb-industry-solutions/retail-customer-retention-backend/tree/staging cd retail-customer-retention-backend Cree y active el entorno virtual.
python3 -m venv .venv source .venv/bin/activate # On Windows: .venv\Scripts\activate Instala las dependencias.
pip install -r requirements.txt Crea un archivo
.enven el directorio principal y configura estas variables de entorno:MONGODB_URI= AWS_REGION= AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= VOYAGE_API_KEY= Inicia la aplicación. Este script inicia el servidor MCP y el monitor de flujo de cambios.
python main.py
Probar la solución
Abre la aplicación en /shop. Interactúa con el catálogo. La aplicación muestra la siguiente mejor acción en pantalla.
Lecciones clave
Retener a los clientes en tiempo real: Con Atlas Stream Processing, pueden procesar eventos de clickstream para activar las siguientes mejores acciones durante las sesiones activas. Esto permite a los minoristas pasar del control de daños reactivo a la intervención proactiva en el momento.
Simplifica tu arquitectura de datos: Con el modelo orientado a documentos de MongoDB, puedes almacenar eventos de clickstream sin procesar, estados de sesión y señales de comportamiento en una única plataforma. Evita pipelines de extracción, transformación y carga, así como la limpieza manual, utilizando índices TTL y colecciones flexibles.
Compile una Acción Siguiente Mejor Agente sobre una capa de datos de inteligencia en MongoDB: Conecte agentes de IA directamente al contexto de sesión en tiempo real y datos operativos en MongoDB. Enriquece las siguientes mejores acciones con capacidades de IA, como la Búsqueda Vectorial, para ofrecer experiencias personalizadas.
Autores
Angie Guemes, MongoDB
Florencia Arin, MongoDB
Rodrigo Leal, MongoDB
Daniel Jamir, MongoDB