Sprawdzone metody raportowania

Zacznij od tworzenia nowych raportów w interfejsie

Raporty podlegają wielu ograniczeniom i wymaganiom związanym z typami raportów, filtrami, wymiarami i danymi. Te ograniczenia są egzekwowane w interfejsie API i zwracają błąd HTTP 400. Aby uniknąć błędów podczas tworzenia raportów, zalecamy, aby najpierw utworzyć nowe raporty w interfejsie Display & Video 360.

Po utworzeniu raportu kliknij funkcję „Wypróbuj ten interfejs API” na stronie z dokumentacją z dokumentacją, aby wykonać queries.get z zasobu Query. Zwróconego pliku JSON możesz użyć do tworzenia przyszłych raportów.

Używanie danych i filtrów dostosowanych do typu raportu

Niektóre wartości danych i filtrów są przypisane do określonych typów raportów. Oprócz tworzenia raportów w interfejsie możesz też identyfikować dane i filtry należące do określonych wartości ReportType według ich wartości w interfejsie Bid Manager API.

Poniżej znajdziesz kilka sposobów na znalezienie odpowiednich filtrów i wartości danych w interfejsie Bid Manager API. Ta tabela nie zawiera pełnej listy filtrów i danych, których można używać w tego typu raportach. Nie wszystkie wartości można wykorzystać w jednym raporcie.

ReportType Odpowiednie filtry i dane
INVENTORY_AVAILABILITY
  • Filtry z prefiksem FILTER_TRUEVIEW_IAR.
YOUTUBE
  • Filtry z prefiksem FILTER_TRUEVIEW oprócz filtrów z prefiksem FILTER_TRUEVIEW_IAR.
  • Dane z prefiksem METRIC_TRUEVIEW.
GRP
  • Dane z prefiksem METRIC_GRP.
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • Filtry z prefiksem FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED.
  • Dane z prefiksem METRIC_PROGRAMMATIC_GUARANTEED.
REACH
  • Dane z prefiksem METRIC_UNIQUE_REACH.
UNIQUE_REACH_AUDIENCE
  • Dane z prefiksem METRIC_UNIQUE_REACH.

Zapisywanie raportów i ich ponowne używanie

Zalecamy tworzenie i zapisywanie raportów dotyczących regularnie wykonywanych zapytań, ponieważ wielokrotne wstawianie i usuwanie tego samego raportu marnuje zasoby. Używanie ustawionych wartości Range, takich jak PREVIOUS_DAY lub LAST_7_DAYS, w polu dataRange ułatwia ponowne wykorzystanie raportów.

Planowanie raportów

Raporty doraźne i jednorazowe mogą powodować marnowanie zasobów, ponieważ są one uruchamiane pojedynczo i mogą być generowane na podstawie niepełnego zbioru danych. Zaplanowane raporty pozwalają w pełni wykorzystać zasoby raportów, ponieważ są generowane zbiorczo i gwarantowane są, że nie zostaną wykonane przed zakończeniem przetwarzania danych z poprzedniego dnia. Aby dowiedzieć się więcej, zobacz 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 łączenie tych raportów, aby zoptymalizować ich liczbę.

Możesz łączyć podobne raporty, dołączając filtry do wszystkich raportów i dodając wszystkie typy filtrów jako wymiary. Po wygenerowaniu raportu możesz podzielić wiersze wynikowego raportu według pierwotnych wartości filtrów, aby uzyskać pierwotne raporty.

Rozważ limity raportowania

Odpowiedzialne korzystanie z funkcji raportowania Display & Video 360 jest wymuszane w ramach podanych niżej limitów wykorzystania w całej usłudze.

Doraźne uruchomienia raportów dziennie

Ogranicza liczbę raportów doraźnych, które użytkownik może wygenerować w ciągu 24 godzin. Aby go nie przekroczyć:

Aktywne zaplanowane raporty

Ogranicza liczbę raportów, które użytkownik może aktywnie zaplanować w określonym czasie. Aby go nie przekroczyć:

  • Połącz podobne zaplanowane raporty, by zmniejszyć ogólną liczbę zaplanowanych raportów.
  • Wyłącz niepotrzebne zaplanowane raporty.
  • Dezaktywuj niepotrzebne skrypty interfejsu API.

Raporty równoczesne

Ogranicza liczbę raportów, które użytkownik może wygenerować jednocześnie. Aby go nie przekroczyć:

  • Zaplanuj regularne generowanie raportów.
  • Dezaktywuj niepotrzebne skrypty interfejsu API.
  • Śledź zakończenie raportów, przeprowadzając odpytywanie za pomocą logiki wykładniczej ponowienia.

Jeśli po zoptymalizowaniu implementacji raportowania nadal przekraczasz swój limit, skontaktuj się z zespołem pomocy Display & Video 360, korzystając z formularza kontaktowego.

Używaj wykładniczego ponowienia podczas odpytywania o stan raportu

Nie można przewidzieć, jak długo potrwa generowanie raportu. Czas ten może wynosić od kilku sekund do godzin i zależy od wielu czynników, m.in. zakresu dat i ilości danych do przetworzenia. Nie ma też związku między czasem działania raportu a liczbą wierszy zwracanych w tym raporcie. Dlatego musisz regularnie pobierać zasób raportu przy użyciu 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 wyświetlanie jest zakończone. Jest to tzw. przeprowadzanie ankiety.

Odpytywanie jest konieczne, ale jego nieefektywne wdrożenie może szybko wyczerpać limit w przypadku długotrwałych raportów. Dlatego zalecamy użycie wykładniczego ponowienia, aby ograniczyć liczbę ponownych prób i zaoszczędzić limit.

Wykładniczy czas ponowienia

Wykładniczy czas ponowienia to standardowa strategia obsługi błędów w aplikacjach sieciowych, w której klient co jakiś czas ponawia próbę żądania przez dłuższy czas. Poprawne wykorzystanie wykładniczego ponowienia zwiększa wydajność wykorzystania przepustowości, zmniejsza liczbę żądań wymaganych do uzyskania pomyślnej odpowiedzi i maksymalizuje przepustowość żądań w równoczesnych środowiskach.

Proces implementacji prostego wykładniczego ponowienia jest następujący:

  1. Wyślij żądanie queries.reports.get do interfejsu API.
  2. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie zawiera wartości DONE ani FAILED, oznacza to, że generowanie raportu nie zostało zakończone, aby kontynuować odpytywanie.
  3. Odczekaj 5 sekund (plus losowa liczba milisekund) i spróbuj ponownie.
  4. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie zawiera wartości DONE ani FAILED, oznacza to, że generowanie raportu nie zostało zakończone, aby kontynuować odpytywanie.
  5. Zaczekaj 10 sekund + losową liczbę milisekund i spróbuj ponownie.
  6. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie zawiera wartości DONE ani FAILED, oznacza to, że generowanie raportu nie zostało zakończone, aby kontynuować odpytywanie.
  7. Zaczekaj 20 sekund + losową liczbę milisekund i spróbuj ponownie.
  8. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie zawiera wartości DONE ani FAILED, oznacza to, że generowanie raportu nie zostało zakończone, aby kontynuować odpytywanie.
  9. Zaczekaj 40 sekund + losową liczbę milisekund i spróbuj ponownie.
  10. Pobierz obiekt raportu. Jeśli pole metadata.status.state nie zawiera wartości DONE ani FAILED, oznacza to, że generowanie raportu nie zostało zakończone, aby kontynuować odpytywanie.
  11. Zaczekaj 80 sekund (plus losową liczbę milisekund) i spróbuj ponownie.
  12. Kontynuuj ten wzorzec, dopóki obiekt raportu nie zostanie zaktualizowany lub nie upłynie maksymalny czas trwania.

Gdy zakończy się tworzenie raportu i zakończy się jego stanem DONE, wygenerowany plik raportu możesz pobrać z Google Cloud Storage przy użyciu ścieżki podanej w polu metadata.googleCloudStoragePath.