Quelle différence y a-t-il entre les diagrammes de wordkflow at.js 1.x et at.js 2.x ?

Voir Mise à niveau d’at.js 1.x vers at.js 2.x pour plus d’informations sur les différences introduites dans la version 2.0 depuis 1.x.

D’un point de vu général, il y a quelques différences entre les deux versions :

  • at.js 2.x n’a pas de concept de requête de mbox globale, mais plutôt une requête de chargement de page. Une requête de chargement de page peut être vue comme une requête pour récupérer le contenu qui doit être appliqué au chargement initial de la page de votre site Web.
  • at.js 2.x gère les concepts appelés Views, qui sont utilisés pour les applications d’une seule page (SPA). at.js 1.x n’a pas conscience de ce concept.

Diagrammes at.js 2.x

Les diagrammes suivants vous aident à comprendre le workflow d’at.js 2.x avec Views et la manière dont cela améliore l’intégration de SPA. Pour une meilleure présentation des concepts utilisés dans at.js 2.x, voir Implémentation d’applications monopage.

(Cliquez sur l’image pour agrandir l’image en largeur réelle.)

Flux Target avec at.js 2.x

ÉtapeDétails
1L’appel renvoie le Experience Cloud ID si l’utilisateur est authentifié. Un autre appel synchronise l’ID de client.
2La bibliothèque at.js se charge de manière synchrone et masque le corps du document.
at.js peut également être chargé de manière asynchrone avec en option un extrait de code pré-masquant, implémenté sur la page.
3Une demande de chargement de page est faite, incluant tous les paramètres configurés (MCID, SDID et ID client).
4Les scripts de profil s’exécutent, puis sont introduits dans le Profile Store. Le Sto demande des audiences qualifiées à partir de Audience Library (par exemple, des audiences partagées à partir de Adobe Analytics, Audience Manager, etc.).
Les attributs du client sont envoyés par lot dans le Profile Store
5Selon les paramètres de requête d’URL et les données de profil, Target décidez quelles activités et expériences renvoyer au visiteur pour la page active et les futures vues.
6Le contenu ciblé est renvoyé à la page, comprenant, éventuellement, les valeurs de profil pour une personnalisation plus poussée.
Le contenu ciblé sur la page actuelle est affiché aussi rapidement que possible, sans scintillement du contenu par défaut.
Contenu ciblé pour les vues présentées à la suite d’actions de l’utilisateur dans une application d’une seule page cache dans le navigateur, afin qu’elles puissent être appliquées instantanément sans appel au serveur supplémentaire lorsque les vues sont déclenchées triggerView().
7Les données Analytics sont envoyées aux serveurs Data Collection.
8Les données ciblées sont associées aux données Analytics via le SDID et sont traitées dans le stockage de rapports Analytics.Les données
Analytics peuvent ensuite être visualisées dans les rapports Analytics et Target via (A4T).

Désormais, partout où triggerView() est implémenté sur votre SPA, les actions Views et sont récupérées dans le cache et affichées pour l’utilisateur sans appel au serveur. triggerView() envoie également une demande de notification au serveur dorsal de Target afin d’incrémenter et d’enregistrer le nombre d’impressions. Pour plus d’informations sur at.js pour les applications monopages avec vues, voir Implémentation d’application monopage.

(Cliquez sur l’image pour agrandir l’image en largeur réelle.)

Déclencheur d’affichage at.js 2.x du flux Target

ÉtapeDétails
1triggerView() est appelé dans le SPA pour effectuer le rendu de View et appliquer des actions pour modifier les éléments visuels.
2Le contenu ciblé pour la vue est lu à partir du cache.
3Le contenu ciblé s’affiche aussi rapidement que possible, sans scintillement du contenu par défaut.
4La demande de notification est envoyée à Target Profile Store pour compter le visiteur dans l’activité et incrémenter les mesures.
5Analytics données envoyées à Data Collection Servers.
6Les données Target sont associées aux données Analytics via le SDID et sont traitées dans le stockage de rapports Analytics. Les données Analytics peuvent ensuite être visualisées dans Analytics et Target au moyen de rapports A4T.

Vidéo : diagramme architectural d’at.js 2.x

at.js 2.x améliore la prise en charge d’applications monopages par Adobe Target et s’intègre aux autres solutions d’Experience Cloud. Cette vidéo explique comment tout se connecte.

Pour plus d’informations, consultez la page Fonctionnement d’at.js 2.x.

Diagramme at.js 1.x

Les diagrammes suivants vous aident à comprendre le processus d’at.js 1.x.

(Cliquez sur l’image pour agrandir l’image en largeur réelle.)

Flux Target at.js 1.x

ÉtapeDescriptionL’appelDescription
1L’appel renvoie l’ID d’Experience Cloud (MCID) si l’utilisateur est authentifié ; un autre appel synchronise l’ID de client.2La bibliothèque at.js se charge de manière synchrone et masque le corps du document.
3Une demande de mbox globale, incluant tous les paramètres configurés (MCID, SDID et ID de client (facultatif)), est envoyée.4Les scripts de profil s’exécutent, puis sont introduits dans le magasin de profils. Le magasin demande des audiences qualifiées auprès de la bibliothèque d’audiences (par exemple, audiences partagées depuis Adobe Analytics, Audience Manager, etc.).
Les attributs du client sont envoyés par lot dans le magasin de profils.
5En fonction de l’URL, des paramètres de mbox et des données de profil, Target décide quelles activités et expériences renvoyer au visiteur.6Le contenu ciblé est renvoyé à la page, y compris, éventuellement, les valeurs de profil pour une personnalisation plus poussée.
L’expérience est affichée aussi rapidement que possible, sans scintillement du contenu par défaut.
7Les données Analytics sont envoyées aux serveurs de collecte de données.8Les données Target sont associées aux données Analytics par l’intermédiaire du SDID et sont traitées dans le stockage de rapports Analytics.
Les données Analytics peuvent ensuite être visualisées dans Analytics et Target par l’intermédiaire des rapports Analytics for Target (A4T).