Konfigurieren von Ereignissen für eine benutzerdefinierte Implementierung

Diese Konfiguration enthält benutzerspezifische Anpassungen. Sie erfordert:

• Grundkenntnisse der JSON-, XML- und JavaScript-Analyse in Adobe Campaign.
• Grundkenntnisse der QueryDef- und Writer-APIs.
• Grundverständnis der Verschlüsselung und Authentifizierung mit privaten Schlüsseln.

Für das Bearbeiten des JavaScript-Codes sind technische Kenntnisse vonnöten. Daher sollten Sie dies nur vornehmen, wenn Sie über entsprechende Kenntnisse verfügen.

Verarbeiten von Ereignissen in JavaScript

JavaScript-Datei

Die Pipeline verwendet eine JavaScript-Funktion, um jede Nachricht zu verarbeiten. Diese Funktion ist benutzerdefiniert.

Sie wird in der Option NmsPipeline_Config unter dem Attribut "JSConnector" konfiguriert. Dieses JavaScript wird jedes Mal aufgerufen, wenn ein Ereignis empfangen wird. Es wird vom pipelined-Prozess ausgeführt.

Die JavaScript-Beispieldatei lautet "cus:Trigger.js".

JavaScript-Funktion

Das pipelined-JavaScript muss mit einer bestimmten Funktion beginnen.

Diese Funktion wird für jedes Ereignis einmal aufgerufen:

function processPipelineMessage(xmlTrigger) {}

Sie sollte zurückgegeben werden als

<undefined/>

Nach der Bearbeitung des JavaScript sollten Sie pipelined neu starten.

Datenformat des Auslösers

Die trigger-Daten werden im XML-Format an die JS-Funktion übergeben.

• Das @triggerId-Attribut enthält den Namen des trigger.
• Das Element Anreicherungen im JSON-Format enthält die von Adobe Analytics generierten Daten und wird an den Auslöser angehängt.
• @offset ist der "Zeiger" auf die Nachricht. Er gibt die Reihenfolge der Nachrichten in der Warteschlange an.
• @partition ist ein Container mit Nachrichten, die sich in der Warteschlange befinden. Der Versatz ist relativ zu einer Partition.
  Es gibt etwa 15 Partitionen in der Warteschlange.

Beispiel:

<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>

Anreicherung von Datenformaten

Der Inhalt wird für jeden Auslöser in Adobe Analytics im JSON-Format definiert.
Zum Beispiel im Auslöser "logoUpload_uploading_Visits":

• eVar01 kann die Käufer-ID im Zeichenfolgenformat ("String") enthalten, die zur Abstimmung mit Adobe Campaign-Empfängern verwendet wird.
  Sie muss abgestimmt werden, um die Käufer-ID zu ermitteln, die den Primärschlüssel darstellt.

• timeGMT kann die Uhrzeit des Auslösers auf Seite von Adobe Analytics im UTC Epoch-Format enthalten (Sekunden seit 1.1.1970 UTC).

Beispiel:

{
 "analyticsHitSummary": {
 "dimensions": {
 "eVar01": {
 "type": "string",
 "data": ["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],
 "name": " eVar01",
 "source": "session summary"
 },
 "timeGMT": {
 "type": "int",
 "data": [1469164186, 1469164195],
 "name": "timeGMT",
 "source": "session summary"
 }
 },
 "products": {}
 }
 }

Reihenfolge der Verarbeitung von Ereignissen

Die Ereignisse werden nacheinander in der Reihenfolge des Versatzes verarbeitet. Jeder Thread des pipelined-Prozesses verarbeitet eine andere Partition.

Der "Versatz" des letzten abgerufenen Ereignisses wird in der Datenbank gespeichert. Wenn der Prozess angehalten wird, startet er daher bei der letzten Nachricht neu. Diese Daten werden im nativen Schema "xtk:pipelineOffset" gespeichert.

Dieser Zeiger ist für jede Instanz und jeden Verbraucher spezifisch. Wenn verschiedene Instanzen auf dieselbe Pipeline mit unterschiedlichen Verbrauchern zugreifen, erhalten diese also alle Nachrichten in derselben Reihenfolge.

Der Parameter consumer der Pipeline-Option identifiziert die aufrufende Instanz.

Derzeit gibt es keine Möglichkeit, unterschiedliche Warteschlangen für separate Umgebungen wie "staging" oder "dev" zu nutzen.

Protokollierung und Fehlerbehandlung

Logs wie "logInfo()" werden an das pipelined-Log weitergeleitet. Fehler wie "logError()" werden in das pipelined-Log geschrieben und führen dazu, dass das Ereignis in eine Warteschlange für erneute Versuche gestellt wird. In diesem Fall sollten Sie das pipelined-Log überprüfen.
Bei fehlerhaften Nachrichten werden im Zeitraum, der in den pipelined-Optionen festgelegt ist, mehrmals erneute Versuche ausgeführt.

Zu Debugging- und Überwachungszwecken werden die vollständigen Auslöserdaten im Feld "data" der Auslösertabelle im XML-Format geschrieben. Alternativ dazu sind die Auslöserdaten auch in "logInfo()" verfügbar.

Analysieren der Daten

Dieser JavaScript-Beispielcode analysiert die eVar01 in den Anreicherungen.

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]
 }
 }
 (…)
 }

Gehen Sie beim Analysieren sorgfältig vor, um Fehler zu vermeiden.
Da dieser Code für alle Auslöser verwendet wird, sind die meisten Daten nicht erforderlich. Sie können daher leer bleiben, wenn nicht vorhanden.

Speichern des Auslösers

Dieser JS-Beispielcode speichert den Auslöser in der Datenbank.

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/>;
 }

Einschränkungen

Dieser Code erfordert optimale Leistung, da er mit hoher Frequenz ausgeführt wird, was sich u. U. negativ auf andere Marketing-Aktivitäten auswirken kann. Das gilt insbesondere, wenn mehr als 1 Million Auslöserereignisse pro Stunde auf dem Marketing-Server verarbeitet werden oder wenn der Server nicht entsprechend angepasst ist.

Der Kontext dieses JavaScripts ist begrenzt. Es sind nicht alle Funktionen der API verfügbar. Beispielsweise funktionieren "getOption()" und "getCurrentdate()" nicht.

Um eine schnellere Verarbeitung zu ermöglichen, werden mehrere Threads des Skripts gleichzeitig ausgeführt. Der Code muss Thread-sicher sein.

Speichern der Ereignisse

Pipeline-Ereignisschema

Ereignisse werden in einer Datenbanktabelle gespeichert. Sie werden in Marketing-Kampagnen verwendet, um mithilfe von Auslösern Zielkunden zu bestimmen und E-Mails anzureichern.
Zwar kann jeder Auslöser eine eigene Datenstruktur aufweisen, doch lassen sich alle Auslöser in einer einzigen Tabelle speichern.
Das Feld "triggerType" gibt an, von welchem Auslöser die Daten stammen.

Hier ist ein Beispiel für einen Schema-Code für diese Tabelle:

Attribut	Typ	Titel	Beschreibung
pipelineEventId	Lang	Primärschlüssel	Der interne Primärschlüssel des Auslösers.
data	Memo	Auslöserdaten	Der vollständige Inhalt der Auslöserdaten im XML-Format. Für Debugging- und Audit-Zwecke.
triggerType	String 50	TriggerType	Der Name des Auslösers. Identifiziert das Verhalten des Kunden auf der Website.
shopper_id	String 32	shopper_id	Die interne Kennung des Käufers. Wird durch den Abstimmungs-Workflow festgelegt. "zero" bedeutet, dass der Kunde in Campaign unbekannt ist.
shopper_key	Lang	shopper_key	Die externe Kennung des Käufers, wie von Analytics erfasst.
Erstellt	Datum/Uhrzeit	Erstellt	Der Zeitpunkt, zu dem das Ereignis in Campaign erstellt wurde.
lastModified	Datum/Uhrzeit	Zuletzt geändert	Der letzte Zeitpunkt, zu dem das Ereignis in Adobe geändert wurde.
timeGMT	Datum/Uhrzeit	Zeitstempel	Der Zeitpunkt, zu dem das Ereignis in Analytics erstellt wurde.

Anzeigen der Ereignisse

Die Ereignisse können mit einem einfachen Formular, das auf dem Ereignisschema basiert, angezeigt werden.

Verarbeiten der Ereignisse

Abstimmungs-Workflow

Bei der Abstimmung gleicht Adobe Analytics den Kunden mit der Adobe Campaign-Datenbank ab. Das Kriterium für die Abstimmung kann beispielsweise "shopper_id" sein.

Aus Leistungsgründen muss die Abstimmung von einem Workflow im Batch-Modus vorgenommen werden.
Die Häufigkeit muss für eine optimale Arbeitslast auf 15 Minuten gesetzt werden. Die Verzögerung zwischen dem Empfang eines Ereignisses in Adobe Campaign und dessen Verarbeitung durch einen Marketing-Workflow beträgt daher bis zu 15 Minuten.

Optionen zur Abstimmung von Einheiten in JavaScript

Es ist möglich, die Abstimmungsabfrage für jeden Auslöser im JavaScript auszuführen. Das sorgt für eine höhere Leistung und schnellere Ergebnisse. Dies kann für spezifische Anwendungsfälle erforderlich sein, wenn eine Reaktionsrate erforderlich ist.

Ist jedoch kein Index für "shopper_id" festgelegt, lässt sich dies nur schwer umsetzen. Wenn sich die Kriterien auf einem anderen Datenbank-Server als dem Marketing-Server befinden, wird ein Datenbank-Link mit geringer Leistung verwendet.

Workflow bereinigen

Trigger werden innerhalb der jeweiligen Stunde verarbeitet. Das Volumen kann etwa 1 Million Auslöser pro Stunde betragen. Aus diesem Grund muss ein Bereinigungs-Workflow eingerichtet werden. Die Bereinigung wird einmal pro Tag ausgeführt und löscht alle Auslöser, die älter als drei Tage sind.

Kampagnen-Workflow

Der Kampagnen-Workflow für Auslöser ähnelt oft anderen wiederkehrenden Kampagnen, die bereits verwendet wurden.
Beispielsweise kann er mit einer Abfrage nach den Auslösern starten, um nach bestimmten Ereignissen zu suchen, die während des letzten Tages stattgefunden haben. Diese Zielgruppe wird zum Senden der E-Mail genutzt. Anreicherungen oder Daten können vom Auslöser übernommen werden. Sie können vom Marketing-Team sicher verwendet werden, da keine Konfiguration erforderlich ist.