Utilisation des bonnes pratiques lors du suivi des applications d’une seule page (SPA) dans Adobe Analytics

Dans ce document, nous décrirons plusieurs bonnes pratiques que vous devez suivre et connaître lorsque vous utilisez Adobe Analytics pour effectuer le suivi des applications d’une seule page (SPA). Ce document se concentre sur l’utilisation de l’Adobe Experience Platform Launch, qui est la méthode de mise en oeuvre recommandée.

NOTES INITIALES :

• Les éléments ci-dessous supposent que vous utilisez Experience Platform Launch pour implémenter sur votre site. Les considérations persistent si vous n’utilisez pas Experience Platform Launch, mais vous devez les adapter à votre méthode de mise en oeuvre.
• Tous les SPA sont différents. Vous devrez peut-être donc ajuster certains des éléments suivants pour répondre le mieux à vos besoins, mais nous avons voulu partager certaines bonnes pratiques avec vous. éléments auxquels vous devez réfléchir pendant la mise en oeuvre d’Adobe Analytics sur SPA pages.

Schéma simple de l’utilisation de SPA dans Experience Platform Launch

REMARQUE : Comme indiqué, il s’agit d’un diagramme simplifié de la manière dont SPA pages sont traitées dans une mise en oeuvre Adobe Analytics à l’aide de Experience Platform Launch. Dans les sections suivantes de cette page, nous discuterons des étapes et des problèmes que vous devez soigneusement étudier ou traiter.

Définition de la couche de données

Lorsque du nouveau contenu est chargé sur une page SPA ou lorsqu’une action a lieu sur une page SPA, l’une des premières choses à faire est de mettre à jour la couche de données. Cela doit se produire AVANT que l’événement personnalisé ne déclenche et ne déclenche des règles dans Experience Platform Launch, de sorte que Experience Platform Launch puisse sélectionner les nouvelles valeurs de la couche de données et les transmettre dans Adobe Analytics.

Vous trouverez ci-dessous un exemple de couche de données, dont les éléments peuvent être modifiés lors du changement d’affichage ou de l’action sur votre SPA. Par exemple, lors d’une modification en plein écran/en majorité, il serait courant de modifier un élément "pageName", de sorte que le nouvel élément puisse être capturé dans Experience Platform Launch et envoyé dans Adobe Analytics.

<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>

Définition des événements personnalisés et de l’écoute dans Experience Platform Launch

Lorsque du nouveau contenu se charge sur la page ou lorsqu’une action se produit sur le site, vous souhaitez informer Experience Platform Launch afin qu’il puisse exécuter une règle et envoyer des données à Analytics. Il existe plusieurs façons de procéder : Appel direct règles ou événements personnalisés.

• Règles d’appel direct : dans Experience Platform Launch, vous pouvez configurer un appel direct qui s’exécute lorsqu’il est appelé directement à partir de la page. Si le chargement de votre page ou l’action effectuée sur votre site est très simple, ou s’il est unique et qu’il peut exécuter un ensemble spécifique d’instructions à chaque fois (définissez eVar4 sur X et déclenchez event2 à chaque fois), vous pouvez utiliser un appel direct règle. Voir Experience Platform Launch documentation concernant la création de règles d’appel direct.
• Événements personnalisés : Pour plus de fonctionnalités et pour la possibilité de joindre dynamiquement une payload avec différentes valeurs, vous devez définir des événements JavaScript personnalisés et les écouter dans Experience Platform Launch, où vous pouvez utiliser la payload pour définir des variables et envoyer les données dans Adobe Analytics. Il est plus probable que vous ayez besoin de cette fonctionnalité. Cette option est donc considérée comme la bonne pratique. Cependant, chaque fonction de votre site peut déterminer la méthode la plus appropriée. Nous avancerons dans ce document en supposant que vous devrez utiliser cette méthode d’événements personnalisée.

Exemples : dans 🔗 CE document d’aide, il existe des liens vers des exemples de sites SPA qui ont mis en oeuvre Analytics (et d’autres solutions Experience Cloud), ainsi que des documents décrivant ce qui a été mis en oeuvre. Dans ces SPA exemples, les événements personnalisés suivants ont été utilisés :

• event-view-start: Cet événement doit se déclencher au démarrage de la vue/de l’état en cours de chargement.
• event-view-end: Cet événement doit être déclenché même lorsqu’un changement d’affichage/d’état s’est produit et que tous les composants SPA de la page ont terminé de se charger. Il s’agit de l’événement qui déclenche généralement un appel dans Adobe Analytics.
• event-action-trigger: Cet événement doit se déclencher lorsqu’un événement se produit sur la page, à l’exception du chargement d’affichage/d’état. Il peut s’agir d’un événement de clic ou d’une modification de contenu plus petite sans changement d’affichage.

Pour plus d’informations sur le mode de déclenchement ou le moment où ils sont déclenchés, consultez les pages/documents référencés ci-dessus. Vous n’avez pas à utiliser ces mêmes noms d’événement, mais les fonctionnalités répertoriées ici sont les bonnes pratiques recommandées. La vidéo suivante montre un exemple de site et où dans Experience Platform Launch écouter les événements personnalisés.

Exécution de s.t() ou s.tl() dans la Experience Platform Launch règle

L’une des choses les plus importantes à comprendre pour Analytics lors de l’utilisation d’un SPA est la différence entre s.t() et s.tl(). Vous déclencherez l’une de ces méthodes dans Experience Platform Launch pour envoyer des données dans Analytics, mais vous devez savoir quand envoyer chacune d’elles.

• s.t() - "t" signifie "track" et correspond à une page vue normale. Même si l’URL ne change pas, la vue change-t-elle suffisamment pour que vous considériez qu’il s’agit d’une nouvelle "page" ? Si tel est le cas, définissez la variable s.pageName et utilisez s.t() pour envoyer l’appel dans Analytics.

• s.tl() : "tl" signifie "lien de suivi" et est généralement utilisé pour le suivi des clics ou des petites modifications de contenu sur la page, par opposition à un changement en plein écran. Si la modification de votre page est faible, de sorte que vous ne la considériez pas comme une nouvelle "page" complète, utilisez s.tl() et ne vous souciez pas de définir la variable s.pageName, car Analytics l’ignorera.

CONSEIL : Certaines personnes utilisent une directive générale selon laquelle si l’écran change de plus de 50 %, il doit être considéré comme une page vue et utilisé s.t(). Si la modification de l’écran est inférieure à 50 %, utilisez s.tl(). Cependant, c’est entièrement à vous et à ce que vous considérez comme une nouvelle "page" et comment vous souhaitez effectuer le suivi de votre site dans Adobe Analytics.

La vidéo suivante montre où/comment déclencher s.t() ou s.tl() en Launch by Adobe.

Effacement des variables

Lors du suivi de votre site avec Adobe Analytics, vous ne souhaitez bien sûr envoyer les données appropriées dans Analytics qu’au bon moment. Dans un environnement SPA, une valeur trackée dans une variable Analytics peut persister et être renvoyée dans Analytics, potentiellement lorsque nous ne le voulons plus. C’est pourquoi il existe une fonction dans l’extension Analytics Launch pour effacer les variables, de sorte que vous obteniez une nouvelle page lorsque vous exécutez la demande d’image suivante et envoyez les données dans Analytics.

Dans le diagramme ci-dessus, il est répertorié à la fin du processus, effaçant les variables après que vous envoyez dans l’accès. En réalité, cela peut être fait avant OU après l’envoi de l’accès, mais doit être cohérent dans vos règles Experience Platform Launch, de sorte que vous effacez toujours avant ou après la définition de variables et leur envoi. Souvenez-vous que si vous allez effacer les variables avant d’exécuter s.t(), assurez-vous d’abord d’effacer les variables, puis définissez les nouvelles variables, puis envoyez enfin les nouvelles données dans Analytics.

REMARQUE : L’effacement des variables n’est pas toujours nécessaire lors de l’exécution s.tl(), car s.tl() nécessite l’utilisation de la linkTrackVars variable à côté de celle-ci à chaque fois pour indiquer Analytics quelles variables vont être définies (automatiquement ajoutées en arrière-plan dans Experience Platform Launch). Cela signifie que les variables errantes ne sont généralement pas présentes lors de l’utilisation de s.tl(), mais il est vivement recommandé d’utiliser s.t() dans un environnement SPA. Cela dit, je recommande vivement d’utiliser la fonction Effacer les variables pour s.t() et s.tl() dans un environnement SPA, afin d’assurer la collecte de données de qualité.

La vidéo suivante montre où/comment effacer les variables dans Launch.

Autres points à prendre en compte

Fenêtres de code personnalisé dans Experience Platform Launch

Dans l’extension Launch Analytics, vous pouvez insérer du code personnalisé à deux endroits : La section Gestion de bibliothèque et la section "Configurer le dispositif de suivi à l’aide du code personnalisé" supplémentaire.

Il est important de savoir que l’un de ces emplacements n’exécute le code qu’une seule fois, lorsque le chargement initial de la page se produit sur votre page SPA. Si vous avez besoin que le code s’exécute sur un changement d’affichage ou sur une action de votre site, vous devez ajouter une action supplémentaire à la règle appropriée (par exemple, dans le "chargement de page : event-view-end" règle), de sorte que le code s’exécute chaque fois que la règle s’exécute. Lors de la création de cette action dans la règle, définissez Extension = Core et Type d’action = Code personnalisé.

"Hybride" SPA/sites standard

Certains sites sont une combinaison de pages "normales" et de pages SPA. Dans ce cas, vous devrez utiliser une stratégie qui fonctionne pour les deux types de page. Lors de la configuration de vos événements personnalisés sur le site et du déclenchement des règles dans Experience Platform Launch, veillez à ce qu’il n’y ait pas de double accès allant dans Analytics à partir de la page, en fonction des modifications de hachage, etc. (si c’est ainsi que vous avez choisi de déclencher la règle Experience Platform Launch). Dans ce cas, vous devrez supprimer l’une des pages vues afin qu’elle ne vous fournisse pas les données incorrectes dans Adobe Analytics.

Si vous décidez de diviser la fonctionnalité en règles distinctes afin que vous ayez plus de contrôle sur celle-ci, veillez à vous rappeler/documenter que vous avez fait cela, de sorte que toute modification d’une règle puisse être apportée à l’autre règle, protégeant ainsi l’intégrité de vos données Analytics.

Intégration à Target via A4T

Juste un petit rappel ici. Si vous effectuez une intégration avec Target à l’aide d’A4T, assurez-vous que la requête Target et la requête Analytics sur la même modification de vue ont le même SDID. Vous aurez ainsi la garantie que vos données se synchronisent correctement sur les solutions.

Pour afficher les accès, utilisez un débogueur ou un programme de renifleur de paquets. Vous pouvez également utiliser l’Experience Cloud Debugger, une extension Chrome qui peut être téléchargée HERE. Target doit être déclenché en premier sur la page. Vous pouvez donc également vérifier cela dans la console JavaScript ou dans le débogueur.

Ressources supplémentaires

• SPA discussion sur les forums de l'Adobe
• Sites d’architecture de référence pour montrer comment mettre en oeuvre SPA dans Experience Platform Launch