Eine Kernfunktion vieler Google Ads-Anwendungen ist das Abrufen von Kontodaten für Anwendungsfälle wie Datenanalyse, Kundenabfragen und Prüfungen auf Einhaltung von Richtlinien. Beim Abrufen der Daten sollten Sie Ihre Nutzung so optimieren, dass Google-Server nicht überlastet werden, weil die Häufigkeit nicht begrenzt wird. Weitere Informationen finden Sie in den Leitfäden zur Ratenbegrenzung und zur Pflege einer aktuellen Kontakt-E-Mail-Adresse.
Informationen zur Google-Richtlinie zur Ressourcennutzung für Berichte
Um die Stabilität der Server sicherzustellen, drosselt die Google Ads API GoogleAdsService.Search- und GoogleAdsService.SearchStream-Abfragemuster, die übermäßig viele API-Ressourcen verbrauchen. Wenn ein bestimmtes Abfragemuster gedrosselt wird, sind andere Dienste, Methoden und Abfragemuster weiterhin davon unberührt. Bei gedrosselten Anfragen werden die folgenden Fehler ausgegeben:
| API-Version | Fehlercode |
|---|---|
| <= Version 16 | QuotaError.RESOURCE_EXHAUSTED |
| >= Version 17 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION oder QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, je nach Dauer einer hohen Ressourcennutzung. |
Damit Sie teure Berichte identifizieren und überwachen 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 Kostenmesswert, der von diesen Feldern zurückgegeben wird, hängt von verschiedenen Faktoren ab, wie z. B.
- Größe Ihrer Konten
- Die in Ihren Berichten abgerufenen Ansichten und Spalten
- Die Auslastung der Google Ads API-Server.
Damit Sie teure Abfragen besser verfolgen können, veröffentlichen wir erste aggregierte Statistiken zum Ressourcenverbrauch verschiedener Abfragemuster auf unseren Servern. Wir veröffentlichen regelmäßig aktualisierte Zahlen, um Ihnen bei der Feinabstimmung Ihrer Abfragen zu helfen.
| Zeitfenster | Durchschnitt (p50). | P70 (mäßig hoch) | P95 (Sehr hoch) |
|---|---|---|---|
| Kurzfristig (5 Min.) | 6.000 | 30.000 | 1800000 |
| Langfristig (24 Std.). | 16.000 | 90000 | 8400000 |
Beispiel: Sie führen ein Abfragemuster mit dem folgenden 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 Termine aus. Ändern Sie dazu die Abfrage, um durch andere Werte für den Filter segments.date zu ersetzen. Die folgende Tabelle zeigt die Anzahl der Berichte, die Sie in einem bestimmten Zeitfenster ausführen können, sodass Ihre Ressourcennutzung in verschiedene Bereiche der Ressourcennutzung passt.
| Zeitfenster | Durchschnitt | Einigermaßen hoch | Sehr hoch |
|---|---|---|---|
| Kurzfristig (5 Min.) | 10 | 50 | 3.000 |
| Langfristig (24 Std.). | 26 | 150 | 14000 |
Wenn Sie dieses Abfragemuster 10-mal in 5 Minuten ausführen, wird dies als durchschnittliche Nutzung gezählt. 3.000 Berichte in 5 Minuten hingegen zählen 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 von den API-Servern abgerufenen Entitätsdetails in einer lokalen Datenbank zwischenspeichern, 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 festzustellen, welche Objekte sich seit der letzten Synchronisierung der Ergebnisse geändert haben.
Häufigkeit der Berichterstellung optimieren
Für Google Ads gibt es veröffentlichte Richtlinien zur Datenaktualität und zur Häufigkeit der Datenaktualisierung. Anhand dieser Anleitung können Sie bestimmen, wie oft Sie Berichte abrufen.
Wenn Sie Konten regelmäßig aktualisieren müssen, sollten Sie die Anzahl dieser Konten auf eine kleine Gruppe beschränken, beispielsweise auf die obersten 20 Google Ads-Konten. Der Rest kann mit einer geringeren Häufigkeit aktualisiert werden, z. B. einmal oder zweimal täglich.
Größe von Berichten optimieren
Ihre Anwendung sollte große Datenmengen abrufen, anstatt eine große Anzahl kleiner Berichte zu erstellen. Ein Faktor, der bei dieser Auswahl 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 mit einem kleinen Testkonto. Google Ads unterstützt jedoch bis zu 20.000 Anzeigengruppen pro Kampagne und 10.000 Kampagnen pro Konto. Wird dieser Code also für ein umfangreiches Google Ads-Konto ausgeführt, kann es zu einer Überlastung der Google Ads API-Server kommen, was zu Ratenbegrenzung und Drosselung führt.
Ein besserer Ansatz wäre, einen einzelnen Bericht zu erstellen und lokal zu verarbeiten. Ein solcher Ansatz mit einer speicherinternen Zuordnung 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);
}
Dies reduziert die Belastung der Google Ads API-Server aufgrund der geringeren Anzahl von Berichten, die ausgeführt werden.
Wenn Sie feststellen, dass der Bericht zu groß für den Arbeitsspeicher ist, können Sie die Abfrage auch in kleinere Gruppen aufteilen, indem Sie eine LIMIT-Klausel wie die folgende 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.
Abruf optimieren
Wenn Sie Berichte erstellen, sollten Sie auf die Spalten achten, die Sie in Ihre Abfragen aufnehmen. 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 überhaupt nicht aktualisiert, sodass ein stündlicher Abruf äußerst ineffizient ist. Sie können diese Werte in einer lokalen Datenbank speichern und einen change-event- oder change-status-Bericht 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 geeignete Filter anwenden.
Nicht verwendete Konten bereinigen
Wenn Sie mit Ihrer Anwendung Konten von Drittanbietern verwalten, müssen Sie sie im Hinblick auf die Kundenabwanderung entwickeln. Sie sollten Ihre Prozesse und Datenspeicher regelmäßig bereinigen, um Konten für Kunden zu entfernen, die Ihre Anwendung nicht mehr verwenden. Beachten Sie beim Bereinigen nicht verwendeter Google Ads-Konten die folgenden Hinweise:
- 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 können.
- Wenn der Kunde die Autorisierung widerrufen hat, sollte Ihre Anwendung die Situation zügig handhaben und das Senden ungültiger API-Aufrufe an die API-Server von Google vermeiden.
- Wenn der Kunde sein Google Ads-Konto aufgelöst hat, sollten Sie es 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 einer gewissen Zeit aus Ihrer lokalen Datenbank.