Gestire i dati in modo efficiente

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 essere limitato dalla frequenza. Per maggiori dettagli, consulta le guide sulla limitazione della frequenza e sul mantenimento di un indirizzo email di contatto aggiornato.

Informazioni sulle norme di utilizzo delle risorse per i report

Per garantire la stabilità dei propri server, l'API Google Ads limita GoogleAdsService.Search e GoogleAdsService.SearchStream pattern di query che consumano quantità eccessive di risorse API. Se un determinato pattern di query è limitato, gli altri servizi, metodi e pattern di query continuano a funzionare senza problemi. Per le richieste limitate vengono generati i seguenti errori:

Codice di errore
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION o QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION a seconda della durata dell'utilizzo elevato delle risorse.

Se riscontri questi errori, attendi 5 minuti prima di riprovare le richieste non riuscite con QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION e 30 minuti per le richieste non riuscite con QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Per aiutarti a identificare e monitorare i report costosi, restituiamo anche una metrica dei costi per i singoli report:

Metodo Campo dei costi
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

La metrica dei costi restituita da questi campi dipende da vari fattori, tra cui:

  • Le dimensioni dei tuoi account
  • Le visualizzazioni e le colonne che recuperi nei report
  • Il carico sui server dell'API Google Ads

La tabella seguente elenca le statistiche aggregate sul consumo di risorse di vari pattern di query sui server dell'API Google Ads per aiutarti a monitorare e ottimizzare le query costose:

Finestra temporale Media (p50) P70 (moderatamente alta) P95 (molto alta)
A breve termine (5 minuti) 6000 30000 1800000
A lungo termine (24 ore) 16000 90000 8400000

Ad esempio, supponiamo che tu stia eseguendo un pattern di query come il seguente, 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 una determinata finestra temporale in modo che l'utilizzo delle risorse rientri in vari bucket di utilizzo delle risorse.

Finestra temporale Media Moderatamente alta Molto alta
A breve termine (5 minuti) 10 50 3000
A 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

Devi memorizzare nella cache i dettagli delle entità che recuperi dai server dell'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. Utilizza gli eventi di modifica e lo stato di modifica, se possibile, per rilevare gli oggetti modificati dall'ultima sincronizzazione dei risultati.

Ottimizzare la frequenza di esecuzione dei report

Google Ads ha pubblicato linee guida sulla freschezza dei dati e sulla frequenza di aggiornamento dei dati. Devi utilizzare queste indicazioni per determinare la frequenza di recupero dei report.

Se devi aggiornare regolarmente gli account, ti consigliamo di limitare il numero di questi account a un piccolo insieme, ad esempio solo i primi venti 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 batch di dati di grandi dimensioni anziché eseguire un numero elevato di report di piccole dimensioni. 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 su un account Google Ads di grandi dimensioni, può sovraccaricare i server dell'API Google Ads, causando limitazioni della frequenza e limitazioni.

Un approccio migliore consiste nell'eseguire un singolo report ed elaborarlo localmente. Di seguito è riportato un 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(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

In questo modo si riduce il carico sui server dell'API Google Ads grazie al minor numero di report eseguiti.

Se il report è troppo grande per essere memorizzato in 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 di reporting. Per saperne di più, consulta la guida alle etichette.

Ottimizzare i dati recuperati

Quando esegui i report, devi prestare attenzione alle colonne che includi nelle query. Considera il seguente esempio, la cui esecuzione è pianificata 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 probabilmente cambiano ogni ora sono metrics.clicks e metrics.impressions. Tutte le altre colonne vengono aggiornate raramente o mai, quindi è molto inefficiente recuperarle ogni ora. Puoi memorizzare questi valori in un database locale ed eseguire un report sugli eventi di modifica o sullo stato di modifica 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 gli account cliente di terze parti, devi svilupparla tenendo conto del churn dei clienti. Devi pulire periodicamente i processi e gli archivi dati per rimuovere gli account dei clienti che non utilizzano più la tua applicazione. Quando pulisci 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, l'applicazione deve gestire la situazione in modo corretto ed evitare di inviare chiamate API non valide ai server API di Google.
  • Se il cliente ha annullato il suo account Google Ads, devi rilevare gli account annullati ed evitare di inviare chiamate API non valide ai server API di Google.
  • Elimina i dati scaricati dagli account Google Ads del cliente dal database locale dopo un periodo di tempo appropriato.