Show Menu
TOPICS×

Impostazione degli ID di Analytics ed Experience Cloud

Il servizio Experience Cloud Identity sostituisce i metodi legacy di raccolta degli ID visitatore di Analytics.
Dopo l’implementazione del servizio ID, questo codice viene eseguito prima di AppMeasurement. Il servizio ID recupera gli ID di Experience Cloud e Analytics in modo che tali valori siano pronti al caricamento di AppMeasurement.
Quando AppMeasurement viene caricato, i valori degli ID di Experience Cloud e Analytics vengono richiesti dal servizio ID e inviati alla raccolta dati a ogni chiamata del server. Poiché il servizio ID determina l’ID visitatore e lo trasmette semplicemente ad AppMeasurement, il servizio ID deve essere incluso e implementato in ogni pagina prima del file JavaScript di AppMeasurement.

Modifiche al processo ID di Analytics

La principale modifica relativa alla migrazione al servizio Experience Cloud ID riguarda la configurazione del cookie ID, che viene effettuata con JavaScript e non più nell'intestazione HTTP restituita dal server Web di raccolta dei dati. Per comprendere questa modifica, le sezioni seguenti descrivono come vengono impostati i cookie utilizzando questi due metodi.
Intestazione HTTP
Una risposta HTTP da un server Web imposta i cookie in un browser. Il
s_vi
cookie viene impostato in questo modo. Il
s_vi
cookie identifica i visitatori di Analytics. Una volta impostato, il cookie viene inviato insieme a tutte le richieste HTTP successive a tale server.
Quando viene inviata una richiesta al server di raccolta dati Adobe, l'intestazione viene controllata per verificare la presenza del cookie
s_vi
. Se il cookie è presente nella richiesta, viene utilizzato per identificare il visitatore. Se il cookie non è presente, il server genera un Experience Cloud ID univoco, lo imposta come cookie nell'intestazione della risposta HTTP e lo invia nuovamente insieme alla richiesta. Il cookie viene memorizzato nel browser e inviato di nuovo al server di raccolta dati durante le successive visite al sito. Questo consente al visitatore di essere identificato attraverso le visite.
Tuttavia, alcuni browser come Apple Safari non accettano i cookie di terze parti. Si tratta di cookie impostati nel browser da domini diversi dal sito Web corrente. Inoltre, Safari blocca i cookie su domini di terze parti se un visitatore non è già stato su quel dominio. Ad esempio, se accedi a
mysite.com
e il server di raccolta dati è
mysite.omtrdc.net
il cookie restituito nell'intestazione HTTP da
mysite.omtrdc.net
potrebbe essere rifiutato dal browser.
Per evitare questo problema, molti clienti hanno implementato record CNAME per i propri server di raccolta dati. Questo può essere un passaggio efficace di una strategia per l’ implementazione di cookie di prima parte . Se viene configurato un record CNAME per mappare un nome host nel dominio del cliente al server di raccolta dati (ad es., mappatura di
metrics.mysite.com
a
mysite.omtrdc.net
), il cookie Experience Cloud ID viene memorizzato, perché il dominio di raccolta dati corrisponde al dominio del sito Web. Questo aumenta la probabilità che il cookie del servizio ID venga memorizzato. Tuttavia, questo comporta un certo sovraccarico perché è necessario configurare i record CNAME e mantenere i certificati SSL per i server di raccolta dati.
JavaScript
JavaScript è in grado di leggere e scrivere i cookie impostati nel dominio di prima parte (il dominio del sito Web corrente). Il servizio Experience Cloud ID utilizza questo metodo per impostare il cookie
AMCV_###@AdobeOrg
, che contiene tutti gli ID dei visitatori, pertanto il dominio del server di monitoraggio non deve più corrispondere al dominio del sito Web per memorizzare il cookie dell'ID visitatore. Nella maggior parte dei casi, questo è il modo migliore per impostare il cookie del servizio ID perché elimina il sovraccarico dei record CNAME e dei certificati SSL.
Tuttavia, ci sono alcuni casi in cui l’impostazione del cookie nell’intestazione HTTP è utile per il tracciamento tra domini diversi, come descritto in CNAME di raccolta dati e tracciamento tra domini diversi .

ID di Analytics personalizzati

L'impostazione di un ID cliente usando
s.visitorID
è un metodo di identificazione degli utenti in Analytics. Tuttavia, le integrazioni in cui vengono esportati o importati i dati di Analytics tramite il servizio ID non funzioneranno quando un visitatore viene identificato tramite
s.visitorID
.
Sono inclusi, ma senza limitazioni, tipi di pubblico condivisi, Analytics for Target (A4T) e attributi cliente. Per queste integrazioni, l'impostazione di un ID Analytics personalizzato non è supportata.

Ordine di identificazione degli ID visitatore in Analytics

Dopo aver implementato il servizio ID visitatore, un visitatore può essere identificato in cinque modi in Analytics (elencati nella tabella seguente in ordine di preferenza):
Ordine utilizzato
Parametro query (metodo di raccolta)
Presente quando
s.visitorID è impostato
Il visitatore aveva un altro cookie s_vi prima dell'implementazione del servizio
Experience Cloud
ID, oppure è stato configurato un periodo di tolleranza .
mid (cookie_AMCV impostato dal servizio ID visitatore di Experience Cloud)
Il browser del visitatore accetta i cookie di prime parti
Un browser non accetta cookie di terze parti e il server di tracciamento di Analytics è impostato come server di tracciamento terze parti.
Nota:
fid
è un identificatore legacy e non viene utilizzato se hai implementato il servizio ID sul tuo sito. In questo caso, il
fid
non è necessario perché il cookie AMCV di prime parti lo rende obsoleto. È stato mantenuto per supportare codice legacy e per motivi storici.
Il browser del visitatore non accetta i cookie.
In molte situazioni potrebbero essere presenti due o tre ID diversi in una chiamata, ma Analytics utilizza il primo ID presente nell'elenco come ID ufficiale di Experience Cloud. Ad esempio, se imposti un ID visitatore personalizzato (incluso nel parametro di query “vid”), questo ID verrà usato prima degli altri ID visualizzati per lo stesso hit.