Utilisation des bonnes pratiques lors du suivi des applications monopages (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 monopages (SPA). Ce document se concentre sur l’utilisation d’Adobe Experience Platform Launch, qui est la méthode d’implémentation recommandée.

NOTES INITIALES :

  • Les éléments ci-dessous supposent que vous utilisez Experience Platform Launch pour l’implémentation sur votre site. Les considérations persistent si vous n’utilisez pas Experience Platform Launch, mais vous devez les adapter à votre méthode d’implémentation.
  • Toutes les SPA sont différentes. Vous devrez peut-être donc ajuster certains des éléments suivants pour répondre au mieux à vos besoins, mais nous avons voulu partager certaines bonnes pratiques avec vous. Il s’agit d’éléments auxquels vous devez réfléchir lorsque vous implémentez Adobe Analytics sur des pages SPA.

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

spa pour analytics dans launch

REMARQUE : comme indiqué, il s’agit d’un schéma simplifié de la façon dont les pages SPA sont traitées dans une implémentation d’Adobe Analytics à l’aide d’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 se déclenche et ne déclenche des règles dans Experience Platform Launch, de sorte qu’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 d’une modification d’affichage ou d’une action sur votre application monopage. 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 est chargé 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 : les règles d’appel direct ou les événements personnalisés.

  • Règles d’appel direct : dans Experience Platform Launch, vous pouvez configurer une règle d’appel direct qui s’exécute lorsqu’elle est appelée 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 peut exécuter un ensemble spécifique d’instructions à chaque fois (définissez eVar4 sur X et déclenchez event2 à chaque fois), vous pouvez alors utiliser une règle d’appel direct. Consultez la documentation d’Experience Platform Launch 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 devez utiliser cette méthode d’événements personnalisés.

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

  • event-view-start : cet événement doit se déclencher au démarrage d’affichage/d’état en cours de chargement.
  • event-view-end : cet événement doit être déclenché même lorsqu’une modification d’affichage/d’état s’est produite et que tous les composants SPA de la page ont terminé leur chargement. 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 les modes et les moments de déclenchement, 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 indique où, dans Experience Platform Launch, écouter les événements personnalisés.

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

L’une des choses les plus importantes à comprendre pour Analytics lors de l’utilisation d’une application monopage 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 la considériez comme 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 « track link » 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 légère, 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 appliquent 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 utiliser s.t(). Si la modification de l’écran est inférieure à 50 %, utilisez s.tl(). Cependant, c’est à vous de décider ce que vous considérez être 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() dans Experience Platform Launch.

Effacement des variables

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

Dans le diagramme ci-dessus, cette opération est répertoriée à la fin du processus, effaçant les variables après l’envoi de l’accès. En réalité, vous pouvez le faire avant OU après l’envoi de l’accès. Toutefois, cela doit être cohérent dans vos règles Experience Platform Launch, afin que l’effacement se fasse toujours avant ou après la définition de variables et leur envoi. Souvenez-vous que si vous devez effacer les variables avant d’exécuter s.t(), assurez-vous d’abord d’effacer les variables, puis de définir les nouvelles variables, et enfin d’envoyer les nouvelles données dans Analytics.

REMARQUE : l’effacement des variables n’est pas toujours nécessaire lors de l’exécution de s.tl(), car s.tl() nécessite l’utilisation parallèle de la variable linkTrackVars à 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 n’apparaissent généralement pas lors de l’utilisation de s.tl(), mais cette opération est vivement recommandée lorsque vous utilisez s.t() dans un environnement SPA. Cela dit, en guise de bonne pratique, je recommande vivement d’utiliser la fonction Effacer les variables pour s.t() et s.tl() dans un environnement SPA, afin d’assurer une 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.

Fenêtres de code personnalisé de Launch Analytics

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 une modification d’affichage ou sur une action de votre site, vous devez ajouter une action supplémentaire à la règle appropriée (par exemple, dans la règle « chargement de page : fin-d’affichage-d’événement »), 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é.

Sites SPA/standard « hybrides »

Certains sites consistent en une combinaison de pages « normales » et de pages SPA. Dans ce cas, vous devez 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 devez 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 d’avoir 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

Voici juste un petit rappel. Si vous effectuez une intégration à Target à l’aide d’A4T, assurez-vous que la requête Target et la requête Analytics sur la même modification d’affichage 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 Experience Cloud Debugger, une extension Chrome qui peut être téléchargée ICI. 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

Sur cette page