Show Menu
SUJETS×

Implémentation d’Analytics for Target

Several steps are required when implementing Adobe Analytics as the reporting source for Target (A4T).

Implementation steps

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

After you implement Analytics as the reporting source for Target, you must be provisioned for Analytics and Target. Pour ce faire, utilisez ce formulaire .

Étape 2 : configuration des autorisations d’utilisateur

User account requirements must be met before you can create an Analytics-based activity in Target. See User permission requirements .

É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. Vous devez mettre en œuvre la version requise de l’identifiant visiteur Experience Cloud ou effectuer la migration vers cette dernière. Pour plus d’informations, consultez « Exigences d’implémentation » dans Avant de procéder à l’implémentation .
See Implement the Experience Cloud ID Service for Target in the Experience Cloud Visitor ID Service documentation.

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

Vous devez mettre en œuvre la version requise d’appMeasurement.js ou effectuer la migration vers cette dernière. Pour plus d’informations, voir « Exigences d’implémentation » dans Avant de procéder à l’implémentation .
Pour les nouvelles mises en oeuvre, voir Présentation de la mise en oeuvre de JavaScript dans le Guide de mise en oeuvre d’ 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 at.js ou mbox.js

À l’aide de votre compte de production, vous devez mettre en œuvre la version requise d’at.js ou de mbox.js ou effectuer la migration vers cette dernière. 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 ou mbox.js

Si vous avez déjà déployé at.js ou mbox.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érencement at.js ou mbox.js sur toutes les pages du site

Insérez at.js ou mbox.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>

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

Il est essentiel que VisitorAPI.js soit chargé avant at.js ou mbox.js. Si vous mettez à jour un fichier at.js ou mbox.js existant, veillez à vérifier l’ordre de chargement.
The way the out-of-the-box settings are configured for Target and Analytics integration from an implementation perspective is to use the SDID that is passed from the page to stitch the Target and Analytics request together on the backend automatically for you.
However, if you want more control on how and when to send analytics data related to Target to Analytics for reporting purposes, and you do not want to opt-in to the default settings of having Target and Analytics automatically stitch the analytics data via the SDID, then you can set 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. Cela signifie que chaque appel effectué par at.js aura analyticsLogging: "client_side" envoyé dans les requêtes et une charge utile Analytics est renvoyée pour chaque requête. Target Lors de la configuration, le format de la charge utile renvoyé ressemble à ce qui 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.
Si un paramètre global n’est pas souhaité et qu’une approche plus à la demande est préférable, vous pouvez utiliser la fonction at.js getOffers() pour obtenir ce résultat en transmettant analyticsLogging: "client_side" . The analytics payload will be returned for only this call and the Target backend will not forward the payload to Analytics. By pursuing this approach, every at.js Target request will not return the payload by default, but instead only when desired and specified.
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 vers Analytics via l’API d’insertion de données.

Étape 8 : validation de l’implémentation

Load your pages after you have updated the JavaScript libraries to confirm that the mboxMCSDID parameter values in Target calls match the sdid parameter value in the Analytics page-view call.
Ceci s’avère particulièrement important dans les applications à une seule page, où l’ordre des appels n’est pas toujours prévisible.
Remarque : Ces valeurs doivent correspondre pour qu’A4T fonctionne correctement.

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

Il est recommandé de supprimer l’intégration précédente afin de simplifier la mise en œuvre et d’éliminer la nécessité d’avoir à résoudre les incohérences entre les systèmes. Vous pouvez supprimer tout code que vous pouvez avoir déployé lors d’une intégration SC à T&T précédente, notamment mboxLoadSCPlugin .

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

In Target, click Administation > Visual Experience Composer and choose either Select per activity or Adobe Analytics to enable the options.
  • L’option Sélection par activité vous permet de choisir entre et lors de la création de chaque activité. Target​Analytics
  • L’option Adobe  définit Analytics en tant que source des rapports pour toutes les activités que vous créez. Analytics