Konfigurieren von Ereignissen für eine benutzerdefinierte Implementierung events
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 events-javascript
JavaScript-Datei file-js
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 function-js
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 trigger-format
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 enrichment-format
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 order-events
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 logging-error-handling
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 data-parsing
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 storing-triggers-js
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 constraints
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 store-events
Pipeline-Ereignisschema pipeline-event-schema
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:
Anzeigen der Ereignisse display-events
Die Ereignisse können mit einem einfachen Formular, das auf dem Ereignisschema basiert, angezeigt werden.
Verarbeiten der Ereignisse processing-the-events
Abstimmungs-Workflow reconciliation-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 options-unit-reconciliation
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 purge-workflow
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 campaign-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.