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 :
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.
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>
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.
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 :
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.
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.
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.
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 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é.
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.
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.