Implémentation d’Analytics for Target

Plusieurs étapes sont requises lors de l’implémentation de Adobe Analytics en tant que source de rapports pour Adobe Target (A4T).

Etapes de mise en oeuvre

Les sections suivantes décrivent les étapes requises pour déployer cette intégration sur votre site.

Étape 1 : Demander l’approvisionnement pour Analytics et la Cible

Après avoir implémenté Analytics en tant que source de rapports pour Target, vous devez être configuré pour Analytics et Target. Pour ce faire, utilisez ce formulaire.

Étape 2 : configuration des autorisations d’utilisateur

Les exigences du compte utilisateur doivent être satisfaites pour que vous puissiez créer une activité basée sur Analytics dans Target. Voir Exigences d’autorisation utilisateur.

Étape 3 : implémentation du service Identification des visiteurs d’Experience Cloud

Le service Identifiant visiteur permet d’identifier les utilisateurs sur l’ensemble des solutions Adobe Experience Cloud. Mettez en oeuvre ou migrez vers la version requise de l’ID de Visiteur Experience Cloud. Pour plus d’informations, consultez « Exigences d’implémentation » dans Avant de procéder à l’implémentation.

Voir Mise en oeuvre du service d’identification des Experience Cloud pour la Cible dans la documentation Service d’identification des Visiteurs Experience Cloud.

Étape 4 : mise à jour d’AppMeasurement pour JavaScript ou s_code

Implémentez ou migrez vers la version requise du fichier appMeasurement.js. Pour plus d’informations, consultez « Exigences d’implémentation » dans Avant de procéder à l’implémentation.

Pour les nouvelles implémentations, voir Présentation de l’implémentation JavaScript dans le Guide d’implémentation Analytics.

Pour une migration, voir Migration vers AppMeasurement pour JavaScript dans le Guide de mise en oeuvre d’Analytics.

Étape 5 : Téléchargement et mise à jour d’at.js

Implémentez ou migrez vers la version requise d’at.js à l’aide de votre compte de production. Aucune modification du code n’est requise.

Pour plus d’informations, consultez « Exigences d’implémentation » dans Avant de procéder à l’implémentation.

Étape 6 : Hôte at.js

Si vous avez déjà déployé at.js, vous pouvez remplacer votre fichier existant par la version mise à jour. Pour plus d’informations, voir « Exigences d’implémentation » dans Avant de procéder à l’implémentation.

Sinon, ce fichier peut être hébergé avec le service Identifiant visiteur et les fichiers AppMeasurement pour JavaScript. Ces fichiers doivent être hébergés sur un serveur web accessible par toutes les pages de votre site. Vous aurez besoin du chemin d’accès à ces fichiers à l’étape suivante.

Étape 7 : Référence au fichier at.js sur toutes les pages du site

Insérez at.js sous VisitorAPI.js en ajoutant la ligne de code suivante dans la balise de chaque page :

Pour at.js :

<script language="JavaScript" type="text/javascript"
src="http://INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/at.js"></script>

Le fichier VisitorAPI.js doit être chargé avant at.js. Si vous mettez à jour un fichier at.js ou mbox.js existant, veillez à vérifier l’ordre de chargement.

Le paramètre par défaut pour l’intégration Target et Analytics, du point de vue de l’implémentation, consiste à utiliser le SDID transmis à partir de la page pour assembler automatiquement les requêtes Target et Analytics sur le serveur principal.

Vous pouvez contrôler comment et quand envoyer des données d'analyse liées à Target à Analytics à des fins de rapports. Si vous ne souhaitez pas opt-in aux paramètres par défaut, à savoir que Target et Analytics assemblent automatiquement les données d’analyse via le SDID, définissez analyticsLogging = client_side via window.targetGlobalSettings. Remarque : Toutes les versions antérieures à 2.1 ne prennent pas en charge cette approche.

Par exemple :

window.targetGlobalSettings = {
  analyticsLogging: "client_side"
};

Cette configuration a un effet global, ce qui signifie que chaque appel effectué par at.js comporte analyticsLogging: "client_side" envoyé dans les requêtes Target et une charge utile d’analyse est renvoyée pour chaque requête. Lorsque cette option est configurée, le format de la charge utile renvoyée se présente comme suit :

"analytics": {
   "payload": {
      "pe": "tnt",
      "tnta": "167169:0:0|0|100,167169:0:0|2|100,167169:0:0|1|100"
   }
}

La charge utile peut ensuite être transférée à Analytics via l’API d’insertion de données. Pour les activités d’affectation automatique et d’Cible automatique, vous devez également transférer l’ID de session. Pour plus d’informations, voir le rapports Analytics for Cible (A4T) dans le guide Adobe Target SDKs.

Si un paramètre global n’est pas souhaité et qu’une approche plus à la demande est préférable, utilisez la fonction at.js getOffers() en transmettant analyticsLogging : "client_side". La charge utile d’analyse est renvoyée pour cet appel uniquement et le serveur principal Target ne transmet pas la charge utile à Analytics. En suivant cette approche, chaque requête at.js Target renvoie la charge par défaut, mais uniquement lorsque cela est souhaité et spécifié.

Par exemple :

adobe.target.getOffers({
      request: {
        experienceCloud: {
          analytics: {
            logging: "client_side"
          }
        },
        prefetch: {
          mboxes: [{
            index: 0,
            name: "a1-serverside-xt"
          }]
        }
      }
    })
    .then(console.log)

Cet appel appelle une réponse à partir de laquelle vous pouvez extraire la charge utile Analytics.

La réponse ressemble à ce qui suit :

{
  "prefetch": {
    "mboxes": [{
      "index": 0,
      "name": "a1-serverside-xt",
      "options": [{
        "content": "<img src=\"http://s7d2.scene7.com/is/image/TargetAdobeTargetMobile/L4242-xt-usa?tm=1490025518668&fit=constrain&hei=491&wid=980&fmt=png-alpha\"/>",
        "type": "html",
        "eventToken": "n/K05qdH0MxsiyH4gX05/2qipfsIHvVzTQxHolz2IpSCnQ9Y9OaLL2gsdrWQTvE54PwSz67rmXWmSnkXpSSS2Q==",
        "responseTokens": {
          "profile.memberlevel": "0",
          "geo.city": "bucharest",
          "activity.id": "167169",
          "experience.name": "USA Experience",
          "geo.country": "romania"
        }
      }],
      "analytics": {
        "payload": {
          "pe": "tnt",
          "tnta": "167169:0:0|0|100,167169:0:0|2|100,167169:0:0|1|100"
        }
      }
    }]
  }
}

La charge utile peut ensuite être transférée à Analytics par l'intermédiaire de l'API d'insertion de données.

Étape 8 : validation de l’implémentation

Chargez vos pages après avoir mis à jour les bibliothèques JavaScript pour vérifier que les valeurs de paramètre mboxMCSDID dans les appels Target correspondent à la valeur de paramètre sdid dans l'appel de vue de page Analytics.

Il est particulièrement important de confirmer que ces valeurs correspondent dans les applications d’une seule page (SPA) où l’ordre des appels n’est pas toujours prévisible.

Remarque : La correspondance de ces valeurs est requise pour que A4T fonctionne correctement.

Étape 9 (facultative) : suppression du code d’intégration précédent

Adobe vous recommande de supprimer l’intégration précédente afin de simplifier votre implémentation et d’éliminer la nécessité de résoudre les incohérences entre les systèmes. Vous pouvez supprimer tout code que vous avez déployé pour une intégration SC à T&T précédente, y compris mboxLoadSCPlugin.

Étape 10 : activation des options pour utiliser Analytics en tant que source de création de rapports pour Target

Dans Target, cliquez sur Administration > Compositeur visuel d’expérience et sélectionnez Sélectionner par activité ou Adobe Analytics pour activer les options.

• **L’option Sélection par activité vous permet de choisir entre et lors de la création de chaque activité.**TargetAnalytics
• **L’option Adobe  définit Analytics en tant que source des rapports pour toutes les activités que vous créez.**Analytics