Interfejs API Bid Managera w wersji 1.1 został wycofany w sierpniu 2022 r. i zostanie wycofany 28 lutego 2023 r.

Aby uniknąć przerw w działaniu usługi, przejdź na v2. Informacje o migracji do wersji 2 znajdziesz w naszym przewodniku po migracji.

Sprawdzone metody raportowania

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Najpierw utwórz nowe raporty w interfejsie

Raportowanie podlega pewnym ograniczeniom i wymaganiom związanym z typami raportów, filtrami, wymiarami i danymi. Te ograniczenia są wymuszane w interfejsie API i zwraca błąd 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 kliknij "Try this API" feature na stronie dokumentacji, aby wykonać queries.get zasobu Query. Zwrócony plik JSON może służyć do tworzenia przyszłych raportów.

Zapisywanie i ponowne używanie raportów

Zalecamy tworzenie i zapisywanie raportów generowanych regularnie, ponieważ wstawianie i usuwanie tego samego raportu wiele razy marnuje się zasoby. Korzystanie z ustawionych wartości Range, takich jak PREVIOUS_DAY lub LAST_7_DAYS, w polu dataRange sprawia, że raporty można wykorzystać ponownie.

Planowanie raportów

Raporty doraźne lub jednorazowe mogą być nadmiernym wykorzystaniem zasobów, ponieważ są uruchamiane pojedynczo i mogą być wykonane w przypadku niepełnego zbioru danych. Zaplanowane raporty w najlepszy sposób wykorzystują zasoby raportowania, bo są generowane zbiorczo, a ich realizacja nie jest możliwa do momentu zakończenia przetwarzania danych z poprzedniego dnia. Więcej informacji znajdziesz w dostępnych polach 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 ich połączenie w celu zoptymalizowania liczby raportów.

Możesz połączyć podobne raporty, łącząc filtry we wszystkich raportach i dodając wszystkie typy filtrów jako wymiary. Po wygenerowaniu możesz podzielić wiersze wynikowego wzdłuż oryginalnych wartości filtra, aby wygenerować oryginalne raporty.

Rozważ limity raportowania

Odpowiedzialne korzystanie z funkcji raportowania w Display &Video 360 jest egzekwowane przez podane niżej limity wykorzystania w całej usłudze.

Dzienne wykonywanie raportów na bieżąco

Ogranicza liczbę jednorazowych raportów generowanych przez użytkownika w ciągu 24 godzin. Aby nie przekroczyć tego limitu:

Aktywne zaplanowane raporty

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

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

Transmisje równoległe

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

  • Zaplanuj regularne generowanie raportów.
  • Dezaktywuj niepotrzebne skrypty interfejsu API.
  • Śledź generowane raporty, przeprowadzając ankiety za pomocą logiki wykładniczej wstecznej.

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

Użyj wzrastającego czasu do ponowienia w przypadku sondowania stanu raportu

Nie można przewidzieć, jak długo potrwa generowanie raportu. Może to być od wielu sekund do wielu godzin, w zależności od wielu czynników, takich jak zakres dat czy ilość danych, które mają zostać przetworzone. Nie ma też związku między czasem trwania raportu a liczbą wierszy zwróconych w raporcie. Dlatego musisz regularnie pobierać zasób raportu za pomocą metody queries.reports.get i sprawdzić, czy pole metadata.status.state zasobu zostało zaktualizowane do DONE lub FAILED, aby sprawdzić, czy zostało zakończone. Jest to proces znany jako "polling&quot.

Sondowanie jest konieczne, ale mało wydajna implementacja może szybko wyczerpać limit, gdy napotykasz długi raport. Dlatego zalecamy używać wzrastającego czasu do ponowienia w celu ograniczenia liczby ponownych prób i oszczędzania limitu.

Wykładnicze ponowienie

Wykładnikowe ponowienie to standardowa strategia obsługi błędów w aplikacjach sieciowych, w której klient okresowo próbuje ponownie wysyłać żądania przez coraz dłuższy czas. Prawidłowo używane pogłębianie zwiększa wydajność wykorzystania przepustowości, zmniejsza liczbę żądań niezbędnych do uzyskania odpowiedzi i maksymalizuje przepustowość w środowiskach równoczesnych.

Proces implementacji prostego pogłębiania wykładniczego wygląda tak:

  1. Wyślij żądanie queries.reports.get do interfejsu API.
  2. Pobieranie obiektu raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został zakończony, więc należy kontynuować sondowanie.
  3. Zaczekaj 5 sekund + losowa liczba milisekund i spróbuj ponownie.
  4. Pobieranie obiektu raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został zakończony, więc należy kontynuować sondowanie.
  5. Zaczekaj 10 sekund + losowa liczba milisekund i spróbuj ponownie.
  6. Pobieranie obiektu raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został zakończony, więc należy kontynuować sondowanie.
  7. Zaczekaj 20 sekund + losowa liczba milisekund i spróbuj ponownie.
  8. Pobieranie obiektu raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został zakończony, więc należy kontynuować sondowanie.
  9. Zaczekaj 40 sekund + losowa liczba milisekund i spróbuj ponownie.
  10. Pobieranie obiektu raportu. Jeśli pole metadata.status.state nie ma wartości DONE ani FAILED, oznacza to, że raport nie został zakończony, więc należy kontynuować sondowanie.
  11. Zaczekaj 80 sekund i losową liczbę milisekund i spróbuj ponownie.
  12. Powtarzaj ten wzorzec, aż obiekt raportu zostanie zaktualizowany lub upłynie maksymalny czas, który upłynął.

Jeśli raport zakończy się i zakończy się stanem DONE, będzie można pobrać wygenerowany plik raportu z Google Cloud Storage w ścieżce podanej w polu metadata.googleCloudStoragePath.