Una funzione di base di molte applicazioni Google Ads è il recupero dei dati dell'account per casi d'uso come analisi dei dati, query dei clienti e 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 essere limitati in termini di frequenza. Per maggiori dettagli, consulta le guide sul limite di frequenza e sulla gestione di un indirizzo email di contatto aggiornato.
Informazioni sulle norme di Google relative all'utilizzo delle risorse 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 determinato pattern di query viene limitato, altri servizi, metodi e pattern di query continueranno a funzionare inalterati. 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
oppure QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION a seconda
della durata dell'utilizzo elevato delle risorse. |
Per aiutarti a identificare e monitorare i report costosi, restituiremo anche una metrica sul costo per i singoli report.
| Metodo | Campo Costo |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
La metrica dei costi restituita da questi campi dipende da vari fattori, ad esempio
- La dimensione dei tuoi account
- Le visualizzazioni e le colonne che recuperi nei report
- Il carico sui server dell'API Google Ads.
Per aiutarti a monitorare le query costose, stiamo pubblicando statistiche iniziali aggregate sul consumo di risorse dei vari pattern di query che riscontriamo sui nostri server. Pubblicheremo periodicamente numeri aggiornati per aiutarti a perfezionare le tue query.
| Finestra temporale | Media (p50). | P70 (moderatamente alto) | P95 (molto alto) |
|---|---|---|---|
| A breve termine (5 minuti) | 6000 | 30000 | 1800000 |
| Lungo termine (24 ore). | 16000 | 90000 | 8400000 |
Ad esempio, supponiamo che tu stia eseguendo un pattern di query come quello che 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 intervallo di tempo in modo che l'utilizzo delle risorse rientri in vari bucket di utilizzo delle risorse.
| Finestra temporale | Nella media | Moderatamente alto | Molto alto |
|---|---|---|---|
| A breve termine (5 minuti) | 10 | 50 | 3000 |
| Lungo termine (24 ore). | 26 | 150 | 14000 |
L'esecuzione di questo pattern di query 10 volte in 5 minuti viene considerata un utilizzo medio, mentre l'esecuzione di 3000 report in 5 minuti viene considerata un utilizzo molto elevato.
Esistono diverse strategie per ottimizzare il consumo di risorse dei report. Il resto di questa guida illustra alcune di queste strategie.
Memorizzare nella cache i dati
Ti consigliamo di memorizzare nella cache i dettagli delle entità che recuperi 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 viene eseguito spesso l'accesso o che cambiano raramente. Utilizza change-event e change-status, se possibile, per rilevare quali oggetti sono cambiati dall'ultima sincronizzazione dei risultati.
Ottimizzare la frequenza di esecuzione dei report
Google Ads ha pubblicato linee guida sull'aggiornamento dei dati e sulla frequenza con cui vengono aggiornati. Devi utilizzare queste indicazioni per determinare la frequenza con cui recuperare i report.
Se devi aggiornare gli account regolarmente, ti consigliamo di limitarne il numero a un piccolo insieme, ad esempio solo i primi 20 account Google Ads. Il resto può essere aggiornato con una frequenza inferiore, ad esempio una o due volte al giorno.
Ottimizzare le dimensioni dei report
L'applicazione deve recuperare grandi batch di dati anziché eseguire un gran numero di piccoli report. Un fattore che influisce su 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 del 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 piccolo account di test. 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 in un account Google Ads di grandi dimensioni, può sovraccaricare i server dell'API Google Ads, con conseguente limitazione della frequenza e throttling.
Un approccio migliore sarebbe eseguire un singolo report ed elaborarlo localmente. Viene mostrato un primo approccio di questo tipo che utilizza 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, il carico sui server dell'API Google Ads viene ridotto grazie al numero inferiore di report eseguiti.
Se il report è troppo grande per essere memorizzato nella memoria, 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 query per i report. Per saperne di più, consulta la guida alle etichette.
Ottimizza i dati che recuperi
Quando esegui i report, devi prestare attenzione alle colonne che includi nelle query. Considera l'esempio seguente, 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 di rado o per niente, pertanto è molto inefficiente recuperarle ogni ora. Puoi memorizzare 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.
Eliminare gli account inutilizzati
Se la tua applicazione gestisce account cliente di terze parti, devi svilupparla tenendo conto del tasso di abbandono dei clienti. Dovresti periodicamente ottimizzare le tue procedure e i tuoi 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.
- Interrompi le chiamate API agli account Google Ads del cliente. Questo vale soprattutto per i job offline come i cron job e le pipeline di dati progettati per essere eseguiti senza intervento dell'utente.
- Se il cliente ha revocato l'autorizzazione, la tua applicazione deve gestire la situazione in modo appropriato ed evitare di inviare chiamate API non valide ai server API di Google.
- Se il cliente ha annullato il proprio account Google Ads, devi 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.