Migrieren der AAM Ihrer Site von Client-Side DIL zu Server-Side Forwarding

Dieses Tutorial gilt für Sie, wenn Sie sowohl über Adobe Audience Manager (AAM) als auch Adobe Analytics verfügen und derzeit einen Treffer von der Seite an AAM mit dem Code "DIL"(Data Integration Library) senden und außerdem einen Treffer von der Seite an Adobe Analytics senden. Da Sie über beide Lösungen verfügen und beide Teil der Adobe Experience Cloud sind, haben Sie die Möglichkeit, die Best Practice zu befolgen, nämlich "Server-Side Forwarding (SSF)"zu aktivieren, wodurch die Datenerfassungsserver Analytics die Site-Analysedaten in Echtzeit an den Audience Manager weiterleiten können, anstatt dass client-side-Code einen zusätzlichen Treffer von der Seite an die AAM sendet. Dieses Tutorial führt Sie durch die Schritte, die erforderlich sind, um den Wechsel von der älteren Implementierung "Client-Side DIL"zur neueren Methode "Server-Side forwarding"vorzunehmen.

Client-Side (DIL) vs. Server-Side

Beim Vergleichen und Vergleichen dieser beiden Methoden zur Datenübernahme in AAM kann es hilfreich sein, die Unterschiede im folgenden Bild zu visualisieren:

Client-seitig bis serverseitig

Client-side DIL-Implementierung

Wenn Sie diese Methode verwenden, um Adobe Analytics-Daten in AAM zu übertragen, bedeutet dies, dass Sie zwei Treffer von Ihren Webseiten haben: Gehen Sie zu Analytics und gehen Sie AAM (nachdem Sie die Analytics-Daten auf die Webseite kopiert haben. Segments werden von AAM an die Seite zurückgegeben, wo sie für die Personalisierung verwendet werden können usw. Dies gilt als "ältere"Implementierung und wird nicht mehr empfohlen.

Abgesehen davon, dass dies nicht den Best Practices folgt, bestehen die Nachteile der Verwendung dieser Methode darin,

  • Zwei Treffer von der Seite anstelle von nur einem
  • Server-Side Forwarding ist für die Echtzeit-Freigabe von AAM Zielgruppen in erforderlich, Analyticssodass Client-side Implementierungen diese Funktion (und möglicherweise andere Funktionen in der Zukunft) nicht zulassen.

Es wird empfohlen, zu einer Server-Side Forwarding-Methode zur AAM Implementierung zu wechseln.

Server-Side Forwarding Implementierung

Wie in der Abbildung oben gezeigt, kommt ein Treffer von der Webseite nach Adobe Analytics. Analytics leitet diese Daten dann an AAM in Echtzeit weiter und Besucher werden in AAM traits und segmentsausgewertet, so als ob der Treffer direkt von der Seite kam.

Segments werden bei demselben Echtzeit-Treffer zurück an zurückgegeben, Analyticswodurch die Antwort zur Personalisierung an die Webseite weitergeleitet wird.

Für die Umstellung auf die serverseitige Weiterleitung gibt es kein Timing nach unten. Es wird dringend empfohlen, dass alle Benutzer, die sowohl über Audience Manager als auch über Analytics verfügen, diese Implementierungsmethode verwenden.

Sie haben zwei Hauptaufgaben:

Auf dieser Seite gibt es eine Menge Informationen, und es ist natürlich alles wichtig. alles läuft jedoch auf zwei wichtige Dinge hinaus, die Sie tun müssen:

  1. Ändern Sie den Code von Client-Side DIL-Code in Server-Side Forwarding-Code
  2. Spiegeln Sie den Schalter in Analytics Admin Console, um die tatsächliche Weiterleitung der Daten zu starten (per report suite).

Wenn Sie eine dieser beiden Optionen überspringen, funktioniert SSF nicht ordnungsgemäß. In diesem Dokument wurden Schritte und zusätzliche Daten hinzugefügt, die Ihnen bei der korrekten Durchführung dieser beiden Schritte helfen.

Implementierungsoptionen

Wenn Sie von client-side zu server-side wechseln, besteht eine der Aufgaben darin, den Code in den neuen Server-Side Forwarding-Code zu ändern. Dies geschieht mit einer der folgenden Optionen:

  • Adobe Experience Platform Launch - Unsere empfohlene Implementierungsoption für Webeigenschaften. Sie werden sehen, dass dies eine sehr einfache Aufgabe ist, denn Launch hat alle harten Sachen für Sie gemacht.
  • Auf der Seite - Sie können den neuen SSF-Code auch direkt in die Funktion doPlugins in Ihrer appMeasurement.js-Datei platzieren, wenn Sie (noch) nicht mit Adobe Launch arbeiten
  • Andere Tag-Manager - Diese können wie die vorherige Option (Auf der Seite) behandelt werden, da Sie den SSF-Code immer noch in doPlugins platzieren, wo immer der andere Tag-Manager den AppMeasurement-Code speichert

Im Abschnitt Aktualisieren des Codes werden wir uns jeden dieser Punkte ansehen.

Implementierungsschritte

Schritt 0: Voraussetzung: Experience Cloud-ID-Dienst (ECID)

Die wichtigste Voraussetzung für den Wechsel zu Server-Side Forwarding ist die Implementierung des Experience Cloud-ID-Diensts. Dies ist am einfachsten, wenn Sie Experience Platform Launch verwenden. In diesem Fall installieren Sie einfach die ECID-Erweiterung und der Rest wird ausgeführt.

Wenn Sie ein TMS ohne Adobe oder gar kein TMS verwenden, implementieren Sie bitte ECID, um vor anderen Adobe-Lösungen auszuführen. Weitere Informationen finden Sie in der ECID-Dokumentation . Die einzige andere Voraussetzung betrifft Codeversionen. Wenn Sie also einfach die neuesten Versionen des Codes in den folgenden Schritten anwenden, ist Ihnen das recht.

HINWEIS

Lesen Sie vor der Implementierung dieses gesamten Dokuments. Der unten stehende Abschnitt "Timing"enthält wichtige Informationen zu wann Sie sollten jedes Element implementieren, einschließlich ECID (sofern es noch nicht implementiert ist).

Schritt 1: Derzeit verwendete Optionen aus DIL-Code aufzeichnen

Wenn Sie bereit sind, von Client-Side DIL-Code zu Server-Side Forwarding zu wechseln, besteht der erste Schritt darin, alles zu identifizieren, was Sie mit DIL-Code tun, einschließlich benutzerdefinierter Einstellungen und Daten, die an AAM gesendet werden. Zu beachten und zu berücksichtigen sind unter anderem:

  • Normale Analytics -Variablen, die das siteCatalyst.init -DIL-Modul verwenden - Sie müssen sich keine Gedanken über dieses Modul machen, da es nur darum geht, die normalen Analytics -Variablen zu senden, was durch die einfache Aktivierung von SSF geschieht.
  • Partner-Subdomäne - Notieren Sie sich in der Funktion DIL.create den Parameter partner . Dies wird als "Partner-Subdomäne"oder manchmal als "Partner-ID"bezeichnet und wird benötigt, wenn Sie den neuen SSF-Code platzieren.
  • Visitor Service Namespace - Wird auch als "Org ID"oder "IMS Org ID"bezeichnet und wird auch bei der Einrichtung des neuen SSF-Codes benötigt. Notieren Sie sich das.
  • containerNSID, uuidCookie und andere erweiterte Optionen - Notieren Sie sich alle zusätzlichen erweiterten Optionen, die Sie verwenden, damit Sie sie auch im SSF-Code festlegen können.
  • Zusätzliche Seitenvariablen - Wenn andere Variablen von der Seite an AAM gesendet werden (zusätzlich zu den normalen Analytics -Variablen, die von SiteCatalyst.init verarbeitet werden), müssen Sie sie beachten, damit sie über SSF (Spoiler-Warnung: über contextData -Variablen).

Schritt 2: Aktualisieren des Codes

Im obigen Abschnitt mit dem Titel "Implementierungsoptionen"werden mehrere Optionen bezüglich der Implementierung von Server-Side Forwarding angegeben. Damit dieser Abschnitt effektiv sein kann, müssen wir ihn in diese Abschnitte unterteilen (mit zwei davon zusammen). Gehen Sie zur Methode dieses Abschnitts , die Ihre Anforderungen am besten beschreibt.

Adobe Experience Platform Launch

Sehen Sie sich das folgende Video an, um mehr über das Verschieben von Implementierungsoptionen von Client-Side DIL-Code in Server-Side Forwarding im Experience Platform Launch zu erfahren.

"Auf der Seite"oder "Nicht-Adobe Tag Manager"

Sehen Sie sich das folgende Video an, um mehr über das Verschieben von Implementierungsoptionen vom Client-Side-DIL-Code in Server-Side Forwarding im AppMeasurement-Code zu erfahren, der sich entweder in einer -Datei oder in einem Nicht-Adobe-Tag-Management-System befindet.

Schritt 3: Aktivieren der Weiterleitung (per Report Suite)

Bis jetzt haben wir in diesem Tutorial die ganze Zeit damit verbracht, den Code von Client-Side DIL -Code auf Server-Side Forwarding zu wechseln. Das ist in Ordnung, denn es ist der schwierigere Teil. Dieser Abschnitt ist zwar sehr einfach, aber ebenso wichtig wie die Aktualisierung des Codes. In diesem Video erfahren Sie, wie Sie den Schalter umdrehen, der die tatsächliche Weiterleitung von Daten von Analytics an Audience Manager ermöglicht.

HINWEIS: Wie im Video angegeben, dauert es bis zu 4 Stunden, bis die Weiterleitung vollständig im Experience Cloud-Backend implementiert werden kann.

Zeit

Zur Erinnerung: Es gibt zwei Hauptaufgaben, die den Übergang von Client-Side DIL zu Server-Side Forwarding ermöglichen:

  1. Aktualisieren des Codes
  2. Spiegeln des Switches im Analytics Admin Console

Aber die Frage ist: Welches ist zuerst? Ist es wichtig? Ok, tut mir leid, das waren zwei Fragen. Aber die Antworten sind… es kommt darauf an und ja, es can zählt. Wie ist das für vage? Teilen wir es auf! Zunächst jedoch eine zusätzliche Frage, die sich stellen kann, wenn Sie eine große Organisation mit vielen Sites sind: Muss ich alles auf einmal machen? Das ist ein bisschen leichter. Keine Hoffnung. Man kann es Stück für Stück machen… irgendwie. :)

Ein kleiner tieferer Tauchgang

Der Grund, warum Timing und Reihenfolge wichtig sind, liegt darin, wie die Weiterleitung *wirklich *funktioniert, was in den folgenden technischen Fakten zusammengefasst werden kann:

  • Wenn der Experience Cloud-ID-Dienst (ECID) implementiert ist und der Wechsel im Analytics Admin Console ("der Schalter") eingeschaltet ist, werden die Daten von Analytics an AAM weitergeleitet, auch wenn Sie den Code noch nicht aktualisiert haben.
  • Wenn Sie ECID nicht implementiert haben, werden die Daten nicht weitergeleitet, auch wenn Sie den Umschalter aktiviert haben und den SSF-Code haben.
  • Der SSF-Code (ob in Launch oder auf der Seite) verarbeitet die Antwort wirklich und ist natürlich notwendig, um die Migration abzuschließen.
  • Beachten Sie, dass der SSF-Switch durch Report Suite aktiviert ist, der Code jedoch von der Eigenschaft in Launch oder von der Datei AppMeasurement verarbeitet wird, wenn Sie Launch nicht verwenden.

Best Practices

Basierend auf diesen technischen Details finden Sie hier die Empfehlungen für den Zeitplan für "Was soll ich wann tun?":

Wenn Sie noch NICHT ECID implementiert haben

  1. Spiegeln Sie den Switch in Analytics für jeden report suite, den Sie für SSF aktivieren.

    1. Die Weiterleitung wird noch nicht gestartet, da Sie keine ECID haben
  2. Aktualisieren Sie Ihren Code pro Site von Client-Side DIL auf SSF (dies kann sich in Launch oder auf der Seite befinden, wie in einem anderen Abschnitt oben beschrieben).

    1. Die Weiterleitung erfolgt jetzt (wie Sie ECID hinzugefügt haben) und Sie sollten auch eine ordnungsgemäße JSON-Antwort auf Ihr Analytics-Beacon erhalten (weitere Informationen finden Sie im Abschnitt "Validierung und Fehlerbehebung"unten).

Wenn ECID implementiert ist

  1. Bereiten Sie vor und planen Sie, dass Sie bereit sind, Ihren Code von DIL auf SSF PER report suite zu aktualisieren, damit Sie ihn für SSF aktivieren:

    1. Spiegeln Sie den Switch in Analytics, um SSF zu aktivieren.

      1. Die Weiterleitung beginnt, da ECID aktiviert ist.
    2. Aktualisieren Sie Ihren Code so bald wie möglich von Client-Side DIL auf SSF (dies kann sich in Launch oder auf der Seite befinden, wie in einem anderen Abschnitt oben beschrieben).

      1. Sie sollten eine richtige JSON-Antwort auf Ihr Analytics-Beacon erhalten (weitere Informationen finden Sie im Abschnitt Validierung und Fehlerbehebung unten).

HINWEIS 1: Es ist wichtig, diese beiden Schritte möglichst nahe beieinander zu platzieren, da zwischen den Schritten 1 und 2 oben Duplikate von Daten vorliegen, die in AAM gehen. Mit anderen Worten: SSF hat begonnen, Daten von Analytics an AAM zu senden. Da sich der DIL-Code noch auf der Seite befindet, wird auch ein Treffer direkt von der Seite in AAM gesendet, wodurch die Daten verdoppelt werden. Sobald Sie den Code von DIL auf SSF aktualisieren, wird dies gelindert.

HINWEIS 2: Wenn Sie eher eine kleine Datendiskrepanz als eine kleine Datenduplizierung wünschen, können Sie die Reihenfolge der Schritte 1 und 2 oben ändern. Wenn Sie den Code von DIL auf SSF verschieben, würde der Datenfluss in AAM gestoppt, bis Sie den Switch zum Aktivieren der SSF für report suite umschalten konnten. Normalerweise möchten Kunden eher eine kleine Datenverdoppelt haben, als Besucher in traits und segments zu verpassen.

Migrationszeit bei vielen Sites und Report Suites

Dieses Thema wird in früheren Abschnitten kurz angesprochen, da die Hauptstrategie wie folgt zusammengefasst werden kann:

Migrieren Sie jeweils eine Site/report suite (oder Site-Gruppe/report suites).

Dies kann jedoch anhand einiger möglicher Szenarien etwas schwierig werden:

  • Sie haben eine Site, die mehrere verschiedene report suites
  • Sie haben eine report suite , die mehrere Sites enthält (z. B. eine globale report suite).
  • Sie verwenden eine Launch-Eigenschaft, um mehrere Sites zu bedecken.
  • Sie haben verschiedene Entwicklungsteams für verschiedene Sites

Aufgrund dieser Elemente kann es ein wenig kompliziert werden. Die besten Dinge, die ich vorschlagen kann, sind:

  • Nehmen Sie sich etwas Zeit, um eine Strategie für die Migration auf SSF zu entwickeln, die auf den oben erläuterten Elementen basiert
  • Da eine einzelne Eigenschaft in Launch (oder eine einzelne AppMeasurement-Datei) normalerweise einer oder zwei verschiedenen report suites zugeordnet wird, können Sie wahrscheinlich einen Plan erstellen, der für diese unterschiedlichen Gruppen einzeln funktioniert, und Ihr Unternehmen auf SSF aktualisieren
  • Wenn Sie mit Adobe Consulting zusammenarbeiten, sprechen Sie mit ihnen über Ihren Migrationsplan, damit sie bei Bedarf helfen können

Validierung und Fehlerbehebung

Die Hauptmethode zum Überprüfen, ob Server-Side Forwarding aktiv ist, besteht darin, die Antwort auf einen Ihrer Adobe Analytics-Treffer zu überprüfen, die von der App kommen.

Wenn Sie keine server-side forwarding-Daten von Analytics zum Audience Manager verwenden, gibt es keine Antwort auf das Analytics-Beacon (abgesehen von einem 2x2-Pixel). Wenn Sie jedoch SSF verwenden, können Sie in der Analytics-Anfrage und -Antwort überprüfen, ob Analytics ordnungsgemäß mit dem Audience Manager kommuniziert, den Treffer weiterleitet und eine Antwort erhält.

Warnung: Vorsicht vor dem falschen “Erfolg”- Wenn eine Antwort vorliegt und alles zu funktionieren scheint, stellen Sie sicher, dass in der Antwort das “stuff”-Objekt enthalten ist. Wenn nicht, wird möglicherweise eine Meldung mit “status”:“SUCCESS” angezeigt. So verrückt das auch klingt, das ist der Beweis dafür, dass es nicht richtig funktioniert. Wenn Sie dies sehen, bedeutet dies, dass Sie die Codeaktualisierung in Launch oder AppMeasurement abgeschlossen haben, die Weiterleitung in Analytics Admin Console jedoch noch nicht abgeschlossen ist. In diesem Fall müssen Sie überprüfen, ob Sie SSF im Analytics Admin Console für report suite aktiviert haben. Wenn Sie dies haben und es noch nicht 4 Stunden gedauert hat, sollten Sie geduldig sein, da es so lange dauern kann, alle notwendigen Änderungen am Backend vorzunehmen.

false success

Weitere Informationen zu Server-Side Forwarding finden Sie in der Dokumentation.

Auf dieser Seite