Best practice per i report

Crea prima i nuovi report nell'interfaccia utente

I report sono soggetti a una serie di limitazioni e requisiti relativi a tipi di report, filtri, dimensioni e metriche. Queste limitazioni vengono applicate nell'API, restituendo un errore HTTP 400. Per evitare errori durante la creazione dei report, ti consigliamo di creare prima 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 unqueries.get della risorsa Query. Puoi utilizzare il JSON restituito per creare report futuri.

Utilizza metriche e filtri specifici per il tipo di report

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

Di seguito sono riportati alcuni modi per identificare i valori delle metriche e dei filtri dell'API Bid Manager pertinenti. 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 unico report.

Salvare e riutilizzare i report

Ti consigliamo di creare e salvare i report per le query che esegui regolarmente perché l'inserimento ed eliminazione dello stesso report più volte comporta uno spreco di risorse. L'utilizzo dei valori impostati Range, ad esempio 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 comportare uno spreco di risorse perché vengono eseguiti singolarmente e potrebbero essere eseguiti su un set di dati incompleto. I report pianificati fanno un uso ottimale delle risorse di generazione di report perché vengono eseguiti collettivamente e non vengono eseguiti fino al completamento dell'elaborazione dei dati del giorno precedente. Per informazioni dettagliate, consulta i campi di pianificazione disponibili.

Combinare report simili

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

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

Valutare le quote di generazione di report

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

Esecuzioni di report ad hoc al giorno

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

• Combina report simili per ridurre il volume di report.
• Pianifica report ad hoc ricorrenti per ridurre in modo specifico il volume di report ad hoc.
• Disattiva gli script API non necessari.

Report pianificati attivi

Limita il numero di report che un utente può pianificare attivamente in un determinato momento. Per rimanere al di sotto di 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 al di sotto di questa quota:

• Pianifica i report da eseguire regolarmente.
• Disattiva gli script API non necessari.
• Monitora quando i report sono stati completati tramite 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 il tempo necessario per l'esecuzione di un report. La durata può variare da alcuni secondi a diverse ore, a seconda di molti fattori, ad esempio l'intervallo di date e la quantità di dati da elaborare. Inoltre, non esiste alcuna correlazione tra il tempo di esecuzione del report e il numero di righe restituite nel report. Pertanto, devi recuperare regolarmente la risorsa report utilizzando il metodo queries.reports.get e controllare se il campo metadata.status.state della risorsa è stato aggiornato a DONE o FAILED per determinare se è stata completata l'esecuzione. Si tratta di una procedura nota come "polling".

Sebbene il polling sia necessario, un'implementazione inefficiente potrebbe esaurire rapidamente la quota quando si verifica un report con un'esecuzione prolungata. Ti consigliamo quindi di utilizzare il backoff esponenziale per limitare le riattempi 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 positiva e massimizza il throughput delle richieste in ambienti simultanei.

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

1. Invia una richiesta queries.reports.get all'API.
2. Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è stata completata e deve essere continuato il polling.
3. Attendi 5 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
4. Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è stata completata e deve essere continuato il polling.
5. Attendi 10 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
6. Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è stata completata e deve essere continuato il polling.
7. Attendi 20 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
8. Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è stata completata e deve essere continuato il polling.
9. Attendi 40 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
10. Recupera l'oggetto report. Se il campo metadata.status.state non è DONE o FAILED, significa che l'esecuzione del report non è stata completata e deve essere continuato il polling.
11. Attendi 80 secondi + un numero casuale di millisecondi e riprova a inviare la richiesta.
12. Continua questo pattern fino a quando l'oggetto report non viene aggiornato o non viene raggiunto un tempo massimo trascorso.

Se l'esecuzione del report termina con lo stato DONE, puoi recuperare il file del report generato da Google Cloud Storage nel percorso specificato nel campo metadata.googleCloudStoragePath.