Unione basata su grafico
- Argomenti:
- Analisi cross-channel
Creato per:
- Amministratore
Nell’unione basata su grafico, specifica un set di dati evento, nonché l’ID persistente (cookie) e lo spazio dei nomi dell’ID transitorio (ID persona) per tale set di dati. L’unione basata su grafico crea una nuova colonna per l’ID unione nel nuovo set di dati uniti. Quindi utilizza l’ID persistente per eseguire query sul grafo delle identità dal servizio Identity di Experience Platform, utilizzando lo spazio dei nomi specificato, per aggiornare l’ID unito.
Funzionamento dell’unione basata su grafico
L’unione esegue almeno due passaggi sui dati in un determinato set di dati.
-
Unione in tempo reale: tenta di unire ogni hit (evento) nel momento in cui arriva, utilizzando l'ID persistente per cercare l'ID transitorio per lo spazio dei nomi selezionato eseguendo una query sul grafo delle identità. Se l’ID transitorio è disponibile dalla ricerca, viene immediatamente unito.
-
Unione ripetizioni: riproduce i dati in base alle identità aggiornate dal grafico delle identità. In questa fase, gli hit da dispositivi precedentemente sconosciuti (ID persistenti) vengono uniti in quanto il grafo delle identità ha risolto l’identità per uno spazio dei nomi. La ripetizione è determinata da due parametri: frequency e lookback window. Adobe offre le seguenti combinazioni di questi parametri:
- Lookback giornaliero su una frequenza giornaliera: i dati vengono ripetuti ogni giorno con un intervallo di lookback di 24 ore. Questa opzione offre un vantaggio in quanto le ripetizioni sono molto più frequenti, ma i visitatori non autenticati devono autenticarsi lo stesso giorno in cui visitano il sito.
- Lookback settimanale su una frequenza settimanale: i dati vengono ripetuti una volta alla settimana con un intervallo di lookback settimanale (vedi opzioni). Questa opzione offre un vantaggio che consente alle sessioni non autenticate un tempo di autenticazione molto più lungo. Tuttavia, i dati non uniti che hanno meno di una settimana non vengono rielaborati fino alla successiva riproduzione settimanale.
- Lookback bisettimanale con frequenza settimanale: i dati vengono ripetuti una volta alla settimana con un intervallo di lookback bisettimanale (vedi opzioni). Questa opzione offre un vantaggio che consente alle sessioni non autenticate un tempo di autenticazione molto più lungo. Tuttavia, i dati non uniti che hanno meno di due settimane non vengono rielaborati fino alla successiva riproduzione settimanale.
- Lookback mensile su una frequenza settimanale: i dati vengono ripetuti ogni settimana con un intervallo di lookback mensile (vedi opzioni). Questa opzione offre un vantaggio che consente alle sessioni non autenticate un tempo di autenticazione molto più lungo. Tuttavia, i dati non uniti che hanno meno di un mese non vengono rielaborati fino alla successiva riproduzione settimanale.
-
Privacy: quando vengono ricevute richieste relative alla privacy, oltre a rimuovere l'identità richiesta dal set di dati di origine, è necessario annullare l'unione di tale identità tra eventi non autenticati. Inoltre, l’identità deve essere rimossa dal grafo delle identità per evitare future unioni basate su grafo per tale identità specifica.
IMPORTANT
Il processo di separazione, come parte delle richieste di accesso a dati personali, cambia all’inizio del 2025. Il processo di rimozione delle unioni corrente riavvia gli eventi utilizzando la versione più recente delle identità note. Questa riassegnazione degli eventi a un’altra identità potrebbe avere conseguenze legali indesiderate. Per risolvere questi problemi, a partire dal 2025 il nuovo processo di rimozione delle unioni aggiorna gli eventi che sono oggetto della richiesta di privacy con l’ID persistente.
I dati oltre l’intervallo di lookback non vengono riprodotti. Un visitatore deve effettuare l’autenticazione all’interno di un intervallo di lookback specificato affinché una visita non autenticata e una visita autenticata siano identificate insieme. Una volta riconosciuto, il dispositivo è live stitched da quel momento in poi.
Considera i due grafici delle identità seguenti per l'ID persistente 246
e 3579
, il modo in cui questi grafici vengono aggiornati nel tempo e come questi aggiornamenti influiscono sui passaggi nell'unione basata su grafico.
È possibile visualizzare un grafo delle identità nel tempo per un profilo specifico utilizzando Visualizzatore grafo identità. Consulta anche Logica di collegamento del servizio Identity per comprendere meglio la logica utilizzata durante il collegamento delle identità.
Passaggio 1: live stitching
L’unione live tenta di unire ogni evento, al momento della raccolta, alle informazioni note in quel momento provenienti dal grafico delle identità.
ECID
Email
246
246
246
246
246
bob.a@gmail.com
bob.a@gmail.com
246
246
bob.a@gmail.com
bob.a@gmail.com
3579
3579
3579
3579
3579
ted.w@gmail.com
ted.w@gmail.com
246
246
bob.a@gmail.com
bob.a@gmail.com
246
246
a.b@yahoo.co.uk
246
bob.ab@gmail.com
a.b@yahoo.co.uk
Puoi vedere come viene risolto l’ID unione per ogni evento. In base al tempo, all’ID persistente e alla ricerca del grafico delle identità per lo spazio dei nomi specificato (nello stesso momento).
Quando la ricerca viene risolta in più ID uniti (come per l'evento 7), viene selezionato il primo ID lessicografico restituito dal grafo delle identità (a.b@yahoo.co.uk
nell'esempio).
Passaggio 2: ripetere l’unione
A intervalli regolari (in base all’intervallo di lookback scelto), l’unione ripetuta ricalcola i dati storici in base alla versione più recente del grafico delle identità, al momento dell’intervallo.
Con un'unione di ripetizione che si verifica alle 16:30 del 2023-05-13, con una configurazione dell'intervallo di lookback di 24 ore, alcuni eventi dell'esempio vengono ricollegati (indicati da
ECID
Email
(dopo unione live)
(dopo la ripetizione 24 ore)
246
246
bob.a@gmail.com
bob.a@gmail.com
bob.a@gmail.com
246
246
bob.a@gmail.com
bob.a@gmail.com
bob.a@gmail.com
3579
3579
ted.w@gmail.com
3579
ted.w@gmail.com
3579
3579
ted.w@gmail.com
ted.w@gmail.com
ted.w@gmail.com
246
246
a.b@yahoo.co.uk
bob.a@gmail.com
a.b@yahoo.co.uk
246
246
a.b@yahoo.co.uk
246
bob.ab@gmail.com
a.b@yahoo.co.uk
a.b@yahoo.co.uk
Con la ripetizione dell’unione che si verifica alle 16:30 23-05-13, con una configurazione dell’intervallo di lookback di 7 giorni, tutti gli eventi dell’esempio vengono ricollegati.
ECID
Email
(dopo unione live)
(dopo la ripetizione 7 giorni)
246
246
246
a.b@yahoo.co.uk
246
246
bob.a@gmail.com
bob.a@gmail.com
a.b@yahoo.co.uk
246
246
bob.a@gmail.com
bob.a@gmail.com
a.b@yahoo.co.uk
3579
3579
ted.w@gmail.com
3579
ted.w@gmail.com
3579
3579
ted.w@gmail.com
ted.w@gmail.com
ted.w@gmail.com
246
246
a.b@yahoo.co.uk
bob.a@gmail.com
a.b@yahoo.co.uk
246
246
a.b@yahoo.co.uk
246
bob.ab@gmail.com
a.b@yahoo.co.uk
a.b@yahoo.co.uk
Passaggio 3: richiesta di accesso a dati personali
Quando ricevi una richiesta di accesso a dati personali, l’ID unione viene eliminato in tutti i record relativi all’oggetto della richiesta di accesso a dati personali.
La tabella seguente rappresenta gli stessi dati di cui sopra, ma mostra l’effetto che ha una richiesta di accesso a dati personali (ad esempio alle 18:00 del 5 maggio 2023) per gli eventi di esempio.
ECID
Email
246
246
a.b@yahoo.co.uk
246
246
246
a.b@yahoo.co.uk
246
246
246
a.b@yahoo.co.uk
246
3579
3579
ted.w@gmail.com
3579
3579
3579
ted.w@gmail.com
3579
246
246
a.b@yahoo.co.uk
246
246
246
a.b@yahoo.co.uk
246
bob.ab@gmail.com
246
Prerequisiti
I seguenti prerequisiti si applicano in modo specifico all’unione basata su grafico:
- Il set di dati dell'evento in Adobe Experience Platform, a cui si desidera applicare l'unione, deve avere una colonna che identifica un visitatore su ogni riga, l'ID persistente. Ad esempio, un ID visitatore generato da una libreria Adobe Analytics AppMeasurement o un ECID generato dal servizio Experience Platform Identity.
- Anche l'ID persistente deve essere definito come identità nello schema.
- Il grafo delle identità di Experience Platform Identity Service deve avere uno spazio dei nomi (ad esempio
Email
oPhone
) da utilizzare durante l'unione per risolvere il ID transitorio. Per ulteriori informazioni, consulta Experience Platform Identity Service.
Limitazioni
Le seguenti limitazioni si applicano in modo specifico all’unione basata su grafico:
-
Le marche temporali non vengono prese in considerazione quando si esegue una query per l’ID transitorio utilizzando lo spazio dei nomi specificato. Pertanto, è possibile che un ID persistente sia unito a un ID transitorio di un record che ha una marca temporale precedente.
-
Negli scenari di dispositivi condivisi, in cui lo spazio dei nomi nel grafico contiene più identità, viene utilizzata la prima identità lessicografica. Se i limiti e le priorità dello spazio dei nomi sono configurati come parte del rilascio delle regole di collegamento del grafico, viene utilizzata l’identità dell’ultimo utente autenticato. Per ulteriori informazioni, vedere Dispositivi condivisi.
-
Esiste un limite rigido di tre mesi per la retrocompilazione delle identità nel grafico delle identità. Puoi utilizzare le identità di backfill nel caso in cui non utilizzi un’applicazione di Experience Platform, come Real-time Customer Data Platform, per compilare il grafico delle identità.
-
Si applicano le protezioni del servizio Identity. Vedi, ad esempio, i seguenti limiti statici:
- Numero massimo di identità in un grafico: 50.
- Numero massimo di collegamenti a un’identità per una singola acquisizione batch: 50.
- Numero massimo di identità in un record XDM per l’acquisizione del grafico: 20.
- Numero minimo di identità in un record XDM per l’acquisizione del grafico: 2.