Sprawdzone metody i ograniczenia

Korzystając z funkcji BatchJobService, pamiętaj o tych wskazówkach.

Zwiększanie przepustowości

  • Preferowana jest mniejsza liczba większych zadań niż wiele mniejszych.

  • Uporządkuj przesłane operacje według ich typu (z wyjątkiem operacji współzależnych, które muszą być zgrupowane kolejno w atomowych podgrupach). Jeśli np. zadanie zawiera operacje dodawania kampanii standardowych, grup reklam i kryteriów grup reklam, uporządkuj operacje w przesłanym pliku tak, aby najpierw były wszystkie operacje dotyczące kampanii, potem wszystkie operacje dotyczące grup reklam, a na końcu wszystkie operacje dotyczące kryteriów grup reklam.

  • W przypadku operacji tego samego typu wydajność można zwiększyć, grupując je według zasobu nadrzędnego. Jeśli na przykład masz serię obiektów AdGroupCriterionOperation, bardziej efektywne jest grupowanie operacji według grupy reklam niż mieszanie operacji, które wpływają na kryteria w różnych grupach reklam.

Atomowość w przypadku dzielenia wsadowego

Interfejs Google Ads API dzieli operacje w przesłanym zadaniu wsadowym na mniejsze podzbiory do przetworzenia. Podczas gdy standardowe podpartie są wykonywane z włączonym częściowym błędem, podpartie w przypadku niektórych współzależnych operacji są przetwarzane atomowo jako pojedyncza transakcja:

W przypadku podgrup tworzenia AssetGroup i kampanii Performance Max Campaign (maksymalnie 1000 operacji w podgrupie; wszystkie operacje podrzędne create powyżej 999 są przenoszone do następnej nieatomowej podgrupy):

  • Operacja nadrzędna create (resource_name w przypadku AssetGroup lub Campaign) i kolejne operacje podrzędne create (asset_group w przypadku AssetGroupAsset lub campaign w przypadku CampaignAsset) muszą określać ten sam ujemny tymczasowy identyfikator.
  • Umieść wszystkie operacje AssetOperation (create) wymagane do utworzenia nowych zasobów Asset przed zasobem nadrzędnym AssetGroupOperation lub CampaignOperation (create), nigdy między zasobem nadrzędnym create a operacjami jego linku podrzędnego create (co spowodowałoby natychmiastowe zamknięcie atomowej podgrupy i rozdzielenie tworzenia zasobu nadrzędnego od jego połączonych komponentów).

Jeśli nie powiedzie się atomowa partia podrzędna, BatchJobResult.status operacji powodującej błąd zawiera podstawowy błąd weryfikacji, a pozostałe operacje w tej partii podrzędnej są wycofywane z odpowiednim błędem transakcji dla tej partii podrzędnej. Sprawdź sąsiednie wpisy BatchJobResult, które mają ten sam identyfikator AdGroup, AssetGroup lub Campaign, aby określić główną przyczynę błędu.

Jeśli powiązane operacje w którejkolwiek z tych grup nie zostaną dodane kolejno, interfejs Google Ads API podzieli je na osobne podpartie, co spowoduje, że modyfikacja nie spełni minimalnych wymagań dotyczących komponentów lub drzewa grup informacji o produktach będą niekompletne. Więcej informacji znajdziesz w artykułach Używanie filtrów grup informacji o produktach w zadaniach wsadowych i Przetwarzanie wsadowe w kampaniach Performance Max.

Grupowanie logiczne

Podczas modyfikowania hierarchii kierowania na produkty (AssetGroupListingGroupFilterOperation w kampaniach Performance Max lub AdGroupCriterionOperation w kampaniach produktowych) albo tworzenia nowej AssetGroup lub kampanii Performance Max Campaign grupuj wszystkie operacje kierowane na to samo zasoby nadrzędne (AssetGroup, AdGroup lub Campaign) w sposób ciągły. Zmniejsza to rywalizację o blokady na backendzie i utrzymuje powiązane ze sobą drzewa razem.

Spójność danych

Drzewa filtrów grup informacji o produktach i wymagania dotyczące komponentów w kampaniach Performance Max są weryfikowane na końcu każdej transakcji atomowej podgrupy, dlatego unikaj dzielenia aktualizacji tego samego zasobu nadrzędnego na nieciągłe zakresy w ramach zadania lub na równoległe zadania.

Unikanie problemów z jednoczesnym dostępem

  • Podczas przesyłania wielu równoczesnych zadań na to samo konto zmniejsz prawdopodobieństwo, że zadania będą działać na tych samych obiektach w tym samym czasie, jeśli utrzymujesz duże rozmiary zadań. Wiele niedokończonych zadań, które mają stan RUNNING i próbują zmieniać ten sam zestaw obiektów, może prowadzić do sytuacji podobnych do zakleszczenia, powodujących znaczne spowolnienie, a nawet niepowodzenie zadań.

  • Nie przesyłaj w tym samym zadaniu wielu operacji, które zmieniają ten sam obiekt, ponieważ wynik może być nieprzewidywalny.

Optymalne pobieranie wyników

  • Nie sprawdzaj stanu zadania zbyt często, aby uniknąć błędów związanych z limitem liczby żądań.

  • Pozostaw parametr page_size bez ustawienia (lub ustaw go na maksymalną wartość 1000) podczas wywoływania funkcji ListBatchJobResults, aby zminimalizować liczbę rund związanych ze stronicowaniem, i ustaw parametr response_content_type na wartość MUTABLE_RESOURCE tylko wtedy, gdy aplikacja sprawdza pola zwracanego zasobu poza resource_name.

  • Kolejność wyników jest taka sama jak kolejność przesyłania.

Dodatkowe wskazówki dotyczące użytkowania

  • Możesz ustawić górną granicę czasu, przez jaki zadanie wsadowe może działać, zanim zostanie anulowane. Podczas tworzenia nowego zadania wsadowego ustaw w polu metadata.execution_limit_seconds preferowany limit czasu w sekundach. Jeśli parametr metadata.execution_limit_seconds nie jest ustawiony, nie ma domyślnego limitu czasu.

  • Chociaż limit protokołu wynosi 10 tys. operacji na żądanie, zalecamy dodawanie nie więcej niż 1000 operacji na AddBatchJobOperationsRequest i używanie sequence_token do przesyłania pozostałych operacji do tego samego zadania. W zależności od rozmiaru operacji wysłanie zbyt wielu operacji w jednym AddBatchJobOperationsRequest może spowodować błąd BatchJobError.REQUEST_TOO_LARGE. Możesz rozwiązać ten problem, zmniejszając liczbę operacji i ponawiając próbę AddBatchJobOperationsRequest.

Ograniczenia

  • Każde BatchJob obsługuje do miliona operacji. Przekroczenie tego limitu podczas wywoływania funkcji AddBatchJobOperations zwraca błąd ResourceCountLimitExceededError.RESOURCE_LIMIT (z wartością ResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOB w parametrze ErrorDetails.resource_count_details).

  • Każde konto może mieć jednocześnie maksymalnie 100 aktywnych lub oczekujących zadań. Przekroczenie tego limitu podczas tworzenia zadania wsadowego za pomocą MutateBatchJob powoduje zwrócenie błędu ResourceCountLimitExceededError.RESOURCE_LIMIT (z ResourceLimitType.BATCH_JOBS_PER_CUSTOMER w ErrorDetails.resource_count_details).

  • Zadania oczekujące od ponad 7 dni są automatycznie usuwane.

  • Każde AddBatchJobOperationsRequest ma limit 10 000 operacji zmiany na żądanie. Przekroczenie 10 tys. operacji w jednym żądaniu powoduje zwrócenie błędu BatchJobError.REQUEST_TOO_LARGE.

  • W polu page_size w sekcji ListBatchJobResultsRequest:

    • Jeśli parametr page_size nie jest ustawiony lub ma wartość 0, domyślnie przyjmuje wartość maksymalną, czyli 1000.
    • Jeśli wartość page_size jest większa niż 1000 lub mniejsza niż 0, interfejs API zwraca błąd BatchJobError.INVALID_PAGE_SIZE.

  • Każde AddBatchJobOperationsRequest może mieć maksymalnie 41 937 920 bajtów. Jeśli przekroczysz ten limit, otrzymasz błąd BatchJobError.REQUEST_TOO_LARGE (lub INTERNAL_ERROR, jeśli żądanie zostanie odrzucone na poziomie transportu). Możesz określić rozmiar żądania przed jego przesłaniem i podjąć odpowiednie działania, jeśli jest ono zbyt duże:

    Java

    
static final int MAX_REQUEST_BYTES = 41_937_920;

// ... (code to get the AddBatchJobOperationsRequest object)

int sizeInBytes = request.getSerializedSize();

    C#

    
const int MAX_REQUEST_BYTES = 41_937_920;

// ... (code to get the AddBatchJobOperationsRequest object)

int sizeInBytes = request.CalculateSize();

    PHP

    
const MAX_REQUEST_BYTES = 41937920;

// ... (code to get the AddBatchJobOperationsRequest object)

$size_in_bytes = $request->byteSize();

    Python

    
MAX_REQUEST_BYTES = 41_937_920

# ... (code to get the AddBatchJobOperationsRequest object)

size_in_bytes = type(request).pb(request).ByteSize()

    Ruby

    
MAX_REQUEST_BYTES = 41_937_920

# ... (code to get the AddBatchJobOperationsRequest object)

size_in_bytes = request.to_proto.bytesize

    Perl

    
use JSON::XS;
use constant MAX_REQUEST_BYTES => 41937920;

# ... (code to get the AddBatchJobOperationsRequest object)

# The Perl client library uses REST/JSON; UTF-8 JSON byte length provides a
# conservative upper-bound estimate of the serialized request size.
my $json_encoder = JSON::XS->new->utf8->convert_blessed;
my $size_in_bytes = length($json_encoder->encode($request));

Rozmiar pojedynczej operacji zmiany

Całkowity rozmiar żądania może wynosić do 41 937 920 bajtów, ale rozmiar serializowany pojedynczego elementu MutateOperation w partii jest ograniczony do 10 484 504 bajtów (10 MiB minus 1256 bajtów). Przekroczenie tego limitu spowoduje zwrócenie błędu BatchJobError.REQUEST_TOO_LARGE. Pamiętaj, że chociaż dokumentacja referencyjna BatchJobError.REQUEST_TOO_LARGE podaje próg 10 484 504 bajtów, AddBatchJobOperations zwraca ten sam kod błędu, gdy zostanie przekroczony którykolwiek z 3 progów żądań (41 937 920 bajtów łącznie, 10 484 504 bajtów w przypadku pojedynczej operacji lub 10 000 operacji na wywołanie), a pole message błędu określa, który limit został przekroczony.

Wstecz
Filtry grup informacji o produktach