Show Menu
SUJETS×

Événements Triggers

Événements de traitement dans JavaScript

Fichier JavaScript

Pipeline utilise une fonction JavaScript pour traiter chaque message. Cette fonction est définie par l’utilisateur.
Elle est configurée dans l’option NmsPipeline_Config sous l’attribut « JSConnector ». Ce JavaScript est appelé chaque fois qu’un événement est reçu. Il est exécuté par le processus pipelined.
L’exemple de fichier JS est cus:triggers.js.

Fonction JavaScript

Le JavaScript pipelined doit commencer avec une fonction spécifique.
Cette fonction est appelée une fois pour chaque événement :
function processPipelineMessage(xmlTrigger) {}

Elle doit être renvoyée comme
<undefined/>

Redémarrez pipelined après avoir modifié le fichier JS.

Format des données Trigger

Les données trigger sont transmises à la fonction JS. Elles sont au format XML.
  • L’attribut @triggerId contient le nom du trigger.
  • L’élément enrichments au format JSON contient les données générées par Analytics et est attaché au déclencheur.
  • @offset est le « pointeur » vers le message. Il indique l’ordre du message dans la file d’attente.
  • **@partitio**n est un conteneur de messages dans la file d’attente. Le décalage est relatif à une partition.
    Il y a environ 15 partitions dans la file d'attente.
Exemple :
<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>

Format des données d'enrichissement

Il s’agit d’un exemple spécifique de différentes implémentations possibles.
Le contenu est défini dans Analytics pour chaque déclencheur. Il est au format JSON. Par exemple, dans un déclencheur LogoUpload_uploading_Visits :
  • eVar01 peut contenir l’identifiant de nouvel acheteur utilisé pour la réconciliation avec les destinataires Campaign. Il est au format Chaîne.
    Il doit être réconcilié pour trouver l'identifiant de nouvel acheteur, qui est la clé principale.
  • timeGMT peut contenir l’heure du déclencheur côté Analytics. Il est au format Epoch UTC (secondes depuis le 01/01/1970 UTC).
Exemple :
{
 "analyticsHitSummary": {
 "dimensions": {
 "eVar01": {
 "type": "string",
 "data": ["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],
 "name": " eVar01",
 "source": "session summary"
 },
 "timeGMT": {
 "type": "int",
 "data": [1469164186, 1469164195],
 "name": "timeGMT",
 "source": "session summary"
 }
 },
 "products": {}
 }
 }

Ordre de traitement des événements

Les événements sont traités un par un, par ordre de décalage. Chaque thread du pipelined traite une partition différente.
Le « décalage » du dernier événement récupéré est stocké dans la base de données. Par conséquent, si le processus est arrêté, il redémarre à partir du dernier message. Ces données sont stockées dans le schéma intégré xtk:pipelineOffset.
Ce pointeur est spécifique à chaque instance et à chaque consommateur. Par conséquent, lorsque de nombreuses instances accèdent au même pipeline avec des consommateurs différents, ils reçoivent tous les messages et dans le même ordre.
Le paramètre « consumer » de l’option de pipeline identifie l’instance appelante.
Actuellement, il n'existe aucun moyen d'avoir des files d'attente différentes pour des environnements distincts tels que 'staging' ou 'dev'.

Journalisation et gestion des erreurs

Les logs tels que logInfo() sont dirigés vers le log pipelined. Des erreurs telles que logError() sont écrites dans le log pipelined et entraînent le placement de l’événement dans une file d’attente de reprise. Vérifiez le log en pipeline. Les messages en erreur sont repris plusieurs fois dans la durée définie dans les options pipelined.
À des fins de débogage et de surveillance, les données de déclenchement complètes sont écrites dans la table des déclencheurs. Elles se trouvent dans le champ « data » au format XML. Une autre solution consiste à utiliser un logInfo() contenant les données de déclenchement dans le même but.

Analyse des données

Cet exemple de code JS analyse l’eVar01 dans les enrichissements.
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]
 }
 }
 (…)
 }

Faites attention lors de l’analyse pour éviter toute erreur. Puisque ce code est utilisé pour tous les déclencheurs, la plupart des données ne sont pas requises. Par conséquent, il peut être laissé vide lorsqu’il n’est pas présent.

Stockage du déclencheur

Il s'agit d’un exemple spécifique de différentes implémentations possibles.
Cet exemple de code JS enregistre le déclencheur dans la base de données.
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/>; 
 }

Contraintes

Les performances de ce code doivent être optimales puisqu’il s’exécute à des fréquences élevées. Des effets négatifs potentiels peuvent exister pour d’autres activités marketing, tout particulièrement si vous traitez plus d’un million d’événements de déclencheur par heure sur le serveur Marketing ou si le paramétrage n’est pas correct.
Le contexte de ce JavaScript est limité. Toutes les fonctions de l’API ne sont pas disponibles. Par exemple, getOption() ou getCurrentdate() ne fonctionnent pas.
Pour accélérer le traitement, plusieurs threads de ce script sont exécutés en même temps. Le code doit être sécurisé par rapport aux threads.

Stockage des événements

Il s’agit d’un exemple spécifique de différentes implémentations possibles.

Schéma d’événement de pipeline

Les événements sont stockés dans une table de base de données. Elle est utilisée par les campagnes marketing pour cibler des clients et pour enrichir les emails à l’aide de déclencheurs. Bien que chaque déclencheur puisse avoir une structure de données distincte, tous les déclencheurs peuvent être conservés dans une seule table. Le champ triggerType identifie à partir duquel les données sont déclenchées.
Voici un exemple de code de schéma pour cette table :
Attribut
Type
Libellé
Description
pipelineEventId
Long
Clé primaire
Clé primaire interne du déclencheur.
data
Memo
Données de déclenchement
Contenu complet des données de déclenchement au format XML. À des fins de débogage et d’audit.
triggerType
Chaîne 50
TriggerType
Nom du déclencheur. Identifie le comportement du client sur le site web.
shopper_id
Chaîne 32
shopper_id
Identifiant interne du nouvel acheteur Défini par le workflow de réconciliation. Si la valeur est nulle, cela signifie que le client est inconnu dans Campaign.
shopper_key
Long
shopper_key
Identifiant externe du nouvel acheteur capturé par Analytics.
created
Datetime
Created
Heure à laquelle l’événement a été créé dans Campaign.
lastModified
Datetime
Dernière modification
Dernière modification de l’événement dans Adobe.
timeGMT
Datetime
Date et heure
Heure à laquelle l’événement a été généré dans Analytics.

Affichage des événements

Les événements peuvent être affichés avec un formulaire simple basé sur le schéma des événements.
Le nœud d’événement de pipeline n’est pas natif et doit être ajouté, de même que le formulaire associé doit être créé dans Campaign. Ces opérations sont limitées aux utilisateurs experts uniquement. Pour plus d’informations à ce sujet, reportez-vous aux sections suivantes : Arborescence de navigation et Éditer les formulaires .

Traitement des événements

Workflow de réconciliation

La réconciliation est le processus de mise en correspondance du client d’Analytics dans la base de données Campaign. Par exemple, les critères de correspondance peuvent être shopper_id.
Pour des raisons de performances, la correspondance doit être effectuée en mode batch par un workflow. La fréquence doit être définie sur 15 minutes pour optimiser la charge de travail. Par conséquent, le délai entre la réception d’un événement dans Adobe Campaign et son traitement par un workflow marketing est de 15 minutes maximum.

Options de réconciliation des unités dans JavaScript

En théorie, il est possible d’exécuter la requête de réconciliation pour chaque déclencheur dans le JavaScript. Les performances sont ainsi supérieures et les résultats sont plus rapides. Cela peut être nécessaire pour des cas pratiques spécifiques lorsqu’une grande réactivité est requise.
Il peut être difficile de le faire si aucun index n'est défini sur shopper_id. Si les critères se trouvent sur un serveur de base de données distinct de celui du serveur marketing, il utilise un lien de base de données, qui offre de faibles performances.

Workflow de purge

Les déclencheurs étant traités dans l’heure, il n’y a aucune raison de les conserver longtemps. Le volume peut être d’environ 1 million de déclencheurs par heure. Cela explique pourquoi un workflow de purge doit être mis en place. La purge supprime tous les déclencheurs qui ont plus de trois jours et s’exécute une fois par jour.

Workflow de campagne

Le workflow de campagne de déclenchement est souvent similaire aux autres campagnes récurrentes qui ont été utilisées. Par exemple, il peut débuter avec une requête sur les déclencheurs à la recherche d’événements spécifiques au cours de la dernière journée. Cette cible est utilisée pour envoyer l’email. Les enrichissements ou les données peuvent provenir du déclencheur. Il peut être utilisé en toute sécurité par Marketing car il ne nécessite aucune configuration.