Forum aux questions sur at.js

Réponses aux questions fréquentes sur la bibliothèque JavaScript at.js Adobe Target.

Quels sont les avantages d’utiliser at.js au lieu de mbox.js ?

La bibliothèque at.js remplace la bibliothèque mbox.js. La bibliothèque mbox.js n’est plus prise en charge. Pour la plupart des utilisateurs, at.js offre cependant des avantages en comparaison de mbox.js.

Autres avantages : at.js réduit les délais de chargement des pages pour les implémentations web, renforce la sécurité et offre des options d’implémentation optimisées pour les applications d’une seule page.

Le diagramme suivant illustre les performances de chargement de page avec mbox.js et at.js.

Comme illustré ci-dessus, avec mbox.js, le contenu de la page ne commençait à charger qu’une fois l’appel Target terminé. Avec at.js, le contenu de la page commence à charger dès que l’appel de Target est initié, sans attendre qu’il soit terminé.

Quel est l’impact de at.js et mbox.js sur le temps chargement de la page ?

Bon nombre de clients et de consultants souhaitent connaître l’impact d’at.js et de mbox.js sur le délai de chargement des pages, particulièrement en ce qui concerne les nouveaux utilisateurs et les utilisateurs réguliers. Il est, malheureusement, difficile de mesurer l’influence d’at.js ou de mbox.js sur le délai de chargement des pages et d’avancer des chiffres concrets en raison de l’implémentation de chaque client.

Toutefois, si l’API visiteur est présente sur la page, Target peut mieux comprendre comment at.js et mbox.js influencent le délai de chargement des pages.

Les sections suivantes décrivent la séquence d’actions pour les nouveaux visiteurs et les visiteurs récurrents :

Nouveaux visiteurs

1. L’API visiteur est chargée, analysée et exécutée.

2. at.js / mbox.js est chargé, analysé, puis exécuté.

3. Si la fonction de création automatique de mbox globale est activée, la bibliothèque JavaScript de Target :

   • instancie l’objet visiteur ;
   • La bibliothèque Target tente de récupérer les données Experience Cloud Visitor ID.
   • Comme il s’agit d’un nouveau visiteur, l’API visiteur déclenche une requête inter-domaines sur demdex.net.
   • Une fois les données Experience Cloud Visitor ID récupérées, une requête vers Target est déclenchée.

Visiteurs récurrents

1. L’API visiteur est chargée, analysée et exécutée.

2. at.js / mbox.js est chargé, analysé, puis exécuté.

3. Si la fonction de création automatique de mbox globale est activée, la bibliothèque JavaScript de Target :

   • instancie l’objet visiteur ;
   • La bibliothèque Target tente de récupérer les données Experience Cloud Visitor ID.
   • l’API visiteur récupère les données du cookies ;
   • Une fois les données Experience Cloud Visitor ID récupérées, une requête vers Target est déclenchée.

Pourquoi les temps de réponse semblent-ils plus lents après la mise à niveau d’une version précédente d’at.js vers la version 1.0.0 ?

at.js version 1.0.0 (et ultérieure) déclenche toutes les demandes en parallèle. Les versions précédentes exécutent les requêtes de manière séquentielle, ce qui signifie que les requêtes sont placées en file d’attente et que Target attend que la première requête se termine avant de passer à la suivante.

La façon dont les versions précédentes d’at.js exécutent les demandes est sujette au « blocage d’en-tête de ligne ». Dans at.js version 1.0.0 et ultérieure, est passé à l’exécution de demandes parallèles.Target

Si vous consultez par exemple la cascade de l’onglet réseau pour at.js 0.9.1, vous verrez que la demande suivante ne démarre pas tant que la précédente n’est pas terminée. Target Cette séquence ne fonctionne pas avec at.js version 1.0.0 et ultérieure, où toutes les requêtes démarrent en même temps.

En termes de temps de réponse, mathématiquement, cette séquence peut se résumer comme suit :

• at.js 0.9.1 : Temps de réponse de tous Target requests = somme du temps de réponse des demandes
• at.js 1.0.0 et versions ultérieures : Temps de réponse de tous Target requêtes = temps de réponse maximal des requêtes

La bibliothèque at.js version 1.0.0 exécute les requêtes plus rapidement. En outre, les demandes at.js sont asynchrones, de sorte que ne bloque pas le rendu de la page. Target Même si le traitement des requêtes ne prend que quelques secondes, la page rendue est toujours visible. Toutefois, certaines parties de la page sont masquées, et ce, jusqu’à ce que Target reçoive une réponse du Edge de Target.

Puis-je charger la bibliothèque Target de manière asynchrone ?

La version 1.0.0 d’at.js permet de charger la bibliothèque Target de manière asynchrone.

Pour charger at.js de manière asynchrone, procédez comme suit :

• L’approche par le biais des balises dans Adobe Experience Platform est celle recommandée.

• Vous pouvez également charger at.js de manière asynchrone en ajoutant l’attribut async à la balise du script qui charge at.js. Utilisez un élément semblable au suivant :

  <script src="<URL to at.js>" async></script>
  

• Vous pouvez également charger at.js de manière asynchrone en utilisant le code suivant :

  var script = document.createElement('script');
  script.async = true;
  script.src = "<URL to at.js>";
  document.head.appendChild(script);
  

Le chargement d’at.js de manière asynchrone est un excellent moyen d’éviter de bloquer le rendu du navigateur. Cependant, cette technique peut entraîner un scintillement de la page web.

Vous pouvez éviter le scintillement à l’aide d’un extrait de code de masquage préalable qui masque la page (ou les parties spécifiées), puis la révèle après le chargement d’at.js et de la requête globale. Vous devez ajouter le fragment de code avant le chargement d’at.js.

Si vous déployez at.js par le biais d’une implémentation Adobe Experience Platform asynchrone, assurez-vous d’inclure le fragment de code de masquage préalable directement sur vos pages, avant le code intégré d’implémentation de Target avec Adobe Experience Platform.

Si vous déployez at.js par le biais d’une implémentation synchrone de la gestion dynamique des balises, le fragment de code prémasqué peut être ajouté au moyen d’une règle de chargement de page déclenchée en haut de la page.

Pour plus d’informations, voir Comment at.js gère le scintillement.

Est-ce qu’at.js est compatible avec l’intégration Adobe Experience Manager (Experience Manager) ?

Adobe Experience Manager 6.2 avec FP-11577 (ou ultérieur) prend maintenant en charge les mises en œuvre d’at.js avec son intégration des Services Cloud d’Adobe Target.

Comment empêcher le scintillement au chargement des pages avec at.js ?

Target propose plusieurs solutions pour éviter le scintillement au chargement des pages. Pour plus d’informations, voir Prévention du scintillement avec at.js.

Quelle est la taille de fichier d’at.js ?

Le fichier at.js fait environ 109 Ko une fois téléchargé. Cependant, comme la plupart des serveurs compressent automatiquement les fichiers pour les rendre plus légers, at.js ne fait plus que 34 Ko environ une fois compressé (avec GZIP ou une autre méthode) sur votre serveur et chargé lorsque des utilisateurs visitent votre site web. Les paramètres de compression du serveur sur lequel vous avez installé at.js déterminent sa taille réelle après compression.

Pourquoi le fichier at.js est-il plus volumineux que le fichier mbox.js ?

Les implémentations at.js utilisent une seule bibliothèque (at.js), tandis que les implémentations mbox.js en utilisent réellement deux (mbox.js et target.js). Il serait donc préférable donc de comparer at.js à mbox.js et target.js. Si l’on compare la taille des fichiers gzip des deux versions, at.js version 1.2 fait 34 Ko, tandis mbox.js version 63 fait 26,2 Ko. ``

Le fichier at.js est plus volumineux, car il effectue beaucoup plus d’analyses DOM que le fichier mbox.js, du fait que le fichier at.js doit interpréter les données « brutes » qu’il récupère dans la réponse JSON. mbox.js utilisait document.write() et toute l’analyse était effectuée par le navigateur.

Malgré une taille de fichier plus importante, nos tests démontrent que les pages se chargent plus rapidement avec at.js qu’avec mbox.js. En outre, at.js offre une sécurité accrue, car il ne charge pas de fichiers supplémentaires de manière dynamique ni n’utilise document.write.

at.js inclut-il jQuery ? Puis-je supprimer cette partie du fichier at.js si jQuery figure déjà dans mon site web ?

Actuellement, at.js utilise des parties de jQuery ; c’est pourquoi l’avis de licence MIT s’affiche en haut du fichier at.js. jQuery n’est pas exposé et n’interfère pas avec la bibliothèque jQuery déjà présente sur votre page, qui peut être d’une autre version. Il n’est pas possible de supprimer le code jQuery dans at.js.

at.js prend-il en charge Safari et un interdomaine défini sur x-uniquement ?

Non, si le suivi inter-domaines est défini sur x-uniquement et que les cookies tiers sont désactivés dans Safari, mbox.js et at.js définissent un cookie désactivé et aucune demande de mbox n’est exécutée pour le domaine de ce client spécifique.

Pour prendre en charge les visiteurs Safari, il convient d’avoir un x-domaine « désactivé » (définit uniquement un cookie propriétaire) ou « activé » (définit un cookie propriétaire sur Safari, ainsi que des cookies propriétaires et tiers sur les autres navigateurs).

Puis-je utiliser le compositeur d’expérience visuelle (VEC) de Target dans mes applications monopages ?

Oui, vous pouvez utiliser le VEC pour votre SPA si vous utilisez at.js 2.x. Pour plus d’informations, consultez Compositeur d’expérience visuelle monopage (SPA).

Puis-je utiliser le débogueur Adobe Experience Cloud avec les implémentations d’at.js ?

Oui. Vous pouvez également utiliser mboxTrace à des fins de débogage ou les outils de développement de votre navigateur pour inspecter les demandes de réseau, en filtrant sur « mbox » pour isoler les appels mbox.

Puis-je utiliser des caractères spéciaux dans les noms mbox avec at.js ?

Oui, comme avec mbox.js.

Pourquoi mes mbox ne se déclenchent-elles pas sur mes pages web ?

Les clients de Target utilisent parfois des instances basées sur le cloud avec Target à des fins de test ou de preuve de concept. Ces domaines, et de nombreux autres, font partie de la liste des suffixes publics.

Les navigateurs modernes n’enregistrent pas les cookies si vous utilisez ces domaines, sauf si vous personnalisez le paramètre cookieDomain à l’aide de targetGlobalSettings(). Pour plus d’informations, voir Utilisation d’instances basées sur Cloud avec Target.

Les adresses IP peuvent-elles être utilisées comme domaine de cookie lors de l’utilisation d’at.js ?

Assurez-vous que vous utilisez la version at.js 1.2 ou ultérieure. Néanmoins, Adobe vous recommande vivement de rester à jour avec la dernière version.

Remarque : En fonction de votre utilisation de targetGlobalSettings, vous devrez peut-être apporter des modifications supplémentaires au code après le téléchargement d’at.js. Par exemple, si vous avez besoin de paramètres légèrement différents pour vos mises en œuvre Target sur plusieurs sites web et que vous ne parvenez pas à définir ces paramètres dynamiquement à l’aide d’un code JavaScript personnalisé, effectuez ces personnalisations manuellement après avoir téléchargé le fichier et avant de le transférer vers le site web correspondant.

Les exemples suivants permettent d’utiliser la fonction targetGlobalSettings() d’at.js pour insérer un fragment de code permettant de prendre en charge les adresses IP.

Cet exemple concerne une adresse IP unique :

if (window.location.hostname === '123.456.78.9') {
    window.targetGlobalSettings = window.targetGlobalSettings || {};
    window.targetGlobalSettings.cookieDomain = window.location.hostname;
}

Cet exemple concerne une plage d’adresses IP :

if (/^123\.456\.78\..*/g.test(window.location.hostname)) {
    window.targetGlobalSettings = window.targetGlobalSettings || {};
    window.targetGlobalSettings.cookieDomain = window.location.hostname;
}

Pourquoi des messages d’avertissement du type « Actions avec sélecteurs manquants » s’affichent-ils ?

Ces messages ne sont pas liés à la fonctionnalité at.js. La bibliothèque at.js tente de signaler tout ce qui est introuvable dans l’élément DOM.

L’affichage de ce message d’avertissement peut s’expliquer par les causes suivantes :

• La page est créée dynamiquement et at.js ne parvient pas à trouver l’élément.

• La page est créée lentement (en raison de la lenteur du réseau) et at.js ne parvient pas à trouver le sélecteur dans le DOM.

• La structure de la page sur laquelle s’exécute l’activité​ a été modifiée. Si vous rouvrez l’activité dans le ​Compositeur d’expérience visuelle (VEC), un message d’avertissement s’affiche. Mettez à jour l’activité afin que tous les éléments nécessaires soient détectés.

• La page sous-jacente fait partie d’une Application monopage (SPA) ou la page contient des éléments qui apparaissent plus bas dans la page et le « mécanisme d’interrogation des sélecteurs » at.js ne parvient pas à trouver ces éléments. Augmenter le selectorsPollingTimeout peut aider. Pour plus d’informations, voir targetGlobalSettings().

• Les mesures de suivi des clics tentent de s’ajouter à chaque page, indépendamment de l’URL à laquelle elles ont été configurées. Bien que sans danger, cette situation entraîne l’affichage répété de ces messages.

  Pour des résultats optimaux, téléchargez et utilisez la dernière version d’at.js. Pour plus d’informations, consultez les Détails de la version at.js et le Téléchargement d’at.js.

À quoi correspond le domaine tt.omtrdc.net auquel les appels au serveur de Target sont adressés ?

tt.omtrdc.net est le nom de domaine du réseau EDGE d’Adobe utilisé pour recevoir tous les appels au serveur pour Target.

Pourquoi at.js n’utilise-t-il pas toujours les indicateurs de cookie HttpOnly et Secure ?

HttpOnly ne peut être défini que via un code côté serveur. TargetLes cookies, tels que mbox, étant créés et enregistrés via le code JavaScript, ne peut pas utiliser l’indicateur de Target cookie HttpOnly. Target utilise la définition HttpOnly pour les cookies tiers définis du côté serveur lorsque le suivi inter-domaines est activé.

Secure ne peut être défini que via JavaScript lorsque la page a été chargée via HTTPS. Si la page se charge initialement via HTTP, JavaScript ne peut pas définir cet indicateur. En outre, si l’indicateur Secure est utilisé, le cookie est disponible uniquement sur les pages HTTPS. Pour les pages chargées via HTTPS, Target définit les attributs Secure et SameSite=None.

Pour garantir le suivi correct des utilisateurs par Target et parce que les cookies sont générés côté client, Target n’utilise aucun de ces indicateurs, sauf dans les situations mentionnées ci-dessus.

À quelle fréquence la bibliothèque at.js déclenche-t-elle une demande de réseau ?

Toutes les prises de décision de Target se font côté serveur. Cela signifie que at.js déclenche une demande de réseau à chaque rechargement de page, ou qu’une API publique de at.js est appelée.

Dans le meilleur des cas, peut-on espérer que l’utilisateur ne subisse pas d’effets visibles liés au masquage, au remplacement et à l’affichage de contenu lors du chargement d’une page ?

at.js tente d’éviter le masquage préalable de l’ensemble HTML BODY ou autres éléments DOM pendant une période prolongée, mais cela dépend des conditions du réseau et de la configuration des activités. at.js fournit des paramètres pouvant être utilisés pour personnaliser BODY en masquant le style CSS. Par exemple, au lieu de masquer entièrement l’ensemble HTML BODY, vous pouvez pré-masquer certaines parties de la page. On s’attend à ce que ces parties contiennent des éléments DOM à « personnaliser ».

Quelle est le déroulement des événements dans une situation type, dans laquelle un utilisateur est admissible pour une activité ?

La requête at.js est une requête XMLHttpRequest asynchrone. Les étapes exécutées sont donc les suivantes :

1. La page charge.
2. at.js pré-masque l’ensemble HTML BODY. Il existe un paramètre qui permet de pré-masquer un conteneur plutôt que l’ensemble HTML BODY.
3. La bibliothèque at.js déclenche une demande.
4. Une fois la réponse de Target reçue, Target extrait les sélecteurs CSS.
5. Grâce aux sélecteurs CSS, Target crée des balises de style pour pré-masquer les éléments DOM qui seront personnalisés.
6. Le style de pré-masquage de l’ensemble HTML BODY est supprimé.
7. Target lance l’interrogation pour les éléments DOM.
8. Si un élément DOM est trouvé, Target apporte des modifications au modèle DOM et le STYLE de pré-masquage de l’élément est supprimé.
9. Si Target ne trouve pas d’élément DOM, un délai d’attente global supprime le masquage des éléments afin d’éviter de faire face à une page endommagée.

À quelle fréquence le contenu des pages est-il complétement chargé et visible lorsqu’at.js finit par supprimer le masquage de l’élément modifié par l’activité ?

Dans le cas ci-dessus, à quelle fréquence le contenu des pages est-il complétement chargé et visible lorsqu’at.js finit par supprimer le masquage de l’élément modifié par l’activité ? Autrement dit, la page est entièrement visible, excepté le contenu de l’activité, qui apparaît légèrement après le reste du contenu.

at.js ne bloque pas le rendu de la page. L’utilisateur peut apercevoir certaines zones vides dans la page, représentant les éléments personnalisés par Target. Si le contenu qui doit être appliqué contient peu d’actifs distants, tels que des scripts et des images, tout devrait être rendu rapidement.

Quel serait l’impact d’une page entièrement en cache dans le cas ci-dessus ? Le contenu de l’activité aurait-il plus de chance d’être visible une fois le reste du contenu de la page chargé ?

Si une page est mise en cache sur un réseau CDN proche de l’emplacement géographique de l’utilisateur, mais loin du serveur Edge de Target, le délai risque d’être un peu plus long. Les serveurs Edge de Target sont bien répartis autour du globe, ce n’est donc pas un problème la plupart du temps.

Est-il possible que la bannière principale s’affiche, puis change après un court instant ?

Dans le cas suivant :

Le délai d’attente de Target est de cinq secondes. Un utilisateur charge une page qui a une activité afin de personnaliser une image principale. at.js envoie une requête pour déterminer s’il faut appliquer une activité, mais dans un premier temps, ne reçoit pas de réponse. On considère que l’utilisateur consulte le contenu de l’image principale, car Target n’a pas envoyé de réponse pour savoir si oui ou non une activité y est associée. Au bout de quatre secondes, Target envoie une réponse avec le contenu de l’activité.

À ce stade, est-il possible d’afficher la version alternative ? Donc, après les quatre secondes, l’image principale a pu changer et l’utilisateur a pu remarquer ce changement ?

Initialement, l’élément DOM de l’image principale est masqué. Une fois la réponse de Target reçue, at.js apporte les modifications aux éléments DOM, comme le changement d’image, et affiche l’image principale personnalisée.

Quel doctype HTML at.js requiert-il ?

at.js requiert le doctype HTML 5.

Cette syntaxe est la suivante :

<!DOCTYPE html>

Le doctype HTML 5 garantit le chargement de la page en mode standard. Lors du chargement en mode quirks, certaines API JS dont le fichier at.js dépend sont désactivées. Target désactive at.js en mode quirks.