Una funzione principale di molte applicazioni Google Ads è il recupero dei dati dell'account per casi d'uso come l'analisi dei dati, le query dei clienti e i controlli di conformità alle norme. Durante il recupero dei dati, devi ottimizzare l'utilizzo in modo da non sovraccaricare i server di Google o rischiare di limitare la frequenza. Per ulteriori dettagli, consulta le guide sulla limitazione di frequenza e sul mantenimento di un indirizzo email di contatto aggiornato.
Informazioni sui criteri di utilizzo delle risorse di Google per i report
Per garantire la stabilità dei suoi server, l'API Google Ads limita i pattern di query GoogleAdsService.Search e GoogleAdsService.SearchStream che consumano quantità eccessive di risorse API. Se un particolare pattern di query viene limitato, gli altri servizi, metodi e pattern di query continueranno a funzionare non solo. Per le richieste limitate, vengono visualizzati i seguenti errori:
| Versione API | Codice di errore |
|---|---|
| <= versione 16 | QuotaError.RESOURCE_EXHAUSTED |
| >= versione 17 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
o QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, a seconda della
durata di utilizzo elevato delle risorse. |
Per aiutarti a identificare e monitorare i tuoi report costosi, restituiamo anche una metrica dei costi per i singoli report.
| Metodo | campo Costo |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
La metrica del costo restituita da questi campi dipende da vari fattori, tra cui
- Le dimensioni degli account.
- Visualizzazioni e colonne recuperate nei report
- Il carico sui server dell'API Google Ads.
Per aiutarti a monitorare le query costose, pubblichiamo statistiche aggregate iniziali sul consumo delle risorse dei vari pattern di query che rileviamo sui nostri server. Pubblicheremo periodicamente numeri aggiornati per aiutarti a perfezionare le query.
| Finestra temporale | Nella media (pag. 50). | P70 (Abbastanza alto) | P95 (molto alto) |
|---|---|---|---|
| Breve termine (5 min) | 6000 | 30000 | 1800000 |
| Lungo termine (24 ore). | 16000 | 90000 | 8400000 |
Ad esempio, supponiamo che tu stia eseguendo un pattern di query come segue, che consuma 600 unità di risorse per report.
SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
segments.date = "YYYY-MM-DD"
Esegui questa query per più account cliente per diverse date singole
modificando la query in modo da sostituire valori diversi per il
filtro segments.date. La tabella seguente mostra il numero di report che puoi eseguire in un determinato periodo di tempo, in modo che l'utilizzo delle risorse rientri in vari bucket di utilizzo delle risorse.
| Finestra temporale | Nella media | Abbastanza alta | Molto alto |
|---|---|---|---|
| Breve termine (5 min) | 10 | 50 | 3000 |
| Lungo termine (24 ore). | 26 | 150 | 14000 |
L'esecuzione di questo pattern di query 10 volte ogni 5 minuti viene conteggiata come un utilizzo medio, mentre l'esecuzione di 3000 report in 5 minuti viene conteggiata come un utilizzo molto elevato.
Esistono diverse strategie per ottimizzare il consumo di risorse dei report. Il resto della guida illustra alcune di queste strategie.
Memorizza nella cache i tuoi dati
Devi memorizzare nella cache i dettagli dell'entità recuperati dai server API in un database locale, anziché chiamare il server ogni volta che hai bisogno dei dati, in particolare per le entità a cui si accede di frequente o che cambiano raramente. Se possibile, utilizza change-event e change-status per rilevare quali oggetti sono stati modificati dall'ultima sincronizzazione dei risultati.
Ottimizza la frequenza di esecuzione dei report
Google Ads ha pubblicato linee guida sull'aggiornamento dei dati e sulla frequenza di aggiornamento dei dati. Dovresti utilizzare queste indicazioni per determinare la frequenza di recupero dei report.
Se devi aggiornare regolarmente gli account, ti consigliamo di limitare il numero di account a un piccolo insieme, ad esempio solo i primi venti account Google Ads. Il resto può essere aggiornato a una frequenza inferiore, ad esempio una o due volte al giorno.
Ottimizzare le dimensioni dei report
L'applicazione dovrebbe recuperare grandi batch di dati invece di eseguire un numero elevato di report di piccole dimensioni. Un fattore determinante per questa scelta sono i limiti dell'account.
Ad esempio, considera il seguente codice che estrae le statistiche per gruppi di annunci specifici e aggiorna una tabella di database delle statistiche:
List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
foreach (long adGroupId in adGroupIds)
{
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
"ad_group.id = ${adGroupId}";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
InsertRowsIntoStatsTable(adGroupId, rows);
}
Questo codice funziona bene su un account di prova di dimensioni ridotte. Tuttavia, Google Ads supporta fino a 20.000 gruppi di annunci per campagna e 10.000 campagne per account. Pertanto, se questo codice viene eseguito su un account Google Ads di grandi dimensioni, può sovraccaricare i server dell'API Google Ads, determinando una limitazione di frequenza e una limitazione.
Un approccio migliore sarebbe eseguire un singolo report ed elaborarlo localmente. Uno di questi approcci viene mostrato utilizzando una mappa in memoria.
Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Ciò riduce il carico sui server dell'API Google Ads perché il numero di report in esecuzione è inferiore.
Se ritieni che il report sia troppo grande per essere conservato in memoria, puoi anche suddividere la query in gruppi più piccoli aggiungendo una clausola LIMIT come la seguente:
SELECT
ad_group.id,
ad_group.name,
metrics.clicks,
metrics.cost_micros,
metrics.impressions,
segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
AND ad_group.id IN (id1, id2, ...)
LIMIT 100000
Le etichette sono un altro modo per raggruppare le entità e ridurre il numero di query dei report. Per saperne di più, consulta la guida alle etichette.
Ottimizza i dati che recuperi
Quando esegui i report, devi tenere conto delle colonne che includi nelle query. Considera il seguente esempio pianificato per l'esecuzione ogni ora:
SELECT
customer.id,
customer.currency_code,
campaign.id,
campaign.name,
ad_group.id,
ad_group.name,
ad_group_criterion.keyword.match_type,
ad_group_criterion.keyword.text,
ad_group_criterion.criterion_id,
ad_group_criterion.quality_info.creative_quality_score,
ad_group_criterion.system_serving_status,
ad_group_criterion.negative,
ad_group_criterion.quality_info.quality_score,
ad_group_criterion.quality_info.search_predicted_ctr,
ad_group_criterion.quality_info.post_click_quality_score,
metrics.historical_landing_page_quality_score,
metrics.search_click_share,
metrics.historical_creative_quality_score,
metrics.clicks,
metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS
Le uniche colonne che potrebbero cambiare ogni ora sono metrics.clicks e metrics.impressions. Tutte le altre colonne vengono aggiornate raramente o per niente, pertanto è molto inefficiente recuperarle su base oraria. Puoi archiviare questi
valori in un database locale ed eseguire un report change-event o
change-status per scaricare le modifiche una o due volte al giorno.
In alcuni casi, puoi ridurre il numero di righe scaricate applicando i filtri appropriati.
Liberare gli account inutilizzati
Se la tua applicazione gestisce account di inserzionisti di terze parti, devi sviluppare l'applicazione tenendo conto del tasso di abbandono dei clienti. Devi ripulire periodicamente i processi e i datastore per rimuovere gli account dei clienti che non utilizzano più la tua applicazione. Quando elimini gli account Google Ads inutilizzati, tieni presente le seguenti indicazioni:
- Revoca l'autorizzazione che il cliente ha concesso alla tua applicazione per gestire il suo account.
- Interrompere le chiamate API agli account Google Ads del cliente. Ciò si applica in particolare a job offline come cron job e pipeline di dati progettate per essere eseguite senza l'intervento dell'utente.
- Se il cliente ha revocato l'autorizzazione, l'applicazione dovrebbe gestire la situazione con attenzione ed evitare di inviare chiamate API non valide ai server API di Google.
- Se il cliente ha cancellato il suo account Google Ads, dovresti rilevarlo ed evitare di inviare chiamate API non valide ai server API di Google.
- Elimina i dati scaricati dagli account Google Ads del cliente dal tuo database locale dopo un periodo di tempo appropriato.