Verwenden von Best Practices beim Verfolgen von Einzelseiten-Apps (SPA) in Adobe Analytics

In diesem Dokument werden wir verschiedene Best Practices beschreiben, die Sie befolgen sollten und die Sie kennen sollten, wenn Sie Adobe Analytics zur Verfolgung von Einzelseiten-Apps (SPA) verwenden. Dieses Dokument konzentriert sich auf die Verwendung der Adobe Experience Platform Launch, der empfohlenen Implementierungsmethode.

ERSTE HINWEISE:

• 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, gibt es weiterhin Überlegungen. Sie müssen diese jedoch an Ihre Implementierungsmethode anpassen.
• Alle SPA unterscheiden sich, sodass Sie möglicherweise einige der folgenden Elemente anpassen müssen, um Ihren Anforderungen am besten zu entsprechen. Wir wollten jedoch 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 SPA in Experience Platform Launch

HINWEIS: Wie angegeben, ist dies ein vereinfachtes Diagramm zur Handhabung SPA Seiten in einer Adobe Analytics-Implementierung mit Experience Platform Launch. In den folgenden Abschnitten dieser Seite werden wir die Schritte und Probleme besprechen, die Sie sorgfältig prüfen oder bearbeiten sollten.

Festlegen 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 die benutzerspezifischen Ereignisregeln in Experience Platform Launch ausgelöst und Trigger ausgelöst werden, damit Experience Platform Launch die neuen Werte aus der Datenschicht abrufen und in Adobe Analytics übertragen kann.

Im Folgenden finden Sie eine Beispieldatenschicht, deren Elemente bei Änderung der Ansicht oder Aktion auf Ihrer SPA geändert werden können. Bei einer Änderung des Vollbild-/Mehrheitsbildschirms ist es beispielsweise üblich, ein "pageName"-Element zu ändern, sodass 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 von benutzerdefinierten Ereignissen und Listening in Experience Platform Launch

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

• Direct ​ CallRules: in Experience Platform Launch, können Sie eine direkte ​ Aufrufregel 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 bestimmte Anweisungen ausführen kann (setzen Sie eVar4 jedes Mal auf X und Trigger event2), können Sie einen Direktaufruf Regel verwenden. Weitere Informationen finden Sie in der Experience Platform Launch Dokumentation zum Erstellen von Direktaufrufen Regeln.
• 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 sie in Experience Platform Launch überwachen, wo Sie die Payload verwenden können, 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 fortfahren, vorausgesetzt, Sie müssen diese benutzerspezifische Ereignismethode verwenden.

Beispiele: Im 🔗 DIESEN Hilfedokument finden Sie Links zu Beispiel-SPA-Sites, die implementiert wurden ( Analytics und andere Experience Cloud-Lösungen), sowie Dokumente, die beschreiben, was implementiert wurde. In diesen SPA wurden die folgenden benutzerdefinierten Ereignisse verwendet:

• event-view-start: Dieses Ereignis sollte beim Ansichtsstart der Ansicht/des Status ausgelöst werden, die 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 Trigger 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 sie ausgelöst werden, finden Sie auf den oben referenzierten Seiten/Dokumenten . Sie müssen nicht dieselben Ereignisnamen verwenden, aber die hier aufgeführten Funktionen sind empfohlene Best Practices. Das folgende Video zeigt eine Beispielsite und wo in Experience Platform Launch , um die benutzerdefinierten Ereignisse zu überwachen.

Ausführen von s.t() oder s.tl() im Experience Platform Launch Regel

Eines der wichtigsten Dinge, die Sie für Analytics beim Arbeiten mit einem SPA verstehen sollten, ist der Unterschied zwischen s.t() und s.tl(). Sie lösen eine dieser Methoden in Experience Platform Launch aus, um Daten an Analytics zu senden. Sie müssen jedoch wissen, wann die einzelnen Nachrichten gesendet werden.

• s.t() - "t"steht für "track"und ist eine normale Seitenansicht. Selbst wenn sich die URL möglicherweise nicht ändert, ändert sich die Ansicht so, dass ** sie als neue "Seite"betrachtet wird? Wenn ja, setzen Sie die Variable s.pageName und verwenden Sie s.t(), um den Aufruf an Analytics zu senden.

• s.tl() - "tl"steht für "track link"und wird normalerweise zum Tracking von Klicks oder kleinen Inhaltsänderungen auf der Seite verwendet, im Gegensatz zu einer Vollbildänderung. Wenn die Änderung auf Ihrer Seite klein ist, sodass Sie sie nicht als vollständige neue "Seite"betrachten, verwenden Sie s.tl() und sorgen Sie sich nicht darum, die Variable s.pageName festzulegen, da Analytics sie ignoriert.

TIPP: Manche Benutzer verwenden eine allgemeine Richtlinie, wonach der Bildschirm, wenn er sich um mehr als 50 % ändert, als Seitenansicht und -nutzung betrachtet werden sollte s.t(). 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 verfolgen möchten.

Das folgende Video zeigt, wo/wie s.t() oder s.tl() in Launch by Adobe Trigger wird.

Variablen löschen

Wenn Sie Ihre Site mit Adobe Analytics verfolgen, möchten Sie natürlich nur die richtigen Daten zum richtigen Zeitpunkt an Analytics senden. In einer SPA-Umgebung kann ein Wert, der in einer Analytics -Variablen verfolgt wird, persistent sein und möglicherweise erneut an Analytics gesendet werden, wenn dies nicht mehr gewünscht wird. Aus diesem Grund gibt es eine Funktion in der Erweiterung Analytics Launch, mit der die Variablen gelöscht werden, sodass Sie eine neue Verzögerung haben, wenn Sie die nächste Bildanforderung ausführen und Daten an Analytics senden.

Im obigen Diagramm wird sie am Ende des Prozesses aufgelistet, wobei die Variablen nach gelöscht werden, die Sie im Treffer senden. In Wirklichkeit kann dies entweder vor ODER nach dem Senden des Treffers erfolgen, sollte jedoch in den Experience Platform Launch-Regeln konsistent sein, sodass Sie immer vor oder nach dem Festlegen von Variablen und dem Senden löschen. Denken Sie daran, dass Sie, wenn Sie die Variablen vor löschen möchten, s.t() ausführen, sicherstellen, dass Sie zuerst die Variablen löschen, dann die neuen Variablen festlegen und dann die neuen Daten schließlich nach Analytics senden.

HINWEIS: Das Löschen von Variablen ist bei der Ausführung nicht immer erforderlich, da s.tl()die s.tl() Variable jedes Mal neben der Variablen verwendet werden muss, um anzugeben, linkTrackVars welche Variablen festgelegt werden (automatisch hinter den Kulissen in hinzugefügt Analytics Experience Platform Launch). Das bedeutet, dass fehlerhafte Variablen normalerweise nicht bei Verwendung von s.tl() eingehen, aber es wird dringend empfohlen, s.t() in einer SPA zu verwenden. Trotzdem möchte ich empfehlen, die Funktion Clear Variables sowohl für s.t() als auch für s.tl() in einer SPA-Umgebung zu verwenden, um eine qualitativ hochwertige Datenerfassung sicherzustellen.

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

Weitere zu berücksichtigende Aspekte

Windows mit benutzerspezifischem Code in Experience Platform Launch

In der Erweiterung Launch Analytics können Sie an zwei Stellen benutzerdefinierten Code einfügen: Der Abschnitt Bibliotheksverwaltung und der zusätzliche Abschnitt "Tracker mit benutzerspezifischem Code konfigurieren".

Es ist wichtig zu wissen, dass einer dieser Orte den Code nur einmal in ihnen ausführt, wenn das erste Laden der Seite auf Ihrer SPA erfolgt. Wenn der Code bei einer Ansichtsänderung oder einer Aktion auf Ihrer Site ausgeführt werden soll, sollten Sie der entsprechenden Regel eine zusätzliche Aktion hinzufügen (z. B. beim "Laden der Seite: event-view-end" rule), sodass der Code jedes Mal ausgeführt wird, wenn rule ausgeführt wird. Legen Sie beim Erstellen dieser Aktion in der Regel Erweiterung = Core und Aktionstyp = Benutzerspezifischer Code fest.

"Hybrid"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. Achten Sie beim Konfigurieren Ihrer benutzerspezifischen Ereignisse auf der Site und beim Auslösen der Regeln in Experience Platform Launch darauf, dass von der Seite aus keine doppelten Treffer gesendet werden, die auf Hash-Änderungen usw. basieren. Analytics (wenn Sie so die Experience Platform Launch-Regel Trigger haben). In diesem Fall müssen Sie eine der Seitenansichten unterdrücken, damit Sie keine fehlerhaften Daten in Adobe Analytics erhalten.

Wenn Sie die Funktion in separate Regeln unterteilen möchten, damit Sie mehr Kontrolle darüber haben, denken Sie daran/dokumentieren, dass Sie dies getan haben, sodass alle Änderungen an einer Regel auch an der anderen Regel vorgenommen werden können, wodurch Ihre Analytics-Datenintegrität geschützt wird.

Integration mit Target über A4T

Nur ein kurzer Hinweis. Wenn Sie mit Target mit A4T integrieren, stellen Sie sicher, dass die Target-Anforderung und die Analytics-Anforderung für dieselbe Ansichtsänderung dieselbe SDID aufweisen. 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 heruntergeladen werden kann HERE. 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 über die Adobe
• Referenzarchitektur-Sites zur Implementierung von SPA in Experience Platform Launch