Sprawdzone metody i ograniczenia

Podczas korzystania z BatchJobService weź pod uwagę te wskazówki.

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 niepodzielnych podgrupach). Jeśli np. zadanie zawiera operacje dodawania standardowych kampanii, grup reklam i ich kryteriów, 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 może być grupowanie operacji według grupy reklam niż mieszanie operacji, które wpływają na kryteria w różnych grupach reklam.

Niepodzielność podczas dzielenia wsadowego

Interfejs Google Ads API dzieli operacje w przesłanym zadaniu wsadowym na mniejsze podzbiory, które następnie przetwarza. Standardowe podzbiory są wykonywane z włączonym częściowym niepowodzeniem, ale podzbiory niektórych współzależnych operacji są przetwarzane niepodzielnie jako pojedyncza transakcja:

W przypadku podzbiorów tworzenia AssetGroup i kampanii Performance Max Campaign (łącznie do 1000 operacji na podzbiór; wszystkie operacje podrzędne create powyżej 999 są przenoszone do następnego niepodzielnego podzbioru):

  • Nadrzędna operacja create (resource_name na AssetGroup lub Campaign) i jej kolejne podrzędne operacje create (asset_group na AssetGroupAsset lub campaign na CampaignAsset) muszą określać ten sam ujemny tymczasowy identyfikator.
  • Umieść wszystkie wymagane operacje AssetOperation (create) dla nowych zasobów Asset przed nadrzędną operacją AssetGroupOperation lub CampaignOperation (create), nigdy między nadrzędną operacją create a jej podrzędnymi operacjami create (co spowodowałoby natychmiastowe zamknięcie niepodzielnej podgrupy i oddzielenie tworzenia zasobu nadrzędnego od połączonych z nim zasobów).

Gdy nie powiedzie się podrzędna operacja wsadowa, BatchJobResult.status operacji, która spowodowała błąd, zawiera błąd weryfikacji, a pozostałe operacje w tej podrzędnej operacji wsadowej są wycofywane z odpowiednim błędem transakcji. Sprawdź sąsiednie wpisy BatchJobResult, które mają ten sam identyfikator AdGroup, AssetGroup lub Campaign, aby zidentyfikować 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 podzbiory, co spowoduje, że modyfikacja nie spełni minimalnych wymagań dotyczących komponentów lub pozostawi niekompletne drzewa grup informacji o produktach. 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) lub tworzenia nowej grupy reklam (AssetGroup) lub grupy komponentów kampanii Performance Max (Campaign) grupuj kolejno wszystkie operacje kierowane na ten sam zasób nadrzędny (AssetGroup, AdGroup lub Campaign). Zmniejsza to rywalizację o blokadę backendu i utrzymuje współzależne drzewa razem.

Spójność danych

Drzewa filtrów grup informacji o produktach i wymagania dotyczące komponentów kampanii Performance Max są sprawdzane na końcu każdej niepodzielnej transakcji podzbioru, dlatego unikaj dzielenia aktualizacji tego samego zasobu nadrzędnego na nieciągłe zakresy w ramach zadania lub między równoczesnymi zadaniami.

Unikanie problemów z równoczesnością

  • Podczas przesyłania wielu równoczesnych zadań na to samo konto staraj się zmniejszyć 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, próbuje zmieniać ten sam zestaw obiektów, co może prowadzić do sytuacji podobnych do zakleszczenia, powodujących znaczne spowolnienie, a nawet niepowodzenie zadań.

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

Optymalne pobieranie wyników

  • Nie sprawdzaj stanu zadania zbyt często, ponieważ możesz przekroczyć limit liczby żądań.

  • Podczas wywoływania metody ListBatchJobResults nie ustawiaj parametru page_size (lub ustaw go na maksymalną wartość 1000), aby zminimalizować liczbę operacji stronicowania w obie strony. Parametr response_content_type ustaw na wartość MUTABLE_RESOURCE tylko wtedy, gdy aplikacja sprawdza zwrócone pola zasobów inne niż 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 być wykonywane, zanim zostanie anulowane. Podczas tworzenia nowego zadania wsadowego ustaw w polu metadata.execution_limit_seconds preferowany limit czasu w sekundach. Jeśli nie ustawisz właściwości metadata.execution_limit_seconds, nie będzie domyślnego limitu czasu.

  • Chociaż limit protokołu wynosi 10 000 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 AddBatchJobOperations zwraca błąd ResourceCountLimitExceededError.RESOURCE_LIMIT (z ResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOB w ErrorDetails.resource_count_details).

  • Każde konto może mieć jednocześnie do 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żda metoda AddBatchJobOperationsRequest ma sztywny limit 10 000 operacji mutacji na żądanie. Przekroczenie 10 000 operacji w jednym żądaniu powoduje błąd BatchJobError.REQUEST_TOO_LARGE.

  • W polu page_size w ListBatchJobResultsRequest:

    • Jeśli parametr page_size nie jest ustawiony lub ma wartość 0, domyślnie przyjmuje wartość maksymalną 1000.
    • Jeśli wartość page_size przekracza 1000 lub jest 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 odrzucenie nastąpiło w warstwie transportowej). 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

Chociaż łączny rozmiar żądania może wynosić do 41 937 920 bajtów, zserializowany rozmiar pojedynczego elementu MutateOperation w ramach zbioru jest ograniczony do 10 484 504 bajtów (10 MiB minus 1256 bajtów). Przekroczenie tego limitu powoduje błąd 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 dowolny z 3 progów żądania (41 937 920 bajtów na żądanie, 10 484 504 bajtów na operację lub 10 000 operacji na wywołanie). Pole message błędu określa, który limit został przekroczony.

Wstecz
Filtry grup informacji o produktach