Best Practices für die Berichterstellung

Neue Berichte zuerst in der Benutzeroberfläche erstellen

Für Berichte gelten eine Reihe von Einschränkungen und Anforderungen im Hinblick auf Berichtstypen, Filter, Dimensionen und Messwerte. Diese Einschränkungen werden in der API erzwungen und es wird ein HTTP 400-Fehler zurückgegeben. Um Fehler beim Erstellen von Berichten zu vermeiden, empfehlen wir, neue Berichte zuerst in der Display & Video 360-Benutzeroberfläche zu erstellen.

Klicken Sie nach dem Erstellen des Berichts auf der Seite mit den Referenzdokumenten auf die Funktion API testen, um eine queries.get der Query-Ressource auszuführen. Sie können die zurückgegebene JSON-Datei für zukünftige Berichte verwenden.

Verwenden Sie Messwerte und Filter, die für den Berichtstyp spezifisch sind.

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

Hier sind einige Möglichkeiten, relevante Bid Manager API-Filter und Messwertwerte zu ermitteln. Diese Tabelle enthält keine vollständige Liste der Filter und Messwerte, die in diesen Berichtstypen verwendet werden können. Nicht alle Werte können in einem Bericht verwendet werden.

ReportType Relevante Filter und Messwerte
YOUTUBE
  • Filter mit dem Präfix FILTER_TRUEVIEW
  • 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

Wir empfehlen, Berichte für Abfragen zu erstellen und zu speichern, die Sie regelmäßig ausführen. Das Einfügen und Löschen desselben Berichts mehrmals verschwendet Ressourcen. Wenn Sie im Feld dataRange festgelegte Range-Werte wie PREVIOUS_DAY oder LAST_7_DAYS verwenden, können Berichte wiederverwendet werden.

Berichte planen

Ad-hoc- oder einmalige Berichte können Ressourcen verschwenden, da sie einzeln ausgeführt werden und möglicherweise auf einem unvollständigen Datensatz basieren. Bei geplanten Berichten werden die Ressourcen für die Berichterstellung optimal genutzt, da sie im Bulk-Verfahren ausgeführt werden und erst dann, wenn die Verarbeitung der Daten des Vortags abgeschlossen ist. Weitere Informationen finden Sie unter Verfügbare Planungsfelder.

Ähnliche Berichte kombinieren

Wenn Sie regelmäßig Berichte mit identischen Messwerten und Zeiträumen für verschiedene Werbetreibende oder Partner erstellen, empfehlen wir Ihnen, die Berichte zu kombinieren, um das 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 der Generierung können Sie die Zeilen des resultierenden Berichts nach den ursprünglichen Filterwerten aufteilen, um die ursprünglichen Berichte zu erstellen.

Kontingente für Berichte berücksichtigen

Die verantwortungsvolle Nutzung der Berichtsfunktion in Display & Video 360 wird durch die folgenden produktweiten Nutzungsquoten erzwungen.

Ausführungen von Ad-hoc-Berichten pro Tag

Hiermit wird die Anzahl der Ad-hoc-Berichte begrenzt, die ein Nutzer innerhalb von 24 Stunden erstellen kann. So verhindern Sie, dass Sie das Kontingent überschreiten:

Aktive geplante Berichte

Hiermit wird die Anzahl der Berichte begrenzt, die ein Nutzer zu einem bestimmten Zeitpunkt aktiv planen kann. So verhindern Sie, dass Sie das Kontingent überschreiten:

Gleichzeitige Berichte

Begrenzt die Anzahl der Berichte, die ein Nutzer gleichzeitig ausführen kann. So verhindern Sie, dass Sie das Kontingent überschreiten:

  • Planen Sie Berichte, die regelmäßig ausgeführt werden.
  • Deaktivieren Sie nicht erforderliche API-Scripts.
  • Sie können mithilfe von exponentiellem Backoff prüfen, ob Ihre Berichte fertig sind.

Wenn Sie Ihre Berichterstellung optimiert haben und das angegebene Kontingent dennoch überschreiten, wenden Sie sich über das Kontaktformular an den Display & Video 360-Support.

Exponentiellen Backoff beim Abfragen des Berichtsstatus verwenden

Es lässt sich nicht vorhersagen, wie lange die Ausführung eines Berichts dauert. Die Dauer kann von Sekunden bis zu Stunden variieren, je nach vielen Faktoren wie dem Zeitraum und der Menge der zu verarbeitenden Daten. Es besteht auch keine Korrelation zwischen der Berichtslaufzeit und der Anzahl der Zeilen, die im Bericht zurückgegeben werden. Sie müssen daher 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 abgeschlossen ist. Dieser Vorgang wird als „Polling“ bezeichnet.

Abfragen sind zwar erforderlich, aber eine ineffiziente Implementierung kann bei einem lang laufenden Bericht schnell Ihr Kontingent aufbrauchen. Wir empfehlen daher, das exponentielle Backoff zu verwenden, um Neuversuche zu begrenzen und das Kontingent zu schonen.

Exponentielle Backoffs

Exponentielle Backoffs bilden eine Standard-Fehlerbehandlungsstrategie für Netzwerkanwendungen, bei denen der Client eine Anfrage über einen immer länger werdenden Zeitraum periodisch wiederholt. Bei richtiger Anwendung erhöht der exponentielle Backoff die Effizienz der Bandbreitennutzung, verringert die Anzahl der Anfragen, die für den Erhalt einer erfolgreichen Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in Umgebungen mit Gleichzeitigkeit.

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 im Feld metadata.status.state kein Wert wie DONE oder FAILED steht, ist die Ausführung des Berichts noch nicht abgeschlossen. Sie sollten die Abfrage fortsetzen.
  3. Warten Sie 5 Sekunden + eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  4. Rufen Sie das Berichtsobjekt ab. Wenn im Feld metadata.status.state kein Wert wie DONE oder FAILED steht, ist die Ausführung des Berichts noch nicht abgeschlossen. Sie sollten die Abfrage fortsetzen.
  5. Warten Sie 10 Sekunden + eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  6. Rufen Sie das Berichtsobjekt ab. Wenn im Feld metadata.status.state kein Wert wie DONE oder FAILED steht, ist die Ausführung des Berichts noch nicht abgeschlossen. Sie sollten die Abfrage fortsetzen.
  7. Warten Sie 20 Sekunden + eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  8. Rufen Sie das Berichtsobjekt ab. Wenn im Feld metadata.status.state kein Wert wie DONE oder FAILED steht, ist die Ausführung des Berichts noch nicht abgeschlossen. Sie sollten die Abfrage fortsetzen.
  9. Warten Sie 40 Sekunden + eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  10. Rufen Sie das Berichtsobjekt ab. Wenn im Feld metadata.status.state kein Wert wie DONE oder FAILED steht, ist die Ausführung des Berichts noch nicht abgeschlossen. Sie sollten die Abfrage fortsetzen.
  11. Warten Sie 80 Sekunden + eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
  12. Fahren Sie so fort, bis das Berichtsobjekt aktualisiert wurde oder die maximale Zeitspanne erreicht ist.

Wenn der Bericht fertig ist und den Status DONE hat, können Sie die generierte Berichtsdatei unter dem im Feld metadata.googleCloudStoragePath angegebenen Pfad aus Google Cloud Storage abrufen.