Forum aux questions sur at.js

Réponses aux questions fréquentes sur at.js.

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

La bibliothèque at.js remplace 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 n’a commencé à 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.

Cependant, 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 de l’identifiant visiteur Experience Cloud ;
   • Comme ce visiteur est nouveau, l’API visiteur déclenche une requête interdomaines sur demdex.net.
   • Une fois les données de l’identifiant de visiteur Experience Cloud récupérée, une requête est déclenchée sur Target.

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 de l’identifiant visiteur Experience Cloud ;
   • l’API visiteur récupère les données du cookies ;
   • Une fois les données de l’identifiant de visiteur Experience Cloud récupérée, une requête est déclenchée sur Target.

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 demandes de manière séquentielle, ce qui signifie que les demandes sont placées en file d’attente et que Target attend que la première demande 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, Target est passé à l’exécution de demandes parallèles.

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 n’est pas le cas avec at.js 1.0.0 et versions ultérieures où toutes les requêtes démarrent en même temps.

D’un point de vue mathématique, cette séquence peut être résumée comme suit :

• at.js 0.9.1 : temps de réponse de toutes les demandes Target = somme des temps de réponse des demandes
• at.js 1.0.0 et versions ultérieures : temps de réponse de toutes les demandes Target = maximum du temps de réponse des demandes

La bibliothèque at.js version 1.0.0 exécute les demandes 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 l’exécution des requêtes prend des secondes, la page rendue est toujours visible, seules certaines parties de la page sont masquées jusqu’à ce que Target reçoive une réponse de Target Edge.

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 recommandée est via Adobe Experience Platform Launch. Pour plus d’informations, consultez la leçon Ajout d’Adobe Target du tutoriel Mise en oeuvre de l’Experience Cloud dans les sites web avec Launch .

• Vous pouvez également charger at.js de manière asynchrone en ajoutant l’attribut async à la balise du script qui charge at.js. Utilisez quelque chose comme ceci :

  <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 en utilisant un fragment de code de pré-masquage qui masque la page (ou les portions 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 asynchrone de Launch, veillez à inclure le fragment de code de masquage préalable directement sur vos pages, avant le code incorporé de Launch, comme décrit dans la section Ajout du fragment de code de masquage préalable de Target du didacticiel Mise en oeuvre de l’Experience Cloud dans les sites web avec Launch.

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.

at.js est-il compatible avec l’intégration d’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 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 ?

at.js utilise actuellement des parties de jQuery et, par conséquent, la notification de licence MIT s’affiche en haut de 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 interdomaine 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 Target compositeur d’expérience visuelle (VEC) dans mes applications d’une seule page ?

Oui, vous pouvez utiliser le VEC pour votre SPA si vous utilisez at.js 2.x. Pour plus d’informations, voir Compositeur d’expérience visuelle d’une seule page (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 utilisent parfois des instances basées sur le cloud avec TargetTarget à 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. Adobe recommande toutefois 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 création de la page est lente (en raison d’un réseau lent) et at.js ne parvient pas à trouver le sélecteur dans le modè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 trouvés.

• La page sous-jacente fait partie d’une application d’une seule page 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 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 et mbox.js n’utilisent-ils pas les indicateurs de cookie HttpOnly et Secure ?

HttpOnly ne peut être défini que via un code côté serveur. Les cookies Target, tels que mbox, étant créés et enregistrés via le code JavaScript, Target ne peut pas utiliser l’indicateur de cookie HttpOnly.

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 vous assurer que Target peut assurer un suivi correct des utilisateurs, et parce que les cookies sont générés côté client, Target n’utilise aucun de ces indicateurs.

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

Toutes les prises de décision d’Adobe 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 de pré-masquer HTML BODY ou d’autres éléments DOM pendant une longue période, mais cela dépend des conditions réseau et de la configuration de l’activité. 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 Target trouve un élément DOM, des modifications sont apportées au modèle DOM et le style de pré-masquage de l’élément supprimé.
9. Si aucun élément DOM n’est trouvé, un délai d’expiration global affiche les éléments pour éviter qu’une page ne soit endommagée.

À quelle fréquence le contenu de la page est-il complètement chargé et visible lorsque at.js finit par libérer l’élément modifié par l’activité ?

Dans le scénario ci-dessus, à quelle fréquence le contenu de la page est-il complètement chargé et visible lorsque at.js finit par libérer 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. Un utilisateur peut remarquer que certaines régions vierges de la page représentent des é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 en cache sur un réseau de diffusion de contenu proche de l’emplacement géographique de l’utilisateur, mais loin du serveur Target Edge, le délai risque d’être un peu plus long. Les périphéries des cibles sont bien réparties dans le monde entier, 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.