Puoi utilizzare una visualizzazione Flow con la dimensione Tipo di dispositivo mobile.
L’esempio per il tipo di dispositivo mobile illustrato qui sopra consente di vedere come le persone passano a tipi di dispositivi mobili e desktop. Tuttavia, non ti consente di distinguere tra browser desktop e browser mobili. Se desideri questa informazione, puoi creare una variabile personalizzata (ad esempio, prop o eVar) che registra se l’esperienza si verifica su un browser desktop, un browser mobile o un’app mobile. Puoi quindi creare un diagramma di flusso come descritto in precedenza, utilizzando la variabile personalizzata invece della dimensione Tipo di dispositivo mobile. Questo metodo fornisce una visualizzazione leggermente diversa del comportamento tra dispositivi diversi.
L’unione tra dispositivi di CDA si verifica in due processi simultanei.
Il primo processo è denominato “live stitching” e avviene durante il flusso dei dati in Adobe Analytics. Durante il live stitching, CDA fa del suo meglio per aggiornare i dati a livello di persona. Ma se la persona è sconosciuta al momento del live stitching, CDA la rappresenta mediante l’ID visitatore.
Il secondo processo è denominato “ripetizione”. Durante la ripetizione, CDA torna indietro nel tempo e aggiorna i dati storici, ove possibile, all’interno di una finestra temporale specificata. Questo finestra temporale può essere di 1 giorno o 7 giorni, a seconda della configurazione di CDA. Durante la ripetizione, CDA tenta di aggiornare i risultati in cui la persona era precedentemente sconosciuta.
Se utilizzi un grafo di dispositivi, Adobe mantiene le mappature del grafo di dispositivi per circa 6 mesi. Un ECID che non ha attività per più di sei mesi viene rimosso dal grafo. I dati già uniti in CDA non vengono influenzati, ma gli hit successivi per tale ECID vengono trattati come una nuova persona.
Adobe tratta gli hit con marca temporale come se fossero stati ricevuti al momento della marca temporale, non quando Adobe ha ricevuto l’hit. Gli hit con marca temporale superiore a 1 mese non vengono mai uniti in quanto non rientrano nell’intervallo utilizzato da Adobe per le unioni.
L’utilizzo di un ID visitatore personalizzato è un metodo legacy per collegare gli utenti a dispositivi diversi. Con un ID visitatore personalizzato, utilizzi la variabile visitorID
per impostare esplicitamente l’ID utilizzato per la logica del visitatore. La variabile visitorID
sostituisce gli ID presenti basati su cookie.
Gli ID visitatore personalizzati hanno diversi effetti collaterali indesiderati che CDA supera o riduce al minimo. Ad esempio, la metodologia dell’ID visitatore personalizzato non ha la funzionalità di ripetizione. Se un utente si autentica nel mezzo di una visita, la prima parte della visita viene associata a un ID visitatore diverso rispetto all’ultima parte della visita. Gli ID visitatore separati generano un’inflazione di visite e visitatori. CDA aggiorna i dati storici in modo che gli hit non autenticati appartengano alla persona corretta.
I clienti che già utilizzano un ID visitatore personalizzato possono effettuare l’aggiornamento a CDA senza apportare alcuna modifica all’implementazione. La variabile visitorID
viene ancora utilizzata nella suite di rapporti sorgente. Tuttavia, CDA ignora la variabile visitorID
nella suite di rapporti virtuali se un utente si autentica.
In alcune situazioni è possibile che più persone accedano dallo stesso dispositivo. Ad esempio, un dispositivo condiviso da casa, PC condivisi in una libreria o un chiosco in un punto vendita.
In alcune situazioni, un singolo utente può essere associato a un numero elevato di ECID. Questo può verificarsi se il singolo utente utilizza molti browser o app e può aggravarsi se cancella frequentemente i cookie o utilizza la modalità di navigazione privata o in incognito del browser.
Entrambe le metriche Persone e Visitatori univoci hanno lo scopo di contare i visitatori distinti (i singoli utenti). Considera comunque la possibilità che 2 dispositivi diversi possano appartenere alla stessa persona. CDA mappa i 2 dispositivi sulla stessa persona, mentre i 2 dispositivi sono registrati come 2 “Visitatori univoci” distinti al di fuori di CDA.
Queste due metriche sono approssimativamente equivalenti tra loro. Si verificano differenze tra le 2 metriche quando:
Per ulteriori esempi e dettagli su come funziona, vedi Dispositivi univoci.
Sì. Analysis Workspace utilizza l’API 2.0 per richiedere dati dai server Adobe e puoi visualizzare le chiamate API utilizzate da Adobe per creare i rapporti:
Sì. Se un singolo utente invia hit da due dispositivi distinti entro il timeout di visita della suite di rapporti virtuali (30 minuti per impostazione predefinita), questi vengono uniti nella stessa visita.
Entrambi gli identificatori sono calcolati da Adobe al momento dell’esecuzione del rapporto, ossia tramite elaborazione al momento del rapporto. L’elaborazione al momento del rapporto non è compatibile con Data Warehouse, feed di dati o altre funzioni di esportazione offerte da Adobe.
Per passare dal grafo di dispositivi all’unione basata sui campi o viceversa, rivolgiti all’Assistenza clienti. Tuttavia, questo cambiamento può richiedere un paio di settimane o più e i dati uniti storici del metodo precedente andranno perduti.
CDA richiama gli elementi dimensione della variabile di identificazione prima che vengano ottimizzati per il reporting. Non devi preoccuparti di limiti univoci per gli scopi di CDA. Tuttavia, se hai provato a utilizzare la variabile prop o eVar in un progetto Workspace, puoi ancora visualizzare l’elemento dimensione (Traffico ridotto).
A decorrere dal 1° maggio 2022, ogni nuova implementazione di CDA sarà limitata a un massimo di tre ID di suite di rapporti (RSID) per cliente. CDA non unisce le suite di rapporti. Ogni suite di rapporti abilitata per CDA deve essere di natura cross-device (contenente dati provenienti da più superfici come web per desktop, web per dispositivi mobili, app per dispositivi mobili, ecc.).
No. Per lo stesso ID organizzazione, CDA può essere abilitato in una sola regione.
Il vantaggio di una ripetizione con intervallo di lookback di 7 giorni è che CDA è in grado di tornare indietro nel tempo per tentare di associare eventi precedentemente anonimi a una persona che ha successivamente effettuato l’accesso in quei 7 giorni. L’intervallo di lookback di 7 giorni presenta tuttavia i seguenti svantaggi: 1) la ripeditione viene eseguita una sola volta alla settimana; 2) i 7 giorni più recenti sono soggetti a modifiche.
I vantaggi di un intervallo di lookback di 1 giorno sono i seguenti: 1) la ripetizione viene eseguita ogni giorno; e 2) solo il giorno immediatamente precedente è soggetto a modifiche. Lo svantaggio dell’intervallo di lookback di 1 giorno è che CDA è in grado di tornare indietro solo di 1 giorno per tentare di associare eventi precedentemente anonimi a una persona che ha effettuato l’accesso il girono precedente.
Se un cliente effettua un downgrade da Ultimate, non avrà più accesso ai dati uniti. Tutti i dati uniti in precedenza verranno rimossi. Ciò significa che le suite di rapporti virtuali di CDA non rifletteranno alcuna unione tra dispositivi diversi. I dati saranno simili a quelli della suite di rapporti originale senza dati uniti.
CDA utilizza una complessa pipeline di elaborazione parallela, con diversi componenti dipendenti. È previsto uno scostamento di circa 1% per il numero totale di hit tra la suite di rapporti originale e la suite di rapporti virtuali di CDA.
Il valore della metrica “Persone identificate” può essere leggermente superiore se per il valore prop/eVar dell’identificatore si verifica una collisione hash.
Per le unioni basate sui campi, la variabile personalizzata dell’identificatore distingue tra maiuscole e minuscole. Il valore della metrica “Persone identificate” può essere significativamente più alto se i valori dell’identificatore usano maiuscole e minuscole diverse. Ad esempio, se per una stessa persona vengono trasmessi i valori bob
e Bob
, CDA li interpreta come due valori distinti.
Questa situazione si verifica solitamente quando un visitatore genera hit autenticati e non autenticati nella finestra di reporting. Il visitatore appartiene sia a “Non identificato” che a “Identificato” nella dimensione Stato identificato, causando l’attribuzione di hit non identificati a un identificatore. Questo scenario può cambiare dopo esecuzioni di Ripetizione in base alla frequenza di ripetizione e al tasso di successo.