Eine Kernfunktion vieler Google Ads-Anwendungen ist das Abrufen von Kontodaten für Anwendungsfälle wie Datenanalyse, Kundenanfragen und Richtlinienkonformitätsprüfungen. Beim Abrufen der Daten sollten Sie die Nutzung so optimieren, dass die Google-Server nicht überlastet werden und das Risiko einer Ratenbegrenzung minimiert wird. Weitere Informationen finden Sie in den Leitfäden zu Ratenbeschränkung und zur Aktualisierung der Kontakt-E-Mail-Adresse.
Google-Richtlinie zur Ressourcennutzung für Berichte
Um die Stabilität seiner Server zu gewährleisten, drosselt Google Ads API GoogleAdsService.Search- und GoogleAdsService.SearchStream-Abfragemuster, die übermäßig viele API-Ressourcen verbrauchen. Wenn ein bestimmtes Abfragemuster gedrosselt wird, funktionieren andere Dienste, Methoden und Abfragemuster weiterhin uneingeschränkt. 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. |
Damit Sie teure Berichte leichter erkennen 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.
- Die Größe Ihrer Konten
- Die Ansichten und Spalten, die Sie in Ihren Berichten abrufen
- Die Last auf den Google Ads API-Servern.
Damit Sie kostspielige Abfragen besser nachvollziehen können, veröffentlichen wir erste aggregierte Statistiken zum Ressourcenverbrauch verschiedener Abfragemuster, die auf unseren Servern auftreten. Wir veröffentlichen regelmäßig aktualisierte Zahlen, damit Sie Ihre Anfragen optimieren können.
| Zeitfenster | Durchschnitt (P50) | P70 (Mittel bis hoch) | P95 (sehr hoch) |
|---|---|---|---|
| Kurzfristig (5 Minuten) | 6000 | 30000 | 1800000 |
| Langfristig (24 Stunden). | 16.000 | 90000 | 8400000 |
Angenommen, Sie führen ein Abfragemuster wie das folgende 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 eingesetzt werden. In der folgenden Tabelle sehen Sie, wie viele Berichte Sie in einem bestimmten Zeitraum ausführen können, damit Ihre Ressourcennutzung in die verschiedenen Ressourcennutzungsbereiche passt.
| Zeitfenster | Durchschnitt | Mäßig hoch | Sehr hoch |
|---|---|---|---|
| Kurzfristig (5 Minuten) | 10 | 50 | 3000 |
| Langfristig (24 Stunden). | 26 | 150 | 14000 |
Wenn Sie dieses Abfragemuster zehnmal in fünf Minuten ausführen, gilt das als durchschnittliche Nutzung. Wenn Sie jedoch 3.000 Berichte in fünf Minuten ausführen, gilt das als sehr hohe Nutzung.
Es gibt verschiedene 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 von den API-Servern abgerufenen Entitätsdetails in einer lokalen Datenbank zwischenspeichern, 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 nur selten ändern. Verwenden Sie nach Möglichkeit change-event und change-status, um zu erkennen, welche Objekte sich seit der letzten Synchronisierung der Ergebnisse geändert haben.
Häufigkeit der Berichterstellung optimieren
Google Ads hat Richtlinien zur Aktualität von Daten veröffentlicht, in denen beschrieben wird, wie oft die Daten aktualisiert werden. 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. Die restlichen Daten können seltener aktualisiert werden, z. B. ein- oder zweimal täglich.
Berichtsgröße 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.
Im folgenden Beispiel werden die Statistiken für bestimmte Anzeigengruppen abgerufen und eine Statistikdatenbanktabelle wird 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. In Google Ads sind jedoch bis zu 20.000 Anzeigengruppen pro Kampagne und 10.000 Kampagnen pro Konto möglich. 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ühren kann.
Besser ist es, einen einzelnen Bericht zu erstellen und ihn lokal zu verarbeiten. Ein solcher Ansatz mit einer In-Memory-Karte wird 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 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
Mit Labels lassen sich Entitäten gruppieren und die Anzahl der Berichtsabfragen reduzieren. Weitere Informationen
Abruf optimieren
Achten Sie beim Ausführen von Berichten auf die Spalten, die Sie in Ihre Abfragen aufnehmen. Hier ein 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 nur selten oder gar nicht aktualisiert. Es ist daher sehr ineffizient, sie stündlich abzurufen. Sie können diese Werte in einer lokalen Datenbank speichern und einen change-event- oder change-status-Bericht erstellen, 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 sie so entwickeln, dass sie auch bei Kundenabwanderung funktioniert. Sie sollten Ihre Prozesse und Datenspeicher regelmäßig bereinigen, um Konten von Kunden zu entfernen, die Ihre Anwendung nicht mehr verwenden. Wenn Sie ungenutzte Google Ads-Konten bereinigen, sollten Sie Folgendes beachten:
- Widerrufen Sie die Autorisierung, die Ihr Kunde Ihrer Anwendung zum Verwalten seines Kontos erteilt hat.
- Stellen Sie keine API-Aufrufe mehr an die Google Ads-Konten des Kunden. Das 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äß 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 dies erkennen und vermeiden, ungültige API-Aufrufe an die API-Server von Google zu 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.