Daten effizient verwalten

Eine Kernfunktion vieler Google Ads-Anwendungen ist das Abrufen von Kontodaten für Anwendungsfälle wie Datenanalysen, Kundenanfragen und Prüfungen der Richtlinienkonformität. Beim Abrufen der Daten sollten Sie die Nutzung optimieren, um die Google-Server nicht zu überlasten und das Risiko einer Ratenbegrenzung zu vermeiden. Weitere Informationen finden Sie in den Leitfäden zu Ratenbegrenzung und zur Aktualisierung der E-Mail-Adresse für Benachrichtigungen.

Google-Richtlinie zur Ressourcennutzung für Berichte

Um die Stabilität der Server zu gewährleisten, begrenzt die Google Ads API GoogleAdsService.Search und GoogleAdsService.SearchStream Abfragemuster, die übermäßig viele API-Ressourcen verbrauchen. Wenn ein bestimmtes Abfragemuster begrenzt wird, funktionieren andere Dienste, Methoden und Abfragemuster weiterhin uneingeschränkt. Für begrenzte Anfragen werden die folgenden Fehler ausgegeben:

Fehlercode
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION oder QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION je nach Dauer der hohen Ressourcennutzung.

Wenn diese Fehler auftreten, warten Sie 5 Minuten, bevor Sie Anfragen wiederholen, die mit QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION fehlgeschlagen sind, und 30 Minuten für Anfragen, die mit QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION fehlgeschlagen sind.

Damit Sie Ihre teuren Berichte leichter identifizieren und im Blick behalten können, geben wir auch einen Kostenmesswert für einzelne Berichte zurück.

Methode Kostenfeld
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

Der von diesen Feldern zurückgegebene Kostenmesswert hängt von verschiedenen Faktoren ab, z. B.

  • der Größe Ihrer Konten
  • den Ansichten und Spalten, die Sie in Ihren Berichten abrufen
  • der Last auf den Google Ads API-Servern

Damit Sie teure Abfragen nachverfolgen können, veröffentlichen wir erste aggregierte Statistiken zur Ressourcennutzung verschiedener Abfragemuster, die auf unseren Servern zu sehen sind. Wir werden regelmäßig aktualisierte Zahlen veröffentlichen, damit Sie Ihre Abfragen optimieren können.

Zeitfenster Durchschnitt (P50) P70 (mittelmäßig hoch) P95 (sehr hoch)
Kurzfristig (5 Minuten) 6000 30000 1800000
Langfristig (24 Stunden) 16000 90000 8400000

Angenommen, Sie führen ein Abfragemuster wie folgt aus, das 600 Ressourceneinheiten pro Bericht verbraucht:

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

Sie führen diese Abfrage für mehrere Kundenkonten für verschiedene einzelne Datumsangaben aus, indem Sie die Abfrage so ändern, dass verschiedene Werte für den Filter segments.date verwendet werden. In der folgenden Tabelle sehen Sie, wie viele Berichte Sie in einem bestimmten Zeitfenster ausführen können, sodass Ihre Ressourcennutzung in verschiedene Ressourcennutzungs-Buckets passt.

Zeitfenster Durchschnittlich Mittelmäßig hoch Sehr hoch
Kurzfristig (5 Minuten) 10 50 3000
Langfristig (24 Stunden) 26 150 14000

Wenn Sie dieses Abfragemuster 10 Mal in 5 Minuten ausführen, gilt das als durchschnittliche Nutzung. Wenn Sie jedoch 3000 Berichte in 5 Minuten ausführen, gilt das als sehr hohe Nutzung.

Es gibt verschiedene Strategien, um die Ressourcennutzung Ihrer Berichte zu optimieren. Im Rest dieses Leitfadens werden einige dieser Strategien behandelt.

Daten im Cache speichern

Sie sollten die Entitätsdetails, die Sie von den API-Servern abrufen, in einer lokalen Datenbank speichern, anstatt den Server jedes Mal aufzurufen, wenn Sie die Daten benötigen. Das gilt insbesondere für Entitäten, auf die häufig zugegriffen wird oder die sich selten ändern. Verwenden Sie Änderungsereignisse und Änderungsstatus wo möglich, um zu erkennen, welche Objekte sich seit der letzten Synchronisierung der Ergebnisse geändert haben.

Häufigkeit der Berichtserstellung optimieren

Google Ads hat Richtlinien veröffentlicht zur Datenaktualität und zur Häufigkeit der Datenaktualisierung. Anhand dieser Richtlinien können Sie festlegen, wie oft Berichte abgerufen werden sollen.

Wenn Sie Konten regelmäßig aktualisieren müssen, empfehlen wir, die Anzahl dieser Konten auf eine kleine Gruppe zu beschränken, z. B. nur die 20 wichtigsten Google Ads-Konten. Die übrigen Konten können seltener aktualisiert werden, z. B. ein- oder zweimal täglich.

Größe Ihrer Berichte optimieren

Ihre Anwendung sollte große Datenmengen abrufen, anstatt eine große Anzahl kleiner Berichte auszuführen. Ein Faktor, der bei dieser Entscheidung eine Rolle spielt, sind die Konto limits.

Betrachten Sie beispielsweise den folgenden Code, der die Statistiken für bestimmte Anzeigengruppen abruft und eine Statistikdatenbanktabelle aktualisiert:

  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);
  }

Dieser Code funktioniert gut in einem kleinen Testkonto. Google Ads unterstützt jedoch bis zu 20.000 Anzeigengruppen pro Kampagne und 10.000 Kampagnen pro Konto. Wenn dieser Code also für ein großes Google Ads-Konto ausgeführt wird, kann er die Google Ads API-Server überlasten, was zu Ratenbegrenzung und Drosselung führen kann.

Ein besserer Ansatz wäre, einen einzelnen Bericht auszuführen und ihn lokal zu verarbeiten. Ein solcher Ansatz mit einer In-Memory-Map wird hier gezeigt.

  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);
  }

Dadurch wird die Last auf den Google Ads API-Servern reduziert, da weniger Berichte ausgeführt werden.

Wenn der Bericht zu groß ist, um ihn im Arbeitsspeicher zu speichern, können Sie die Abfrage auch in kleinere Gruppen aufteilen, indem Sie eine LIMIT-Klausel wie diese hinzufügen:

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

Mit Labels können Sie Entitäten gruppieren und die Anzahl der Berichtsabfragen reduzieren. Weitere Informationen finden Sie im Leitfaden zu Labels.

Abruf optimieren

Beim Ausführen von Berichten sollten Sie auf die Spalten achten, die Sie in Ihre Abfragen einbeziehen. Betrachten Sie das folgende Beispiel, das stündlich ausgeführt werden soll:

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

Die einzigen Spalten, die sich wahrscheinlich stündlich ändern, sind metrics.clicks und metrics.impressions. Alle anderen Spalten werden selten oder gar nicht aktualisiert. Daher ist es sehr ineffizient, sie stündlich abzurufen. Sie können diese Werte in einer lokalen Datenbank speichern und ein Änderungsereignis oder Änderungsstatus-Bericht ein- oder zweimal täglich ausführen, um Änderungen herunterzuladen.

In einigen Fällen können Sie die Anzahl der heruntergeladenen Zeilen reduzieren, indem Sie entsprechende Filter anwenden.

Nicht verwendete Konten bereinigen

Wenn Ihre Anwendung Kundenkonten von Drittanbietern verwaltet, müssen Sie bei der Entwicklung Ihrer Anwendung berücksichtigen, dass Kunden abwandern können. Sie sollten Ihre Prozesse und Datenspeicher regelmäßig bereinigen, um Konten von Kunden zu entfernen, die Ihre Anwendung nicht mehr verwenden. Beachten Sie beim Bereinigen nicht verwendeter Google Ads-Konten die folgenden Richtlinien:

  • Entziehen Sie die Autorisierung, die Ihr Kunde Ihrer Anwendung erteilt hat, um sein Konto zu verwalten.
  • Führen Sie keine API-Aufrufe mehr für die Google Ads-Konten des Kunden aus. Das gilt insbesondere für Offline-Jobs wie Cron-Jobs und Datenpipelines, die ohne Nutzereingriff ausgeführt werden.
  • Wenn der Kunde seine Autorisierung entzogen hat, sollte Ihre Anwendung die Situation ordnungsgemäß verarbeiten und vermeiden, ungültige API-Aufrufe an die API-Server von Google zu senden.
  • Wenn der Kunde sein Google Ads-Konto gekündigt hat, sollten Sie das erkennen und vermeiden, ungültige API-Aufrufe an die API-Server von Google zu senden.
  • Löschen Sie die Daten, die Sie von den Google Ads-Konten des Kunden heruntergeladen haben, nach einem angemessenen Zeitraum aus Ihrer lokalen Datenbank.