Connettore di origine di Adobe Analytics per i dati della suite di rapporti
Adobe Experience Platform consente di acquisire dati Adobe Analytics tramite il connettore di origine Analytics. Il connettore trasmette i dati della suite di rapporti in un set di dati Platform in tempo reale, convertendoli in formato XDM.
Funzionamento del connettore di origine di Analytics
Continui a utilizzare l’implementazione di Adobe Analytics esistente, come AppMeasurement o l’estensione tag Adobe Analytics, per raccogliere dati nelle suite di rapporti. Il connettore di origine non modifica la modalità di raccolta o di creazione di rapporti su tali dati. Una volta che i dati raggiungono i server di raccolta dati di Analytics, il connettore ne acquisisce una copia.
Questa copia è una forma parzialmente elaborata di ogni hit, nota come mid-values. Analytics produce valori medi dopo la pre-elaborazione (ad esempio, le regole di elaborazione) ma prima dell’elaborazione a livello di visita e visitatore. Di conseguenza, non includono il contesto post-elaborazione, ad esempio il numero di visita. L’hit originale continua attraverso la pipeline per essere scritto come di consueto nella suite di rapporti.
Il connettore trasmette questi valori medi in un set di dati in Experience Platform in tempo reale. Dal data lake, i dati sono disponibili per Query Service e altre applicazioni di data discovery e possono arricchire Real-Time Customer Profile.
Per informazioni dettagliate su come Analytics raccoglie ed elabora i dati, inclusa la fase del valore intermedio, vedere Ordine di elaborazione per i dati in Adobe Analytics.
Mappatura dei campi di Adobe Analytics su XDM
Quando crei una connessione di origine nell’interfaccia utente di Experience Platform, i campi di Analytics vengono mappati automaticamente su XDM e acquisiti in un set di dati di Platform. Per istruzioni, consulta l’esercitazione sul connettore di origine di Analytics.
Per informazioni dettagliate sulla mappatura campi tra Analytics e Experience Platform, consulta la guida alla mappatura campi di Adobe Analytics.
Identificatori primari nei dati di Analytics
Ogni hit dal connettore di origine di Analytics contiene un identificatore primario che dipende dall’esistenza di un ECID o un AAID. Se è presente un ECID, questo viene designato come identificatore primario. Se è presente un AAID, questo viene designato come primario.
La tabella seguente fornisce ulteriori informazioni sui campi di identità nei dati di Analytics.
s_vi. Nonostante ciò, viene creato un AAID anche se il cookie s_vi non è presente. AAID è rappresentato dalle colonne post_visid_high e post_visid_low nei feed dati di Analytics. In un dato evento, il campo AAID contiene una singola identità che può essere uno dei diversi tipi descritti nell’ordine delle operazioni per gli ID di Analytics. Nota: all’interno di un’intera suite di rapporti, un AAID può contenere diversi tipi tra gli eventi.mcvisid nei feed dati di Analytics. Per ulteriori informazioni su ECID, consulta la panoramica ECID. Per informazioni sul funzionamento di ECID con Analytics, consulta il documento su Richieste Analytics ed Experience Cloud ID.visitorID nell’implementazione di Analytics. Se AACUSTOMID è presente, AAID è basato su AACUSTOMID perché AACUSTOMID supera tutti gli altri identificatori come definito dall’ordine delle operazioni per gli ID di Analytics.Trattamento delle identità da parte dell’origine Analytics
L’origine di Analytics trasmette queste identità ad Experience Platform in formato XDM come:
endUserIDs._experience.aaid.idendUserIDs._experience.mcid.idendUserIDs._experience.aacustomid.id
Questi campi non sono contrassegnati come identità. Le stesse identità (se presenti nell’evento) vengono invece copiate in identityMap di XDM come coppie chiave-valore:
{ "key": "AAID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "ECID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "AACUSTOMID", "value": [ { "id": "<identity>", "primary": false } ] }
Quando l’identità o le identità vengono copiate in identityMap, anche endUserIDs._experience.mcid.namespace.code viene impostato sullo stesso evento:
- Se AAID è presente,
endUserIDs._experience.aaid.namespace.codeè impostato su “AAID”. - Se ECID è presente,
endUserIDs._experience.mcid.namespace.codeè impostato su “ECID”. - Se AACUSTOMID è presente,
endUserIDs._experience.aacustomid.namespace.codeè impostato su “AACUSTOMID”.
Nella mappa di identità, se ECID è presente, viene contrassegnato come identità primaria dell’evento. In questo caso, AAID può essere basato su ECID a causa del periodo di tolleranza del servizio Identity. In caso contrario, AAID è contrassegnato come identità primaria dell’evento. AACUSTOMID non viene mai contrassegnato come ID primario dell’evento. Tuttavia, se AACUSTOMID è presente, AAID è basato su AACUSTOMID a causa dell’ordine delle operazioni di Experience Cloud.
Precisione della marca temporale dell’hit e ordinamento degli eventi
Il connettore riceve i dati di Analytics come valori medi, che contengono timestamp di hit di secondo livello. Poiché Analytics registra il tempo solo con precisione di secondo livello e non tiene traccia della tempistica dei secondi secondari, l’ordine degli hit raccolti nello stesso secondo non è deterministico. Di conseguenza, l’ordine degli eventi dello stesso secondo acquisiti tramite il connettore può differire dall’ordine mostrato nel reporting di Analytics.
Customer Journey Analytics risolve i timestamp in millisecondi, ma i dati originati da Analytics popolano solo interi secondi. Il solo timestamp non può quindi stabilire l’ordine relativo degli eventi che condividono lo stesso secondo. Ciò è più evidente quando più hit vengono raccolti nello stesso secondo (ad esempio, una visualizzazione di pagina e un hit di Adobe Target (A4T)).
Per ulteriori informazioni sulla precisione delle marche temporali di Analytics, consulta la variabile timestamp di Adobe Analytics e la documentazione Hit depth. Per i campi di marca temporale mappati dal connettore a XDM (hit_time_gmt e post_cust_hit_time_gmt), consulta la guida alla mappatura dei campi di Adobe Analytics.
Le opzioni per la precisione della marca temporale includono:
- Accettare differenze di ordinamento minori nello stesso secondo. Per la maggior parte dei rapporti, l’effetto è limitato agli eventi che condividono lo stesso secondo e non influisce sulle metriche aggregate. Questo è l’approccio consigliato, anche per scenari misti di visualizzazione pagina e Adobe Target (A4T).
- Per i casi d’uso sensibili all’ordine, preferisci il Web SDK. L’invio di dati tramite Adobe Experience Platform Web SDK direttamente in Experience Platform e Customer Journey Analytics consente di mantenere la precisione della marca temporale dei secondi secondari (millisecondi) ed evita la rielaborazione di Analytics. Questo approccio è consigliato quando l’ordine degli eventi è importante.
Latenza e retrocompilazione dei dati
La latenza prevista per i dati di Analytics su Experience Platform è descritta nella tabella seguente. La latenza varia a seconda della configurazione del cliente, dei volumi di dati e delle applicazioni consumer. Ad esempio, se l’implementazione di Analytics è configurata con A4T, la latenza della pipeline aumenta di 5-10 minuti.
Per ulteriori informazioni sulle latenze di Customer Journey Analytics, vedere: Guardrail Customer Journey Analytics.
Il valore predefinito della retrocompilazione di Analytics per le sandbox di produzione è 13 mesi. Per i dati di Analytics nelle sandbox non di produzione, la retrocompilazione è impostata su tre mesi. Il limite di 10 miliardi di eventi menzionato nella tabella precedente è strettamente in relazione alla latenza prevista.
Quando crei un flusso di dati di origine Analytics in una sandbox di produzione, vengono creati due flussi di dati:
- Un flusso di dati che esegue una retrocompilazione di 13 mesi dei dati storici della suite di rapporti nel data lake. Questo flusso di dati termina quando la retrocompilazione è completa.
- Un flusso di dati che invia dati live al data lake e al profilo cliente in tempo reale. Questo flusso di dati viene eseguito in modo continuo.
Best practice
Segui queste best practice per evitare di superare i diritti di licenza e di travolgere le metriche di archiviazione totale e ricchezza dei dati:
- Imposta Experience Event Dataset Retention Time-To-Live (TTL) all’inizio per ottimizzare la gestione del ciclo di vita dei dati e l’efficienza dello storage. Per ulteriori dettagli, consulta la guida su gestione della conservazione dei set di dati di Experience Event nel data lake tramite TTL.
- Quando crei un flusso di dati di origine Analytics, inizia configurando il connettore per acquisire i dati solo nel data lake. Dopo aver confermato che il flusso di dati funziona, puoi abilitare l’acquisizione del profilo per il set di dati. Questo approccio funziona al meglio quando i filtri di riga e colonna riducono efficacemente il volume di dati. Per ulteriori informazioni, consulta la documentazione sulla connessione di Adobe Analytics ad Experience Platform.