Derzeit werden einige Berichtstypen von Offline- auf Sofortberichte umgestellt. Nachdem ein Nutzer migriert wurde, enthalten die Antworten von queries.list vorhandene Sofortberichte. Weitere Informationen finden Sie in unserem Blogpost.

Diese Seite wurde von der Cloud Translation API übersetzt.

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.

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:

Ähnliche Berichte kombinieren, um das Berichtsvolumen zu reduzieren
Planen Sie wiederkehrende Ad-hoc-Berichte, um das Volumen von Ad-hoc-Berichten zu reduzieren.
Deaktivieren Sie unnötige API-Skripts.

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:

Kombinieren Sie ähnliche geplante Berichte, um die Gesamtzahl der geplanten Berichte zu reduzieren.
Deaktivieren Sie unnötige geplante Berichte.
Deaktivieren Sie unnötige API-Skripts.

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:

Stellen Sie eine queries.reports.get-Anfrage an die API.
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.
Warten Sie 5 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
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.
Warten Sie 10 Sekunden plus eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
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.
Warten Sie 20 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
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.
Warten Sie 40 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
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.
Warten Sie 80 Sekunden und eine zufällige Anzahl von Millisekunden und wiederholen Sie die Anfrage.
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.