La administración de ofertas en Adobe Campaign requiere una administración cuidadosa para funcionar de forma eficaz. Para evitar problemas, debe encontrar un equilibrio entre el número de contactos y el número de categorías de ofertas y ofertas.
Esta sección presenta las prácticas recomendadas para administrar el Interacción en Adobe Campaign, incluidas las reglas de idoneidad, los filtros predefinidos, las actividades de flujo de trabajo y las opciones de base de datos.
Cuándo implementación y configuración de interacciones, debe tener en cuenta las siguientes recomendaciones:
A continuación se enumeran algunas prácticas recomendadas al trabajar con reglas de elegibilidad:
A continuación se enumeran algunas prácticas recomendadas con respecto a tabla de propuestas:
Esta sección contiene consejos más detallados sobre la administración de ofertas y el uso del módulo de interacción en Adobe Campaign.
Cuando se incluyen ofertas en las entregas, las ofertas generalmente se seleccionan de forma ascendente en el flujo de trabajo de Campaign a través de una Enriquecimiento actividad de flujo de trabajo (u otra actividad similar).
Al seleccionar ofertas en una Enriquecimiento actividad, puede elegir qué espacio de oferta utilizar. Sin embargo, independientemente del espacio de oferta seleccionado, el menú de personalización de la entrega depende del espacio de oferta configurado en la entrega.
En el ejemplo siguiente, el espacio de oferta seleccionado en la entrega es Email (Environment - Recipient):
Si el espacio de oferta seleccionado en la entrega no tiene una función de renderización HTML configurada, no la va a ver en el menú de entrega y no va a estar disponible para su selección. Esto es independiente del espacio de oferta seleccionado en la Enriquecimiento actividad.
En el ejemplo siguiente, la función de renderización HTML está disponible en la lista desplegable porque el espacio de oferta seleccionado en la entrega tiene una función de renderización:
Esta función inserta un código como: <%@ include proposition="targetData.proposition" view="rendering/html" %>
.
Al seleccionar la propuesta, el valor del atributo de view es el siguiente:
Cuando se incluyen varios espacios de oferta en una entrega por correo electrónico único y algunos de ellos tienen funciones de renderización y otros no, se debe recordar qué ofertas utilizan qué espacios de oferta y qué espacios de oferta tienen funciones de renderización.
Por lo tanto, para evitar cualquier problema, se recomienda que todos los espacios de oferta tengan una función de renderización HTML definida, aunque el espacio de oferta solo requiera contenido HTML.
Los espacios de oferta tienen la capacidad de almacenar datos en la tabla de propuesta cuando se generan o aceptan propuestas:
Sin embargo, esto solo se aplica a las interacciones entrantes.
También es posible almacenar datos adicionales en la tabla de propuestas cuando se utilizan interacciones salientes y también cuando se utilizan ofertas salientes sin el módulo de interacción.
Cualquier campo de la tabla temporal del flujo de trabajo cuyo nombre coincida con el nombre de un campo de la tabla de propuestas se copia en el mismo campo de la tabla de propuestas.
Por ejemplo, al seleccionar una oferta manualmente (sin interacción) en una Enriquecimiento actividad de flujo de trabajo, los campos estándar se definen de la siguiente manera:
Se pueden añadir campos adicionales, como un @rank
campo:
Porque hay un campo en la tabla de propuestas llamado @rank
, se copiará el valor de la tabla temporal del flujo de trabajo.
Para obtener más información sobre el almacenamiento de campos adicionales en la tabla de propuestas, consulte esta sección.
En el caso de las ofertas salientes con interacción, esto resulta útil cuando se seleccionan varias ofertas y se desea registrar en qué orden se van a mostrar en un mensaje de correo electrónico.
También puede almacenar metadatos adicionales directamente en la tabla de propuestas, como el nivel de gasto actual, para mantener registros históricos sobre el gasto en el momento en que se generaron las ofertas.
Cuando se utiliza la interacción saliente, la variable @rank
se puede añadir un campo de, como en el ejemplo anterior, pero su valor se establece automáticamente en función del orden devuelto por Interaction. Por ejemplo, si utiliza Interacción para seleccionar tres ofertas, la variable @rank
tendrá los valores 1, 2 y 3 devueltos.
Al utilizar la interacción y seleccionar ofertas manualmente, el usuario puede combinar ambos métodos. Por ejemplo, el usuario puede configurar manualmente la variable @rank
el campo debe ser 1 para la oferta seleccionada manualmente y utilizar una expresión como "1 + @rank"
para las ofertas devueltas por interacción. Si damos por supuesto que la interacción selecciona tres ofertas, las ofertas devueltas por ambos métodos se van a clasificar de 1 a 4:
Al ampliar el esquema nms:offer, asegúrese de seguir la estructura predeterminada ya configurada:
Defina cualquier campo nuevo para almacenamiento de contenido en <element name="view">
.
Cada nuevo campo debe definirse dos veces. Una vez como campo XML normal y una vez como campo XML CDATA con “_jst” anexado al nombre. Por ejemplo:
<element label="Price" name="price" type="long" xml="true"/>
<element advanced="true" label="Script price" name="price_jst" type="CDATA" xml="true"/>
Todos los campos que contengan direcciones URL que se van a rastrear deben colocarse bajo <element name="trackedUrls">
que se encuentra en <element name="view" >
.