ID dispositivo di prime parti in Web SDK

Adobe Experience Platform Web SDK assegna ID Adobe Experience Cloud (ECID) ai visitatori del sito Web utilizzando i cookie per monitorare il comportamento degli utenti. Per tenere conto delle restrizioni del browser sulla durata dei cookie, puoi invece scegliere di impostare e gestire gli identificatori dei tuoi dispositivi. Tali ID sono denominati ID dispositivo di prime parti (FPIDs).

NOTE
Il supporto per gli ID dispositivo di prime parti è disponibile solo quando si inviano dati all’Edge Network Experience Platform tramite Web SDK.
IMPORTANT
Gli ID dispositivo di prime parti non sono compatibili con la funzionalità cookie di terze parti in Web SDK.
Puoi utilizzare gli ID dispositivo di prime parti oppure cookie di terze parti, ma non puoi utilizzare entrambe le funzioni contemporaneamente.

Questo documento spiega come configurare gli ID dispositivo di prime parti per l’implementazione dell’SDK web.

Prerequisiti

Questa guida presuppone che tu abbia familiarità con il funzionamento dei dati di identità per Platform Web SDK, incluso il ruolo di ECID e identityMap. Per ulteriori informazioni, consulta la panoramica sui dati di identità nell'SDK per web.

Utilizzo degli ID dispositivo di prime parti (FPID) using-fpid

Gli ID dispositivo di prime parti (FPIDs) tengono traccia dei visitatori utilizzando cookie di prime parti. I cookie di prime parti sono più efficaci quando vengono impostati utilizzando un server che utilizza un record A DNS (per IPv4) o un record AAAA DNS (per IPv6), anziché un codice DNS CNAME o JavaScript.

IMPORTANT
I record A o AAAA sono supportati solo per l'impostazione e il tracciamento dei cookie. Il metodo primario per la raccolta dati è tramite un DNS CNAME. In altre parole, FPIDs sono impostati utilizzando un record A o AAAA e vengono quindi inviati ad Adobe utilizzando un CNAME.
Il programma di certificazione gestito da Adobe è ancora supportato per la raccolta dati di prime parti.

Una volta impostato il cookie FPID, il relativo valore può essere recuperato e inviato all'Adobe durante la raccolta dei dati dell'evento. I FPIDs raccolti vengono utilizzati come seed per generare ECIDs, che continuano a essere gli identificatori primari nelle applicazioni Adobe Experience Cloud.

Per inviare un FPID per un visitatore del sito Web all'Edge Network, è necessario includere FPID in identityMap per tale visitatore. Per ulteriori informazioni, consulta la sezione più avanti in questo documento sull'utilizzo degli FPID in identityMap🔗 per .

Requisiti di formattazione degli ID dispositivo di prime parti formatting-requirements

L'Edge Network accetta solo IDs conformi al formato UUIDv4. Gli ID dispositivo non nel formato UUIDv4 verranno rifiutati.

La generazione di un UUID produrrà quasi sempre un ID casuale univoco, con una probabilità di collisione trascurabile. Impossibile eseguire il seeding di UUIDv4 utilizzando indirizzi IP o altre informazioni personali identificabili (PII). UUIDs sono onnipresenti e le librerie possono essere trovate praticamente per ogni linguaggio di programmazione per generarle.

È possibile specificare il nome di un cookie nell'interfaccia utente di Datastreams, dove può risiedere FPID, anziché dover leggere il valore del cookie e includere FPID nella mappa delle identità.

IMPORTANT
Questa funzionalità richiede l'abilitazione di Raccolta dati di prime parti.

Per informazioni dettagliate su come configurare uno stream di dati, consulta la documentazione sugli stream di dati.

Durante la configurazione dello stream di dati, abilita l'opzione Cookie ID di prime parti. Questa impostazione indica all'Edge Network di fare riferimento a un cookie specificato durante la ricerca di un ID dispositivo di prime parti, anziché cercare questo valore nella mappa identità.

Consulta la documentazione su cookie di prime parti per ulteriori dettagli sul loro funzionamento con Adobe Experience Cloud.

Immagine dellinterfaccia utente di Platform che mostra la configurazione dello stream di dati evidenziando limpostazione del cookie ID di prime parti

Quando abiliti questa impostazione, devi fornire il nome del cookie in cui si prevede che l’ID venga memorizzato.

Quando utilizzi ID di prime parti, non puoi eseguire sincronizzazioni ID di terze parti. Le sincronizzazioni ID di terze parti si basano sul servizio Visitor ID e sul UUID generati da tale servizio. Quando si utilizza la funzionalità ID di prima parte, ECID viene generato senza l'utilizzo del servizio Visitor ID, rendendo impossibile le sincronizzazioni ID di terze parti.

Quando si utilizzano ID di prime parti, le funzionalità Audience Manager mirate all'attivazione nelle piattaforme partner non sono supportate, dato che le sincronizzazioni degli ID partner Audience Manager sono per lo più basate su UUIDs o DIDs. ECID derivato da un ID di prima parte non è collegato a un UUID, rendendolo non indirizzabile.

Quando imposti un cookie utilizzando un server di tua proprietà, puoi utilizzare diversi metodi per impedire che il cookie sia soggetto a restrizioni a causa dei criteri del browser:

  • Generare cookie utilizzando linguaggi di script lato server
  • Imposta i cookie in risposta a una richiesta API effettuata a un sottodominio o a un altro endpoint sul sito
  • Genera cookie utilizzando CMS
  • Genera cookie utilizzando CDN
IMPORTANT
I cookie impostati con il metodo document.cookie di JavaScript non saranno quasi mai protetti dai criteri del browser che limitano la durata dei cookie.

Il cookie FPID dovrebbe idealmente essere impostato prima di effettuare qualsiasi richiesta all'Edge Network. Tuttavia, negli scenari in cui ciò non è possibile, ECID viene ancora generato utilizzando i metodi esistenti e funge da identificatore primario finché il cookie esiste.

Supponendo che ECID sia infine interessato da un criterio di eliminazione del browser, ma FPID non lo è, FPID diventerà l'identificatore primario alla visita successiva e verrà utilizzato per seed ECID a ogni visita successiva.

L'impostazione della scadenza di un cookie è un'operazione da considerare attentamente durante l'implementazione della funzionalità FPID. Nel decidere questa opzione, è necessario considerare i paesi o le aree geografiche in cui l'organizzazione opera insieme alle leggi e alle politiche in ognuna di queste aree.

Come parte di questa decisione, puoi adottare un criterio di impostazione dei cookie a livello aziendale o diverso a seconda delle impostazioni internazionali.

Indipendentemente dall’impostazione scelta per la scadenza iniziale di un cookie, è necessario assicurarsi di includere una logica che estenda la scadenza del cookie ogni volta che si verifica una nuova visita al sito.

Esistono diversi flag di cookie che influiscono sul modo in cui i cookie vengono trattati nei diversi browser:

HTTPOnly http-only

Impossibile accedere ai cookie impostati con il flag HTTPOnly utilizzando script lato client. Ciò significa che se si imposta un flag HTTPOnly durante l'impostazione di FPID, è necessario utilizzare un linguaggio di script lato server per leggere il valore del cookie da includere in identityMap.

Se si sceglie di far leggere all'Edge Network il valore del cookie FPID, l'impostazione del flag HTTPOnly garantisce che il valore non sia accessibile da alcuno script lato client, ma non avrà alcun impatto negativo sulla capacità dell'Edge Network di leggere il cookie.

NOTE
L'utilizzo del flag HTTPOnly non ha alcun impatto sui criteri dei cookie che possono limitare la durata dei cookie. Tuttavia, si tratta comunque di un aspetto da considerare durante l'impostazione e la lettura del valore di FPID.

Secure secure

I cookie impostati con l'attributo Secure vengono inviati solo al server con una richiesta crittografata tramite il protocollo HTTPS. L’utilizzo di questo flag può contribuire a garantire che gli aggressori man-in-the-middle non possano accedere facilmente al valore del cookie. Quando possibile, è sempre consigliabile impostare il flag Secure.

SameSite same-site

L'attributo SameSite consente ai server di determinare se i cookie vengono inviati con richieste intersito. L’attributo fornisce una certa protezione contro gli attacchi di tipo cross-site forgery. Esistono tre valori possibili: Strict, Lax e None. Consulta il team interno per determinare quale impostazione è corretta per la tua organizzazione.

Se non viene specificato alcun attributo SameSite, l'impostazione predefinita per alcuni browser è ora SameSite=Lax.

Utilizzo di FPID in identityMap identityMap

Di seguito è riportato un esempio di come impostare un FPID in identityMap:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

Come con altri tipi di identità, è possibile includere FPID con altre identità all'interno di identityMap. Di seguito è riportato un esempio di FPID incluso con un CRM ID autenticato:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Se FPID è contenuto in un cookie letto dall'Edge Network quando la raccolta dati di prime parti è abilitata, è necessario acquisire solo CRM ID autenticato:

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

identityMap genererebbe una risposta di errore dall'Edge Network poiché manca l'indicatore primary per FPID. Almeno uno degli ID presenti in identityMap deve essere contrassegnato come primary.

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

La risposta di errore restituita dall’Edge Network in questo caso è simile alla seguente:

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

Impostazione di un FPID sul proprio dominio setting-fpid-domain

Oltre a impostare FPID nella mappa delle identità, puoi impostare il cookie FPID sul tuo dominio, se hai configurato una raccolta dati di prime parti CNAME.

Quando la raccolta dati di prime parti viene abilitata utilizzando CNAME, tutti i cookie per il dominio verranno inviati su richieste effettuate all'endpoint di raccolta dati.

Vengono eliminati tutti i cookie non rilevanti ai fini della raccolta dati di Adobe. Per FPID, è possibile specificare il nome del cookie FPID nella configurazione dello stream di dati. In questo caso, l'Edge Network leggerà il contenuto del cookie FPID invece di cercare FPID nella mappa delle identità.

Per utilizzare questa funzionalità, è necessario impostare FPID al livello principale del dominio anziché a un sottodominio specifico. Se viene impostato su un sottodominio, il valore del cookie non verrà inviato all'Edge Network e la soluzione FPID non funzionerà come previsto.

Gerarchia ID id-hierarchy

Quando sono presenti sia un ECID che un FPID, l'utente ECID ha la priorità nell'identificazione dell'utente. In questo modo, quando un ECID esistente è presente nell'archivio dei cookie del browser, rimane l'identificatore primario e i conteggi dei visitatori esistenti non rischiano di essere interessati. Per gli utenti esistenti, FPID non diventerà l'identità primaria fino alla scadenza di ECID o all'eliminazione a seguito di un criterio del browser o di un processo manuale.

Le identità hanno la priorità nel seguente ordine:

  1. ECID inclusi in identityMap
  2. ECID archiviato in un cookie
  3. FPID inclusi in identityMap
  4. FPID archiviato in un cookie

Migrazione agli ID dispositivo di prime parti migrating-to-fpid

Se stai eseguendo la migrazione agli ID dispositivo di prime parti da un’implementazione precedente, potrebbe essere difficile visualizzare l’aspetto della transizione a un livello basso.

Per illustrare questo processo, considera uno scenario che coinvolge un cliente che ha già visitato il tuo sito e quale impatto avrebbe una migrazione di FPID sul modo in cui tale cliente viene identificato nelle soluzioni Adobe.

Diagramma che mostra come i valori ID di un cliente vengono aggiornati tra le visite dopo la migrazione a FPID

IMPORTANT
Il cookie ECID ha sempre la priorità rispetto a FPID.
Visita
Descrizione
Prima visita
Si supponga di non aver ancora iniziato a impostare il cookie FPID. Il ECID contenuto nel cookie AMCV sarà l'identificatore utilizzato per identificare il visitatore.
Seconda visita
Rollout della soluzione FPID avviato. ECID esistente è ancora presente e rimane l'identificatore primario per l'identificazione dei visitatori.
Terza visita
Tra la seconda e la terza visita, è trascorso abbastanza tempo che ECID è stato eliminato a causa dei criteri del browser. Tuttavia, poiché FPID è stato impostato utilizzando un record A di DNS, FPID persiste. FPID è ora considerato l'ID primario ed è utilizzato per eseguire il seeding di ECID, che viene scritto sul dispositivo dell'utente finale. L’utente viene ora considerato un nuovo visitatore nelle soluzioni Adobe Experience Platform e Experience Cloud.
Quarta visita
Tra la terza e la quarta visita, è trascorso abbastanza tempo che ECID è stato eliminato a causa dei criteri del browser. Analogamente alla visita precedente, FPID rimane dovuto al modo in cui è stato impostato. Questa volta viene generato lo stesso ECID della visita precedente. L’utente viene visualizzato in tutte le soluzioni di Experience Platform e Experience Cloud come lo stesso utente della visita precedente.
Quinta visita
Tra la quarta e la quinta visita, l’utente finale ha cancellato tutti i cookie nel suo browser. Viene generato un nuovo FPID e utilizzato per la creazione di un nuovo ECID. L’utente viene ora considerato un nuovo visitatore nelle soluzioni Adobe Experience Platform e Experience Cloud.

Domande frequenti faq

Di seguito è riportato un elenco di risposte alle domande più frequenti sugli ID dispositivo di prime parti.

In che modo il seeding di un ID è diverso dalla semplice generazione di un ID?

Il concetto di seeding è univoco in quanto FPID passato a Adobe Experience Cloud viene convertito in ECID utilizzando un algoritmo deterministico. Ogni volta che lo stesso FPID viene inviato all'Edge Network, lo stesso ECID viene preimpostato da FPID.

Quando deve essere generato l’ID dispositivo di prime parti?

Per ridurre l'inflazione di visitatori potenziali, è necessario generare FPID prima di effettuare la prima richiesta tramite Web SDK. Tuttavia, se non è possibile eseguire questa operazione, verrà comunque generato un ECID per tale utente che verrà utilizzato come identificatore primario. Il FPID generato diventerà l'identificatore primario solo dopo che ECID non sarà più presente.

Quali metodi di raccolta dati supportano gli ID dispositivo di prime parti?

Attualmente solo Web SDK supporta gli ID dispositivo di prime parti.

Gli ID dispositivo di prime parti sono memorizzati su qualsiasi piattaforma o soluzione Experience Cloud?

Una volta che FPID è stato utilizzato per il seeding di un ECID, viene eliminato da identityMap e sostituito con ECID generato. FPID non è archiviato in alcuna soluzione Adobe Experience Platform o Experience Cloud.

recommendation-more-help
ad108910-6329-42f1-aa1d-5920a2b13636