Bonnes pratiques d’implémentation pour les applications monopages (SPA) implementation-best-practices-for-single-page-appliations

Découvrez quelques bonnes pratiques pour implémenter Adobe Analytics sur des applications monopages (SPA). Cela inclut l’utilisation des Experience Platform Tags, la méthode d’implémentation recommandée.

REMARQUES INITIALES :

  • Le contenu ci-dessous fait référence à l’utilisation des Experience Platform Tags pour implémenter Adobe Analytics sur votre site. Ces considérations s’appliquent si les Experience Platform Tags ne sont pas utilisées. Dans ce cas, vous devrez les adapter à votre méthode d’implémentation.
  • Il existe des différences entre les SPA. Vous devez donc ajuster votre approche en fonction de vos besoins.

Schéma simple de l’utilisation des SPA dans les Experience Platform Tags simple-diagram-of-working-with-spas-in-tags

SPA pour Analytics dans les balises

REMARQUE : 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 des Experience Platform Tags. Les sections suivantes décrivent les étapes et les problèmes à prendre en compte.

Définir la couche de données set-the-data-layer

Lors du chargement d’un nouveau contenu ou d’une action sur une page SPA, mettez à jour la couche de données en premier. Cela doit se produire avant qu’un événement personnalisé qui déclenche l’exécution d’une règle ne s’exécute dans les Experience Platform Tags. Cela permet de s’assurer que les valeurs correctes de la couche de données sont transmises dans les balises, puis dans Adobe Analytics.

Voici un exemple de couche de données. L’un de ces éléments peut changer en fonction de l’affichage initial ou de sa modification ultérieure, compte tenu d’une action effectuée sur votre page SPA. Par exemple, lors d’un changement d’affichage complet ou majoritaire, il est courant de transmettre une valeur « pageName » unique pour différencier les affichages dans les rapports 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éfinir des événements personnalisés et les écouter dans les Experience Platform Tags setting-custom-events-and-listening-in-tags

Lors du chargement d’un nouveau contenu ou d’une action sur la page SPA, les balises Experience Platform doivent être informées afin d’exécuter une règle qui envoie des données à Analytics. Il existe deux approches pour cela : Règles d’appel direct ou Événements personnalisés.

  • Règles d’appel direct : configurez une règle d’appel direct qui s’exécute lorsqu’elle est appelée directement à partir de la page. Si le chargement ou l’action de la page est simple ou unique et peut exécuter un ensemble spécifique d’instructions à chaque fois (par exemple, définir eVar4 sur X et déclencher event2 à chaque fois), cette approche sera adaptée. Pour plus d’informations sur la création de règles d’appel direct, voir la documentation des Experience Platform Tags.
  • Événements personnalisés : si vous devez joindre dynamiquement une payload avec des valeurs uniques pour les événements qui se produisent sur les pages SPA, utilisez des événements JavaScript personnalisés et écoutez-les dans les Experience Platform Tags. Utilisez la payload pour définir les éléments de données et les variables Analytics dans les balises. Cette méthode est considérée comme la bonne pratique, car ce besoin est généralement courant pour les SPA. Les exemples ci-dessous utilisent la méthode d’événements personnalisés.

Exemples : ce document d’aide comporte des liens vers des exemples de sites SPA qui implémentent Analytics et d’autres solutions Experience Cloud. Dans ces exemples, les événements personnalisés suivants ont été utilisés :

  • Event-view-start  : s’exécute au démarrage d’affichage/d’état en cours de chargement.
  • Event-view-end  : s’exécute lorsqu’une modification d’affichage/d’état se produit et que tous les composants SPA de la page terminent leur chargement. Il s’agit de l’événement qui envoie généralement des données à Adobe Analytics.
  • Event-action-trigger  : s’exécute lorsqu’un événement se produit sur la page, à l’exception du chargement d’affichage/d’état. Il peut s’agir, par exemple, d’un événement de clic ou d’une modification de contenu plus petite sans changement d’affichage.

Pour plus d’informations sur comment et quand ces événements se déclenchent, reportez-vous aux pages et documents susmentionnés. Vous n’avez pas besoin d’utiliser les mêmes noms d’événement dans votre implémentation. Il est essentiel de comprendre le cas d’utilisation fonctionnel de la méthode utilisée, car il s’agit de la bonne pratique recommandée pour chacune. La vidéo suivante présente un exemple de page SPA et un exemple de code dans les Experience Platform Tags qui écoute les événements personnalisés.

Exécuter s.t() ou s.tl() dans les Experience Platform Tags running-s-t-or-s-tl-in-the-launch-rule

Un concept important à comprendre pour Analytics, lorsque vous utilisez une SPA, est la différence entre s.t() et s.tl(). Votre code déclenche l’une ou l’autre de ces méthodes dans les Experience Platform Tags pour envoyer des données dans Analytics.

  • s.t()  : « t » signifie « track » (suivi) et correspond à une page vue. Si l’affichage change au point que vous le considérez comme une nouvelle « page », utilisez cet appel. Définissez une valeur unique sur la variable s.pageName et utilisez s.t() pour envoyer les données dans Analytics.

  • s.tl()  : « tl » signifie « track link » (lien de suivi) et représente un clic sur les liens ou un petit changement de contenu. Si le changement d’affichage est minimal, utilisez s.tl() pour transmettre une valeur unique sur l’interaction à Analytics. Cette variable transmise n’est pas s.pageName, car elle est ignorée dans Analytics lorsque des appels s.tl() sont reçus.

CONSEIL : en règle générale, si l’écran change de plus de 50 %, utilisez l’appel de page vue s.t(). Sinon, utilisez s.tl(). Toutefois, faites preuve de jugement lorsque vous envisagez des actions qui constituent une nouvelle « page » et la manière dont elles doivent être présentées dans les rapports Adobe Analytics.

La vidéo suivante montre où et comment déclencher s.t() ou s.tl() dans les balises.

Effacer des variables clear-variables

Envoyez les données appropriées dans Analytics au bon moment. Dans un environnement SPA, une valeur stockée dans une variable Analytics peut persister et être renvoyée dans Analytics, potentiellement lorsque vous ne le voulez plus. Une fonction existe dans l’extension Analytics Tags pour effacer les variables, de façon à s’assurer que l’appel suivant n’envoie pas par erreur des données dans Analytics.

Le diagramme ci-dessus montre les variables effacées après avoir envoyé des données. En réalité, cela peut se produire avant OU après l’appel. Toutefois, restez cohérent dans la définition de vos règles Experience Platform Tags pour une implémentation plus épurée. Si vous effacez des variables avant d’exécuter s.t(), définissez les nouvelles variables immédiatement après l’appel, puis procédez à l’envoi des nouvelles données dans Analytics.

REMARQUE : l’effacement des variables n’est pas toujours nécessaire lors de l’exécution de s.tl(). Cet appel nécessite l’utilisation de la variable linkTrackVars pour indiquer à Analytics les variables à définir. Cela se produit automatiquement sur Experience Platform Tags via la configuration. Cela empêche les variables errantes de définir en contraste avec le comportement avec les appels s.t() dans un environnement SPA. Pour garantir l’implémentation la plus épurée et la plus fiable, il est probablement plus facile d’utiliser la fonction d’effacement des variables pour les deux appels dans un environnement SPA.

La vidéo suivante montre où et comment effacer les variables dans les Tags.

Remarques complémentaires additional-considerations

Fenêtres de code personnalisé dans les Experience Platform Tags custom-code-windows-in-tags

L’extension Tags Analytics vous permet d’insérer du code personnalisé à deux endroits : les sections « Gestion des bibliothèques » et « Configurer le dispositif de suivi à l’aide du code personnalisé ».

Fenêtres de code personnalisé des balises Analytics

L’un de ces emplacements exécute le code contenu une fois pour que la page initiale charge votre page SPA. Si le code doit s’exécuter sur une modification d’action ou d’affichage, implémentez-le dans la règle appropriée (par exemple, la règle « page load: event-view-end »), pour vous assurer 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 « hybrides » traditionnels et SPA hybrid-spa-and-traditional-sites

Certains sites sont constitués d’une combinaison de pages traditionnelles et de pages SPA. Dans ce cas, utilisez une stratégie qui fonctionne pour les deux types de page. Lors de la configuration d’événements personnalisés sur le site et du déclenchement de règles dans les Experience Platform Tags, assurez-vous que les accès doubles ne sont pas envoyés dans Analytics en fonction des modifications de hachage, etc. Dans ce cas, supprimez l’une des pages vues pour empêcher la transmission de données en double dans Adobe Analytics.

Si vous décidez de séparer la fonctionnalité en des règles uniques pour plus de contrôle, pensez à documenter cette action. Si vous modifiez une règle, apportez la même modification à l’autre règle.

Intégration à Target via A4T integration-with-target-using-a4t

Lors de l’intégration à Target à l’aide d’A4T, vérifiez que les requêtes Target et Analytics envoyées sur le même affichage ou la même action transmettent la même valeur de paramètre SDID. Cela garantit que vos données se synchronisent correctement dans le serveur principal.

Pour afficher ces accès, utilisez un débogueur ou un outil de surveillance des paquets. Adobe fournit un débogueur Experience Platform à cet effet. Il s’agit d’une extension Chrome qui peut être téléchargée ici. Target doit s’exécuter en premier sur la page. Cela peut également être vérifié dans le débogueur.

Ressources supplémentaires additional-resources

recommendation-more-help
b5d9c99f-be9f-4b96-8809-4e7d6ae353ba