Offer Decisioning
Esta guía proporciona una referencia de implementación completa para Offer Decisioning mediante Adobe Journey Optimizer (AJO) Decisioning y Adobe Real-Time Customer Data Platform (RT-CDP). Está diseñado para arquitectos de soluciones, tecnólogos de marketing e ingenieros de implementación que necesitan implementar una lógica de selección de ofertas centralizada que determine la mejor oferta de próxima generación para cada perfil de cliente en todos los canales.
Utilice esta guía para comprender qué se debe configurar, dónde existen las opciones y qué compensaciones se aplican a cada decisión.
El patrón desvincula la decisión "qué mostrar" de la lógica del canal "dónde mostrarlo", lo que permite una selección de ofertas coherente y optimizada en el correo electrónico, la web, la aplicación móvil y cualquier otro punto de contacto. AJO Decisioning administra todo el ciclo de vida de la oferta: creación de ofertas y administración del catálogo, reglas de elegibilidad (que pueden ver cada oferta), estrategias de clasificación (cómo seleccionar entre ofertas aptas), ubicaciones (donde aparecen las ofertas) y políticas de decisión (que unen todo).
Resumen del caso de uso
Las organizaciones suelen tener que presentar la oferta, la promoción o el incentivo más relevantes a cada cliente en el momento de la interacción. Tanto si la interacción se produce en una campaña de correo electrónico, en una página de inicio de un sitio web, en una aplicación móvil o en un punto de decisión dentro de un recorrido de varios pasos, el desafío es el mismo: seleccionar la oferta óptima de un catálogo de opciones disponibles en función de quién es el cliente, para qué cumplen los requisitos y qué oferta es la que tiene más probabilidades de impulsar el resultado deseado.
Offer Decisioning soluciona esto centralizando toda la lógica de selección de ofertas en el motor de gestión de decisiones de AJO. En lugar de codificar las asignaciones de ofertas en campañas o canales individuales, el motor de decisión evalúa los atributos de cada perfil, la pertenencia a audiencias y las señales contextuales para determinar la mejor oferta en tiempo real. Esta centralización garantiza que el mismo cliente reciba ofertas coherentes y optimizadas independientemente del canal al que acceda.
Este patrón difiere del ámbito de la personalización de aplicaciones/web de visitantes conocidos: Offer Decisioning no depende del canal y está centralizado, mientras que la personalización de visitantes conocidos se centra en la personalización de superficies digitales. Difiere de la recomendación de comportamiento en el modelo de catálogo: utilice Offer Decisioning cuando el conjunto de artículos elegibles esté regido por reglas comerciales, restricciones de elegibilidad o requisitos regulatorios (promociones, productos financieros, incentivos). Utilice recomendaciones de comportamiento cuando el conjunto de elementos sea grande, cambie continuamente y la selección esté impulsada por señales de similitud o afinidad de comportamiento (catálogos de productos, bibliotecas de contenido).
Objetivos empresariales clave
Este patrón de caso de uso admite los siguientes objetivos empresariales.
Ofrecer experiencias personalizadas a los clientes
Adapte el contenido, las ofertas y los mensajes a las preferencias, los comportamientos y las fases del ciclo de vida individuales.
KPI: participación, tasas de conversión, satisfacción del cliente (CSAT)
Aumentar los ingresos de ventas cruzadas y ventas adicionales
Promocione productos o servicios complementarios y de primera calidad a los clientes existentes en función del comportamiento y el historial de compras.
KPI:, porcentaje de ampliación de venta/venta cruzada, ingresos incrementales, valor de duración del cliente
Aumentar la lealtad del cliente y el valor de duración
Profundice las relaciones con los clientes y maximice el valor a largo plazo mediante programas de fidelidad, recompensas y participación personalizada.
KPI: valor de duración del cliente, retención, aumento de venta/venta cruzada %
Casos de uso tácticos de ejemplo
Los siguientes escenarios ilustran cómo se puede aplicar la toma de decisiones de oferta en la práctica.
- La siguiente mejor oferta en campañas de correo electrónico: seleccione la promoción más relevante por destinatario en el momento de la entrega
- Titular promocional en tiempo real en el sitio web: al tomar decisiones, se selecciona la oferta al cargar la página en función del perfil del visitante
- Tarjeta personalizada en la aplicación con el mejor incentivo para la fase de ciclo vital del usuario
- Coherencia de ofertas en canales múltiples: la misma lógica de toma de decisiones sirve para el correo electrónico, la web y la notificación push para que el cliente vea una experiencia de oferta unificada
- Selección dinámica de cupones o descuentos basada en el nivel de valor del cliente (por ejemplo, los clientes de alto valor reciben una oferta premium)
- Selección de ofertas de ampliación o actualización de productos según el nivel de suscripción actual
- Personalización de ofertas de recompensas de fidelización en función del nivel y el historial de actividades
Indicadores clave de rendimiento
Los siguientes KPI ayudan a medir la eficacia de una implementación de Offer Decisioning.
Patrón de caso de uso
Esta sección describe la cadena de funciones y la definición de patrones para Offer Decisioning.
Offer Decisioning
Utilice la lógica de decisión centralizada para seleccionar la mejor oferta o el contenido siguiente para un perfil entre canales.
Cadena de funciones: Evaluación de audiencias > Idoneidad de la oferta > Estrategia de clasificación > Ejecución de decisiones > Entrega > Informes
Consulte la sección Opciones de implementación para ver cómo se manifiesta cada composición.
Aplicaciones
En este patrón de caso de uso se utilizan las siguientes aplicaciones de Adobe.
- Adobe Journey Optimizer (AJO): motor de administración de decisiones para la creación de ofertas, reglas de elegibilidad, estrategias de clasificación, ubicaciones y políticas de decisión; configuración de canal y creación de mensajes para la entrega de ofertas; ejecución de campañas y recorridos
- Adobe Real-Time Customer Data Platform (RT-CDP) — Evaluación de audiencia para segmentos de elegibilidad de ofertas; datos de perfil y atributos calculados utilizados en la elegibilidad y la clasificación
- Adobe Experience Platform (AEP): almacén de perfiles unificado, resolución de identidades y base de datos compatible con AJO y RT-CDP
Funciones básicas
Para este patrón de caso de uso, deben existir las siguientes capacidades básicas. Para cada función, el estado indica si suele ser necesaria, si se supone que está preconfigurada o si no es aplicable.
Funciones de soporte
Las siguientes capacidades aumentan este patrón de caso de uso, pero no son necesarias para la ejecución principal.
Funciones de aplicación
Este plan utiliza las siguientes funciones del Catálogo de funciones de la aplicación. Las funciones se asignan a fases de implementación en lugar de pasos numerados.
Journey Optimizer (AJO)
En la tabla siguiente se enumeran las funciones de AJO y las fases de implementación en las que están configuradas.
Real-Time CDP (RT-CDP)
En la tabla siguiente se enumeran las funciones RT-CDP y las fases de implementación en las que están configuradas.
Prerrequisitos
Complete los siguientes requisitos previos antes de comenzar la implementación.
- [ ] zona protegida de AJO con capacidades de Administración de decisiones habilitadas
- [ ] funciones de usuario con permisos de Administración de decisiones (crear/editar ofertas, ubicaciones, decisiones)
- [ ]: el esquema de perfil incluye los atributos necesarios para la idoneidad de la oferta (por ejemplo: nivel de lealtad, segmento de cliente o nivel de suscripción)
- [ ] Los datos del perfil están actuales y se han ingerido activamente para mantener actualizados los atributos de elegibilidad
- [ ] para opción A (correo electrónico): superficie de canal de correo electrónico configurada con subdominio verificado y grupo de IP calentadas
- [ ] para Opción B (web/aplicación): Web SDK implementado con el servicio AJO habilitado en el conjunto de datos; directiva de combinación activa para Edge configurada
- [ ] para Opción C (Recorrido): permisos de lienzo de Recorrido y al menos un evento de entrada de recorrido o una audiencia configurada
- [ ] recursos creativos de ofertas (imágenes, copias, CTA) preparados para cada combinación de oferta y ubicación
- [ ] contenido de oferta de reserva preparado para cada ubicación
- [ ] audiencias para reglas de elegibilidad de ofertas definidas y evaluadas en RT-CDP
Opciones de implementación
Esta sección describe las opciones de implementación disponibles para Offer Decisioning. Cada opción ofrece un canal de entrega y un contexto de caso de uso diferentes.
Opción A: Offer Decisioning de correo electrónico
Esta opción es perfecta para seleccionar la mejor oferta que se debe incluir en las campañas de correo electrónico salientes: correos electrónicos promocionales, personalización de boletines informativos y correos electrónicos del ciclo vital con contenido de oferta dinámica. La decisión se toma en el momento de procesar el mensaje para cada destinatario.
Cómo funciona
Las políticas de decisión se invocan durante el procesamiento del mensaje de correo electrónico para seleccionar la mejor oferta para cada destinatario. La plantilla de correo electrónico incluye una zona de colocación de ofertas en la que el motor de decisión inserta la representación de contenido de la oferta seleccionada (imagen, HTML o texto). En el momento de la entrega, el motor evalúa el perfil de cada destinatario con las reglas de idoneidad para la oferta, aplica la estrategia de clasificación e incrusta el contenido de la oferta ganadora en el correo electrónico.
Este método funciona tanto con campañas programadas (evaluadas en el momento de la ejecución de la campaña) como con correos electrónicos incrustados en el recorrido (evaluados cuando el perfil llega al nodo de acción del mensaje). El contenido de la oferta (imagen, titular, texto independiente y CTA) se personaliza por destinatario en función del resultado de la decisión.
Consideraciones clave
- La idoneidad de la oferta se evalúa en el momento de la entrega mediante el estado actual del perfil
- La evaluación de audiencias por lotes es suficiente, ya que las decisiones se toman durante el procesamiento de mensajes
- Cada oferta necesita una representación de contenido de imagen o HTML para la ubicación del correo electrónico
- La oferta de reserva debe tener contenido para cada ubicación de correo electrónico utilizada
Ventajas
- Ruta de implementación más sencilla: utiliza la entrega de correo electrónico de recorrido o campaña estándar
- No hay requisitos de SDK del lado del cliente
- Funciona con infraestructuras de correo electrónico y superficies de canal existentes
- Admite grandes volúmenes de audiencia mediante la ejecución de campañas por lotes
Limitaciones
- La decisión se toma en el momento del envío; no se puede adaptar al comportamiento posterior al envío
- El contenido de la oferta es estático una vez enviado el correo electrónico (sin actualizaciones en tiempo real)
- Limitado a los atributos de perfil disponibles en el almacén de perfiles de hub (no de edge)
Recursos de Experience League
Opción B: Web/aplicación de decisiones de oferta en tiempo real
Esta opción es perfecta para la selección de ofertas en tiempo real en páginas web o aplicaciones móviles: titulares promocionales de página de inicio, widgets de oferta del tablero de cuentas, tarjetas de oferta en la aplicación o cualquier superficie digital en la que la oferta deba seleccionarse en el momento en que se carga la página o se procesa la pantalla.
Cómo funciona
Las políticas de decisión se invocan al cargar la página o al procesar la pantalla de la aplicación a través de la red de Edge Decisioning o mediante experiencias basadas en código. Cuando un visitante carga una página, Web SDK envía una solicitud a Edge Network, que evalúa el perfil de Edge del visitante frente a las reglas de elegibilidad de las ofertas y las estrategias de clasificación. La oferta seleccionada se devuelve en la respuesta y se procesa en la ubicación configurada en la superficie digital.
En el caso de las experiencias basadas en código, la aplicación recupera la respuesta de decisión y procesa el contenido de la oferta mediante una lógica front-end personalizada. Para las experiencias de canal web, el canal web de AJO puede insertar el contenido de la oferta directamente en la página mediante la creación visual o basada en código.
Consideraciones clave
- Requiere la implementación de Web SDK o Mobile SDK con el servicio de AJO habilitado en el conjunto de datos
- Se requiere una política de combinación activa para Edge para las búsquedas de perfiles en tiempo real
- Las audiencias utilizadas para los requisitos deben admitir la evaluación de Edge (comprobaciones de atributos simples y pertenencia a segmentos)
- Las representaciones de contenido de las ofertas deben utilizar formatos JSON o URL de imagen para el procesamiento en el lado del cliente
- El seguimiento de impresiones debe implementarse para capturar las vistas de ofertas y los clics
Ventajas
- Selección de ofertas en tiempo real dentro de la sesión en función del estado del perfil actual del visitante
- Latencia de decisión subsegunda a través de Edge Network
- Las ofertas se adaptan a los datos de perfil más actuales disponibles en Edge
- Admite pruebas A/B de estrategias de oferta mediante experimentación de contenido
Limitaciones
- Requiere implementación de SDK del lado del cliente (Web SDK o Mobile SDK)
- El perfil de Edge tiene un subconjunto de atributos de perfil hub completos; es posible que las reglas de idoneidad complejas no se evalúen correctamente
- Los segmentos de Edge tienen restricciones de complejidad de reglas de segmentos (sin consultas de series temporales)
- Requiere desarrollo front-end para procesamiento personalizado en experiencias basadas en código
Recursos de Experience League
En qué se diferencia de la opción B de personalización de aplicaciones/web de visitantes conocidos:
La infraestructura es idéntica: ambos utilizan AJO Decisioning en el perímetro con Web SDK y una política de combinación activa para el perímetro. La diferencia es el modelo de gobernanza del catálogo. Esta opción rige un catálogo de ofertas limitado con reglas de idoneidad, contadores de límite y fechas de validez. Utilícela cuando las restricciones comerciales o regulatorias determinen qué ofertas se pueden mostrar y con qué frecuencia. Personalización web/aplicación de visitante conocido La opción B selecciona elementos de contenido mediante la pertenencia a segmentos o estrategias de clasificación sin la administración del ciclo de vida de ofertas. Si el conjunto de artículos es grande, cambia continuamente y no requiere límite ni control de elegibilidad, use la Opción B de visitante conocido en su lugar.
Opción C: nodo de decisión de Recorrido
Esta opción es mejor para la selección de ofertas dentro de un recorrido de varios pasos: seleccionar la mejor oferta en un punto de decisión en un recorrido de clientes y, a continuación, entregarla a través del siguiente nodo de acción. Utilícelo cuando la decisión de oferta forme parte de un flujo de orquestación más amplio con esperas, condiciones y varias acciones de mensaje.
Cómo funciona
Las políticas de decisión se invocan desde un nodo de decisión dentro de un lienzo de recorrido de AJO. Cuando un perfil llega al nodo de decisión, el motor evalúa la idoneidad y la clasificación de la oferta para seleccionar la oferta óptima. La oferta seleccionada informa de la siguiente acción de mensaje: qué contenido de oferta se va a incluir, qué canal se va a utilizar o qué rama de recorrido se va a tomar en función del resultado de la oferta.
Este método permite recorridos adaptables en los que la decisión de oferta influye en los pasos de recorrido siguientes. Por ejemplo: un recorrido puede seleccionar la mejor oferta, enviarla por correo electrónico, esperar a la participación y, a continuación, enviar una notificación push si la oferta no se ha abierto.
Consideraciones clave
- El recorrido debe diseñarse con un nodo de decisión seguido de uno o más nodos de acción de mensaje
- La idoneidad de la oferta se evalúa mediante el estado del perfil en el momento en que este alcanza el nodo de decisión
- Los pasos de espera de recorrido entre la decisión y la entrega pueden hacer que el estado del perfil cambie
- Se puede combinar con la bifurcación de recorridos para seguir diferentes rutas en función de la oferta seleccionada
Ventajas
- Integra la selección de ofertas en flujos de orquestación de varios pasos
- Habilita recorridos adaptables en los que la opción de oferta influye en los pasos siguientes
- Admite entrega en canales múltiples dentro del mismo recorrido (correo electrónico, push, SMS)
- Se puede combinar con condiciones de recorrido para el seguimiento de la participación posterior a la oferta
Limitaciones
- Es más complejo de configurar que la toma de decisiones de campaña independiente
- Se aplican límites de rendimiento de recorrido (tasa de entrada de 5000 perfiles por segundo)
- La decisión está vinculada al contexto del recorrido: los cambios requieren el control de versiones del recorrido
- El recorrido debe volver a publicarse para que las actualizaciones del catálogo de ofertas o de la directiva de decisiones surtan efecto
Recursos de Experience League
Comparación de opciones
En la tabla siguiente se comparan las tres opciones de implementación en función de criterios clave.
Elija la opción correcta
Siga estas directrices para seleccionar la mejor opción de implementación para su caso de uso.
- Elija la opción A si el caso de uso principal es seleccionar la mejor oferta por destinatario en campañas de correo electrónico salientes y no hay ninguna SDK del lado del cliente disponible. Esta es la ruta de implementación más sencilla y funciona bien para correos electrónicos promocionales, boletines informativos y campañas del ciclo vital.
- Elija la opción B si las ofertas deben seleccionarse en tiempo real en el momento en que un visitante carga una página web o abre una aplicación móvil. Esto requiere Web SDK o Mobile SDK y una política de combinación activa para Edge, pero ofrece la selección de ofertas más rápida y contextual.
- Elija la opción C si la decisión de oferta es parte de un recorrido del cliente más amplio con varios pasos, esperas y ramificación condicional. Esta es la opción correcta cuando la oferta seleccionada debe influir en las acciones de recorrido descendentes o cuando se necesita un seguimiento de varios canales basado en la participación en la oferta.
- Combine opciones cuando las ofertas deban entregarse de manera consistente entre canales. Utilice la misma política de decisión en las tres opciones para asegurarse de que el cliente vea la misma oferta en el correo electrónico (opción A), en el sitio web (opción B) y dentro de un seguimiento del recorrido (opción C).
Fases de implementación
Las siguientes fases describen la secuencia de implementación de extremo a extremo para Offer Decisioning.
Fase 1: Validar los requisitos previos básicos
Función de la aplicación: AEP: Modelado y preparación de datos, AEP: Configuración de identidad y perfil
Esta fase valida que la capa de datos fundacional admite Offer Decisioning. Los esquemas de perfil deben incluir los atributos utilizados en las reglas de aceptación de ofertas y la configuración de identidad debe habilitar la resolución de perfiles en canales múltiples.
Decisión: Atributos de perfil para la elegibilidad
Determine qué atributos de perfil se utilizarán en las reglas de aceptación de ofertas.
Detalles de configuración clave
- Compruebe que el esquema de perfil incluye campos a los que se hace referencia en las reglas de idoneidad (por ejemplo,
_tenantId.loyaltyTier,_tenantId.subscriptionType) - Confirme que existe el esquema de seguimiento de interacción de la oferta para los eventos de impresión, clics y conversión
- Para la opción B: Compruebe que la política de combinación activa en el perímetro está configurada y que el flujo de datos de Web SDK tiene habilitado el servicio AJO
Documentación de Experience League
Fase 2: Configurar la evaluación de audiencias
Función de aplicación: RT-CDP: Evaluación de audiencia
Esta fase define y evalúa las audiencias utilizadas como criterios de idoneidad para la oferta. Estas audiencias determinan qué segmentos de clientes cumplen los requisitos para ofertas específicas (por ejemplo, "clientes de alto valor" cumplen los requisitos para ofertas Premium, "usuarios de prueba" para ofertas de conversión).
Decisión: método de evaluación de audiencia
Determine la rapidez con la que el abono a audiencia debe actualizarse para poder optar a la oferta.
Navegación de la interfaz de usuario: Cliente > Audiencias > Crear audiencia > Generar regla
Detalles de configuración clave
- Defina audiencias de segmentación para los requisitos de oferta (por ejemplo, "Nivel Gold de fidelidad", "Clientes de alto valor", "Usuarios de prueba")
- Defina audiencias de supresión si es necesario (por ejemplo, "Oferta X recibida recientemente")
- Para la opción B: compruebe que las audiencias de idoneidad cumplen los requisitos para la evaluación de extremos; evite consultas de series temporales y agregaciones complejas en las expresiones de reglas de segmentos
Dónde divergen las opciones
Para La Opción A (Toma De Decisiones Por Correo Electrónico):
La evaluación por lotes o de flujo continuo es suficiente. Las audiencias se evalúan antes o durante la ejecución de la campaña. Las expresiones de reglas de segmentos complejos, incluidas las condiciones basadas en el tiempo y las agregaciones de eventos, son totalmente compatibles.
Para Opción B (Web/Aplicación En Tiempo Real):
Se requiere la evaluación de Edge. Las audiencias deben utilizar comprobaciones de atributos sencillas o condiciones de pertenencia a segmentos. Pruebe la idoneidad del perímetro comprobando que la expresión de regla del segmento cumple los requisitos para la segmentación de perímetros.
Para Opción C (Nodo De Decisión De Recorrido):
Cualquier método de evaluación funciona según los criterios de entrada de recorrido. Si el recorrido utiliza entradas basadas en audiencias, el método de evaluación de audiencias coincide con los requisitos del recorrido.
Documentación de Experience League
Fase 3: Configuración de la toma de decisiones
Función de aplicación: AJO: Decisioning
Esta es la fase principal en la que se crean el catálogo de ofertas, las reglas de elegibilidad, las estrategias de clasificación y las políticas de decisión. Esta fase crea la configuración del motor de decisión que comparten todas las opciones de entrega (A, B, C).
Decisión: Canal de ubicación y formato de contenido
Determine dónde aparecerán las ofertas y en qué formato.
Decisión: Estrategia de clasificación
Determine cómo se debe seleccionar la mejor oferta entre las ofertas aptas.
Decisión: Límite de oferta
Determine si debe haber límites en cuanto a la cantidad de veces que se muestra una oferta.
Navegación de la interfaz de usuario: Componentes > Administración de decisiones > Ubicaciones / Reglas / Ofertas / Decisiones
Detalles de configuración clave
-
Crear ubicaciones: defina dónde aparecen las ofertas especificando el tipo de canal y el formato de contenido para cada ubicación.
- IU: Componentes > Administración de decisiones > Ubicaciones
- Cree una ubicación por combinación de canal y formato (por ejemplo, "Email Hero Banner - HTML", "Web Homepage - JSON", "Mobile App Card - JSON")
-
Definir reglas de elegibilidad: cree reglas utilizando expresiones de reglas de segmentos que hagan referencia a atributos de perfil o a pertenencia a audiencias.
- IU: Componentes > Administración de decisiones > Reglas
- Las reglas pueden hacer referencia a miembros de audiencias, atributos de perfil (nivel de lealtad, tipo de suscripción), restricciones de fecha o datos contextuales
-
Crear ofertas personalizadas: cree cada oferta con representaciones de contenido para cada ubicación, asigne reglas de elegibilidad, establezca prioridad y configure un límite opcional.
- IU: Componentes > Administración de decisiones > Ofertas > Crear oferta
- Cada oferta necesita una representación de contenido por ubicación (por ejemplo, HTML para correo electrónico, JSON para web)
- Asigne reglas de aceptación para controlar qué perfiles pueden ver cada oferta
- Definición de fechas de validez de la oferta (inicio/final) y límite de frecuencia opcional
- Apruebe cada oferta para que sea apta para la toma de decisiones
-
Crear ofertas de reserva: cree una oferta predeterminada para cada ubicación que se muestre cuando no se califique ninguna oferta personalizada.
- IU: Componentes > Administración de decisiones > Ofertas > Crear oferta de reserva
- La reserva debe tener representaciones para cada ubicación utilizada en la decisión
-
Crear calificadores y colecciones: organice ofertas en colecciones con etiquetas de calificador.
- IU: Componentes > Administración de decisiones > Cualificadores de recopilación
- Ofertas relacionadas con el grupo (por ejemplo, "Promociones de verano", "Recompensas de fidelidad") para su uso en ámbitos de decisión
-
Crear directivas de decisión: vincule ubicaciones, colecciones, estrategias de clasificación y ofertas de reserva a decisiones ejecutables.
- IU: Componentes > Administración de decisiones > Decisiones > Crear decisión
- Cada ámbito de decisión vincula una ubicación a una colección y especifica el método de clasificación
Documentación de Experience League
Fase 4: Configuración de canal y superficie
Función de aplicación: AJO: Configuración de canal
Esta fase configura las superficies de canal a través de las cuales se enviarán las ofertas. La configuración depende de las opciones de implementación que se utilicen.
Decisión: Tipo de canal
Determine qué canal de mensajería requiere el caso de uso.
Dónde divergen las opciones
Para La Opción A (Toma De Decisiones Por Correo Electrónico):
- IU: Administración > Canales > Superficies de canal > Crear superficie (correo electrónico)
- Configuración de subdominio, grupo de IP, nombre/correo electrónico del remitente, respuesta, cancelación de suscripción
- Compruebe los registros SPF, DKIM y DMARC del subdominio de envío
Para Opción B (Web/Aplicación En Tiempo Real):
- IU: Administración > Canales > Superficies de canal > Crear superficie (web o en la aplicación)
- Para la web: configure el patrón de URL de la superficie web
- Para experiencias basadas en código: Defina el URI de superficie para la aplicación
- Compruebe que el flujo de datos tiene habilitado el servicio AJO
Para Opción C (Nodo De Decisión De Recorrido):
- Configure las superficies de canal para cada canal utilizado en el recorrido (correo electrónico, push, SMS o web)
- Cada acción de mensaje de recorrido requiere una superficie de canal activa correspondiente
Documentación de Experience League
Fase 5: Configuración de contenido y envío
Función de la aplicación: AJO: Creación de mensajes, AJO: Ejecución de campañas
En esta fase se diseñan las plantillas de mensaje o las superficies de experiencia que muestran la oferta seleccionada y, a continuación, se configura el mecanismo de entrega (campaña, recorrido o experiencia basada en código).
Decisión: enfoque del contenido para la representación de ofertas
Determine cómo se debe integrar el contenido de la oferta en el mensaje o la experiencia.
Decisión: Tipo de campaña (solo opción A)
Determine si se trata de una campaña de marketing programada o de una campaña activada por una API.
Dónde divergen las opciones
Para La Opción A (Toma De Decisiones Por Correo Electrónico):
-
Crear el mensaje de correo electrónico con el Designer de correo electrónico
- IU: Campañas > Crear campaña > Seleccionar correo electrónico > Editar contenido
- Inserte un componente de decisión de oferta en el diseño de correo electrónico para definir la zona de colocación
- Añadir tokens de personalización para el contenido de nivel de perfil (nombre, nivel de lealtad)
- Configuración de la línea de asunto y el preencabezado con personalización opcional
-
Creación y configuración de la campaña
- IU: Campañas > Crear campaña > Programado o activado por API
- Enlace la audiencia de destinatario y seleccione la superficie de canal
- Establecer la programación de ejecución o la configuración del déclencheur de API
- Revisión y activación de la campaña
Para Opción B (Web/Aplicación En Tiempo Real):
-
Configurar la experiencia basada en código o el canal web
- IU: Campañas > Crear campaña > Experiencia basada en código (o web)
- Vinculación de la política de decisión a la superficie de experiencia
- Defina el formato de renderización (respuesta JSON para código basado; editor visual para canal web)
-
Implementar el procesamiento del lado del cliente
- Usar la respuesta de Web SDK
sendEventpara recuperar la oferta seleccionada - Procesar el contenido de la oferta en la ubicación designada en la página
- Implementación del rastreo de clics y impresiones
- Usar la respuesta de Web SDK
Para Opción C (Nodo De Decisión De Recorrido):
-
Diseño del recorrido con un nodo de decisión
- IU: Recorrido > Crear Recorrido > Agregar nodo de decisión
- Configure el nodo de decisión para invocar la directiva de decisión desde la fase 3
-
Añadir nodos de acción de mensaje después de la decisión
- Configurar acciones de correo electrónico, push o SMS que hagan referencia a la oferta seleccionada
- Agregar pasos de espera, condiciones o ramas en función de la participación en la oferta
-
Publicación del recorrido
Documentación de Experience League
Fase 6: Prueba y validación
Función de la aplicación: AJO: Decisioning, AJO: Message Authoring
Esta fase valida que el motor de decisión devuelve las ofertas correctas para los perfiles de prueba y que el contenido de la oferta se procesa correctamente en cada canal de entrega.
Lógica de toma de decisiones de prueba
Utilice perfiles de prueba con atributos conocidos para comprobar que se han seleccionado las ofertas correctas en función de la idoneidad y la clasificación.
- Cree perfiles de prueba que coincidan con diferentes criterios de idoneidad (por ejemplo, nivel Gold, nivel Silver, usuario de prueba)
- Verifique que cada perfil de prueba reciba la oferta esperada
- Compruebe que los perfiles que no coinciden con ninguna regla de idoneidad reciben la oferta de reserva
Prueba de representación de contenido
Previsualice el contenido de la oferta en cada canal de entrega.
- Para la opción A: utilice la previsualización de correo electrónico con perfiles de prueba para verificar que el contenido de la oferta se procese correctamente
- Para la opción B: Probar la respuesta de Edge Decisioning en un entorno de ensayo
- Para la opción C: utilice el modo de prueba recorrido para comprobar que el nodo de decisión se selecciona correctamente
Validar el seguimiento de impresiones
Confirme que se está realizando un seguimiento de las impresiones, los clics y las conversiones de la oferta.
- Verificar que los eventos de interacción de ofertas aparezcan en los conjuntos de datos de seguimiento
- Confirmar atribución entre impresiones de oferta y conversiones descendentes
Documentación de Experience League
Fase 7: Configurar la creación de informes y la monitorización del rendimiento
Función de aplicación: AJO: Informes y análisis de rendimiento
Esta fase configura los informes para rastrear la distribución de selección de ofertas, las tasas de aceptación, el impacto de conversión y las tasas de reserva. Esta fase abarca tanto los informes nativos de AJO como el análisis entre canales basado en CJA.
Decisión: método de creación de informes
Determine qué herramientas de creación de informes se necesitan para el análisis del rendimiento de las ofertas.
Detalles de configuración clave
-
Creación de informes nativos de AJO: supervise el rendimiento de la campaña o del recorrido mediante informes integrados.
- IU: Campañas > Seleccionar campaña > Informe de todos los tiempos (o Informe en vivo)
- Revise las métricas específicas de la oferta: impresiones por oferta, tasa de pulsaciones por oferta, tasa de reserva
- Monitorización de la entrega funnel: Objetivos > Enviado > Entregado > Aperturas > Clics
-
Análisis de CJA (recomendado): genere paneles de rendimiento de ofertas en canales múltiples.
- Configuración de una conexión CJA que incluya conjuntos de datos de interacción de ofertas AJO
- Cree una vista de datos con dimensiones específicas de la oferta (nombre de la oferta, ubicación, decisión) y métricas (impresiones, clics, conversiones)
- Cree un análisis del espacio de trabajo para: distribución de la selección de ofertas, tasa de aceptación por segmento, impacto en los ingresos, coherencia de la oferta en canales múltiples
Documentación de Experience League
Consideraciones sobre la implementación
Esta sección cubre las barreras, los escollos comunes, las prácticas recomendadas y las decisiones de compensación para las implementaciones de Offer Decisioning.
Protecciones y límites
Tenga en cuenta las siguientes limitaciones y protecciones de la plataforma al planificar la implementación.
- Máximo de 10 000 ofertas personalizadas aprobadas por espacio aislado: protecciones de administración de decisiones
- Máximo de 30 colocaciones por decisión
- Máximo de 30 ámbitos de recopilación por solicitud de decisión
- Los modelos de clasificación de IA requieren un mínimo de 1000 eventos de conversión para la formación.
- Los contadores de límite de oferta pueden tener un retraso de hasta unos segundos en escenarios de alto rendimiento
- Las decisiones de Edge se limitan a atributos de perfil disponibles en el almacén de perfiles Edge
- Máximo de 4000 definiciones de segmento por zona protegida — Protecciones de plataforma
- Solo puede haber una política de combinación activa en Edge por zona protegida
- Máximo de 500 campañas activas por zona protegida
- Límite de tasa de entrada de recorrido: 5000 perfiles por segundo
- Máximo de 10 superficies de canal por tipo de canal y zona protegida
Peligros comunes
Evite estos problemas que se producen con frecuencia durante la implementación.
- La decisión siempre devuelve la oferta de reserva: Esto generalmente significa que las ofertas personalizadas no están aprobadas, están fuera de su intervalo de fechas de validez o las reglas de elegibilidad no coinciden con los atributos del perfil de prueba. Compruebe cada condición: estado de aprobación, intervalo de fechas y precisión de expresión de regla de segmento. Compruebe también que no se han alcanzado los límites.
- La oferta no aparece en la colección: Asegúrese de que la oferta se haya etiquetado con el calificador de colección correcto y de que el filtro de colección coincida. Las ofertas deben estar etiquetadas y aprobadas para aparecer en ámbitos de decisión basados en colecciones.
- Fórmula de clasificación no aplicada: Compruebe que la fórmula es sintácticamente válida y hace referencia a atributos de perfil accesibles. Los errores de fórmula vuelven silenciosamente a la clasificación basada en prioridades sin ningún error visible.
- La entrega de Edge devuelve la personalización vacía: Asegúrese de que la secuencia de datos esté configurada con el servicio Adobe Journey Optimizer habilitado y de que el ámbito de decisión tenga el formato correcto. Compruebe que existe la política de combinación activa para extremos.
- Ofertas incoherentes en todos los canales: Si se usan directivas de decisión independientes por canal, el mismo perfil puede recibir ofertas diferentes. Utilice una única política de decisión en todos los canales para mantener la coherencia o acepte divergencias intencionadas basadas en ubicaciones específicas del canal.
- El contenido de la oferta no se representa en el correo electrónico: Compruebe que la oferta tenga una representación de contenido que coincida con el formato de ubicación del correo electrónico (HTML o URL de imagen). La falta de representaciones da como resultado zonas de colocación en blanco.
Prácticas recomendadas
Siga estas recomendaciones para una implementación correcta de Offer Decisioning.
- Comience con un pequeño catálogo de ofertas e itere: Empiece con 5-10 ofertas y amplíe a medida que se valida el marco de toma de decisiones. Esto simplifica la resolución de problemas y garantiza que las reglas de idoneidad funcionen correctamente antes de escalarlas.
- Use calificadores de colección de forma estratégica: Etiquete ofertas por categoría (por ejemplo, "Adquisición", "Retención", "Ampliación de venta") para habilitar ámbitos de decisión flexibles basados en colecciones que se puedan reutilizar en campañas y recorridos.
- Cree siempre ofertas de reserva significativas: las ofertas de reserva no son solo una red de seguridad; son la experiencia predeterminada para perfiles que no coinciden con ninguna regla de elegibilidad. Invierta en contenido de reserva que proporcione valor incluso sin personalización.
- Diseñe reglas de elegibilidad para que sean mutuamente excluyentes siempre que sea posible — Cuando varias ofertas tienen elegibilidad superpuesta, la estrategia de clasificación se vuelve crítica. Si los requisitos comerciales dictan una oferta específica para un segmento específico, las reglas de elegibilidad se excluyen mutuamente en lugar de depender únicamente de la clasificación.
- Prueba con perfiles representativos de Edge para la opción B: los perfiles de Edge contienen un subconjunto de atributos de perfil de hub. Haga pruebas con perfiles que tengan atributos disponibles del perímetro para garantizar que la idoneidad se evalúe correctamente en la producción.
- Monitorizar tasas de reserva como métrica de estado: una tasa de reserva alta (por encima del 20-30%) indica que el catálogo de ofertas no cubre suficientes segmentos de clientes. Expanda el catálogo de ofertas o amplíe las reglas de idoneidad.
- Directivas de decisión de versión en lugar de editar las activas: cree una nueva versión de directiva de decisión en lugar de modificar una activa. Esto evita interrupciones en las campañas en directo y permite la comparación A/B de las estrategias de decisión.
Decisiones de compensación
Tenga en cuenta las siguientes compensaciones cuando tome decisiones sobre arquitectura y configuración.
Precisión de elegibilidad frente a cobertura de ofertas
Las reglas de elegibilidad estrictas garantizan que cada oferta alcance solo los perfiles más relevantes, pero puede dar como resultado altas tasas de reserva cuando los perfiles no coinciden con ninguna oferta. Las reglas de aceptación generales maximizan la cobertura de la oferta pero reducen la precisión de la personalización.
- Favoritos de elegibilidad ajustados: mayores tasas de aceptación, mejor personalización, menor fatiga de ofertas
- Favoritos de elegibilidad generales: Tasas de reserva más bajas, más perfiles reciben ofertas personalizadas y administración de reglas más sencilla
- Recomendación: Comience con reglas de elegibilidad más amplias y apriételas en función de los datos de rendimiento. Monitorice las tasas de reserva y las tasas de aceptación para encontrar el equilibrio adecuado. Utilice estrategias de clasificación para diferenciar entre ofertas ampliamente aptas.
Clasificación basada en prioridades y clasificación por IA
La clasificación basada en prioridades proporciona al negocio control total sobre las ofertas mostradas, mientras que la clasificación basada en IA optimiza la conversión, pero reduce el control humano sobre la selección de ofertas.
- Favoritos basados en prioridades: Control empresarial, predictibilidad, sin requisito de datos de capacitación, implementación inmediata
- Favoritos de clasificación de IA: Optimización de conversión, descubrimiento de patrones inesperados, adaptación automática a un comportamiento cambiante del cliente
- Recomendación: Use la clasificación basada en prioridades para los lanzamientos iniciales y las ofertas confidenciales según la normativa, donde el control empresarial es primordial. La transición a IA se clasifica para casos de uso de alto volumen y optimizado para el rendimiento una vez que haya disponibles suficientes datos de conversión (más de 1000 eventos).
Política de decisión única frente a políticas de decisión por canal
Una única política de decisión garantiza la coherencia de la oferta en todos los canales, pero restringe la optimización por canal. Las políticas por canal permiten la clasificación y la idoneidad específicas del canal, pero arriesgan experiencias de cliente incoherentes.
- Favoritos de directiva única: coherencia en canales múltiples, administración más sencilla, informes unificados
- Las políticas por canal favorecen: Clasificación optimizada para el canal, idoneidad específica para el canal (por ejemplo, ofertas solo para la web), iteración independiente
- Recomendación: Comience con una directiva de decisión única para la coherencia entre canales. Cree directivas por canal únicamente cuando los requisitos empresariales exijan estrategias de oferta específicas del canal (por ejemplo, ventas flash exclusivas de la web).
Toma de decisiones en Hub (Opción A/C) vs. toma de decisiones en Edge (Opción B)
Hub Decisioning tiene acceso al perfil completo, pero funciona en el momento de la entrega. Edge Decisioning funciona en tiempo real con latencia de subsegundos, pero se limita a atributos de perfil disponibles para Edge.
- Favoritos de Hub Decisioning: Acceso a datos de perfil completos, reglas de elegibilidad complejas, volúmenes de campañas por lotes
- Favoritos en la toma de decisiones de Edge: Contexto en tiempo real, personalización durante la sesión, respuesta en segundos
- Recomendación: Utilice la toma de decisiones de concentrador para canales salientes (correo electrónico, push) donde los datos de perfil completos mejoran la relevancia de la oferta. Utilice Edge Decisioning para canales entrantes (web, aplicación) donde la respuesta en tiempo real es crítica. Asegúrese de que las reglas de idoneidad para el uso de Edge solo utilicen atributos disponibles en Edge.
Documentación relacionada
Los siguientes recursos proporcionan detalles adicionales sobre los componentes utilizados en este patrón de caso de uso.