Migration de l’implémentation de l’Audience Manager de votre site du DIL côté client vers le transfert côté serveur migrating-your-site-s-aam-implementation-from-client-side-dil-to-server-side-forwarding

Ce tutoriel s’applique à vous si vous disposez à la fois de Adobe Audience Manager (AAM) et d’Adobe Analytics, et que vous envoyez actuellement un accès de la page à AAM à l’aide du code du DIL (Data Integration Library), ainsi qu’un accès de la page à Adobe Analytics. Puisque vous disposez de ces deux solutions et qu’elles font toutes deux partie de Adobe Experience Cloud, vous avez la possibilité de suivre la bonne pratique consistant à activer le transfert côté serveur, ce qui permet aux serveurs de collecte de données Analytics de transférer les données d’analyse de site en temps réel vers l’Audience Manager, au lieu d’avoir un code côté client qui envoie un accès supplémentaire de la page vers AAM. Ce tutoriel vous guide tout au long des étapes permettant de passer de l’ancienne mise en oeuvre du DIL côté client à la nouvelle méthode de transfert côté serveur.

Côté client (DIL) et côté serveur client-side-dil-vs-server-side

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

Mise en oeuvre du DIL côté client client-side-dil-implementation

Si vous utilisez cette méthode pour obtenir des données Adobe Analytics dans AAM, vous obtenez deux accès provenant de vos pages web : l’un se rend sur Analytics et l’autre sur 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. Cette opération est considérée comme une implémentation héritée et n’est plus recommandée.

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

Il est recommandé de passer à une méthode de transfert côté serveur de mise en oeuvre AAM.

Mise en oeuvre du transfert côté serveur server-side-forwarding-implementation

Comme illustré dans l’image ci-dessus, un accès provient de la page Web vers Adobe Analytics. Analytics transfère ensuite ces données à AAM en temps réel, et les visiteurs sont évalués en caractéristiques AAM et segments, comme si l’accès provenait directement de la page.

Segments sont renvoyés sur le même accès en temps réel à Analytics, qui transfère la réponse sur la page web pour la personnalisation, etc.

Il n’y a aucun inconvénient à ce que le transfert côté serveur soit effectué. Adobe recommande vivement à quiconque possède à la fois une Audience Manager et Analytics d’utiliser cette méthode de mise en oeuvre.

Vous avez deux tâches principales : you-have-two-main-tasks

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

Si vous ignorez l’une de ces tâches, le transfert côté serveur 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 de mise en oeuvre implementation-options

Lorsque vous passez du transfert côté client au transfert côté serveur, l’une des tâches qui s’affiche est de modifier le code en nouveau code de transfert côté serveur. Pour ce faire, utilisez l’une des options suivantes :

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

Etapes de mise en oeuvre implementation-steps

Les étapes suivantes décrivent la mise en oeuvre.

Étape 0 : condition requise : service d’ID Experience Cloud (ECID) step-prerequisite-experience-cloud-id-service-ecid

La principale condition préalable au passage au transfert côté serveur consiste à mettre en oeuvre le service d’ID Experience Cloud. Cela est plus facile si vous utilisez 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 ECID pour exécuter avant toute autre solution d’Adobe. Pour plus d’informations, consultez la documentation ECID . La seule autre condition préalable concerne les versions de code. Par conséquent, comme vous appliquez simplement les versions les plus récentes du code dans les étapes suivantes, tout ira bien.

Étape 1 : enregistrer les options actuellement utilisées du code du DIL step-record-currently-used-options-from-dil-code

Lorsque vous vous préparez à passer du code du DIL côté client au transfert côté serveur, la première étape consiste à identifier tout ce que vous faites avec le code du DIL, y compris les paramètres personnalisés et les données envoyées à AAM. Voici quelques éléments à noter et à prendre en compte :

Étape 2 : mise à jour du code step-updating-the-code

Dans Options d’implémentation (ci-dessus), plusieurs options sont données concernant la manière et l’emplacement d’implémentation du transfert côté serveur. Pour que cette section soit efficace, nous devons la diviser en deux sections (deux d’entre elles étant combinées). Accédez à la méthode de cette section qui décrit le mieux vos besoins.

Balises Adobe Experience Platform launch-by-adobe

Regardez la vidéo ci-dessous pour en savoir plus sur le déplacement des options de mise en oeuvre du code du DIL côté client vers le transfert côté serveur dans Experience Platform Launch.

"Sur la page" ou gestionnaire de balises non Adobe on-the-page-or-non-adobe-tag-manager

Regardez la vidéo ci-dessous pour en savoir plus sur le déplacement des options de mise en oeuvre du code du DIL côté client vers le transfert côté serveur 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) step-enabling-the-forwarding-per-report-suite

Jusqu’à présent, dans ce tutoriel, nous avons passé tout notre temps à changer le code du DIL côté client en transfert côté serveur. C'est bien, parce que c'est la partie la plus difficile. Bien que cette section soit très facile à voir, elle est tout aussi importante que la mise à jour du code. Dans cette vidéo, vous allez découvrir comment changer 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 timing

Pour rappel, il existe deux tâches principales pour passer du DIL côté client au transfert côté serveur :

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. En quoi est-ce vague ? Faisons une ventilation. Mais d'abord une question supplémentaire qui peut apparaître si vous êtes une grande organisation avec de nombreux sites : Dois-je tout faire en même temps ? Celle-là est un peu plus facile. Non. Vous pouvez le faire morceau par morceau.

Une plongée un peu plus profonde a-little-deeper-dive

La raison pour laquelle le timing et la commande sont importants est due au fonctionnement du transfert true, qui peut être résumé dans les quelques faits techniques suivants :

Bonnes pratiques best-practices

Sur la base de ces détails techniques, voici les recommandations pour connaître le moment et le moment où :

Si vous n’avez PAS encore implémenté ECID if-you-do-not-have-ecid-yet-implemented

Si ECID est implémenté if-you-do-have-ecid-implemented

Délai de migration lorsque vous avez de nombreux sites et report suites migration-timing-when-you-have-many-sites-and-report-suites

Cette rubrique est brièvement abordée dans les sections précédentes, dans la mesure où 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 devenir un peu délicat en fonction de quelques scénarios possibles :

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

Validation et dépannage validation-and-troubleshooting

La principale façon de vérifier que le transfert côté serveur est opérationnel consiste à examiner la réponse à l’un de vos accès Adobe Analytics provenant de l’application.

Si vous n’effectuez pas de transfert côté serveur des données de Analytics vers l’Audience Manager, aucune réponse n’est apportée à la balise Analytics (hormis un pixel 2x2). Cependant, si vous effectuez un transfert côté serveur, vous pouvez vérifier certains éléments dans la requête Analytics et la réponse qui vous permettront de savoir que Analytics communique correctement avec l’Audience Manager, de transférer l’accès et d’obtenir une réponse.

Pour plus d’informations sur le transfert côté serveur, consultez la documentation.