Verwenden von Best Practices beim Tracking von Single Page Applications (SPA) in Adobe Analytics

In diesem Dokument beschreiben wir verschiedene Best Practices, die Sie befolgen und kennen sollten, wenn Sie Adobe Analytics zum Tracking von Single Page Applications (SPA) verwenden. Dieses Dokument konzentriert sich auf die Verwendung von Adobe Experience Platform Launch, was die empfohlene Implementierungsmethode ist.

VORABBEMERKUNGEN:

• Bei den folgenden Elementen wird davon ausgegangen, dass Sie Experience Platform Launch zur Implementierung auf Ihrer Site verwenden. Wenn Sie Experience Platform Launch nicht verwenden, gelten die Überlegungen trotzdem, Sie müssen sie jedoch an Ihre Implementierungsmethode anpassen.
• Alle SPAs sind unterschiedlich, sodass Sie möglicherweise einige der folgenden Elemente anpassen müssen, damit sie bestmöglich auf Ihre Anforderungen passen. Dennoch wollten wir einige Best Practices mit Ihnen teilen – Dinge, über die Sie bei der Implementierung von Adobe Analytics auf SPA-Seiten nachdenken müssen.

Einfaches Diagramm zum Arbeiten mit SPAs in Experience Platform Launch

HINWEIS: Wie angegeben, ist dies ein vereinfachtes Diagramm dazu, wie SPA-Seiten in einer Adobe Analytics-Implementierung mit Experience Platform Launch gehandhabt werden. In den folgenden Abschnitten dieser Seite erläutern wir die Schritte und Probleme, die Sie sorgfältig überdenken bzw. bei denen Sie Maßnahmen ergreifen sollten.

Definieren der Datenschicht

Wenn neuer Inhalt auf einer SPA-geladen wird oder wenn eine Aktion auf einer SPA-Seite stattfindet, sollten Sie als Erstes die Datenschicht aktualisieren. Dies muss geschehen, BEVOR das benutzerspezifische Ereignis eintritt und als Trigger für Regeln in Experience Platform Launch fungiert, sodass Experience Platform Launch die neuen Werte aus der Datenschicht übernehmen und in Adobe Analytics übertragen kann.

Im Folgenden finden Sie eine Beispieldatenschicht, deren Elemente bei Änderung der Ansicht oder Aktion in Ihrer SPA geändert werden können. Bei einer vollständigen/mehrheitlichen Bildschirmänderung wäre es beispielsweise üblich, ein pageName-Element zu ändern, damit das neue Element in Experience Platform Launch erfasst und an Adobe Analytics gesendet werden kann.

<script>
    digitalData = {
        pageInstanceID: "Launch Demo Site",
        page:{
            pageInfo:{
                pageID: '2745374',
                pageName: 'acs demo - product listing page'
            },
            attributes:{
                project: "Experience Platform Launch Project"
            }
        },
        user : [ {
          "profile" : [ {
            "attributes" : {
              "gender" : "male",
              "age" : "35"
            }
          } ]
        }],
        libraries : {
          adobe : {
            launch : {
              state : 0, // 0 = not loaded , 1 = loaded
              domain : "assets.adobedtm.com"
            }
          }
        }

     };
    </script>

Festlegen benutzerspezifischer Ereignisse und Listening-Ereignisse in Experience Platform Launch

Wenn neuer Inhalt auf der Seite geladen wird oder eine Aktion auf der Site stattfindet, sollten Sie Experience Platform Launch darüber in Kenntnis setzen, damit eine Regel ausgeführt und Daten an Analytics gesendet werden können. Dazu gibt es verschiedene Möglichkeiten: Direktaufruf-Regeln oder benutzerspezifische Ereignisse.

• Direktaufruf-Regeln: In Experience Platform Launch können Sie eine Direktaufruf-Regel einrichten, die ausgeführt wird, wenn sie direkt von der Seite aus aufgerufen wird. Wenn das Laden Ihrer Seite oder Ihre Aktion auf Ihrer Site sehr einfach ist oder wenn sie eindeutig ist und jedes Mal einen bestimmten Satz von Anweisungen ausführen kann (definieren Sie eVar4 als X und lösen Sie jedes Mal event2 aus), können Sie eine Direktaufruf-Regel verwenden. Weitere Informationen zum Erstellen von Direktaufruf-Regeln finden Sie in der Experience Platform Launch-Dokumentation.
• Benutzerspezifische Ereignisse: Für mehr Funktionalität und für die Möglichkeit, eine Payload mit unterschiedlichen Werten dynamisch anzuhängen, sollten Sie benutzerdefinierte JavaScript-Ereignisse festlegen und diese mit Experience Platform Launch im Blick behalten. Dort können Se die Payload verwenden, um Variablen festzulegen und die Daten an Adobe Analytics zu senden. Es ist wahrscheinlicher, dass Sie diese Funktion benötigen. Daher gilt diese Option als Best Practice. Jede Funktion auf Ihrer Site kann jedoch bestimmen, welche Methode am besten geeignet ist. Wir werden in diesem Dokument unter der Annahme fortfahren, dass Sie diese benutzerspezifische Ereignismethode verwenden.

Beispiele: In DIESEM Hilfedokument gibt es Links zu Beispiel-SPA-Sites, auf denen Analytics (und anderen Experience Cloud-Lösungen) implementiert sind, sowie Unterlagen, die beschreiben, was implementiert wurde. In diesen SPA-Beispielen wurden die folgenden benutzerdefinierten Ereignisse verwendet:

• event-view-start: Dieses Ereignis sollte beim Ansichtsbeginn der Ansicht/des Status ausgelöst werden, die bzw. der geladen wird.
• event-view-end: Dieses Ereignis sollte auch dann ausgelöst werden, wenn eine Ansicht-/Statusänderung stattgefunden hat und alle SPA-Komponenten auf der Seite vollständig geladen wurden. Dies ist das Ereignis, bei dem normalerweise ein Aufruf an Adobe Analytics getriggert wird.
• event-action-trigger: Dieses Ereignis sollte ausgelöst werden, wenn ein beliebiges Ereignis auf der Seite auftritt, mit Ausnahme des Ladevorgangs von Ansicht/Status. Dies kann ein Klickereignis oder eine kleinere Inhaltsänderung ohne Änderung der Ansicht sein.

Weitere Informationen dazu, wie/wann diese Ereignisse ausgelöst werden, finden Sie auf bzw. in den oben referenzierten Seiten/Dokumenten. Sie müssen nicht dieselben Ereignisnamen verwenden, aber die hier aufgeführten Funktionen sind empfohlene Best Practices. Im folgenden Video wird eine Beispiel-Site gezeigt und auch, wo in Experience Platform Launch auf die benutzerdefinierten Ereignisse gewartet werden sollte.

Ausführen von „s.t()“ oder „s.tl()“ in der Experience Platform Launch-Regel

Eines der wichtigsten Dinge, die es bei der Arbeit mit einer SPA im Hinblick auf Analytics zu verstehen gilt, ist der Unterschied zwischen s.t() und s.tl(). Sie werden eine dieser Methoden in Experience Platform Launch zum Senden von Daten an Analytics auslösen, aber Sie müssen wissen, wann die jeweilige Methode gesendet wird.

• s.t(): „t“ steht für „track“ (nachverfolgen) und ist eine normale Seitenansicht. Auch wenn sich die URL möglicherweise nicht ändert, ändert sich die Ansicht so, dass Sie sie als neue „Seite“ betrachten würden? Wenn ja, legen Sie die Variable „s.pageName“ fest und verwenden Sie s.t(), um den Aufruf an Analytics zu senden.

• s.tl(): „tl“ steht für „track link“ (Link nachverfolgen) und wird normalerweise zum Tracking von Klicks oder kleinen Inhaltsänderungen m Gegensatz zu einer kompletten Änderung der Anzeige verwendet. Wenn die Änderung auf Ihrer Seite nur klein ist, sodass Sie sie nicht als vollständige neue „Seite“ betrachten, verwenden Sie s.tl() und sparen Sie sich den Aufwand, die Variable s.pageName festzulegen, denn Analytics wird sie ignorieren.

TIPP: Einige Benutzer verwenden eine allgemeine Regel, wonach der Bildschirm, wenn er sich um mehr als 50 % ändert, als Seitenansicht betrachtet und s.t() verwendet werden sollte. Wenn die Änderung am Bildschirm weniger als 50 % beträgt, verwenden Sie s.tl(). Es liegt jedoch ganz bei Ihnen, was Sie als neue „Seite“ betrachten und wie Sie Ihre Site in Adobe Analytics nachverfolgen möchten.

Im folgenden Video wird gezeigt, wo und wie Sie in Experience Platform Launch s.t() oder s.tl() auslösen lassen können.

Löschen von Variablen

Wenn Sie Ihre Site mit Adobe Analytics nachverfolgen, möchten Sie natürlich nur die richtigen Daten zum richtigen Zeitpunkt an Analytics senden. In einer SPA-Umgebung kann ein in einer Analytics-Variable verfolgter Wert bestehen bleiben und erneut an Analytics gesendet werden, möglicherweise auch dann, wenn wir dies nicht mehr wünschen. Aus diesem Grund gibt es eine Funktion in der Launch-Erweiterung von Analytics, um die Variablen zu löschen, sodass Sie bei der nächsten Bildanforderung und beim Senden von Daten in Analytics einen neuen Anfang machen können.

Im obigen Diagramm ist sie am Ende des Prozesses aufgeführt und löscht die Variablen, nachdem Sie den Treffer gesendet haben. In Wirklichkeit kann dies entweder vor ODER nach dem Absenden des Treffers geschehen, aber Sie sollten in Ihren Experience Platform Launch-Regeln konsequent sein, sodass das Löschen immer entweder vor oder nach dem Setzen der Variablen und dem Absenden erfolgt. Denken Sie daran: Wenn Sie die Variablen löschen möchten, bevor Sie s.t() ausführen, stellen Sie sicher, dass Sie zuerst die Variablen löschen, dann die neuen Variablen setzen und schließlich die neuen Daten an Analytics senden.

HINWEIS: Das Löschen von Variablen ist nicht immer erforderlich, wenn s.tl() ausgeführt wird, da s.tl() jedes Mal die Verwendung der linkTrackVars-Variable erfordert, um Analytics mitzuteilen, welche Variablen gesetzt werden sollen (wird automatisch hinter den Kulissen in Experience Platform Launch hinzugefügt). Das bedeutet, dass fehlerhafte Variablen bei der Verwendung von s.tl() normalerweise nicht auftauchen, aber es wird sehr empfohlen, wenn s.t() in einer SPA-Umgebung verwendet wird. Dennoch möchte ich empfehlen, in einer SPA-Umgebung die Funktion „Variablen löschen“ sowohl für s.t() als auch für s.tl() zu verwenden, um eine qualitativ hochwertige Datenerfassung zu gewährleisten.

Das folgende Video zeigt, wo und wie die Variablen in Launch gelöscht werden können.

Weitere zu berücksichtigende Aspekte

Fenster mit benutzerspezifischem Code in Experience Platform Launch

In der Analytics-Erweiterung von Launch gibt es zwei Stellen, an denen Sie benutzerdefinierten Code einfügen können: im Abschnitt Bibliotheksverwaltung und im zusätzlichen Abschnitt Tracker mit benutzerdefiniertem Code konfigurieren.

Es ist wichtig zu wissen, dass der Code an diesen beiden Stellen nur einmal ausgeführt wird, nämlich beim ersten Laden der SPA-Seite. Wenn der Code bei einem Wechsel der Ansicht oder bei einer Aktion auf Ihrer Seite ausgeführt werden soll, sollten Sie eine zusätzliche Aktion zu der entsprechenden Regel hinzufügen (z. B. in der Regel „page load: event-view-end“), sodass der Code jedes Mal ausgeführt wird, wenn die Regel läuft. Wenn Sie diese Aktion in der Regel erstellen, setzen Sie Extension = Core und Action Type = Custom Code.

„Hybride“ SPA-/reguläre Sites

Einige Websites sind eine Kombination aus „regulären“ Seiten und SPA-Seiten. In diesem Fall müssen Sie eine Strategie verwenden, die für beide Seitentypen funktioniert. Wenn Sie Ihre benutzerdefinierten Ereignisse auf der Website konfigurieren und die Regeln in Experience Platform Launch ausgelöst werden, achten Sie darauf, dass es keine doppelten Treffer gibt, die von der Seite aus in Analytics eingehen, basierend auf Hash-Änderungen usw. (falls Sie die Experience Platform Launch-Regel auf diese Weise auslösen wollen). In diesem Fall müssen Sie eine der Seitenansichten unterdrücken, damit Sie keine fehlerhaften Daten in Adobe Analytics erhalten.

Wenn Sie sich entscheiden, die Funktionalität in separate Regeln aufzuteilen, um mehr Kontrolle darüber zu haben, stellen Sie sicher, dass Sie sich daran erinnern bzw. dokumentieren, dass Sie dies getan haben, damit alle Änderungen an einer Regel auch an der anderen Regel vorgenommen werden können, um die Integrität Ihrer Analytics-Daten zu schützen.

Integration mit Target über A4T

Nur ein kurzer Hinweis. Wenn Sie Target mit A4T integrieren, stellen Sie sicher, dass die Target-Anfrage und die Analytics-Anfrage bei der gleichen Ansichtsänderung die gleiche SDID haben. Dadurch wird sichergestellt, dass Ihre Daten ordnungsgemäß mit den Lösungen synchronisiert werden.

Um die Treffer anzuzeigen, verwenden Sie ein Debugger- oder Paket-Sniffer-Programm. Sie können auch den Experience Cloud Debugger verwenden, eine Chrome-Erweiterung, die HIER heruntergeladen werden kann. Target sollte zuerst auf der Seite ausgelöst werden, damit Sie dies auch in der JavaScript-Konsole oder im Debugger überprüfen können.

Zusätzliche Ressourcen

• SPA in den Adobe-Foren
• Referenz-Sites zur Architektur, die zeigen, wie SPA in Experience Platform Launch implementiert wird