Show Menu
SUJETS×

Triggers événements

é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.
Il est configuré dans l'option NmsPipeline_Config sous l'attribut "JSConnector". Ce javascript est appelé chaque fois qu'un événement est reçu. Il est géré par le processus pipeliné.
L'exemple de fichier JS est cus:triggers.js.

JavaScript, fonction

Le script Javascript du pipeline doit être début avec une fonction spécifique.
Cette fonction est appelée une fois pour chaque événement :
function processPipelineMessage(xmlTrigger) {}

Il doit retourner comme
<undefined/>

Redémarrez l’oléoduc après avoir modifié la JS.

Format de données de déclenchement

Les trigger données sont transmises à la fonction JS. Il est au format XML.
  • L'attribut @triggerId contient le nom du trigger.
  • L’élément enrichissements au format JSON contient les données générées par Analytics et est associé 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 de 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 Shopper utilisé pour la conciliation avec les destinataires Campaign. Il est au format Chaîne.
    Il doit être rapproché pour trouver l'identifiant Shopper, qui est la clé principale.
  • timeGMT peut contenir l’heure du déclencheur côté Analytics. Il est au format Epoque 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 pipeline 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 nombreux utilisateurs 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 "consommateur" 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 "test" ou "dev".

Journalisation et gestion des erreurs

Les journaux tels que logInfo() sont dirigés vers le journal en pipeline. Des erreurs telles que logError() sont consignées dans le journal en file d'attente et entraînent le placement du événement dans une file d'attente de nouvelle tentative. Vérifier le journal en pipeline. Les messages en erreur sont répétés plusieurs fois dans la durée définie dans les options en pipeline.
À des fins de débogage et de surveillance, les données de déclenchement complètes sont écrites dans la table de déclenchement. Il se trouve dans le champ "données" 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]
 }
 }
 (…)
 }

Soyez prudent lors de l’analyse pour éviter les erreurs. 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. D'autres activités marketing peuvent avoir des effets négatifs. Surtout si vous traitez plus d’un million de événements de déclenchement par heure sur le serveur Marketing. Ou s'il n'est pas correctement réglé.
Le contexte de ce JavaScript est limité. Toutes les fonctions de l’API ne sont pas disponibles. Par exemple, getOption() ou getCurrent() 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 thread-safe.

Stockage des événements

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

schéma de événement de tuyau

Les Événements sont stockés dans une table de base de données. Il est utilisé par les campagnes marketing pour cible des clients et pour enrichir les courriers électroniques à 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 un seul tableau. Le champ triggerType identifie à partir duquel les données sont déclenchées.
Voici un exemple de code de schéma pour ce tableau :
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 commerçant. Défini par le processus de réconciliation. Si la valeur est nulle, cela signifie que le client est inconnu à Campaign.
shopper_key
Long
shopper_key
L'Identifiant externe du commerçant capturé par Analytics.
created
Datetime
Created
Heure à laquelle le événement a été créé dans Campaign.
lastModified
Datetime
Dernière modification
Dernière modification du événement en Adobe.
timeGMT
Datetime
Horodatage
Heure à laquelle le é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 noeud de Événement Pipeline n’est pas intégré 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 : Hiérarchie de navigation et Modification de formulaires .

Traitement des événements

Processus de rapprochement

La réconciliation est le processus de mise en correspondance du client d’Analytics avec 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 processus. La fréquence doit être définie à 15 minutes pour optimiser la charge de travail. Par conséquent, le délai entre la réception d’un événement dans l’Adobe Campaign et son traitement par un processus 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 code JavaScript. Il a un impact sur les performances plus élevé et donne des résultats plus rapides. Il peut être nécessaire pour des cas d’utilisation spécifiques lorsque la réactivité est nécessaire.
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 présente de faibles performances.

Processus de purge

Les déclencheurs sont traités dans l’heure, il n’y a donc aucune raison de les conserver longtemps. Le volume peut être d'environ 1 million de déclencheurs par heure. Il explique pourquoi un processus 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.

Processus Campaign

Le processus de déclenchement d’une campagne est souvent similaire aux autres campagnes récurrentes qui ont été utilisées. Par exemple, il peut début avec une requête sur les déclencheurs à la recherche de événements spécifiques au cours de la dernière journée. Cette cible est utilisée pour envoyer le courriel. 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.