Migration de l’implémentation AAM de votre site du DIL Client-Side vers Server-Side Forwarding

Ce didacticiel s’applique à vous si vous avez Adobe Audience Manager (AAM) et Adobe Analytics, et que vous envoyez actuellement un accès de la page à AAM à l’aide du code "DIL" (Data Integration Library) et que vous envoyez également un accès de la page à Adobe Analytics. Puisque vous disposez de ces deux solutions et qu'elles font toutes deux partie de la Adobe Experience Cloud, vous avez la possibilité de suivre la bonne pratique consistant à activer "Server-Side Forwarding (SSF)", qui permet aux serveurs de collecte de données Analytics de transférer les données d'analyse du site en temps réel à l'Audience Manager, au lieu d'avoir client-side code qui envoie un accès supplémentaire de la page à l'AAM. Ce didacticiel vous guide tout au long des étapes permettant de passer de l’implémentation plus ancienne "Client-Side DIL" à la nouvelle méthode "Server-Side forwarding".

Client-Side (DIL) ou Server-Side

Lors de la comparaison et de la comparaison de ces deux méthodes d’obtention de données Adobe Analytics en AAM, il peut s’avérer utile de visualiser les différences dans l’image suivante :

côté client vers côté serveur

Client-side Mise en oeuvre DIL

Si vous utilisez cette méthode pour obtenir des données Adobe Analytics dans AAM, cela signifie que vous avez deux accès provenant de vos pages Web : L'un se rend à Analytics et l'autre à AAM (après avoir copié les données Analytics sur la page Web. Segments sont renvoyés d’AAM à la page, où ils peuvent être utilisés pour la personnalisation, etc. Il s’agit d’une mise en oeuvre "héritée" et n’est plus recommandé.

Outre le fait qu'il ne s'agit pas de pratiques exemplaires, l'utilisation de cette méthode présente les inconvénients suivants :

  • Deux accès provenant de la page au lieu d’un seul
  • Server-Side Forwarding est requis pour le partage en temps réel des audiences AAM à Analytics, de sorte que les Client-side implémentations ne permettent pas cette fonctionnalité (et potentiellement d’autres fonctionnalités dans le futur)

Il est recommandé de passer à une méthode Server-Side Forwarding d’implémentation AAM.

Server-Side ForwardingImplémentation

Comme le montre l'image ci-dessus, un accès vient de la page Web à Adobe Analytics. Analytics transfère ensuite ces données à l’AAM en temps réel et les visiteurs sont évalués en AAM traits et segmentscomme si l’accès provenait directement de la page.

Segments sont renvoyés lors du même accès en temps réel à Analytics, qui renvoie la réponse à la page Web pour la personnalisation, etc.

Le transfert côté serveur ne présente aucun inconvénient temporel. Nous recommandons vivement que toute personne ayant à la fois Audience Manager et Analytics utilise cette méthode d’implémentation.

Vous Avez DEUX Tâches principales

Il y a pas mal d'informations sur cette page, et c'est important, bien sûr. Cependant, il se résume à deux choses principales que vous devez faire :

  1. Remplacez votre code par le code Client-Side DIL par Server-Side Forwarding.
  2. Basculez le commutateur dans Analytics Admin Console pour début du transfert réel des données (par report suite).

Si vous ignorez l’un ou l’autre de ces deux paramètres, SSF ne fonctionnera pas correctement. Des étapes et des données supplémentaires ont été ajoutées à ce document pour vous aider à effectuer ces deux étapes correctement pour votre configuration.

Options d’implémentation

Lorsque vous passez de client-side à server-side, l'une des tâches que vous aurez est de remplacer le code par le nouveau code Server-Side Forwarding. Pour ce faire, utilisez l’une des options suivantes :

  • Adobe Experience Platform Launch - Notre option d'implémentation recommandée pour les propriétés Web. Vous verrez que c'est une tâche très facile, car Launch a fait toutes les choses difficiles pour vous.
  • Sur la page - Vous pouvez également placer le nouveau code SSF directement dans la fonction doPlugins à l'intérieur de votre fichier appMeasurement.js, si vous n'utilisez pas (encore) le lancement d'Adobe.
  • Autres gestionnaires de balises : ils peuvent être traités de la même manière que l’option précédente (Sur la page), car vous placerez toujours le code SSF dans doPlugins, où l’autre gestionnaire de balises stocke le code AppMeasurement.

Nous allons examiner chacun de ces éléments ci-dessous dans la section Mise à jour du code.

Procédure de mise en œuvre

Étape 0 : Condition préalable : Service d’identification des Experience Cloud (ECID)

La principale condition requise pour passer à Server-Side Forwarding est la mise en oeuvre du service d’identification des Experience Cloud. Cela est plus facile si vous utilisez l'Experience Platform Launch, auquel cas vous installez simplement l'extension ECID et cela fera le reste.

Si vous utilisez un TMS non Adobe ou aucun TMS du tout, implémentez l'ECID pour exécuter avant toute autre solution d'Adobe. Voir la documentation ECID pour plus de détails. Le seul autre prérequis concerne les versions de code, de sorte que, comme vous appliquez simplement les versions les plus récentes du code dans les étapes suivantes, vous vous en sortirez bien.

REMARQUE

Veuillez lire ce document entier avant de procéder à la mise en oeuvre. La section "Minutage" ci-dessous contient des informations importantes sur quand vous devez implémenter chaque élément, y compris l'ECID (s'il n'est pas encore implémenté).

Étape 1 : Enregistrer les options actuellement utilisées à partir du code DIL

Lorsque vous vous préparez à passer du code de DIL Client-Side à Server-Side Forwarding, la première étape consiste à identifier tout ce que vous faites avec le code de DIL, y compris les paramètres personnalisés et les données envoyées à l'AAM. Voici les points à prendre en compte :

  • Variables Analytics normales, à l'aide du module DIL siteCatalyst.init - Vous n'aurez pas à vous inquiéter de celle-ci, car son travail consiste simplement à envoyer les variables Analytics normales, et cela se fera simplement en ayant SSF activé.
  • Sous-domaine partenaire : dans la fonction DIL.create, notez le paramètre partner. Il s’agit de votre "sous-domaine partenaire", ou parfois de votre "identifiant partenaire", qui sera nécessaire lorsque vous placerez le nouveau code SSF.
  • Visitor Service Namespace - Également appelé "Org ID" ou "IMS Org ID", vous en aurez également besoin lorsque vous configurerez le nouveau code SSF. En prends note.
  • containerNSID, uuidCookie et d'autres options avancées : notez les options avancées supplémentaires que vous utilisez afin de pouvoir les définir dans le code SSF.
  • Variables de page supplémentaires - Si d'autres variables sont envoyées à l'AAM à partir de la page (en plus des variables Analytics normales gérées par siteCatalyst.init), vous devez en prendre note afin qu'elles puissent être envoyées via SSF (spoiler alert : par le biais de contextData variables).

Étape 2 : Mise à jour du code

Dans la section ci-dessus intitulée "Options d’implémentation", plusieurs options sont fournies concernant la manière et l’emplacement d’implémentation de Server-Side Forwarding. Pour que cette section soit efficace, nous devons la diviser en deux sections (dont deux sont combinées). Accédez à la méthode de cette section qui décrit le mieux vos besoins.

Adobe Experience Platform Launch

Regardez la vidéo ci-dessous pour en savoir plus sur le déplacement des options d'implémentation du code du DIL Client-Side vers Server-Side Forwarding dans l'Experience Platform Launch.

"Sur la page" ou non-Adobe Tag Manager

Regardez la vidéo ci-dessous pour en savoir plus sur le déplacement des options d’implémentation du code du DIL Client-Side vers Server-Side Forwarding dans le code AppMeasurement, résidant dans un fichier ou dans un système de gestion des balises non Adobe.

Étape 3 : Activation du transfert (par Report Suite)

Jusqu'à présent, dans ce tutoriel, nous avons passé tout notre temps à changer le code de Client-Side DIL en Server-Side Forwarding. C'est bien, parce que c'est la partie la plus difficile. Cette section, bien que vous verrez qu'elle est très facile, est tout aussi importante que la mise à jour du code. Dans cette vidéo, vous verrez comment basculer le commutateur qui permet le transfert réel des données d’Analytics vers l’Audience Manager.

REMARQUE : Comme indiqué dans la vidéo, n'oubliez pas que l'activation du transfert prendra jusqu'à 4 heures pour être entièrement mise en oeuvre sur le serveur principal Experience Cloud.

Minutage

Pour rappel, il existe deux tâches principales pour passer de Client-Side DIL à Server-Side Forwarding :

  1. Mise à jour du code
  2. Basculement du commutateur dans Analytics Admin Console

Mais la question est, laquelle faites-vous en premier ? Est-ce important ? OK, désolé, c'était deux questions. Mais les réponses sont… ça dépend, et oui, ça peut compter. Comment cela est-il vague ? Partageons-le. Mais d'abord une question supplémentaire qui peut se poser si vous êtes une grande organisation avec beaucoup de sites : Dois-je tout faire en même temps ? Celle-là est un peu plus facile. Non. Vous pouvez le faire morceau par morceau… en quelque sorte. 😃

Un petit plongeon plus profond

La raison pour laquelle le timing et la commande sont importants est la façon dont le transfert *fonctionne vraiment, ce qui peut être résumé dans les quelques faits techniques suivants :

  • Si le service d’ID d’Experience Cloud (ECID) est mis en oeuvre et que le commutateur Analytics Admin Console ("le commutateur") est activé, les données seront transférées de Analytics à l’AAM, même si vous n’avez pas encore mis à jour le code.
  • Si l'ECID n'est pas implémenté, les données ne seront pas transférées, même si le commutateur est activé et que le code SSF est activé.
  • Le code SSF (que ce soit dans Launch ou sur la page) traite réellement la réponse et est bien sûr nécessaire pour terminer la migration.
  • N'oubliez pas que le commutateur SSF est activé par Report Suite, mais que le code est géré par la propriété dans Launch ou par le fichier AppMeasurement si vous n'utilisez pas Launch.

Bonnes pratiques

Sur la base de ces détails techniques, voici les recommandations concernant le calendrier de "quoi faire quand" :

Si vous n’avez PAS encore implémenté l’ECID

  1. Retourner le commutateur dans Analytics pour chaque report suite que vous allez activer pour SSF

    1. Le transfert ne sera pas encore début car vous n’avez pas ECID
  2. Par site, mettez à jour votre code de Client-Side DIL vers SSF (il peut s’agir de Launch ou de la page, comme expliqué dans une autre section ci-dessus).

    1. Désormais, le transfert s’effectue (comme vous avez ajouté ECID) et vous devriez également recevoir une réponse JSON appropriée à votre balise Analytics (voir la section Validation et dépannage ci-dessous pour plus d’informations).

Si ECID est implémenté

  1. Préparez et planifiez pour que vous soyez prêt à mettre à jour votre code du DIL vers SSF PER report suite que vous activez pour SSF :

    1. Retourner le commutateur dans Analytics pour activer SSF

      1. Transfert WILL début car l'ECID est activé
    2. Dans les meilleurs délais, mettez à jour votre code de Client-Side DIL vers SSF (il peut s’agir de Launch ou de la page, comme expliqué dans une autre section ci-dessus).

      1. Vous devez recevoir une réponse JSON appropriée à votre balise Analytics (voir la section Validation et dépannage ci-dessous pour plus de détails).

REMARQUE 1 : Il est important d'effectuer ces deux étapes aussi près que possible, car entre les étapes 1 et 2 ci-dessus, vous aurez la duplication des données en AAM. En d’autres termes, SSF a commencé à envoyer des données de Analytics à l’AAM, et comme le code du DIL est toujours sur la page, il y aura également un accès allant directement de la page à l’AAM, doublant ainsi les données. Dès que vous mettez à jour le code du DIL vers SSF, cela sera allégé.

REMARQUE 2 : Si vous préférez une légère incohérence des données plutôt qu'une petite duplication des données, vous pouvez changer l'ordre des étapes 1 et 2 ci-dessus. Si vous déplacez le code du DIL vers SSF, le flux de données vers l'AAM s'arrêterait jusqu'à ce que vous fassiez basculer le commutateur pour activer le SSF pour le report suite. En règle générale, les clients préfèrent avoir un petit doublement de données plutôt que de ne pas obtenir de visiteurs dans traits et segments.

Minutage de la migration lorsque vous avez plusieurs sites et Report Suites

Cette question est brièvement abordée dans les sections précédentes, en ce sens que la stratégie principale peut être résumée comme suit :

Migrez un site/report suite (ou un groupe de sites/report suites) à la fois.

Cependant, cela peut se révéler délicat en fonction de quelques scénarios possibles :

  • Vous disposez d’un site qui contient plusieurs report suites distincts.
  • Vous avez un report suite qui comprend plusieurs sites (par exemple un report suite global).
  • Vous utilisez une propriété Launch pour couvrir plusieurs sites.
  • Vous avez différentes équipes de développement pour différents sites

A cause de ces éléments, ça peut devenir un peu compliqué. Les meilleures choses que je puisse suggérer sont les suivantes :

  • Prenez le temps d'élaborer une stratégie de migration vers le SSF, en fonction des éléments décrits ci-dessus.
  • En vous fondant sur le fait qu'une seule propriété dans Launch (ou un seul fichier AppMeasurement) correspond généralement à 1 ou 2 report suites distincts, vous serez probablement en mesure de faire un plan qui fonctionne sur ces groupes distincts un par un, mettant à jour votre entreprise en SSF.
  • Si vous travaillez avec Adobe Consulting, contactez-les au sujet de votre plan de migration afin qu’ils puissent vous aider au besoin.

Validation et dépannage

Le principal moyen de vérifier que Server-Side Forwarding est en cours d’exécution consiste à examiner la réponse à n’importe quel accès Adobe Analytics provenant de l’application.

Si vous ne faites pas server-side forwarding de données de Analytics à l'Audience Manager, il n'y a vraiment pas de réponse à la balise Analytics (en plus d'un pixel de 2x2). Cependant, si vous utilisez SSF, il existe des éléments que vous pouvez vérifier dans la requête et la réponse Analytics qui vous informeront que Analytics communique correctement avec l'Audience Manager, transfère l'accès et obtient une réponse.

AVERTISSEMENT : Attention au faux “succès” - S’il y a une réponse, et que tout semble fonctionner, assurez-vous que vous avez l’objet “truc” dans la réponse. Si vous ne le faites pas, vous pouvez voir un message indiquant “status”:“SUCCESS”. Aussi fou que cela paraisse, c’est en fait BAT qu’il ne fonctionne PAS correctement. Si vous voyez cela, cela signifie que vous avez terminé la mise à jour du code dans Launch ou AppMeasurement, mais que le transfert dans Analytics Admin Console n’est pas encore terminé. Dans ce cas, vous devez vérifier que vous avez activé SSF dans Analytics Admin Console pour votre report suite. Si vous l’avez fait, et cela n’a pas encore été 4 heures, soyez patient, car cela peut prendre autant de temps pour apporter tous les changements nécessaires sur le serveur principal.

faux succès

Pour plus d'informations sur Server-Side Forwarding, consultez la documentation.

Sur cette page