Domande frequenti su at.js

Risposte alle domande frequenti sulla libreria JavaScript at.js di Adobe Target.

Quali vantaggi offre at.js rispetto a mbox.js?

La libreria at.js sostituisce mbox.js. La libreria mbox.js non è più supportata. Tuttavia, per la maggior parte delle persone, at.js offre vantaggi rispetto a mbox.js.

Ad esempio, at.js migliora i tempi di caricamento delle pagine per le implementazioni web, migliora la sicurezza e fornisce migliori opzioni di implementazione per le applicazioni a pagina singola.

Nella figura seguente vengono illustrate le prestazioni di caricamento delle pagine utilizzando mbox.js e at.js.

(Fare clic sull'immagine per espanderla a larghezza intera.)

Come illustrato in precedenza, utilizzando mbox.js il contenuto della pagina inizia a caricarsi solo una volta completata la richiesta di Target. Utilizzando at.js, il contenuto della pagina comincia a caricarsi quando viene avviata la richiesta di Target, senza attenderne il completamento.

Qual è l’impatto di at.js e mbox.js sui tempi di caricamento delle pagine?

Molti clienti e consulenti vogliono conoscere l’impatto di at.js e mbox.js sui tempi di caricamento delle pagine, soprattutto nel contesto di nuovi utenti rispetto a utenti di ritorno. Sfortunatamente, è difficile misurare e fornire numeri concreti per quanto riguarda l’influenza di at.js o mbox.js sul tempo di caricamento della pagina a causa dell’implementazione di ciascun cliente.

Tuttavia, se sulla pagina è presente l’API visitatore, Target può capire meglio in che modo at.js e mbox.js influenzano il tempo di caricamento delle pagine.

Le sezioni seguenti illustrano la sequenza di azioni per i visitatori nuovi e per i visitatori di ritorno:

Visitatori nuovi

Visitatori di ritorno

Perché mi sembra di notare tempi di risposta più lenti dopo l’aggiornamento da una versione precedente di at.js alla versione 1.0.0?

at.js versione 1.0.0 o successiva attiva tutte le richieste in parallelo. Le versioni precedenti eseguono le richieste in modo sequenziale, ovvero le richieste formano una coda e Target aspetta il completamento della richiesta corrente prima di passare alla successiva.

Il modo in cui le versioni precedenti di at.js eseguono le richieste è suscettibile al cosiddetto blocco del primo elemento. In at.js 1.0.0 e versioni successive, Target è stata attivata l’esecuzione parallela delle richieste.

Se controlli la cascata delle schede di rete di at.js 0.9.1, ad esempio, vedrai il prossimo Target la richiesta di non viene avviata fino al completamento della precedente. Diverso è il caso con at.js 1.0.0 e versioni successive, dove tutte le richieste partono essenzialmente nello stesso momento.

Per quanto riguarda il tempo di risposta, la sequenza può essere riassunta così:

La libreria at.js versione 1.0.0 completa le richieste più rapidamente. Inoltre, le richieste at.js sono asincrone, quindi Target non blocca il rendering della pagina. Anche se il completamento delle richieste impiega qualche secondo, la pagina renderizzata sarà comunque visibile, anche se alcune parti della pagina resteranno vuote finché Target non avrà ricevuto una risposta dal server Edge di Target.

È possibile caricare la libreria di Target in modo asincrono?

La versione di at.js 1.0.0 permette di caricare la libreria di Target in modo asincrono.

Per caricare at.js in modo asincrono:

Caricare at.js in modo asincrono è un ottimo modo per evitare di bloccare il rendering del browser; tuttavia, questa tecnica può portare alla visualizzazione momentanea di altri contenuti della pagina web.

Puoi evitare sfarfallii utilizzando uno snippet che nasconde preventivamente la pagina (o specifiche porzioni), quindi la rivela dopo il caricamento di at.js e della richiesta globale. Lo snippet deve essere aggiunto prima del caricamento di at.js.

Se distribuisci at.js tramite un sistema asincrono Adobe Experience Platform implementazione, assicurati di includere lo snippet per nascondere le pagine direttamente, prima di implementare Target utilizzo Adobe Experience Platform Codice di incorporamento.

Durante l’implementazione di at.js tramite un’implementazione sincrona di DTM, puoi aggiungere lo snippet tramite una regola di caricamento della pagina attivata nella parte superiore della pagina.

Per ulteriori informazioni, consulta Gestione at.js della visualizzazione momentanea di altri contenuti.

at.js è compatibile con l’integrazione Adobe Experience Manager (Experience Manager)?

Adobe Experience Manager 6.2 con FP-11577 (o versioni successive) supporta ora le implementazioni di at.js con Cloud Service Adobe Target integrazione.

Come posso evitare la visualizzazione momentanea di altri contenuti al caricamento pagina, utilizzando at.js?

Target offre diversi modi per evitare la visualizzazione momentanea di altri contenuti al caricamento della pagina. Per ulteriori informazioni, consulta Prevenzione della visualizzazione momentanea di altri contenuti con at.js.

Qual è la dimensione del file di at.js?

Il file di at.js che scarichi è approssimativamente 109 KB. Tuttavia, poiché la maggior parte dei server comprime automaticamente i file per renderli di dimensioni più piccole, at.js è circa 34 KB quando è compresso (utilizzando GZIP o un altro metodo) sul server e caricato dagli utenti che visitano il tuo sito. Le impostazioni di compressione sul server in cui è stato installato at.js determinano la dimensione effettiva.

Perché at.js è più grande di mbox.js?

Le implementazioni di at.js utilizzano una sola libreria ( at.js), mentre quelle di mbox.js usano due librerie ( mbox.js e target.js). Quindi un confronto più equo è quello tra at.js e mbox.js più target.js. Confrontando le dimensioni compresse con GZIP delle due versioni, at.js versione 1.2 è di 34 KB e mbox.js versione 63 è di 26,2 KB. ``

at.js è più grande perché effettua molta più analisi DOM rispetto a mbox.js. Questo è necessario perché at.js ottiene dati “grezzi” dalla risposta JSON e deve interpretarli. mbox.js utilizzava invece document.write() ed era il browser a eseguire l’analisi.

Nonostante le dimensioni più grandi del file, i nostri test indicano che le pagine vengono caricate più velocemente con at.js rispetto a mbox.js. Inoltre, at.js è superiore dal punto di vista della sicurezza perché non carica file aggiuntivi in modo dinamico né utilizza document.write.

at.js include jQuery? Posso rimuovere questa parte di at.js se sul mio sito ho già jQuery?

at.js attualmente utilizza parti di jQuery e quindi vedrai la notifica della licenza MIT nella parte superiore di at.js. jQuery non è esposto e non interferisce con la libreria jQuery che hai già sulla pagina, che potrebbe essere una versione diversa. La rimozione del codice jQuery all’interno di at.js non è supportata.

at.js supporta Safari e l’attraversamento di più domini impostato su “solo x”?

No, se l’attraversamento di più domini è impostato su "solo x" e in Safari i cookie di terze parti sono disabilitati, allora sia mbox.js che at.js impostano un cookie disabilitato e non viene eseguita alcuna richiesta mbox per quel particolare dominio del client.

Per supportare i visitatori Safari, un dominio X migliore sarebbe "disabilitato" (imposta solo un cookie di prima parte) o "abilitato" (imposta solo un cookie di prima parte su Safari, mentre imposta i cookie di prima e terze parti su altri browser).

Posso usare Target? Compositore esperienza visivo (VEC) nelle applicazioni a pagina singola?

Sì, puoi utilizzare il Compositore esperienza visivo se utilizzi at.js 2.x. Per maggiori informazioni, consulta Compositore esperienza visivo per applicazione a singola pagina (SPA).

Posso utilizzare il debugger di Adobe Experience Cloud con le implementazioni di at.js?

Sì. È inoltre possibile utilizzare mboxTrace per il debug o gli Strumenti per sviluppatori del browser per controllare le richieste di rete, filtrando “mbox” per isolare le chiamate mbox.

Posso usare caratteri speciali nei nomi delle mbox con at.js?

Sì, come con mbox.js.

Perché le mie mbox non vengono lanciate sulle mie pagine web?

I Target clienti di utilizzano talvolta istanze basate su cloud con Target per test o semplici prove di concetto. Questi domini, e molti altri, fanno parte dell’elenco dei suffissi pubblici.

I browser moderni non salvano i cookie se usi questi domini, a meno che non personalizzi l’impostazione cookieDomain utilizzando targetGlobalSettings(). Per ulteriori informazioni, consulta Utilizzo di istanze basate su cloud con Target.

Gli indirizzi IP possono essere utilizzati come dominio dei cookie quando si utilizza at.js?

Sì, se utilizzi at.js versione 1.2 o successive. Tuttavia, Adobe consiglia vivamente di utilizzare sempre l’ultima versione.

A seconda di come utilizzi targetGlobalSettings, potrebbe essere necessario apportare ulteriori modifiche al codice dopo aver scaricato at.js. Ad esempio, se ti servivano impostazioni leggermente diverse per le tue implementazioni di Target su vari siti web e non hai potuto definirle in modo dinamico con JavaScript personalizzato, apporta tali personalizzazioni manualmente dopo aver scaricato il file e prima di caricarlo sul rispettivo sito web.

Gli esempi seguenti consentono di utilizzare la funzione di at.js targetGlobalSettings() per inserire uno snippet di codice per supportare gli indirizzi IP:

Esempio per un solo indirizzo IP:

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

Esempio per un intervallo di indirizzi IP:

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

Perché ricevo messaggi di avviso, ad esempio “azioni con selettori mancanti”?

Questi messaggi non sono legati alla funzionalità at.js. La libreria at.js tenta di segnalare tutto ciò che non si trova nel DOM.

Di seguito sono riportate le possibili cause principali per questo messaggio di avviso:

Le chiamate server di Target sono indirizzate al dominio tt.omtrdc.net: di che si tratta?

tt.omtrdc.net è il nome di dominio della rete EDGE di Adobe, utilizzato per ricevere tutte le chiamate server per Target.

Perché at.js non utilizza sempre i flag dei cookie HttpOnly e Secure?

HttpOnly può essere impostato solo tramite codice basato su server. TargetI cookie, come mbox, vengono creati e salvati tramite il codice JavaScript, quindi non può utilizzare il flag di Target cookie HttpOnly. Target utilizza il flag HttpOnly impostato per i cookie di terze parti impostati lato server quando è abilitato l’attraversamento di più domini.

È possibile impostare il flag Secure tramite JavaScript solo se la pagina è stata caricata tramite HTTPS. Se la pagina viene inizialmente caricata tramite HTTP, JavaScript non può impostare questo flag. Inoltre, se viene utilizzato il flag Secure, il cookie sarà disponibile solo nelle pagine HTTPS. Per le pagine caricate tramite HTTPS, Target imposta gli attributi Secure e SameSite=None.

Per garantire che Target possa tracciare correttamente gli utenti e che i cookie siano generati lato client, Target non utilizza nessuno di questi flag, tranne nelle situazioni sopra menzionate.

In che modo at.js gestisce problemi di sicurezza come attacchi XSS e MITM?

La comunicazione con la rete Adobe Edge, abilitata da at.js, avviene solo su HTTPS, purché il secureOnly è impostata su true nella funzione targetGlobalSettings() (targetGlobalSettings), altrimenti at.js è autorizzato a passare da HTTP a HTTPS in base al protocollo della pagina.

Le seguenti intestazioni vengono applicate per impostazione predefinita:

È possibile applicare tutte le intestazioni già utilizzate nelle pagine client. Un modo comune per farlo è tramite "HTTP Request Header Authorization". L’Assistenza clienti di Adobe può fornire ulteriori consigli su metodi e pratiche ottimali.

Inoltre, le richieste a Adobe Edge Network sono pubbliche (in quanto sono progettate per essere effettuate dai browser dei visitatori) e non contengono dettagli visibili del visitatore (contengono solo un ID visitatore). Queste richieste consegnano esperienze ai visitatori e contengono dettagli su ciò che un visitatore dovrebbe vedere sulla pagina.

Tieni presente che per i token di risposta e gli ID sessione trasmessi in queste richieste:

È previsto che visualizzi Access-Control-Allow-Origin intestazione con valore "*" nelle richieste at.js, poiché sono pubbliche, non è richiesta l’autenticazione e la rete Adobe Edge deve essere accessibile da qualsiasi dominio tramite chiamate JavaScript.

Tuttavia, i criteri sulla sicurezza dei contenuti (Content Security Policy, CSP) devono essere applicati sulla pagina. Per ulteriori informazioni sui requisiti CSP per at.js, consulta Informativa sulla sicurezza dei contenuti e targetGlobalSettings.

Con quale frequenza at.js attiva una richiesta di rete?

Target esegue tutte le sue decisioni sul lato server. Ciò significa che at.js at.js genera una richiesta di rete ogni volta che la pagina si ricarica o viene richiamata un'API pubblica di at.js.

Nel migliore dei casi, possiamo aspettarci che l'utente non verifichi effetti visibili sul caricamento della pagina dovuti al fatto che si nasconde, sostituisce e visualizza il contenuto?

at.js cerca di evitare di nascondere anticipatamente HTML BODY o altri elementi DOM per un periodo di tempo prolungato, ma ciò dipende dalle condizioni di rete e dalla configurazione dell’attività. at.js offre impostazioni che è possibile utilizzare per personalizzare lo stile CSS per nascondere il BODY, in modo tale che invece di svuotare l’intero BODY HTML sia possibile nascondere anticipatamente solo alcune parti della pagina. L'aspettativa è che quelle parti contengano elementi DOM che devono essere “personalizzati”.

Qual è la sequenza di eventi in uno scenario medio in cui un utente si qualifica per un’attività?

La richiesta at.js è un XMLHttpRequest asincrono, quindi eseguiamo i seguenti passaggi:

Quanto spesso il contenuto della pagina è completamente caricato e visibile quando at.js rivela infine l’elemento che l’attività sta modificando?

Considerando lo scenario precedente, quanto spesso il contenuto della pagina è completamente caricato e visibile quando at.js rivela infine l’elemento che l’attività sta modificando? In altre parole, la pagina è completamente visibile ad eccezione del contenuto dell'attività, che viene poi rivelato leggermente dopo il resto del contenuto.

at.js non blocca il rendering della pagina. Un utente potrebbe notare alcune aree vuote nella pagina che rappresentano elementi che verranno personalizzati da Target. Se il contenuto da applicare non contiene molte risorse remote, come SCRIPT o IMG, il rendering dovrebbe essere eseguito rapidamente.

In che modo una pagina interamente salvata nella cache influirà sullo scenario precedente? Sarebbe più probabile che il contenuto dell’attività diventi visibile notevolmente dopo il caricamento del resto del contenuto della pagina?

Se una pagina viene salvata nella cache in una rete CDN vicina alla posizione dell’utente, ma non vicina al server Edge di Target, l’utente potrebbe notare alcuni ritardi. I server Edge di Target sono ben distribuiti in tutto il mondo, quindi nella maggior parte dei casi questo non è un problema.

È possibile che un’immagine protagonista venga visualizzata e poi scambiata dopo un breve ritardo?

Considerando lo scenario seguente:

Il timeout di Target è di cinque secondi. Un utente carica una pagina che ha un'attività per personalizzare un'immagine protagonista. at.js invia la richiesta per determinare se c'è un'attività da applicare, ma non è presente una risposta iniziale. Supponiamo che l’utente veda il contenuto regolare dell’immagine principale, perché non è stata ricevuta alcuna risposta da Target sull’esistenza di un’attività associata. Dopo quattro secondi, Target restituisce una risposta con il contenuto dell’attività.

A questo punto, è possibile che la versione alternativa venga mostrata? Perciò dopo quattro secondi, l'immagine protagonista potrebbe essere scambiata e l'utente potrebbe notare questo scambio di immagini?

Inizialmente, l'elemento DOM dell’immagine protagonista è nascosto. Una volta ricevuta una risposta da Target, at.js applica le modifiche DOM, come la sostituzione dell’IMG e la visualizzazione dell’immagine principale personalizzata.

Quale doctype HTML richiede at.js?

at.js richiede il doctype HTML5.

La sintassi è:

<!DOCTYPE html>

Il doctype HTML5 assicura che la pagina venga caricata in modalità standard. Durante il caricamento in modalità quirks, alcune API JS dalle quali dipende at.js sono disabilitate. Target disabilita at.js in modalità quirks.

at.js funziona in un ambiente di app Ionic.

Questa implementazione non è mai stata testata, poiché at.js non era destinato a funzionare in un ambiente non web. Adobe consiglia quanto segue SDK per le implementazioni per dispositivi mobili.