Una funzione principale di molte applicazioni di Google Ads è il recupero dei dati dell'account da utilizzare come analisi dei dati, query dei clienti e controlli di conformità alle norme. Durante il recupero dei dati, è consigliabile ottimizzare l'utilizzo in modo da non sovraccaricare ai server di Google, o rischiano di subire una limitazione di frequenza. Per ulteriori dettagli, consulta le guide su limitazione della frequenza e il mantenimento di indirizzo email di contatto aggiornato.
Informazioni sulle norme di utilizzo delle risorse di Google per i report
Per garantire la stabilità dei suoi server, l'API Google Ads limita le limitazioni
GoogleAdsService.Search e
Pattern di query di GoogleAdsService.SearchStream che consumano una quantità eccessiva
di risorse API. Se un particolare pattern di query viene limitato,
servizi, metodi e pattern di query continueranno a funzionare inalterati. La
per le richieste limitate vengono generati i seguenti errori:
| Versione API | Codice di errore |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| >= v18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
o QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION a seconda
per la durata dell'utilizzo elevato delle risorse. |
Per aiutarti a identificare e monitorare i tuoi rapporti costosi, ti restituiremo anche un 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
- Le visualizzazioni e le colonne recuperate nei report
- Il carico sui server dell'API Google Ads.
Per aiutarti a tenere traccia delle query costose, abbiamo deciso di pubblicare iniziali aggregate le statistiche sul consumo di risorse da parte di vari pattern di query nei nostri server. Pubblicheremo periodicamente i dati aggiornati per aiutarti a perfezionare le tue query.
| Finestra temporale | Media (p50). | P70 (Abbastanza alto) | P95 (molto alta) |
|---|---|---|---|
| Breve termine (5 min) | 6000 | 30000 | 1800000 |
| Lungo termine (24 ore). | 16000 | 90000 | 8400000 |
Supponi, ad esempio, di eseguire un pattern di query come il seguente, che utilizza 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 per sostituire valori diversi per segments.date
filtro. La tabella seguente mostra il numero di report che puoi eseguire in un determinato
finestra temporale in modo che l'utilizzo delle risorse rientri in vari utilizzi
bucket.
| Finestra temporale | Nella media | Moderatamente alto | Molto alto |
|---|---|---|---|
| Breve termine (5 min) | 10 | 50 | 3000 |
| Lungo termine (24 ore). | 26 | 150 | 14000 |
Eseguire questo pattern di query 10 volte in 5 minuti conta come una media mentre l'esecuzione di 3000 report in 5 minuti conta come un utilizzo molto elevato.
Esistono diverse strategie per ottimizzare il consumo di risorse report. Il resto della guida illustra alcune di queste strategie.
Memorizzare i dati nella cache
Devi memorizzare nella cache i dettagli dell'entità che recuperi dai server API in una anziché chiamare il server ogni volta che ne hai bisogno, in particolare per le entità a cui si accede di frequente o che cambiano con minore frequenza. Usa change-event e change-status dove possibili per rilevare quali oggetti sono stati modificati dall'ultima sincronizzazione dei risultati.
Ottimizzare la frequenza di esecuzione dei report
Google Ads ha pubblicato linee guida sull'aggiornamento dei dati e su come i dati vengono aggiornati di frequente. È necessario utilizzare queste indicazioni per stabilire per recuperare spesso i report.
Se hai bisogno di aggiornare regolarmente gli account, ti consigliamo di limitare i di questi account a un piccolo gruppo, ad esempio, solo i primi venti account . Il resto può essere aggiornato con una frequenza inferiore, ad esempio una volta o due volte al giorno.
Ottimizzare le dimensioni dei report
L'applicazione dovrebbe recuperare grandi batch di dati invece di eseguire un di report di piccole dimensioni. Un fattore determinante in questa scelta è l'account limiti.
Ad esempio, considera il seguente codice che estrae le statistiche per un annuncio specifico gruppi e aggiornare 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 piccole dimensioni. Tuttavia, Google Ads supporta fino a 20.000 gruppi di annunci per campagna e 10.000 campagne per account. Quindi se questo codice viene eseguito su un account Google Ads di grandi dimensioni, può sovraccaricare i server dell'API Google Ads il che porta a una limitazione e una limitazione di frequenza.
Un approccio migliore sarebbe quello di creare un singolo report e di elaborarlo localmente. Uno. questo approccio 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);
}
In questo modo si riduce il carico sui server dell'API Google Ads a causa del minor numero di report in esecuzione.
Se noti che il report è troppo grande per essere memorizzato, puoi anche
suddividere la query in gruppi più piccoli aggiungendo una clausola LIMIT come questa:
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 report query. Per saperne di più, consulta la guida alle etichette.
Ottimizza i dati recuperati
Quando esegui i report, fai attenzione alle colonne che includi le tue query. Considera l'esempio seguente, pianificato per essere eseguito 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 non in
tutte, quindi è molto inefficiente recuperarle ogni ora. Puoi archiviare questi dati
di valori in un database locale ed esegui un evento change-event
change-status per scaricare le modifiche una o due volte al giorno.
In alcuni casi, potresti ridurre il numero di righe scaricate applicando i filtri appropriati.
Libera spazio negli account inutilizzati
Se la tua applicazione gestisce account di inserzionisti di terze parti, devi sviluppare l'applicazione tenendo presente il tasso di abbandono dei clienti. Di tanto in tanto eseguire la pulizia dei processi e dei datastore per rimuovere gli account dei clienti che non non useranno più la tua applicazione. Quando ripulisci gli account Google Ads inutilizzati, tieni tieni a mente le seguenti indicazioni:
- Revocare l'autorizzazione che il cliente ha concesso alla tua applicazione di gestione. il proprio account.
- Interrompere le chiamate API agli account Google Ads del cliente. Applicabile in particolare ai job offline come cron job e pipeline di dati progettata per essere eseguita senza l'intervento dell'utente.
- Se il cliente ha revocato l'autorizzazione, la tua richiesta dovrebbe gestire agevolmente la situazione ed evitare di inviare chiamate API non valide a server API di Google.
- Se il cliente ha cancellato il proprio account Google Ads, devi rilevare ed evitare di inviare chiamate API non valide ai server API di Google.
- Eliminare i dati scaricati dagli account Google Ads del cliente dal tuo o del database locale dopo un adeguato periodo di tempo.