Show Menu
SUJETS×

Minimisation du nombre de visiteurs ou de visites exagéré dans A4T.

Informations destinées à vous aider à minimiser les effets d’un nombre de visiteurs ou de visites exagéré lors de l’utilisation d’Analytics comme source de création de rapports.
Le 14 novembre 2016, Adobe Analytics a modifié la façon dont certaines données sont traitées pour les clients qui utilisent la création de rapports Analytics pour Target (A4T). Ces modifications améliorent l’alignement entre les données Adobe Target et le modèle de données d’Adobe Analytics. Ces modifications ont été déployées pour tous les clients utilisant A4T. Ces modifications ont pour but de résoudre un problème en raison duquel certains clients ont remarqué un nombre de visiteurs exagéré lors de l’exécution d’activités Target.
Notez que cette modification n’est pas rétroactive. Si vos rapports historiques indiquent des nombres exagérés et que vous souhaitez les exclure de vos rapports, vous pouvez créer une suite de rapports virtuelle, comme expliqué ci-dessous.
Par ailleurs, plusieurs bibliothèques JavaScript ont été mises à jour afin de minimiser les nombres de visites ou de visiteurs exagérés. Nous vous recommandons de mettre les bibliothèques à niveau vers les versions de bibliothèque suivantes (ou ultérieures) :
  • Service d’identification des visiteurs d’Experience Cloud : visitorAPI.js version 2.3.0 ou ultérieure.
  • Adobe Analytics : appMeasurement.js version 2.1.
  • Adobe Target : at.js version 0.9.6 ou ultérieure (à l’exception de la version 1.1.0 si vous utilisez les offres de redirection avec A4T).
La bibliothèque mbox.js ne prend pas en charge les offres de redirection avec A4T. Votre mise en œuvre doit utiliser at.js.

Qu’est-ce qui a changé ?

Lorsqu’Adobe Analytics est utilisé pour mesurer les activités Target (sous le nom A4T), Analytics collecte des données supplémentaires qui ne sont pas disponibles lorsqu’il n’y a pas d’activité Target sur la page. Cela est dû au fait que l’activité Target déclenche un appel en haut de la page, tandis qu’Analytics déclenche généralement ses appels de collecte de données au bas de la page. Dans l’implémentation d’A4T actuelle, nous avons inclus ces données supplémentaires chaque fois qu’une activité Target était active. À l’avenir, nous inclurons ces données supplémentaires uniquement en cas de déclenchement des balises Target et Analytics.

Pourquoi Adobe a-t-il apporté cette modification ?

Adobe se targue de la précision et de la qualité de ses données. Lorsque la balise Target se déclenche mais que la balise Analytics ne se déclenche pas, nous enregistrons des « données partielles » (parfois appelées « accès désassemblés »), qui ne seraient pas capturées par Analytics en l’absence d’activité Target. Si l’inclusion des données partielles dans les rapports Analytics fournit des informations supplémentaires, elle crée également des incohérences par rapport aux données historiques des périodes où aucune activité Target n’était active. Cela peut être source de problèmes pour les utilisateurs d’Analytics qui analysent les tendances qui se dégagent au fil du temps. Afin d’assurer la cohérence des données dans Analytics, nous allons supprimer toutes les données partielles.

Qu’est-ce qui contribue aux données partielles ?

Certains clients enregistrent des taux de données partielles très élevés dans Analytics. Ce phénomène peut être dû à une implémentation incorrecte, mais il existe également des causes légitimes.
Les causes identifiées des données partielles incluent :
  • Alignement incorrect des identifiants de suites de rapports (implémentation) : la suite de rapports spécifiée lors de la configuration d’une activité ne correspond pas à la suite de rapports de la page où le test est diffusé. Les données obtenues apparaissent comme partielles parce qu’elles ne peuvent pas être réconciliées sur les serveurs Analytics.
  • Pages lentes : étant donné que les appels Target se trouvent en haut de la page et que les appels Analytics se trouvent généralement au bas de la page, si la page se charge lentement, cela augmente la probabilité qu’un visiteur quitte la page après le déclenchement de l’appel Target mais avant l’appel Analytics. Cela peut s’avérer particulièrement problématique sur les sites web mobiles où les connexions sont souvent plus lentes.
  • Erreurs de page : en cas d’erreurs JavaScript ou d’autres scénarios où tous les points de contact ne se déclenchent pas (service d’Experience Cloud ID, Target et Analytics), des données partielles sont générées.
  • Offres de redirection dansTargetlactivité : Pour les offres de redirection dans les activités utilisant A 4 T, votre implémentation doit satisfaire à certaines exigences minimales. En outre, vous devez prendre connaissance de certaines informations importantes. Pour plus d’informations, voir FAQ sur les offres de redirection (A4T).
  • Versions obsolètes des bibliothèques : au cours de l’année écoulée, Adobe a apporté diverses améliorations à ses bibliothèques JavaScript (appMeasurement.js, at.js/mbox.js, et visitorAPI.js) pour garantir un envoi de données aussi efficace que possible. Pour en savoir plus sur les exigences d’implémentation, voir Avant l’implémentation.

Quelles sont les bonnes pratiques pour réduire les données partielles ?

Pour réduire la collecte de données partielles, nous vous recommandons de passer en revue les étapes suivantes dans l’ordre.
Étape
Tâche
Assurez-vous que la suite de rapports sélectionnée dans Target est identique à celle des pages où l’activité sera présentée.
Assurez-vous que les bibliothèques visitorAPI.js, appMeasurement.js, at.js / mbox.js se trouvent sur des versions compatibles avec A4T. Pour en savoir plus sur les exigences d’implémentation, voir Avant l’implémentation.
Vérifiez que le SDID est défini sur tous les appels Target et Analytics qui quittent la page et que les SDID correspondent.
Pour ce faire, utilisez un analyseur de réseau ou un outil de débogage pour vérifier que le paramètre mboxMCSDID sur l’appel Target correspond au paramètre SDID de l’appel Analytics.
Vérifiez que les bibliothèques d’implémentation se chargent dans l’ordre correct sur vos sites. Pour plus d’informations, voir Implémentation d’Analytics pour Target.

Comment puis-je voir de combien de données partielles je dispose ?

Ces informations ne sont pas directement disponibles dans Analytics, mais vous pouvez contacter l’Assistance clientèle d’Adobe pour obtenir un rapport de données partielles. Ce rapport est destiné à faciliter le débogage.

Comment puis-je afficher les tendances historiques sans les données partielles ?

Dans la mesure où cette modification du traitement des données n’affecte les données qu’après la date de publication (14 novembre 2016), si vous souhaitez ajuster vos mesures historiques pour qu’elles correspondent, nous vous recommandons de créer un segment afin d’exclure les données partielles.
Les informations suivantes relatives à cette modification incluent des instructions destinées à vous aider à définir le segment et à l’appliquer à une suite de rapports virtuelle pour que ce segment soit toujours appliqué à vos vues Analytics.
Dans la plupart des cas, un Target accès est associé à un Analytics accès sur chaque page web. Cet assemblage se produit lorsqu’un paramètre SDID cohérent se trouve à la fois dans un appel Target et Analytics et qu’un appel Experience Cloud ID (MCID) se trouve dans un appel Analytics sur la même page. Target dispose également du MCID, mais si l’appel à Target se produit avant le retour de l’ID du visiteur, l’accès sera assemblé en raison du SDID. De plus, lutilisateur doit rester suffisamment longtemps sur la page pour déclencher Analytics un appel après le déclenchement d Targetun appel. Il s’agit du scénario idéal.
Accès aux données partielles : les utilisateurs ne restent parfois pas suffisamment longtemps sur une page pour envoyer un Analytics appel, mais Target dispose d’un MCID correct. De ce fait, les accès enregistrent des données partielles (accès sans affichage de la page Analytics). Si ces utilisateurs reviennent sur votre site et affichent une page comportant du code Analytics, ils seront probablement comptés en tant que visiteurs récurrents. Ces accès auraient été perdus si la page ne comportait que du code Analytics. Certains clients ne souhaitent pas récupérer les données de ces accès car elles exagèrent certaines mesures (visites) et diminuent d’autres mesures (nombre de pages vues par visite, durée par visite, etc.). Vous verrez également des visites sans aucune page vue. Toutefois, il existe de bonnes raisons de conserver ces données.
Afin de minimiser les accès à données partielles, vous pouvez faire charger votre page plus rapidement, mettre à jour les bibliothèques vers les versions les plus récentes ou créer une suite de rapports virtuelle qui exclut ces accès. Pour connaître les instructions étape par étape, voir Création de suites de rapports virtuelles dans la documentation du produit Analytics.
L’illustration suivante présente la définition de segment pour la suite de rapports virtuelle :
Lors de la création de la suite de rapports virtuelle, spécifiez la configuration suivante pour la définition de segment (comme présenté dans l’illustration ci-dessus) :
  • Afficher les accès :
  • Analytics for Target : Existe
  • Et
  • Pages vues : N’existe pas
  • Et
  • Instances de liens personnalisés : N’existe pas
  • Et
  • Instances de lien de téléchargement : N’existe pas
  • Et
  • Instances de lien de sortie : N’existe pas
Accès orphelins : Dans le cas contraire, les utilisateurs ne restent pas suffisamment longtemps sur la page pour un appel Analytics et Target na pas obtenu de MCID correct. Ces accès sont ce que nous appelons des « orphelins ». Ils représentent les clients qui reviennent rarement et ils exagèrent le nombre de visites et de visiteurs de manière inappropriée.
Afin de minimiser ces accès « orphelins », vous pouvez créer une suite de rapports virtuelle qui exclut ces accès, comme expliqué ci-dessus.

Quel impact cette modification a-t-elle sur mes Target rapports ?

Une fois cette modification effectuée, vous verrez peut-être une diminution du nombre de visiteurs et de visites dans les tests en direct vu que Adobe ne traitera plus les données partielles entrantes. Les conversions et les accès aux autres mesures Analytics ne connaîtront aucun changement.