FAQ sur les offres de redirection - A4T

Réponse Votre mise en oeuvre doit respecter les conditions minimales suivantes :

• 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 1.6.2 ou ultérieure.

Les trois bibliothèques doivent être incluses sur la page comportant l’offre de redirection et sur la page vers laquelle est redirigé le visiteur.

Réponse Un nombre limité de clients ont signalé des degrés de variation de trafic plus élevés lors de l’utilisation d’offres de redirection dans des activités configurées avec Analytics pour Target (A4T).

Tenez compte des points suivants :

• Ordre incorrect de Target et Analytics les appels peuvent être responsables de degrés de variance plus élevés.

  Le Target doit précéder l’appel Analytics appel sur la page source (où se produit la redirection) et sur la page de destination (où se termine la redirection).

• Assurez-vous d’utiliser les offres de redirection dans les activités de redirection A4T.

• S’il existe plusieurs Target requêtes d’emplacement sur la page source (où la redirection a lieu), Adobe recommande d’exécuter l’activité de redirection sur la première Target requête d’emplacement.

  Exécuter l’activité de redirection sur la première Target la requête d’emplacement réduit les risques que des qualifications d’activité se produisent sur d’autres Target requêtes d’emplacement et comptage dans le rapport. Les visiteurs qui sont redirigés n’ont pas besoin d’être comptabilisés dans les rapports des autres activités, car ils ne verront pas les expériences.

Réponse Lors de l’utilisation d’at.js version 1.6.3 ou ultérieure, le comptage des pages vues sur les deux pages n’est pas un problème. Cette situation de concurrence affecte uniquement les clients qui utilisent des versions antérieures. L’équipe Target gère deux versions seulement d’at.js : la version actuelle et la version la plus récente avant celle-ci. Mettez à jour at.js si nécessaire pour vous assurer que vous utilisez une version prise en charge{target=_blank}.

Si vous utilisez une version antérieure d’at.js non prise en charge, il est possible qu’une condition de concurrence puisse se produire et que l’appel Analytics se déclenche avant que la redirection ne s’exécute sur la première page. Cette situation peut entraîner la comptabilisation des pages vues sur la page originale et la page de redirection. Cette situation entraîne la comptabilisation d’une page vue supplémentaire sur la première page, bien que le visiteur ne l’ait jamais véritablement consultée.

Il est recommandé d’utiliser le compositeur d’après les formulaires pour créer une activité de redirection afin d’accélérer la redirection de la page en raison de l’emplacement d’exécution du code sur la page. Il est également recommandé de créer une offre de redirection pour chaque expérience où la redirection renvoie la page originale, y compris l’expérience par défaut. La création d’une offre de redirection pour chaque expérience garantit que si un mauvais comptage se produit, cela se produit dans toutes les expériences. Les rapports et analyses sont toujours valides pour le test.

L’utilisation des offres de redirection pour toutes les expériences de l’activité, y compris l’expérience par défaut (contrôle), permet de mettre les mêmes conditions sur toutes les expériences. Par exemple, si l’expérience par défaut ne comporte pas d’offre de redirection alors que les autres en ont, la vitesse de l’expérience sans offre de redirection présente un avantage inhérent. Les offres de redirection sont recommandées pour des scénarios temporaires uniquement, comme les tests. Les offres de redirection ne sont pas recommandées pour les scénarios permanents tels que la personnalisation. Après avoir déterminé le "gagnant", vous devez supprimer la redirection afin d’améliorer les performances de chargement de page.

Répondez Oui, les deux compositeurs sont pris en charge tant que vous utilisez les offres de redirection intégrées.

Si vous utilisez votre propre code personnalisé pour la redirection, vous devez vous assurer de générer les deux nouveaux paramètres associés aux URL de redirection (adobe_mc_sdid et adobe_mc_ref, tel qu’expliqué ci-dessus).

Réponse Les paramètres de chaîne de requête suivants sont associés aux offres de redirection :

table 0-row-2 1-row-2 2-row-2
Paramètre	Description
adobe_mc_sdid	Le adobe_mc_sdid transmet l’ID de données supplémentaire (SDID) et l’ID d’organisation Experience Cloud de la page par défaut à la nouvelle page. Ces identifiants permettent à A4T de "regrouper" la requête Target sur la page par défaut avec la requête Analytics sur la nouvelle page. Le format attendu pour transmettre sdid dans l’URL (pour les applications hybrides ou d’une application à un site web ou d’un site web à un autre) est `ex. adobe_mc_sdid=SDID=123
adobe_mc_ref	Le paramètre adobe_mc_ref transfère l’URL de référence de la page par défaut vers la nouvelle page. Lorsqu’il est utilisé avec AppMeasurement.js version 2.1 (ou ultérieure), Analytics utilise cette valeur de paramètre comme URL de référence sur la nouvelle page.

Ces paramètres sont automatiquement ajoutés aux URL de redirection lorsque vous utilisez les offres de redirection intégrées dans le compositeur d’expérience visuelle et le compositeur d’expérience d’après les formulaires, lorsque le service Identifiant visiteur est mis en œuvre dans la page. Si vous utilisez votre propre code de redirection personnalisé dans le compositeur d’expérience visuelle ou le compositeur d’expérience d’après les formulaires, vous devez vous assurer de transférer ces paramètres avec votre code personnalisé.

Réponse Utilisez une redirection personnalisée si :

• Vous n’utilisez pas A4T avec votre activité de redirection.
• Le service d’identification des visiteurs est mis en oeuvre
• Vous ne souhaitez pas que ces paramètres soient automatiquement ajoutés à vos URL.

Cependant, il est recommandé de conserver le paramètre adobe_mc_ref dans l’URL pour signaler correctement les informations référentes à Analytics.

Réponse Si vous utilisez A4T et que vous redirigez des offres, Target ajoute la variable adobe_mc_ref et adobe_mc_sdid à l’URL. Ces valeurs sont déjà en codage URL. La plupart du temps, tout fonctionne comme prévu, mais certains clients peuvent avoir des équilibrages de charge ou des serveurs Web qui tentent de coder à nouveau les paramètres de la chaîne de requête.

En raison de ce double codage, lorsque l’API visiteur tente de décoder la valeur adobe_mc_sdid, elle ne parvient pas à extraire le SDID et en génère un nouveau. Ce processus entraîne l’envoi de valeurs SDID incorrectes à Target et Analytics et un fractionnement inégal des redirections dans les rapports Analytics.

Adobe vous recommande de discuter avec votre équipe informatique pour vous assurer que adobe_mc_ref et adobe_mc_sdid sont placées sur la liste autorisée afin que ces valeurs ne soient jamais transformées.

Réponse Supposons qu’un visiteur clique sur un lien de www.google.com à votre page d’accueil (www.mysite.com/index.html) sur laquelle une activité de redirection est active, puis est redirigée vers une nouvelle page (www.mysite.com/index2.html).

Auparavant, la requête Analytics sur la nouvelle page signalait l’URL de référence www.mysite.com/index.html au lieu de www.google.com. Dans Analytics, cela générait des rapports inexacts concernant les URL de référence (dans les rapports sur les canaux marketing, par exemple). Les rapports manquaient la véritable provenance du visiteur, c’est-à-dire www.google.com.

Avec at.js version 0.9.6 (ou ultérieure) et AppMeasurement.js 2.1 (ou version ultérieure), la variable Analytics sur la nouvelle page, la requête signale une URL de référence de www.google.com.