Impostazione degli ID di Analytics ed Experience Cloud setting-analytics-and-experience-cloud-ids
Experience Cloud Identity Service 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 section-79bb86ae63f546419bb1a7ef5e710462
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.
ID di Analytics personalizzati section-b6a7bd19e9ff432390010062450808f6
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 section-de1dc9fc9b6d4388995b70e35b8bcddf
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):
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.
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.