Dati di identità in Web SDK
Adobe Experience Platform Web SDK utilizza Adobe Experience Cloud ID (ECID) per monitorare il comportamento dei visitatori. Utilizzando ECIDs, puoi verificare che ogni dispositivo abbia un identificatore univoco che può persistere in più sessioni, collegando a un dispositivo specifico tutti gli hit che si verificano durante e tra sessioni web.
Questo documento fornisce una panoramica su come gestire ECIDs e CORE IDs tramite Web SDK.
Tracciamento degli ECID tramite Web SDK tracking-ecids-web-sdk
L'SDK Web assegna e tiene traccia di ECIDs utilizzando i cookie, con più metodi disponibili per configurare la modalità di generazione di questi cookie.
Quando un nuovo utente arriva sul tuo sito Web, il servizio Adobe Experience Cloud Identity tenta di impostare un cookie di identificazione del dispositivo per tale utente.
- Per i nuovi visitatori, viene generato un ECID che viene restituito nella prima risposta dall'Edge Network di Experience Platform.
- Per i visitatori di ritorno, ECID viene recuperato dal cookie
kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
e aggiunto al payload della richiesta dall'Edge Network.
Una volta impostato il cookie contenente ECID, ogni richiesta successiva generata da Web SDK include un ECID codificato nel cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
.
Quando si utilizzano i cookie per l’identificazione del dispositivo, è possibile interagire con l’Edge Network in due modi:
- Crea un CNAME nel tuo dominio che punti a
adobedc.net
. Questo metodo è denominato raccolta dati di prime parti. - Invia dati direttamente al dominio Edge Network
adobedc.net
. Questo metodo è denominato raccolta dati di terze parti.
Come spiegato nelle sezioni seguenti, il metodo di raccolta dei dati che scegli di utilizzare ha un impatto diretto sulla durata dei cookie nei vari browser.
Tracciamento degli ID CORE tramite Web SDK tracking-coreid-web-sdk
Quando si utilizza Google Chrome con cookie di terze parti abilitati e non è impostato alcun cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
, la prima richiesta di Edge Network passa attraverso un dominio demdex.net
, che imposta un cookie demdex. Questo cookie contiene CORE ID. Questo è un ID utente univoco, diverso da ECID.
A seconda dell'implementazione, potrebbe essere utile accedere a CORE ID.
Raccolta di dati di prime parti first-party
La raccolta dati di prime parti comporta l'impostazione di cookie tramite CNAME
nel proprio dominio che punta a adobedc.net
.
Sebbene i browser abbiano a lungo trattato i cookie impostati da CNAME
endpoint in modo simile a quelli impostati dagli endpoint di proprietà del sito, le recenti modifiche implementate dai browser hanno creato una distinzione nella gestione dei cookie CNAME
. Sebbene non vi siano browser che attualmente bloccano i cookie di prime parti CNAME
per impostazione predefinita, alcuni browser limitano la durata dei cookie impostati con CNAME
a soli sette giorni.
Raccolta di dati di terze parti third-party
La raccolta dati di terze parti comporta l'invio diretto di dati al dominio Edge Network adobedc.net
.
Negli ultimi anni, i browser web sono diventati sempre più restrittivi nella gestione dei cookie impostati da terze parti. Per impostazione predefinita, alcuni browser bloccano i cookie di terze parti. Se utilizzi cookie di terze parti per identificare i visitatori del sito, la durata di tali cookie è quasi sempre più breve di quella che sarebbe altrimenti disponibile utilizzando i cookie di prima parte. A volte, un cookie di terze parti scade entro appena sette giorni.
Inoltre, quando si utilizza la raccolta dati di terze parti, alcuni ad blocker limitano il traffico agli endpoint di raccolta dati di Adobe.
Effetti della durata dei cookie sulle applicazioni Adobe Experience Cloud lifespans
Indipendentemente dal fatto che si scelga la raccolta dati di prime parti o di terze parti, il periodo di tempo in cui un cookie può persistere ha un impatto diretto sui conteggi dei visitatori in Adobe Analytics e Customer Journey Analytics. Inoltre, gli utenti finali potrebbero sperimentare esperienze di personalizzazione incoerenti quando Adobe Target o Offer Decisioning sono utilizzati sul sito.
Ad esempio, considera una situazione in cui hai creato un’esperienza di personalizzazione che promuove qualsiasi elemento nella home page se un utente lo ha visualizzato tre volte negli ultimi sette giorni.
Se un utente finale visita il sito tre volte alla settimana e poi non vi ritorna per sette giorni, potrebbe essere considerato un nuovo utente quando ritorna sul sito, perché i suoi cookie potrebbero essere stati eliminati da una policy del browser (a seconda del browser che stava utilizzando quando ha visitato il sito). In questo caso, lo strumento Analytics tratta il visitatore come un nuovo utente, anche se ha visitato il sito poco più di sette giorni fa. Inoltre, ricomincia qualsiasi tentativo di personalizzare l’esperienza per l’utente.
ID dispositivo di prime parti (FPID) fpid
Per tenere conto degli effetti delle durate dei cookie come descritto in precedenza, puoi invece scegliere di impostare e gestire gli identificatori dei dispositivi. Per ulteriori informazioni, consulta la guida su ID dispositivo di prime parti.
Recupera l’ECID e l’area geografica dell’utente corrente retrieve-ecid
A seconda del caso d'uso, è possibile accedere a ECID in due modi:
- Recupera il ECID tramite la preparazione dati per la raccolta dati: metodo consigliato da utilizzare.
- Recupera ECID tramite il comando
getIdentity()
: utilizzare questo metodo solo quando sono necessarie le informazioni ECID sul lato client.
Recupera ECID tramite la preparazione dati per la raccolta dati retrieve-ecid-data-prep
Utilizza Preparazione dati per raccolta dati per mappare ECID a un campo XDM. Questo è il modo consigliato per accedere a ECID.
A questo scopo, imposta il campo di origine sul seguente percorso:
xdm.identityMap.ECID[0].id
Quindi, imposta il campo di destinazione su un percorso XDM in cui il campo è di tipo string
.
Recupera ECID tramite il comando getIdentity()
retrieve-ecid-getidentity
getIdentity()
solo se si richiede ECID sul lato client. Se desideri mappare solo l'ECID a un campo XDM, utilizza invece Preparazione dati per raccolta dati.Per recuperare l'ECID univoco per il visitatore corrente, utilizzare il comando getIdentity
. Per i nuovi visitatori che non hanno ancora un ECID, questo comando genera un nuovo ECID. getIdentity
restituisce anche l'ID di regione per il visitatore.
alloy("getIdentity")
.then(function(result) {
// The command succeeded.
console.log("ECID:", result.identity.ECID);
console.log("RegionId:", result.edge.regionId);
})
.catch(function(error) {
// The command failed.
// "error" will be an error object with additional information.
});
Recupera l'ID CORE per l'utente corrente retrieve-coreid
Per recuperare l'ID CORE di un utente, è possibile utilizzare il comando getIdentity()
, come illustrato di seguito.
alloy("getIdentity",{
"namespaces": ["CORE"]
});
Utilizzo di identityMap
using-identitymap
Utilizzando un campo identityMap
XDM, è possibile identificare un dispositivo/utente utilizzando più identità, impostarne lo stato di autenticazione e decidere quale identificatore è considerato primario. Se non è stato impostato alcun identificatore come primary
, l'impostazione predefinita è ECID
.
I campi identityMap
sono stati aggiornati con il comando sentEvent
.
alloy("sendEvent", {
xdm: {
"identityMap": {
"ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
{
"id": "1234",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
});
CRMID
, come identità primaria.Ogni proprietà all'interno di identityMap
rappresenta identità appartenenti a un particolare spazio dei nomi identità. Il nome della proprietà deve essere il simbolo dello spazio dei nomi dell'identità, che puoi trovare elencato nell'interfaccia utente di Adobe Experience Platform in "Identities". Il valore della proprietà deve essere un array di identità relative a tale spazio dei nomi di identità.
identityMap
distingue tra maiuscole e minuscole. Assicurati di utilizzare l’ID dello spazio dei nomi corretto per evitare la raccolta incompleta dei dati.Ogni oggetto identità nell’array delle identità contiene le seguenti proprietà:
id
authenticatedState
ambiguous
, authenticated
e loggedOut
.primary
false
.Se si utilizza il campo identityMap
per identificare dispositivi o utenti, si ottiene lo stesso risultato dell'utilizzo del metodo setCustomerIDs
di ID Service API. Per ulteriori dettagli, consulta la documentazione API del servizio ID.
Migrazione dall’API visitatore a ECID migrating-visitor-api-ecid
Durante la migrazione da utilizzando l’API visitatore, puoi anche eseguire la migrazione dei cookie AMCV esistenti. Per abilitare la migrazione ECID, imposta il parametro idMigrationEnabled
nella configurazione. La migrazione degli ID abilita i seguenti casi d’uso:
- Quando alcune pagine di un dominio utilizzano l’API Visitor e altre pagine utilizzano questo SDK. Per supportare questo caso, l’SDK legge i cookie AMCV esistenti e scrive un nuovo cookie con l’ECID esistente. Inoltre, l'SDK scrive i cookie AMCV in modo che, se l'ECID viene ottenuto per primo su una pagina instrumentata con l'SDK, le pagine successive instrumentate con l'API visitatore abbiano lo stesso ECID.
- Quando Adobe Experience Platform Web SDK è configurato in una pagina che dispone anche dell’API visitatore. Per supportare questo caso, se il cookie AMCV non è impostato, l'SDK cerca l'API visitatore nella pagina e la chiama per ottenere l'ECID.
- Quando l’intero sito utilizza Adobe Experience Platform Web SDK e non dispone dell’API visitatore, è utile migrare gli ECID in modo che vengano conservate le informazioni sul visitatore restituite. Dopo che l'SDK è stato distribuito con
idMigrationEnabled
per un certo periodo di tempo in modo che la maggior parte dei cookie del visitatore vengano migrati, l'impostazione può essere disattivata.
Aggiornamento delle caratteristiche per la migrazione
Quando si inviano dati in formato XDM a Audience Manager, questi devono essere convertiti in segnali durante la migrazione. Le caratteristiche devono essere aggiornate per riflettere le nuove chiavi fornite da XDM. Questo processo è facilitato dall'utilizzo dello strumento BAAAM creato dall'Audience Manager.
Utilizzo nell’inoltro degli eventi
Se al momento hai abilitato inoltro eventi e utilizzi appmeasurement.js
e visitor.js
, puoi mantenere abilitata la funzione di inoltro eventi e non si verificheranno problemi. Nel back-end, Adobe recupera tutti i segmenti AAM e li aggiunge alla chiamata ad Analytics. Se la chiamata ad Analytics contiene tali segmenti, Analytics non chiamerà Audience Manager per inoltrare alcun dato, quindi non esiste una doppia raccolta di dati. Inoltre, non è necessario usare il suggerimento posizione quando si utilizza l’SDK per web, in quanto nel back-end vengono chiamati gli stessi endpoint di segmentazione.