Best Practices für die Berichterstellung

Neue Berichte zuerst in der Benutzeroberfläche erstellen

Berichte unterliegen einer Reihe von Einschränkungen und Anforderungen in Bezug auf Berichtstypen, Filter, Dimensionen und Messwerte. Diese Einschränkungen werden in der API erzwungen und es wird der Fehler HTTP 400 zurückgegeben. Um Fehler beim Erstellen von Berichten zu vermeiden, sollten Sie neue Berichte zuerst in der Benutzeroberfläche von Display & Video 360 erstellen.

Klicken Sie nach dem Erstellen des Berichts auf der Seite mit der Referenzdokumentation auf die Funktion API testen, um einen queries.get der Ressource Query auszuführen. Sie können das zurückgegebene JSON-Format verwenden, um zukünftige Berichte zu erstellen.

Für den Berichtstyp spezifische Messwerte und Filter verwenden

Einige Messwert- und Filterwerte gelten nur für bestimmte Berichtstypen. Sie können Ihre Berichte zuerst in der Benutzeroberfläche erstellen. Sie können auch die Messwerte und Filter, die zu bestimmten ReportType-Werten gehören, anhand ihres Bid Manager API-Werts identifizieren.

Hier sind einige Möglichkeiten, wie Sie relevante Bid Manager API-Filter und -Messwerte ermitteln können. Die folgende Tabelle ist keine vollständige Liste der Filter und Messwerte, die in solchen Berichten verwendet werden können. Nicht alle Werte können gemeinsam in einem Bericht verwendet werden.

ReportType Relevante Filter und Messwerte
INVENTORY_AVAILABILITY
  • Filter mit dem Präfix FILTER_TRUEVIEW_IAR.
YOUTUBE
  • Filter mit dem Präfix FILTER_TRUEVIEW, ausgenommen die mit dem Präfix FILTER_TRUEVIEW_IAR.
  • Messwerte mit dem Präfix METRIC_TRUEVIEW.
GRP
  • Messwerte mit dem Präfix METRIC_GRP.
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • Filter mit dem Präfix FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED.
  • Messwerte mit dem Präfix METRIC_PROGRAMMATIC_GUARANTEED.
REACH
  • Messwerte mit dem Präfix METRIC_UNIQUE_REACH.
UNIQUE_REACH_AUDIENCE
  • Messwerte mit dem Präfix METRIC_UNIQUE_REACH.

Berichte speichern und wiederverwenden

Es wird empfohlen, Berichte für Abfragen zu erstellen und zu speichern, die Sie regelmäßig ausführen, da durch das mehrfache Einfügen und Löschen desselben Berichts Ressourcen vergeudet werden. Wenn Sie Range-Werte wie PREVIOUS_DAY oder LAST_7_DAYS im Feld dataRange verwenden, sind Berichte wiederverwendbar.

Berichte planen

Ad-hoc- oder einmalige Berichte können Ressourcen verschwenden, da sie einzeln und möglicherweise für ein unvollständiges Dataset ausgeführt werden. Geplante Berichte nutzen die Berichtsressourcen optimal, da sie im Bulk-Verfahren ausgeführt werden und garantiert erst dann ausgeführt werden, wenn die Datenverarbeitung des Vortags abgeschlossen ist. Einzelheiten finden Sie in den verfügbaren Feldern für die Planung.

Ähnliche Berichte kombinieren

Wenn Sie regelmäßig Berichte mit identischen Messwerten und Zeiträumen für verschiedene Werbetreibende oder Partner generieren, empfehlen wir, die Berichte zu kombinieren, um ihr Berichtsvolumen zu optimieren.

Sie können ähnliche Berichte kombinieren, indem Sie die Filter aller Berichte anhängen und alle Filtertypen als Dimensionen hinzufügen. Nach dem Erstellen können Sie die Zeilen des resultierenden Berichts entlang der ursprünglichen Filterwerte aufteilen, um die ursprünglichen Berichte zu erhalten.

Kontingente für die Berichterstellung berücksichtigen

Die verantwortungsbewusste Nutzung der Berichtsfunktion in Display & Video 360 wird durch die folgenden produktweiten Nutzungskontingente geregelt.

Ausführung von Ad-hoc-Berichten pro Tag

Schränkt die Anzahl der Ad-hoc-Berichte ein, die ein Nutzer in einem Zeitraum von 24 Stunden erstellen kann. So bleiben Sie unter diesem Kontingent:

Aktive geplante Berichte

Beschränkt die Anzahl der Berichte, die ein Nutzer zu einem bestimmten Zeitpunkt aktiv planen kann. So bleiben Sie unter diesem Kontingent:

Gleichzeitige Berichte

Begrenzt die Anzahl der Berichte, die ein Nutzer gleichzeitig erstellen kann. So bleiben Sie unter diesem Kontingent:

  • Planen Sie regelmäßig erstellte Berichte.
  • Deaktivieren Sie unnötige API-Skripts.
  • Verfolgen Sie die Erstellung Ihrer Berichte durch Abfragen mit der exponentiellen Backoff-Logik.

Wenn Sie die Berichterstellung optimiert haben und das Kontingent immer noch überschritten wird, wenden Sie sich über das Kontaktformular an den Display & Video 360-Support.

Exponentiellen Backoff beim Abfragen des Berichtsstatus verwenden

Die Ausführungsdauer eines Berichts kann nicht vorhergesagt werden. Die Dauer kann von Sekunden bis Stunden reichen und ist von vielen Faktoren abhängig, z. B. vom Datumsbereich und der zu verarbeitenden Datenmenge. Außerdem gibt es keinen Zusammenhang zwischen der Laufzeit des Berichts und der Anzahl der im Bericht zurückgegebenen Zeilen. Daher müssen Sie die Berichtsressource regelmäßig mit der Methode queries.reports.get abrufen und prüfen, ob das Feld metadata.status.state der Ressource auf DONE oder FAILED aktualisiert wurde, um festzustellen, ob die Ausführung beendet ist. Dieser Vorgang wird als „Umfragen“ bezeichnet.

Abfragen sind zwar notwendig, eine ineffiziente Implementierung kann Ihr Kontingent jedoch schnell aufbrauchen, wenn ein lang andauernder Bericht erstellt wird. Daher empfehlen wir, dass Sie den exponentiellen Backoff verwenden, um Wiederholungsversuche zu begrenzen und Kontingente zu sparen.

Exponentielle Backoffs

Der exponentielle Backoff ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen, bei denen der Client die Anfrage regelmäßig über einen immer größer werdenden Zeitraum wiederholt. Bei richtiger Anwendung erhöht der exponentielle Backoff die Effizienz der Bandbreitennutzung, reduziert die Anzahl der für eine erfolgreiche Antwort erforderlichen Anfragen und maximiert den Durchsatz von Anfragen in gleichzeitigen Umgebungen.

Der Ablauf für das Implementieren eines einfachen exponentiellen Backoffs sieht so aus:

  1. Stellen Sie eine queries.reports.get-Anfrage an die API.
  2. Rufen Sie das Berichtsobjekt ab. Wenn das Feld metadata.status.state nicht DONE oder FAILED ist, bedeutet dies, dass die Ausführung des Berichts noch nicht abgeschlossen ist.
  3. Warten Sie 5 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  4. Rufen Sie das Berichtsobjekt ab. Wenn das Feld metadata.status.state nicht DONE oder FAILED ist, bedeutet dies, dass die Ausführung des Berichts noch nicht abgeschlossen ist.
  5. Warten Sie 10 Sekunden plus eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  6. Rufen Sie das Berichtsobjekt ab. Wenn das Feld metadata.status.state nicht DONE oder FAILED ist, bedeutet dies, dass die Ausführung des Berichts noch nicht abgeschlossen ist.
  7. Warten Sie 20 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  8. Rufen Sie das Berichtsobjekt ab. Wenn das Feld metadata.status.state nicht DONE oder FAILED ist, bedeutet dies, dass die Ausführung des Berichts noch nicht abgeschlossen ist.
  9. Warten Sie 40 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  10. Rufen Sie das Berichtsobjekt ab. Wenn das Feld metadata.status.state nicht DONE oder FAILED ist, bedeutet dies, dass die Ausführung des Berichts noch nicht abgeschlossen ist.
  11. Warten Sie 80 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  12. Fahren Sie mit diesem Muster fort, bis das Berichtsobjekt aktualisiert wurde oder eine maximale verstrichene Zeit erreicht ist.

Wenn die Ausführung des Berichts abgeschlossen ist und im Status DONE endet, können Sie die generierte Berichtsdatei aus Google Cloud Storage über den Pfad im Feld metadata.googleCloudStoragePath abrufen.