Najpierw utwórz nowe raporty w interfejsie
Raporty podlegają wielu ograniczeniom i wymaganiom dotyczącym typów raportów, filtrów, wymiarów i danych. Te ograniczenia są egzekwowane w interfejsie API i spowodują zwrócenie błędu HTTP 400
. Aby uniknąć błędów podczas tworzenia raportów, zalecamy najpierw utworzenie nowych raportów w interfejsie Display & Video 360.
Po utworzeniu raportu na stronie dokumentów referencyjnych kliknij funkcję „Wypróbuj to API”, aby wykonać queries.get
za pomocą zasobu Query
. Możesz użyć zwróconego pliku JSON do tworzenia przyszłych raportów.
Używaj danych i filtrów odpowiednich dla danego typu raportu
Niektóre wartości danych i filtrów są charakterystyczne dla określonych typów raportów. Oprócz tworzenia raportów w interfejsie użytkownika możesz też identyfikować dane i filtry należące do określonych wartości ReportType
na podstawie ich wartości w interfejsie API Bid Managera.
Oto kilka sposobów identyfikowania odpowiednich wartości filtrów i danych interfejsu API Bid Managera. Tabela nie zawiera pełnej listy filtrów i danych, których można używać w tych rodzajach raportów. Nie wszystkie wartości można używać razem w jednym raporcie.
ReportType |
Odpowiednie filtry i dane |
---|---|
YOUTUBE |
|
GRP |
|
YOUTUBE_PROGRAMMATIC_GUARANTEED |
|
REACH |
|
UNIQUE_REACH_AUDIENCE |
|
Zapisywanie i ponowne używanie raportów
Zalecamy tworzenie i zapisywanie raportów dotyczących zapytań, które są regularnie wykonywane, ponieważ wielokrotne wstawianie i usuwanie tego samego raportu marnuje zasoby.
Używanie w polu dataRange
wartości Range
, np. PREVIOUS_DAY
lub LAST_7_DAYS
, zwiększa możliwość wielokrotnego używania raportów.
Planowanie raportów
Doraźne lub jednorazowe raporty mogą być nieefektywne pod względem zużycia zasobów, ponieważ są one wykonywane osobno i mogą być realizowane na podstawie niepełnego zbioru danych. Zaplanowane raporty optymalnie wykorzystują zasoby raportowania, ponieważ są wykonywane zbiorczo i nie są uruchamiane, dopóki nie zostaną przetworzone dane z poprzedniego dnia. Więcej informacji znajdziesz w sekcji dostępne pola harmonogramu.
Łączenie podobnych raportów
Jeśli regularnie generujesz raporty z identycznymi danymi i zakresami dat dla różnych reklamodawców lub partnerów, zalecamy połączenie tych raportów, aby zoptymalizować ich liczbę.
Możesz łączyć podobne raporty, dołączając filtry ze wszystkich raportów i dodając wszystkie typy filtrów jako wymiary. Po wygenerowaniu możesz podzielić wiersze raportu według pierwotnych wartości filtra, aby uzyskać pierwotne raporty.
Limity raportowania
Odpowiedzialne korzystanie z funkcji raportowania w Display & Video 360 jest egzekwowane za pomocą tych limitów wykorzystania obejmujących wszystkie usługi:
Doraźne uruchomienia raportu dziennie
Ogranicza liczbę raportów ad hoc, które użytkownik może utworzyć w ciągu 24 godzin. Aby nie przekroczyć tego limitu:
- Połącz podobne raporty, aby zmniejszyć ich liczbę.
- Zaplanuj powtarzające się doraźne raporty, aby zmniejszyć ich liczbę.
- Deaktywuj niepotrzebne skrypty interfejsu API.
Aktywne zaplanowane raporty
Ogranicza liczbę raportów, które użytkownik może aktywnie zaplanować w danym momencie. Aby nie przekroczyć tego limitu:
- Połącz podobne zaplanowane raporty, aby zmniejszyć łączną liczbę zaplanowanych raportów.
- Dezaktywuj niepotrzebne zaplanowane raporty.
- Deaktywuj niepotrzebne skrypty interfejsu API.
Raporty równoczesne
Ogranicza liczbę raportów, które użytkownik może uruchomić jednocześnie. Aby nie przekroczyć tego limitu:
- planować raporty, które są wykonywane regularnie;
- Deaktywuj niepotrzebne skrypty interfejsu API.
- Śledź, kiedy raporty są gotowe, przeprowadzając ankietę z użyciem logiki wzrastającego czasu ponowienia.
Jeśli po optymalizacji implementacji raportowania nadal przekraczasz limit, skontaktuj się z zespołem pomocy Display & Video 360, korzystając z formularza kontaktowego.
Używanie wzrastającego czasu ponowienia podczas sprawdzania stanu raportu
Nie można przewidzieć, jak długo potrwa generowanie raportu. Czas przetwarzania może wynosić od kilku sekund do kilku godzin w zależności od wielu czynników, takich jak zakres dat i ilość danych do przetworzenia. Nie ma też korelacji między czasem wykonywania raportu a liczbą wierszy zwracanych w raporcie. Dlatego musisz regularnie pobierać zasób raportu za pomocą metody queries.reports.get
i sprawdzać, czy pole metadata.status.state
zasobu zostało zaktualizowane do wartości DONE
lub FAILED
, aby określić, czy proces został zakończony. Jest to proces zwany „odpytywaniem”.
Chociaż pobieranie danych jest konieczne, nieefektywne wdrożenie może szybko wyczerpać limit, jeśli raport jest długotrwały. Dlatego zalecamy stosowanie strategii wzrastającego czasu do ponowienia, aby ograniczyć liczbę prób i zaoszczędzić limit.
Wzrastający czas do ponownej próby
Wzrost czasu do ponowienia to standardowa strategia obsługi błędów w przypadku aplikacji sieciowych, w których klient okresowo powtarza żądanie z coraz dłuższym opóźnieniem. Prawidłowo stosowany algorytm ujemnego wygaszania zwiększa efektywność wykorzystania przepustowości, zmniejsza liczbę żądań wymaganych do uzyskania udanej odpowiedzi i maksymalizuje przepustowość żądań w środowiskach współbieżnych.
Schemat implementacji prostego wzrastającego czasu do ponowienia:
- Wyślij żądanie
queries.reports.get
do interfejsu API. - Pobierz obiekt raportu. Jeśli pole
metadata.status.state
nie ma wartościDONE
aniFAILED
, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt. - Zaczekaj 5 sekund + losową liczbę milisekund i spróbuj ponownie.
- Pobierz obiekt raportu. Jeśli pole
metadata.status.state
nie ma wartościDONE
aniFAILED
, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt. - Zaczekaj 10 sekund + losową liczbę milisekund i ponów prośbę.
- Pobierz obiekt raportu. Jeśli pole
metadata.status.state
nie ma wartościDONE
aniFAILED
, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt. - Zaczekaj 20 sekund + losową liczbę milisekund i ponów prośbę.
- Pobierz obiekt raportu. Jeśli pole
metadata.status.state
nie ma wartościDONE
aniFAILED
, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt. - Zaczekaj 40 sekund + losową liczbę milisekund i ponów prośbę.
- Pobierz obiekt raportu. Jeśli pole
metadata.status.state
nie ma wartościDONE
aniFAILED
, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt. - Zaczekaj 80 sekund + losową liczbę milisekund i spróbuj ponownie.
- Powtarzaj ten wzór, dopóki obiekt raportu nie zostanie zaktualizowany lub nie zostanie osiągnięty maksymalny czas trwania.
Jeśli raport zakończy działanie i będzie w stanie DONE
, możesz pobrać wygenerowany plik raportu z Google Cloud Storage pod ścieżką podaną w polu metadata.googleCloudStoragePath
.