Utilizzare gli ID dispositivo di prime parti in Web SDK

Adobe Experience Platform Web SDK assegna ID Adobe Experience Cloud (ECID) ai visitatori del sito Web che utilizzano i cookie per monitorare il comportamento degli utenti. Per risolvere le restrizioni del browser relative alla durata dei cookie, puoi impostare e gestire gli identificatori dei tuoi dispositivi, noti come ID dispositivo di prime parti (FPID, first party device ID).

Prerequisiti prerequisites

Prima di iniziare, assicurati di conoscere il funzionamento dei dati di identità nel Web SDK, inclusi gli ECID e identityMap. Per ulteriori informazioni, vedere la panoramica sui dati di identità nel Web SDK.

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

Edge Network accetta solo ID conformi al formato UUIDv4. Gli ID dispositivo non in formato UUIDv4 verranno rifiutati.

Imposta il cookie FPID utilizzando il tuo server set-cookie-server

Quando imposti un cookie tramite il tuo server, puoi utilizzare diversi metodi per impedire che il cookie sia soggetto a restrizioni a causa dei criteri del browser:

Inoltre, è sempre necessario impostare il cookie FPID sotto il record A del dominio.

Quando impostare il cookie when-to-set-cookie

Il cookie FPID dovrebbe idealmente essere impostato prima di effettuare qualsiasi richiesta ad 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.

Impostazione della scadenza per il cookie set-expiration

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.

Impatto dei flag dei cookie cookie-flag-impact

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 fare in modo che Edge Network legga 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à di Edge Network di leggere il cookie.

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.

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:

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.

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.

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

È possibile utilizzare FPIDs in due modi:

Metodo 1: configurare un CNAME per le chiamate Web SDK e impostare un cookie ID di prime parti nello stream di dati setting-cookie-datastreams

Per impostare un cookie FPID dal proprio dominio, è necessario configurare il proprio CNAME (nome canonico) per le chiamate di Web SDK, quindi abilitare la funzionalità First Party ID Cookie nella configurazione dello stream di dati.

Passaggio 1. Configurare un CNAME per il dominio di distribuzione di Web SDK

Un record CNAME nel DNS consente di creare un alias da un nome di dominio a un altro. Questo può aiutare a far apparire i servizi di terze parti come se facessero parte del tuo dominio, rendendo così i loro cookie simili ai cookie di prima parte.

Esempio

Si supponga di voler implementare Web SDK nel sito Web mywebsite.com. Il Web SDK invia i dati ad Edge Network al dominio edge.adobedc.net.

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.

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

Passaggio 2. Abilita la funzionalità ​​ Cookie ID di prime parti ​​ per lo stream di dati

Dopo aver configurato il tuo CNAME, devi abilitare l'opzione Cookie ID di prime parti per il tuo flusso di dati. Questa impostazione indica ad Edge Network di fare riferimento a un cookie specificato durante la ricerca di un ID dispositivo di prime parti, invece di cercare questo valore nella mappa identità.

Consulta la documentazione sulla configurazione dello stream di dati per scoprire come impostare lo stream di dati.

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

Quando si abilita questa impostazione, è necessario fornire il nome del cookie in cui è prevista la memorizzazione di FPID.

Metodo 2: utilizzare gli FPID in identityMap identityMap

In alternativa all'archiviazione di FPID nel proprio cookie, è possibile inviare FPID ad Edge Network tramite la mappa delle identità.

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 da Edge Network quando è abilitata la raccolta dati di prime parti, è necessario acquisire solo CRM ID autenticato:

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

identityMap genererebbe una risposta di errore da parte di 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 da 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}"
    }
}

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 ad 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 soluzione Platform o 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.