Domande frequenti sui feed di dati

Domande frequenti sui feed di dati.

I nomi dei feed devono essere univoci?

I nomi dei file di feed dati sono costituiti dall’ID suite di rapporti e dalla data. Tutti e due i feed configurati per lo stesso RSID e la stessa data hanno lo stesso nome file. Se tali feed vengono inviati nella stessa posizione, un file sovrascrive l’altro. Per evitare la sovrascrittura di un file, non è possibile creare un feed che possa sovrascrivere un feed esistente nella stessa posizione.

Se si tenta di creare un feed quando ne esiste un altro con lo stesso nome di file, viene visualizzato il seguente messaggio:

Se ricevi questo errore, considera le seguenti soluzioni alternative:

• Modificare il percorso di consegna
• Se possibile, modifica le date
• Se possibile, modifica la suite di rapporti

Quando vengono elaborati i dati?

Prima di elaborare i dati su base oraria o giornaliera, i feed di dati attendono che tutti gli hit che hanno inserito la raccolta dati entro l’intervallo di tempo (giorno o ora) siano stati scritti in data warehouse. In seguito, i feed di dati raccolgono i dati con marche temporali che rientrano nell’intervallo temporale, li comprime e li invia tramite FTP. Per i feed orari, in genere i file vengono scritti in data warehouse entro 15-30 minuti dopo l'ora, ma non esiste un periodo di tempo impostato. Se non vi erano dati con marche temporali che rientrano nell’intervallo temporale, il processo prova nuovamente l’intervallo temporale successivo. Il processo di feed dati corrente utilizza il campo date_time per determinare quali hit appartengono all’ora. Questo campo è basato sul fuso orario della suite di rapporti.

Qual è la differenza tra le colonne con un prefisso post_ e le colonne senza un prefisso post_?

Le colonne senza il prefisso post_ contengono i dati esattamente come sono stati inviati alla raccolta dati. Le colonne con un prefisso post_ contengono il valore dopo l’elaborazione. Esempi che possono modificare un valore sono la persistenza delle variabili, le regole di elaborazione, le regole VISTA, la conversione di valuta o altri Adobi logici lato server. Se possibile, Adobe consiglia di utilizzare la versione post_ di una colonna.

Se una colonna non contiene una versione post_ (ad esempio, visit_num), può essere considerata una colonna post.

Come vengono gestiti i feed di dati per la distinzione tra maiuscole e minuscole?

In Adobe Analytics, la maggior parte delle variabili viene considerata senza distinzione tra maiuscole e minuscole a scopo di reporting. Ad esempio, "neve", "neve", "NEVE" e "sNow" sono tutti considerati allo stesso valore. La distinzione tra maiuscole e minuscole viene mantenuta nei feed di dati.

Se vedi diverse varianti di maiuscole e minuscole dello stesso valore tra colonne non post e post (ad esempio, "neve" nella colonna pre e "neve" nella colonna post), l’implementazione utilizza sia valori maiuscoli che minuscoli nel sito. La variazione di maiuscole e minuscole nella colonna post è stata precedentemente passata e memorizzata nel cookie virtuale o è stata elaborata più o meno nello stesso momento per quella suite di rapporti.

I bot vengono filtrati dalle regole bot di Admin Console incluse nei feed di dati?

I feed di dati non includono bot filtrati da regole bot della console di amministrazione.

Perché visualizzo più valori 000 nella colonna dei feed di dati event_list o post_event_list?

Alcuni editor di fogli di calcolo, in particolare Microsoft Excel, arrotondano automaticamente numeri grandi. La colonna event_list contiene molti numeri delimitati da virgole e a volte Excel ne considera un numero elevato. Arrotonda le ultime diverse cifre a 000.

Adobe consiglia di non aprire automaticamente i file hit_data.tsv in Microsoft Excel. Utilizzare invece la finestra di dialogo Importa dati di Excel e assicurarsi che tutti i campi siano trattati come testo.

Perché mancano informazioni nella colonna del dominio per alcuni gestori?

Alcuni gestori di dispositivi mobili (come T-Mobile e O1) non forniscono più informazioni di dominio per le ricerche DNS inverse. Pertanto, tali dati non sono disponibili per la generazione di rapporti sul dominio.

Perché non posso estrarre file "Orari" da dati che hanno più di 7 giorni?

Per i dati che hanno più di 7 giorni, i file "Ogni ora" di un giorno vengono combinati in un unico file "Giornaliero".

Esempio: Il 9 marzo 2021 è stato creato un nuovo feed di dati e i dati dal 1° gennaio 2021 al 9 marzo vengono consegnati come "Orario". Tuttavia, i file "Ogni ora" prima del 2 marzo 2021 sono combinati in un unico file "Giornaliero". Puoi estrarre i file "Ogni ora" solo dai dati che hanno meno di 7 giorni dalla data di creazione. In questo caso, dal 2 marzo al 9 marzo.

Qual è l’impatto del risparmio giornaliero sui feed di dati orari?

Per alcuni fusi orari, l'ora cambia due volte all'anno a causa delle definizioni dell'ora legale (DST). I feed di dati rispettano il fuso orario per il quale è configurata la suite di rapporti. Se il fuso orario per la suite di rapporti non utilizza DST, la consegna dei file continua normalmente come qualsiasi altro giorno. Se il fuso orario della suite di rapporti è quello che utilizza DST, la consegna dei file viene modificata per l’ora in cui si verifica la modifica dell’ora (di solito 2:00).

Quando si eseguono transizioni di tempo STD -> DST ("Primavera avanti"), il cliente riceve solo 23 file. L’ora saltata nella transizione DST viene omessa. Ad esempio, se la transizione si verifica alle 2 del mattino, ottengono un file per l’ora 1:00 e un file per l’ora 3:00. Non c'è alcun file 2:00 perché, alle 2:00 STD, diventa 3:00 DST.

Quando si eseguono transizioni DST -> STD, ("Fall Back"), il cliente ottiene 24 file. Tuttavia, l'ora della transizione include in realtà due ore di dati. Ad esempio, se la transizione si verifica alle 2:00, il file per 1:00 viene ritardato di un'ora, ma contiene dati per due ore. Contiene dati da 1:00 DST a 2:00 STD (che sarebbe stato 3:00 DST). Il file successivo inizia alle 2:00 STD.

In che modo Analytics gestisce gli errori di trasferimento FTP?

Se un trasferimento FTP non riesce (a causa di un accesso negato, connessione persa, errore fuori quota o altro problema), Adobe tenta di connettersi e inviare automaticamente i dati fino a tre volte separate. Se gli errori persistono, il feed viene contrassegnato come non riuscito e viene inviata una notifica e-mail.

Se un trasferimento ha esito negativo, è possibile eseguire nuovamente un processo fino a quando non ha esito positivo.

In caso di problemi durante il recupero del feed di dati dal sito FTP, consulta Risoluzione dei problemi relativi ai processi.

Come faccio a rimandare un lavoro?

Dopo aver verificato/corretto il problema di consegna, esegui nuovamente il processo per ottenere i file.

Qual è l’impostazione BucketOwnerFullControl per i feed di dati Amazon S3?

​​BucketOwnerFullControlfornisce diritti tra account diversi per creare oggetti in altri bucket.

Il caso d'uso comune per Amazon S3 è che il proprietario dell'account Amazon Web Services (AWS) crea un bucket, quindi crea un utente che dispone dell'autorizzazione per creare oggetti in quel bucket e quindi fornisce le credenziali per tale utente. In questo caso, gli oggetti di un utente appartengono allo stesso account e il proprietario dell'account ha implicitamente il pieno controllo dell'oggetto (lettura, eliminazione e così via). Questo processo è simile al funzionamento della consegna FTP.

AWS consente inoltre a un utente di creare oggetti in un bucket che appartiene a un account utente diverso. Ad esempio, due utenti AWS, userA e userB, non appartengono allo stesso account AWS ma desiderano creare oggetti in altri bucket. Se l’utente A crea un bucket denominato "bucketA", può creare un criterio per i bucket che consente esplicitamente all’utente B di creare oggetti in bucketA anche se l’utente non possiede il bucket. Questo criterio può essere vantaggioso perché non richiede agli utenti A e userB di scambiare le credenziali. Al contrario, userB fornisce a userA il loro numero di account, e userA crea una policy di bucket che sostanzialmente dice "lascia che l'utente B crei oggetti in bucketA".

Tuttavia, gli oggetti non ereditano le autorizzazioni dal bucket principale. Pertanto, se userB carica un oggetto nel bucket dell'utente A, userB "possiede" ancora tale oggetto e, per impostazione predefinita, a userA non vengono concesse autorizzazioni per tale oggetto anche se l'utente A è proprietario del bucket. UserB deve concedere esplicitamente le autorizzazioni userA perché userB è ancora il proprietario dell'oggetto. Per concedere questa autorizzazione, userB deve caricare l'oggetto con un ACL BucketOwnerFullControl, che specifica che al proprietario del bucket (userA) sono concesse autorizzazioni complete per l'oggetto (lettura, scrittura, eliminazione e così via), anche se l'oggetto è "di proprietà" di userB.