Al momento stiamo eseguendo la migrazione di un sottoinsieme di tipi di report da report offline a report istantanei. Una volta eseguita la migrazione di un utente, le risposte di queries.list includeranno i report istantanei esistenti. Per ulteriori informazioni, leggi il post del nostro blog.

Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice per i report

Creare prima nuovi report nell'interfaccia utente

I report sono soggetti a una serie di restrizioni e requisiti relativi a tipi di report, filtri, dimensioni e metriche. Queste limitazioni sono applicate nell'API, restituendo un errore HTTP 400. Per evitare errori durante la creazione dei report, ti consigliamo innanzitutto di creare nuovi report nell'interfaccia utente di Display & Video 360.

Dopo aver creato il report, fai clic sulla funzionalità"Prova questa API" nella pagina della documentazione di riferimento per eseguire una queries.get della risorsa Query. Puoi utilizzare il JSON restituito per creare report futuri.

Utilizzare metriche e filtri specifici per il tipo di report

Alcuni valori di metrica e filtro sono specifici di determinati tipi di report. Oltre a creare prima i report nell'interfaccia utente, puoi anche identificare le metriche e i filtri appartenenti a determinati valori ReportType in base al relativo valore dell'API Bid Manager.

Ecco alcuni modi per identificare i filtri e i valori delle metriche pertinenti dell'API Bid Manager. Questa tabella non è un elenco esaustivo dei filtri e delle metriche che possono essere utilizzati in questi tipi di report. Non tutti i valori possono essere utilizzati insieme in un singolo report.

`ReportType`	Filtri e metriche pertinenti
`INVENTORY_AVAILABILITY`	Filtri con prefisso `FILTER_TRUEVIEW_IAR`.
`YOUTUBE`	Filtri con prefisso `FILTER_TRUEVIEW`, esclusi quelli con prefisso `FILTER_TRUEVIEW_IAR`. Metriche con prefisso `METRIC_TRUEVIEW`.
`GRP`	Metriche con prefisso `METRIC_GRP`.
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	Filtri con prefisso `FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED`. Metriche con prefisso `METRIC_PROGRAMMATIC_GUARANTEED`.
`REACH`	Metriche con prefisso `METRIC_UNIQUE_REACH`.
`UNIQUE_REACH_AUDIENCE`	Metriche con prefisso `METRIC_UNIQUE_REACH`.

Salvare e riutilizzare i report

Ti consigliamo di creare e salvare i report per le query che esegui regolarmente, in quanto l'inserimento e l'eliminazione più volte dello stesso report comporta uno spreco di risorse. L'utilizzo dei valori Range impostati, come PREVIOUS_DAY o LAST_7_DAYS, nel campo dataRange rende i report più riutilizzabili.

Pianificare i report

I report ad hoc o una tantum possono sprecare risorse perché vengono eseguiti singolarmente e possono essere eseguiti su un set di dati incompleto. I report pianificati sfruttano al meglio le risorse di reporting perché vengono eseguiti in blocco e non viene eseguito fino al termine dell'elaborazione dei dati del giorno precedente. Per ulteriori dettagli, consulta i campi di pianificazione disponibili.

Combinare report simili

Se generi regolarmente report con metriche e intervalli di date identici per inserzionisti o partner diversi, ti consigliamo di combinare i report per ottimizzare il volume dei report.

Puoi combinare report simili aggiungendo i filtri di tutti i report e aggiungendo tutti i tipi di filtro come dimensioni. Dopo la generazione, puoi suddividere le righe del report risultante in base ai valori di filtro originali per produrre i report originali.

Considera le quote di reporting

L'uso responsabile della funzionalità di generazione di report di Display & Video 360 viene applicato tramite le seguenti quote di utilizzo a livello di prodotto.

Esecuzioni giornaliere di report ad hoc

Limita il numero di report ad hoc che un utente può eseguire in un periodo di 24 ore. Per rimanere entro questa quota:

Combinare report simili per ridurne il volume.
Pianifica report ad hoc ricorrenti per ridurre specificamente il volume di report ad hoc.
Disattiva gli script API non necessari.

Report pianificati attivi

Limita il numero di report che un utente può avere attivamente pianificati in un determinato momento. Per rimanere entro questa quota:

Combina report pianificati simili per ridurre il numero complessivo di report pianificati.
Disattiva i report pianificati non necessari.
Disattiva gli script API non necessari.

Report simultanei

Limita il numero di report che un utente può eseguire contemporaneamente. Per rimanere entro questa quota:

Pianifica l'esecuzione periodica di report.
Disattiva gli script API non necessari.
Monitora l'esecuzione dei report eseguendo il polling utilizzando la logica di backoff esponenziale.

Se hai ottimizzato l'implementazione dei report e continui a superare la quota assegnata, contatta l'assistenza di Display & Video 360 utilizzando il modulo di contatto.

Utilizza il backoff esponenziale quando esegui il polling per lo stato del report

Non è possibile prevedere quanto tempo sarà necessario per eseguire un report. Il periodo di tempo può variare da secondi a ore, a seconda di molti fattori, tra cui ad esempio l'intervallo di date e la quantità di dati da elaborare. Inoltre, non esiste una correlazione tra il tempo di esecuzione del report e il numero di righe restituite nel report. Devi quindi recuperare regolarmente la risorsa del report utilizzando il metodo queries.reports.get e verificare se il campo metadata.status.state della risorsa è stato aggiornato in DONE o FAILED per determinare se l'esecuzione è terminata. Si tratta di un processo noto come "polling".

Sebbene il polling sia necessario, un'implementazione inefficiente può esaurire rapidamente la quota quando si verifica un report a lunga esecuzione. Consigliamo quindi di utilizzare il backoff esponenziale per limitare i nuovi tentativi e risparmiare quota.

Backoff esponenziale

Il backoff esponenziale è una strategia di gestione degli errori standard per le applicazioni di rete in cui il client riprova periodicamente la richiesta per un periodo di tempo crescente. Se utilizzato correttamente, il backoff esponenziale aumenta l'efficienza dell'utilizzo della larghezza di banda, riduce il numero di richieste necessarie per ottenere una risposta corretta e ottimizza la velocità effettiva delle richieste in ambienti contemporanei.

Il flusso per l'implementazione di un backoff esponenziale semplice è il seguente:

Effettua una richiesta queries.reports.get all'API.
Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è terminata e dovrebbe continuare a eseguire il polling.
Attendi 5 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è terminata e dovrebbe continuare a eseguire il polling.
Attendi 10 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è terminata e dovrebbe continuare a eseguire il polling.
Attendi 20 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è terminata e dovrebbe continuare a eseguire il polling.
Attendi 40 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è terminata e dovrebbe continuare a eseguire il polling.
Attendi 80 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
Continua questo pattern finché l'oggetto del report non viene aggiornato o non viene raggiunto un tempo massimo trascorso.

Se il report termina e termina con lo stato DONE, puoi recuperare il file del report generato da Google Cloud Storage seguendo il percorso indicato nel campo metadata.googleCloudStoragePath.