Visitatori nuovi

  1. L'API dei visitatori viene caricata, analizzata ed eseguita.

  2. at.js / mbox.js è caricato, analizzato ed eseguito.

  3. Se la creazione automatica della mbox globale è abilitata, la libreria JavaScript di Target:

    • Crea un'istanza dell'oggetto Visitatore.
    • La libreria Target tenta di recuperare i dati dell'ID visitatore Experience Cloud.
    • Poiché si tratta di un nuovo visitatore, l’API Visitor genera una richiesta cross-domain a demdex.net.
    • Dopo il recupero dei dati dell'ID visitatore di Experience Cloud, viene avviata una richiesta a Target.

Visitatori di ritorno

  1. L'API dei visitatori viene caricata, analizzata ed eseguita.

  2. at.js / mbox.js è caricato, analizzato ed eseguito.

  3. Se la creazione automatica della mbox globale è abilitata, la libreria JavaScript di Target:

    • Crea un'istanza dell'oggetto Visitatore.
    • La libreria Target tenta di recuperare i dati dell'ID visitatore Experience Cloud.
    • L'API dei visitatori recupera i dati dai cookie.
    • Dopo il recupero dei dati dell'ID visitatore di Experience Cloud, viene avviata una richiesta a Target.
NOTE
Per i nuovi visitatori, quando è presente l'API visitatore, Target deve connettersi più volte per assicurarsi che Target richieste contengano dati di ID visitatore Experience Cloud. Per i visitatori di ritorno, Target si connette a Target solo per recuperare il contenuto personalizzato.

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 è passato all'esecuzione parallela delle richieste.

Se controlli la cascata delle schede di rete di at.js 0.9.1, ad esempio, vedrai che la successiva richiesta di Target si avvia solo dopo che la precedente è stata completata. 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ì:

  • at.js 0.9.1: tempo di risposta di tutte le Target richieste = somma del tempo di risposta delle richieste
  • at.js 1.0.0 e versioni successive: tempo di risposta di tutte le Target richieste = tempo di risposta massimo delle richieste

La libreria at.js versione 1.0.0 completa le richieste più rapidamente. Inoltre, le richieste at.js sono asincrone, pertanto 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.