Show Menu
TEMAS×

Eventos de activadores

Procesamiento de eventos en JavaScript

Archivo JavaScript

La canalización utiliza una función de JavaScript para procesar cada mensaje. Esta función está definida por el usuario.
Se configura en la opción NmsPipeline_Config bajo el atributo "JSConnector". Se llama a este javascript cada vez que se recibe un evento. Está dirigido por el proceso pipelined .
El archivo JS de muestra es cus:triggers.js.

Función JavaScript

El pipelined Javascript debe iniciarse con una función específica.
Esta función se llama una vez por cada evento:
function processPipelineMessage(xmlTrigger) {}

Debería devolverse como
<undefined/>

Reinicie pipelined después de editar el JS.

Activar formato de datos

Los datos trigger se pasan a la función JS. Está en formato XML.
  • El atributo @triggerId contiene el nombre del trigger.
  • El elemento enriquecimientos en formato JSON contiene los datos generados por Analytics y se adjunta al activador.
  • @offset es el "puntero" del mensaje. Indica el orden del mensaje en la cola.
  • **@partitio**n es un contenedor de mensajes dentro de la cola. El desplazamiento es relativo a una partición.
    Hay unas 15 particiones en la cola.
Ejemplo:
<trigger offset="1500435" partition="4" triggerId="LogoUpload_1_Visits_from_specific_Channel_or_ppp">
 <enrichments>{"analyticsHitSummary":{"dimensions":{" eVar01":{"type":"string","data":["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],"name":" eVar01","source":"session summary"}, "timeGMT":{"type":"int","data":[1469164186,1469164195],"name":"timeGMT","source":"session summary"}},"products":{}}}</enrichments>
 <aliases/>
 </trigger>

Formato de datos de enriquecimiento

Es un ejemplo específico de varias implementaciones posibles.
El contenido se define en Analytics para cada activador. Está en formato JSON. Por ejemplo, un activador LogoUpload_upload_Visits:
  • eVar01 puede contener el ID del comprador que se utiliza para reconciliar con destinatarios de Campaign. Está en formato de cadena.
    Debe conciliarse para encontrar el ID del comprador, que es la clave primaria.
  • timeGMT puede contener la hora del activador en el lado de Analytics. Está en formato UTC Epoch (segundos desde 01/01/1970 UTC).
Ejemplo:
{
 "analyticsHitSummary": {
 "dimensions": {
 "eVar01": {
 "type": "string",
 "data": ["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],
 "name": " eVar01",
 "source": "session summary"
 },
 "timeGMT": {
 "type": "int",
 "data": [1469164186, 1469164195],
 "name": "timeGMT",
 "source": "session summary"
 }
 },
 "products": {}
 }
 }

Orden del procesamiento de eventos

Los eventos se procesan de a uno, por orden de desplazamiento. Cada subproceso del pipelined procesa una partición diferente.
El "desplazamiento" del último evento recuperado se almacena en la base de datos. Por lo tanto, si el proceso se detiene, se reinicia a partir del último mensaje. Estos datos se almacenan en el esquema integrado xtk:pipelineOffset.
Este puntero es específico para cada instancia y cada consumidor. Por lo tanto, cuando muchas instancias acceden a la misma canalización con diferentes consumidores, cada una recibe todos los mensajes y en el mismo orden.
El parámetro "consumidor" de la opción de canalización identifica la instancia que realiza la llamada.
Actualmente, no hay forma de tener diferentes colas para entornos separados como "staging" o "dev".

Registro y gestión de errores

Los registros como logInfo() se dirigen al registro pipelined . Los errores como logError() se escriben en el registro pipelined y hacen que el evento se coloque en una cola de reintentos. Compruebe el registro de canalización. Los mensajes de error se vuelven a intentar varias veces en la duración establecida en las opciones pipelined .
Para fines de depuración y monitoreo, los datos de desencadenador completos se escriben en la tabla de desencadenadores. Se encuentra en el campo "data" en formato XML. De forma alternativa, el logInfo() que contenga los datos desencadenadores tiene el mismo propósito.

Análisis de los datos

Este código JS de muestra analiza eVar01 en los enriquecimientos.
function processPipelineMessage(xmlTrigger)
 {
 (…)
 var shopper_id = ""
 if (xmlTrigger.enrichments.length() > 0)
 {
 if (xmlTrigger.enrichments.toString().match(/eVar01/) != undefined)
 {
 var enrichments = JSON.parse(xmlTrigger.enrichments.toString())
 shopper_id = enrichments.analyticsHitSummary.dimensions. eVar01.data[0]
 }
 }
 (…)
 }

Tenga cuidado al analizar para evitar errores. Dado que este código se utiliza para todos los activadores, la mayoría de los datos no son obligatorios. Por lo tanto, se puede dejar vacío cuando no esté presente.

Almacenamiento del activador

Es un ejemplo específico de varias implementaciones posibles.
Este código JS de muestra guarda el activador en la base de datos.
function processPipelineMessage(xmlTrigger)
 {
 (…)
 var event = 
 <pipelineEvent
 xtkschema = "cus:pipelineEvent"
 _operation = "insert"
 created = {timeNow}
 lastModified = {timeNow}
 triggerType = {triggerType}
 timeGMT = {timeGMT}
 shopper_id = {shopper_id}
 data = {xmlTrigger.toXMLString()}
 />
 xtk.session.Write(event)
 return <undef/>; 
 }

Restricciones

El rendimiento de este código debe ser óptimo, ya que se ejecuta a altas frecuencias. Existen posibles efectos negativos de otras actividades de marketing. Especialmente si se procesan más de un millón de eventos de activación por hora en el servidor de marketing. O si no está correctamente ajustado.
El contexto de este JavaScript es limitado. No todas las funciones de la API están disponibles. Por ejemplo, getOption() o getCurrentdate() no funcionan.
Para permitir un procesamiento más rápido, se ejecutan varios subprocesos de esta secuencia de comandos al mismo tiempo. El código debe ser seguro para subprocesos.

Almacenamiento de los eventos

Es un ejemplo específico de varias implementaciones posibles.

esquema de evento de canalización

Los Eventos se almacenan en una tabla de la base de datos. Se utiliza en campañas de marketing para clientes de destinatario y enriquece los correos electrónicos mediante activadores. Aunque cada activador puede tener una estructura de datos distinta, todos los activadores se pueden guardar en una sola tabla. El campo triggerType identifica de dónde se originan los datos.
Este es un ejemplo de código de esquema para esta tabla:
Atributo
Tipo
Etiqueta
Descripción
pipelineEventId
Largo
Clave principal
La clave primaria interna del activador.
datos
Nota
Activar datos
El contenido completo de los datos desencadenadores en formato XML. Para fines de depuración y auditoría.
triggerType
Cadena 50
TriggerType
Nombre del activador. Identifica el comportamiento del cliente en el sitio web.
shopper_id
Cadena 32
shopper_id
Identificador interno del comprador. Definido por el flujo de trabajo de reconciliación. Si es cero, significa que el cliente es desconocido en Campaign.
shopper_key
Largo
shopper_key
El Identificador externo del comprador según Analytics.
created
Datetime
Creado
Hora a la que se creó el evento en Campaign.
lastModified
Datetime
Última modificación
La última vez que se modificó el evento en Adobe.
timeGMT
Datetime
Marca de tiempo
Hora a la que se generó el evento en Analytics.

Visualización de los eventos

Los eventos se pueden mostrar con un formulario sencillo basado en el esquema de eventos.
El nodo Evento de canalización no está integrado y debe añadirse, así como el formulario relacionado debe crearse en Campaign. Estas operaciones están restringidas únicamente a usuarios expertos. Para obtener más información, consulte estas secciones: Jerarquía de navegación y edición de formularios .

Procesamiento de los eventos

Flujo de trabajo de reconciliación

La reconciliación es el proceso de hacer coincidir el cliente de Analytics con la base de datos de Campaign. Por ejemplo, los criterios para la coincidencia pueden ser shopper_id.
Por motivos de desempeño, la coincidencia debe realizarse en modo por lotes mediante un flujo de trabajo. La frecuencia debe establecerse en 15 minutos para optimizar la carga de trabajo. Como consecuencia, el retraso entre una recepción de evento en Adobe Campaign y su procesamiento por un flujo de trabajo de marketing es de hasta 15 minutos.

Opciones para la reconciliación de unidades en JavaScript

En teoría, es posible ejecutar la consulta de reconciliación para cada activador en JavaScript. Tiene un mayor impacto en el rendimiento y ofrece resultados más rápidos. Podría ser necesario para casos de uso específicos cuando sea necesaria la reactividad.
Puede resultar difícil hacerlo si no se establece ningún índice en shopper_id. Si los criterios se encuentran en un servidor de base de datos independiente al servidor de marketing, utiliza un vínculo de base de datos, que tiene un rendimiento deficiente.

Flujo de trabajo de depuración

Los activadores se procesan dentro de la hora, por lo que no hay razón para mantenerlos durante mucho tiempo. El volumen puede ser de aproximadamente 1 millón de activadores por hora. Esto explica por qué se debe implementar un flujo de trabajo de depuración. La depuración elimina todos los activadores que tengan más de tres días y se ejecuta una vez al día.

Flujos de trabajo de la campaña

El flujo de trabajo de la campaña de desencadenadores suele ser similar al de otras campañas recurrentes que se han utilizado. Por ejemplo, puede establecer un inicio con una consulta en los activadores que buscan eventos específicos durante el último día. Ese destinatario se utiliza para enviar el correo electrónico. Los enriquecimientos o datos pueden provenir del activador. Marketing puede utilizarla de forma segura, ya que no requiere ninguna configuración.