Show Menu
TOPICS×

Verwenden des ID-Diensts mit A4T und einer serverseitigen Implementierung der Target-Komponente

Diese Anweisungen richten sich an A4T-Kunden mit kombinierten server- und clientseitigen Implementierungen von Target, Analytics und dem ID-Dienst. Kunden, die den ID-Dienst in einer NodeJS- oder Rhino-Umgebung ausführen müssen, sollten diese Informationen ebenfalls lesen. Diese ID-Dienstinstanz verwendet eine gekürzte Version der VisitorAPI.js-Codebibliothek, die Sie über den Node Package Manager (NPM) herunterladen und installieren können. Lesen Sie diesen Abschnitt zu den Installationsanweisungen und anderen Konfigurationsanforderungen.

Einführung

A4T-Kunden (und andere Kunden) können diese Version des ID-Diensts verwenden, wenn sie:
  • Webseiteninhalt auf ihren Servern rendern müssen und ihn für die endgültige Anzeige an einen Browser weiterleiten müssen.
  • Serverseitige Target-Aufrufe starten.
  • Clientseitige (im Browser) Aufrufe zu Analytics starten müssen.
  • Separate Target- und Analytics-IDs synchronisieren müssen, um zu bestimmen, ob ein von einer Lösung erkannter Besucher dieselbe Person ist, die von einer anderen Lösung erkannt wurde.

Codedownload und bereitgestellte Schnittstellen

Wechseln Sie zu ID service NPM repository , um das serverseitige Codepaket herunterzuladen und die im aktuellen Build enthaltenen Schnittstellen zu überprüfen.

Arbeitsablauf

In den folgenden Diagrammen und Abschnitten wird beschrieben, was Sie bei jedem Schritt des serverseitigen Implementierungsprozesses konfigurieren müssen.

Schritt 1: Anforderungsseite

Die serverseitige Aktivität beginnt, wenn ein Besucher eine HTTP-Anforderung zum Laden einer Webseite erstellt. Während dieses Schritts empfängt Ihr Server diese Anforderung und sucht nach dem AMCV-Cookie . Das AMCV-Cookie enthält die Experience Cloud ID (MID) des Besuchers.

Schritt 2: ID-Dienstnutzlast generieren

Erstellen Sie als nächstes eine serverseitige
payload request
für den ID-Dienst erstellen. Eine Nutzlastanforderung:
  • gibt das AMCV-Cookie an den ID-Dienst weiter.
  • Fordert für Target und Analytics in den nachfolgenden Schritten erforderliche Daten an, die im Folgenden beschrieben werden.
Für diese Methode ist eine einzelne mbox aus Target erforderlich. Rufen Sie generateBatchPayload auf, sofern Sie mehrere mboxes in einem einzelnen Aufruf benötigen.
Ihre Nutzlastanforderung sollte wie das folgende Codebeispiel aussehen. Die Funktion
visitor.setCustomerIDs
ist im Codebeispiel optional. Weitere Informationen finden Sie unter Kunden-IDs und Authentifizierungszustände.
//Import the ID service server package var Visitor = require("@adobe-mcid/visitor-js-server"); //Pass in your Organization ID to instantiate Visitor var visitor = new Visitor("Insert Experience Cloud ID here"); // <i>(Optional)</i> Set a custom customer ID visitor.setCustomerIDs({ userid:{ id:"1234", authState: Visitor.AuthState.UNKNOWN //AuthState is a static property of the Visitor class } }); //Parse the visitor's HTTP request for the AMCV cookie var cookies = cookie.parse(req.headers.cookie || ""); var cookieName = visitor.getCookieName(); // Visitor API that returns the cookie name. var amcvCookie = cookies[cookieName]; //Generate the payload request pass your mbox name and the AMCV cookie if present var visitorPayload = visitor.generatePayload({ mboxName: "bottom-banner-mbox", amcvCookie: amcvCookie });
Der ID-Dienst gibt die Nutzlast in einem JSON-Objekt zurück, das dem folgenden Beispiel ähnelt. Nutzlastdaten werden durch Target benötigt.
{ "marketingCloudVisitorId": "02111696918527575543455026275721941645", "mboxParameters": { "mboxAAMB": "abcd1234", "mboxMCGLH": "9", "mboxMCSDID": "56BE026543F7E211-1CC51BCAAE88F0D2", "vst.userid.id": "1234567890", "vst.userid.authState": 0 } }
Wenn Ihr Besucher über kein AMCV-Cookie verfügt, lässt die Nutzlast die folgenden Schlüssel-Wert-Paare aus:
  • marketingCloudvisitorId
  • mboxAAMB
  • mboxMCGLH

Schritt 3: Dem Target-Aufruf Nutzlast hinzufügen

Nachdem Ihr Server Nutzlastdaten vom ID-Dienst erhalten hat, müssen Sie zusätzlichen Code instanziieren, um ihn mit den an Target weitergegebenen Daten zusammenzuführen. Das endgültige JSON-Objekt, das an Target weitergegeben wird, ähnelt dem folgenden:
{ "mbox" : "target-global-mbox", "marketingCloudVisitorId":"02111696918527575543455026275721941645", "requestLocation" : { "pageURL" : "http://www.domain.com/test/demo.html", "host" : "localhost:3000" }, "mboxParameters" : { "mboxAAMB" : "abcd1234", "mboxMCGLH" : "9", "mboxMCSDID": "56BE026543F7E211-1CC51BCAAE88F0D2", "vst.userid.id": "1234567890", "vst.userid.authState": 0, } }

Schritt 4: Serverstatus für den ID-Dienst abrufen

Serverstatusdaten enthalten Informationen über die auf dem Server vorgenommene Arbeit. Diese Informationen sind für den clientseitigen ID-Dienstcode erforderlich. Kunden, die den ID-Dienst über Dynamic Tag Manager Dynamischen Tag-Manager (DTM) implementiert haben, können DTM so konfigurieren, dass Serverstatusdaten über dieses Tool weitergegeben werden. Wenn Sie den ID-Dienst über einen benutzerdefinierten Prozess eingerichtet haben, müssen Sie den Serverstatus mit Ihrem eigenen Code zurückgeben. Der clientseitige ID-Dienst und Analytics-Code geben die Daten an Adobe weiter, wenn die Seite geladen wird.
Abrufen des Serverstatus über DTM
Wenn Sie den ID-Dienst mit DTM implementiert haben, müssen Sie Ihrer Seite Code hinzufügen und ein Namens-Wert-Paar in den DTM-Einstellungen angeben.
Seiten-Code
Fügen Sie dem
<head>
Tag Ihrer HTML-Seite diesen Code hinzu:
//Get server state var serverState = visitor.getState(); Response.send(" ... <head> <script> //Add 'serverState' as a stringified JSON global variable. "var serverState = "+ JSON.stringify(serverState) +"; </script> <script src = "DTM script (satellite JS)"> </script> </head> ...
DTM-Einstellungen
Fügen Sie dem Abschnitt
Allgemein &gt; Einstellungen
Ihrer ID-Dienstinstanz diese als Namens-Wert-Paare hinzu:
  • Name:
    serverState
  • Wert:
    %serverState%
    Der Wertname muss mit dem Variablennamen übereinstimmen, den Sie für
    serverState
    in Ihrem Seitencode festgelegt haben.
Ihre konfigurierten Einstellungen sollten wie folgt aussehen:
Abrufen des Serverstatus ohne DTM
Wenn Sie über eine benutzerdefinierte Implementierung des ID-Diensts verfügen, müssen Sie diesen Code so konfigurieren, dass er auf Ihrem Server ausgeführt wird, während er die angeforderte Seite zusammenstellt:
//Get server state var serverState = visitor.getState(); Response.send(" ... <head> <script src="VisitorAPI.js"></script> <script> var visitor = Visitor.getInstance(orgID, { serverState: serverState ... </script> </head> ...

Schritt 5: Eine Seite verarbeiten und Experience Cloud-Daten zurückgeben

Zu diesem Zeitpunkt sendet der Webserver Seiteninhalt an den Browser des Besuchers. Ab diesem Zeitpunkt nimmt der Browser (nicht der Server) alle verbleibenden ID-Dienst- und Analytics-Aufrufe vor. Zum Beispiel im Browser:
  • Der ID-Dienst empfängt Statusdaten vom Server und gibt die SDID an AppMeasurement weiter.
  • AppMeasurement sendet Daten über die Seitenaufrufe an Analytics, einschließlich der SDID.
  • Analytics und Target vergleichen SDIDs für diesen Besucher. Bei einer identischen SDID fügen Target und Analytics den serverseitigen Aufruf und den clientseitigen Aufruf zusammen. Zu diesem Zeitpunkt erkennen beide Lösungen diesen Besucher als dieselbe Person.