Daten effizient verwalten

Eine Hauptfunktion vieler Google Ads-Anwendungen ist das Abrufen von Kontodaten für Anwendungsfälle wie Datenanalyse, Kundenanfragen und Prüfungen der Richtlinieneinhaltung. Beim Abrufen der Daten sollten Sie die Nutzung optimieren, um die Google-Server nicht zu überlasten oder eine Ratenbegrenzung zu riskieren. Weitere Informationen finden Sie in den Leitfäden zur Ratenbegrenzung und zur Aktualisierung der Kontakt-E-Mail-Adresse.

Nutzungsrichtlinie für Berichte

Um die Stabilität der Server zu gewährleisten, werden in der Google Ads API GoogleAdsService.Search- und GoogleAdsService.SearchStream-Abfragemuster gedrosselt, die übermäßig viele API-Ressourcen verbrauchen. Wenn ein bestimmtes Abfragemuster gedrosselt wird, funktionieren andere Dienste, Methoden und Abfragemuster weiterhin ohne Beeinträchtigung. Die folgenden Fehler werden für gedrosselte Anfragen 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 bei Anfragen, die mit QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION fehlgeschlagen sind.

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

Methode Feld „Kosten“
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.:

  • Die Größe Ihrer Konten
  • Die Ansichten und Spalten, die Sie in Ihren Berichten abrufen
  • Die Auslastung der Google Ads API-Server

In der folgenden Tabelle sind aggregierte Statistiken zum Ressourcenverbrauch verschiedener Abfragemuster auf Google Ads API-Servern aufgeführt, damit Sie ressourcenintensive Abfragen verfolgen und optimieren können:

Zeitfenster Durchschnitt (P50) P70 (mittelmäßig) P95 (sehr hoch)
Kurzfristig (5 Min.) 6000 30000 1800000
Langfristig (24 Std.) 16.000 90000 8400000

Angenommen, Sie führen ein Abfragemuster 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 mehrere einzelne Datumsangaben aus, indem Sie die Abfrage so ändern, dass verschiedene Werte für den Filter segments.date eingesetzt werden. In der folgenden Tabelle sehen Sie, wie viele Berichte Sie in einem bestimmten Zeitfenster ausführen können, damit Ihre Ressourcennutzung in verschiedene Ressourcennutzungs-Buckets passt.

Zeitfenster Durchschnittlich Mittel bis hoch Sehr hoch
Kurzfristig (5 Min.) 10 50 3000
Langfristig (24 Std.) 26 150 14000

Wenn Sie dieses Abfragemuster zehnmal in fünf Minuten ausführen, gilt dies als durchschnittliche Nutzung. Wenn Sie dagegen 3.000 Berichte in fünf Minuten ausführen, gilt dies als sehr hohe Nutzung.

Es gibt mehrere Strategien, um den Ressourcenverbrauch Ihrer Berichte zu optimieren. Im weiteren Verlauf 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 im Cache speichern, anstatt den Server jedes Mal aufzurufen, wenn Sie die Daten benötigen. Dies gilt insbesondere für Entitäten, auf die häufig zugegriffen wird oder die sich selten ändern. Verwenden Sie nach Möglichkeit change-event und change-status, um zu ermitteln, welche Objekte sich seit der letzten Synchronisierung der Ergebnisse geändert haben.

Häufigkeit der Berichtsausführung optimieren

Google Ads hat Richtlinien zur Datenaktualität und zur Häufigkeit der Datenaktualisierung veröffentlicht. Anhand dieser Anleitung 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. Der Rest kann seltener aktualisiert werden, z. B. ein- oder zweimal am Tag.

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 Kontolimits.

Sehen Sie sich beispielsweise den folgenden Code an, mit dem die Statistiken für bestimmte Anzeigengruppen abgerufen und eine Statistikdatenbanktabelle aktualisiert wird:

  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 für ein kleines Testkonto. Google Ads unterstützt jedoch bis zu 20.000 Anzeigengruppen pro Kampagne und 10.000 Kampagnen pro Konto. Wenn dieser Code 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ührt.

Besser wäre es, einen einzelnen Bericht zu erstellen und lokal zu verarbeiten. Hier ist ein solcher Ansatz mit einer In-Memory-Zuordnung dargestellt:

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

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

Wenn der Bericht zu groß ist, um im Arbeitsspeicher gespeichert zu werden, 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

Labels sind eine weitere Möglichkeit, Entitäten zu gruppieren und die Anzahl der Berichtsabfragen zu reduzieren. Weitere Informationen finden Sie im Leitfaden zu Labels.

Abrufe optimieren

Beim Erstellen von Berichten sollten Sie darauf achten, welche Spalten Sie in Ihre Abfragen aufnehmen. Betrachten Sie das folgende Beispiel, das jede Stunde 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 jede Stunde ändern, sind metrics.clicks und metrics.impressions. Alle anderen Spalten werden selten oder gar nicht aktualisiert. Es ist also sehr ineffizient, sie stündlich abzurufen. Sie können diese Werte in einer lokalen Datenbank speichern und einen Bericht zu Änderungsereignissen oder zum Änderungsstatus ausführen, um Änderungen ein- oder zweimal täglich 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 Ihre Anwendung unter Berücksichtigung der Kundenabwanderung entwickeln. 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 Folgendes:

  • Widerrufen Sie die Autorisierung, die Ihr Kunde Ihrer Anwendung zur Verwaltung seines Kontos erteilt hat.
  • Senden Sie keine API-Aufrufe mehr an die Google Ads-Konten des Kunden. Dies gilt insbesondere für Offlinejobs wie Cronjobs und Datenpipelines, die ohne Nutzereingriff ausgeführt werden sollen.
  • Wenn der Kunde seine Autorisierung widerrufen hat, sollte Ihre Anwendung die Situation ordnungsgemäß handhaben und keine ungültigen API-Aufrufe an die API-Server von Google senden.
  • Wenn der Kunde sein Google Ads-Konto aufgelöst hat, sollten Sie aufgelöste Konten erkennen und keine ungültigen API-Aufrufe an die API-Server von Google senden.
  • Löschen Sie die Daten, die Sie aus den Google Ads-Konten des Kunden heruntergeladen haben, nach einem angemessenen Zeitraum aus Ihrer lokalen Datenbank.
Zurück
Monitoring
Weiter
Ratenlimits