Sprawdzone metody raportowania

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.

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:

1. Wyślij żądanie queries.reports.get do interfejsu API.
2. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt.
3. Zaczekaj 5 sekund + losową liczbę milisekund i spróbuj ponownie.
4. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt.
5. Zaczekaj 10 sekund + losową liczbę milisekund i ponów prośbę.
6. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt.
7. Zaczekaj 20 sekund + losową liczbę milisekund i ponów prośbę.
8. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt.
9. Zaczekaj 40 sekund + losową liczbę milisekund i ponów prośbę.
10. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został jeszcze uruchomiony i należy kontynuować odczyt.
11. Zaczekaj 80 sekund + losową liczbę milisekund i spróbuj ponownie.
12. 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.