Limity

W tym dokumencie znajdziesz limity, które obowiązują w Merchant API.

Interfejs Merchant API korzysta z limitów, aby zapewnić stabilne i uczciwe środowisko dla wszystkich użytkowników. Limity zapobiegają nadmiernemu obciążeniu systemu przez pojedynczego użytkownika interfejsu API, co zapewnia wysoką wydajność. Znajomość tych limitów jest kluczowa w zarządzaniu danymi produktów i skalowaniu firmy w Google.

Pojęcia ogólne

Limitami interfejsu Merchant API zarządza się za pomocą grup limitów.

Metody interfejsu API są mapowane na grupy limitów. Struktura tego mapowania może się różnić:

  • Jedna metoda na grupę: niektóre grupy limitów dotyczą tylko jednej metody interfejsu API. Na przykład metoda list data sources (wyświetlanie źródeł danych)accounts.dataSources.list ma własną grupę limitów.
  • Wiele metod w grupie (pakiet): często powiązane metody są łączone w jedną grupę limitów. Wszystkie metody w tej grupie mają te same limity dzienne i minutowe. Typowe przykłady:
    • Grupowanie wszystkich operacji odczytu dla powiązanych metod i zasobów, np.merchant-accounts-read-methods.
    • Grupowanie wszystkich operacji zapisu dla powiązanych metod i zasobów, takich jak merchant-accounts-write-methods.

Każde wywołanie metody liczy się raz, niezależnie od jego typu. list żądanie 250 elementów jest liczone tylko raz, a nie jako 250 get żądań.

Wbudowane grupowanie żądań HTTP nie ma wpływu na limit. Każde pojedyncze żądanie w partii żądań jest liczone jako jedno w ramach limitu. Na przykład żądanie zbiorcze zawierające 500 żądań insert jest rozliczane jako 500 osobnych żądań insert metody.

Wyjątek dotyczący przetwarzania zbiorczego w przypadku regionów dedykowanych: specjalistyczne metody przetwarzania zbiorczego w przypadku regionów (batchCreate, batchUpdate, batchDelete) są liczone jako jedno wywołanie interfejsu API w ramach grupy limitów merchant_regions, niezależnie od liczby operacji w regionie zawartych w ładunku.

Aby skutecznie zarządzać integracją, sprawdź konkretną grupę limitów związaną z każdą metodą interfejsu API, której zamierzasz używać. Szczegóły te znajdziesz w metodzie listy limitów. Więcej informacji znajdziesz w artykule Monitorowanie i widoczność.

Zaktualizuj zasadę

Interfejs Merchant API egzekwuje te zasady dotyczące aktualizacji:

  • Domyślnie możesz aktualizować produkty maksymalnie 2 razy dziennie. Aby zachować zgodność z limitem minutowym, połączenia należy rozłożyć równomiernie w ciągu dnia.
  • Domyślnie możesz aktualizować subkonta maksymalnie 2 razy dziennie. Twój dzienny limit aktualizacji subkonta to łączny limit oparty na łącznej liczbie dozwolonych subkont.
  • Domyślnie możesz wywoływać metody źródła danych na potrzeby subkont, np. list lub create, maksymalnie 2 razy dziennie na subkonto.

Limity liczby żądań

Każda grupa limitów ma 2 rodzaje limitów (i dzienne wykorzystanie):

  • Limit dzienny (quotaLimit): maksymalna liczba żądań dozwolonych dziennie. Limity dzienne są resetowane o 12:00 w południe czasu UTC.
  • Limit na minutę (quotaMinuteLimit): maksymalna liczba żądań dozwolonych na minutę, która kontroluje szybkość żądań. Limity minutowe korzystają z okna ruchomego, w którym okres egzekwowania rozpoczyna się w momencie wykonania pierwszego wywołania interfejsu API dla danej metody i zasobu. Jeśli na przykład wykonasz połączenie o godzinie 10:01:30, okno limitu na minutę dla tej metody będzie trwać do godziny 10:02:30.
  • Dzienne wykorzystanie (quotaUsage): liczba żądań, które zostały już wysłane i zaliczone do limitu dziennego na bieżący dzień. Jeśli pole jest puste, oznacza to, że w przypadku tej grupy nie wykorzystano jeszcze limitu.

W odpowiedzi metody quotas.list znajdziesz 3 pola opisane wcześniej (quotaLimit, quotaMinuteLimit i quotaUsage).

Poszczególne limity dzienne i minutowe znacznie się różnią w zależności od grupy limitów. Operacje o większej oczekiwanej liczbie lub niższym koszcie systemowym, takie jak odczytywanie danych o produktach, mają zwykle wyższe limity. Z kolei bardziej intensywne lub poufne operacje, takie jak modyfikacje konta, mogą mieć niższe limity.

Przydział limitu i hierarchia

W tej sekcji wyjaśniamy, w imieniu kogo interfejs Merchant API śledzi i stosuje wykorzystanie limitu:

Ogólnie limit jest naliczany na podstawie użytkownika, który wysyła żądanie do interfejsu API.

  • Konta samodzielne: w przypadku kont samodzielnych uwierzytelniających wywołanie interfejsu API to żądanie jest wliczane do limitu tego konta.
    • Przykład: sprzedawca Shoe Store A (identyfikator konta: 12345) uwierzytelnia się za pomocą własnego konta usługi, aby wywołać products.insert kierowane na własne konto (accounts/12345). Limit jest wykorzystywany z puli limitów Shoe Store A.
  • Konta zaawansowane: uwierzytelnianie jako konto zaawansowane zużywa limit z puli konta zaawansowanego, nawet jeśli kierujesz reklamy na subkonto.
    • Przykład: agencja Konto do zarządzania sprzedażą detaliczną (identyfikator konta zaawansowanego: 12345) zarządza subkontem Sklep odzieżowy B (identyfikator konta: 11111). Agencja uwierzytelnia się za pomocą własnych danych logowania i wywołuje products.insert, kierując reklamy na sklep odzieżowy B (accounts/11111). Limit jest wykorzystywany z puli konta głównego agencji (identyfikator konta zaawansowanego: 12345), a nie z puli subkonta.
  • Subkonta: gdy wywołania interfejsu API są uwierzytelniane za pomocą danych logowania subkonta, limit jest naliczany w ramach puli tego subkonta. Działa ono tak samo jak konto samodzielne, mimo że jest zarządzane przez nadrzędne konto zaawansowane.
    • Przykład: przy tej samej konfiguracji co wcześniej, jeśli Sklep odzieżowy B (identyfikator konta: 11111) uwierzytelnia się za pomocą danych logowania skonfigurowanych specjalnie dla jego konta podrzędnego, aby wywołać products.insert, kierując je na własne konto (accounts/11111), limit jest wykorzystywany z indywidualnej puli limitów Sklepu odzieżowego B, a pula agencji nadrzędnej pozostaje nietknięta.

Wyjątki od ogólnych reguł

Istnieje kilka wyjątków od ogólnych zasad przydzielania limitów:

  • Accounts.list: Limit dla tej metody jest naliczany na podstawie uwierzytelnionego użytkownika lub konta usługi, które wywołuje metodę, a nie identyfikatora konta Merchant Center. Wykorzystanie limitu nie będzie widoczne na standardowej stronie diagnostyki interfejsu Merchant Center API. Jeśli masz konto zaawansowane, zalecamy użycie metody accounts.listSubaccounts, która jest wliczana do limitu kont zaawansowanych.
  • Metody rozwiązywania problemów: te metody zawsze są wliczane do limitu konta, którego problemy są zgłaszane, nawet jeśli żądanie jest uwierzytelniane przez inne konto.

Hierarchia przydziału

  • Usługi porównywania cen (CSS): są to witryny, które agregują oferty produktów i kierują użytkowników do witryn sprzedawców, aby umożliwić im dokonanie zakupu. Podczas wywoływania interfejsu API limity są stosowane do konkretnej grupy usług porównywania cen, domeny usługi porównywania cen, konta lub subkonta, w przypadku których następuje uwierzytelnianie.

    Przykłady:

    • Grupa usług porównywania cen o nazwie Europe Shopping Group (identyfikator konta: 10001) chce wyświetlić listę powiązanych z nią domen usług porównywania cen. Uwierzytelniając się za pomocą własnych danych logowania w celu wywołania tego interfejsu API, limit jest wykorzystywany bezpośrednio z puli limitów Europe Shopping Group.
    • Domena usługi porównywania cen TopDeals CSS (identyfikator konta: 20002) uwierzytelnia się, aby wywołać metodę kierowaną na jedno z powiązanych z nią kont sprzedawcy (accounts/30003) w celu przypisania etykiety. Limit jest wykorzystywany z puli limitów usługi porównywania cen TopDeals, a nie z puli konta sprzedawcy.

  • Platformy handlowe: platformy internetowe, które hostują wielu sprzedawców indywidualnych. Działają one jak specjalne konta zaawansowane, które umożliwiają tworzenie osobnych subkont dla każdego sprzedawcy.

Diagram poniżej przedstawia hierarchię grup usług porównywania cen, usług porównywania cen, platform handlowych, kont zaawansowanych, kont samodzielnych i subkont.

Grupa usług porównywania cen to nadrzędny poziom uwierzytelniania, w którym mogą znajdować się poszczególne usługi porównywania cen, konta w tych usługach i konta podrzędne jako najbardziej indywidualny poziom.

Automatyczne dostosowywanie limitów

Interfejs Merchant API ma automatyczny system zarządzania limitami dla określonych usług, który dostosowuje limity dla rozwijających się sprzedawców na podstawie wykorzystania, oferty i rozmiaru konta. Interfejs Merchant API codziennie ponownie oblicza te limity.

Grupy limitów uwzględnione w automatycznych dostosowaniach limitów to:

Usługi związane z produktami

  • Wszystkie grupy limitów metod powiązanych z zasobami products i productInputs.
  • Dzienny limit wywołań jest zwykle 2 razy większy niż limit ofert sprzedawcy. Zakładamy, że sprzedawca może potrzebować aktualizować każdy ze swoich produktów maksymalnie 2 razy dziennie.
  • Poszczególne produkty można aktualizować więcej niż 2 razy, ale łączna liczba wywołań interfejsu API w ciągu dnia nie może przekraczać łącznego dziennego limitu wywołań.

Usługi związane z kontami

  • Wszystkie grupy limitów metod powiązanych z różnymi szczegółowymi zasobami związanymi z kontem w interfejsie Merchant API.
  • Dzienny limit wywołań jest ustawiony na maksymalną liczbę subkont dozwolonych dla tego konta. Umożliwia to wykonywanie do 2 odczytów dziennie na subkonto.

Usługi źródeł danych

  • Wszystkie grupy limitów metod związanych z zasobami powiązanymi ze źródłem danych w Merchant API, takimi jak list lub create, które konto zaawansowane wykonuje na swoich subkontach.
  • Dzienny limit wywołań jest zwykle ustawiony na 2-krotność liczby subkont, które ma konto zaawansowane. Zakładamy, że sprzedawca może aktualizować źródła danych każdego subkonta maksymalnie 2 razy dziennie.

Tylko usługi opisane wcześniej mają automatyczne dostosowywanie limitów. Inne usługi mają domyślny limit, a wszelkie zwiększenia muszą być zgłaszane ręcznie. Więcej informacji znajdziesz w sekcji dotyczącej procesu zwiększania limitu.

Co się dzieje po przekroczeniu limitów

Po przekroczeniu limitu w odpowiedziach interfejsu API i na stronie diagnostyki na koncie Merchant Center będą się pojawiać błędy:

  • Za minutę: quota/request_rate_too_high
{
    "error": {
        "code": 429,
        "message": "Quota per minute exceeded. Please distribute your requests over a longer time period. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_REQUEST_RATE_TOO_HIGH"
                }
            }
        ]
    }
}
  • Dziennie: quota/daily_limit_exceeded
{
    "error": {
        "code": 429,
        "message": "Daily request quota exceeded. Please reduce number of requests. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_TOO_MANY_REQUESTS"
                }
            }
        ]
    }
}

Poniższe błędy są związane z limitami Merchant Center i nie mają związku z limitami Merchant API. Możesz spróbować poprosić o dodatkowy limit produktów, plików danych lub subkont:

  • too_many_items: przekroczono limit sprzedawcy
  • too_many_subaccounts: Osiągnięto maksymalną liczbę kont podrzędnych

Monitorowanie i widoczność

Aby sprawdzić bieżące limity połączeń i wykorzystanie na koncie, wywołaj funkcję quotas.list z nazwą konta.

POST https://merchantapi.googleapis.com/quota/v1/accounts/{ACCOUNT_ID}/quotas
Content-Type: application/json
Authorization: Bearer {ACCESS_TOKEN}

Zastąp te elementy:

  • ACCOUNT_ID: Twój identyfikator w Merchant Center
  • ACCESS_TOKEN: token autoryzacji do wykonania wywołania interfejsu API.

Po pomyślnym żądaniu interfejs API zwraca listę zasobów quotaGroups zawierających zasób name grupy limitów, różne limity i metody, do których odnosi się limit grupy.

{
    "quotaGroups": [
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-quota-listquotagroups",
            "quotaUsage": "2",
            "quotaLimit": "1000",
            "methodDetails": [
                {
                    "method": "quotaservice.listquotagroups",
                    "version": "v1",
                    "subapi": "quota",
                    "path": "quota/v1/quotaservice.listquotagroups"
                }
            ],
            "quotaMinuteLimit": "10"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-commission-group-list",
            "quotaLimit": "10000",
            "methodDetails": [
                {
                    "method": "commissiongroupservice.listcommissiongroups",
                    "version": "v1",
                    "subapi": "youtube",
                    "path": "youtube/v1/commissiongroupservice.listcommissiongroups"
                }
            ],
            "quotaMinuteLimit": "60"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-merchantreviews-list",
            "quotaLimit": "20000000",
            "methodDetails": [
                {
                    "method": "merchantreviewsservice.listmerchantreviews",
                    "version": "v1",
                    "subapi": "reviews",
                    "path": "reviews/v1/merchantreviewsservice.listmerchantreviews"
                }
            ],
            "quotaMinuteLimit": "60000"
        }
    ]
}

Proces zwiększania limitu

Aby poprosić o dodatkowy limit, otwórz formularz kontaktowy, w polu „Jaki jest problem lub pytanie” wybierz „Prośba o zwiększenie limitu” i wypełnij wszystkie wymagane pola, w tym identyfikator Merchant Center, metody kierowania i uzasadnienie biznesowe.

  • W przypadku zasobów z automatycznymi limitami (products, accounts i datasources w przypadku kont zaawansowanych): możesz poprosić tylko o tymczasowe zwiększenie limitu w specjalnych sytuacjach, takich jak wprowadzenie usługi na nowy rynek lub w okresach dużego natężenia ruchu w sezonach zakupowych. Nie akceptujemy trwałych zwiększeń limitów w przypadku tych typów zasobów.
  • W przypadku wszystkich innych zasobów bez automatycznych limitów: w razie potrzeby poproś o zwiększenie limitu.

Zalecamy okresowe sprawdzanie limitów, aby mieć pewność, że masz wystarczającą ilość miejsca na potrzeby wdrożenia, i obserwować, jak limity są automatycznie dostosowywane. Użyj metody quotas.list, aby sprawdzić aktualny dzienny limit wykorzystania, limit minutowy i bieżące dzienne wykorzystanie w przypadku każdej grupy metod interfejsu API.

Sprawdzone metody

Wdrożenie tych sprawdzonych metod pomoże Ci zapewnić płynne działanie integracji, uniknąć nieoczekiwanych błędów związanych z limitami i efektywnie wykorzystywać zasoby Merchant Center.

Optymalizacja dystrybucji żądań

  • Równomierne rozkładanie żądań: unikaj wysyłania dużych serii żądań. Rozłóż dzienne wywołania interfejsu API równomiernie w ciągu dnia, aby nie przekroczyć limitów minutowych (quotaMinuteLimit).
  • Proaktywne ograniczanie: wdróż w aplikacji ograniczanie liczby żądań po stronie klienta. Nie polegaj wyłącznie na serwerach Google w zakresie odrzucania nadmiernego ruchu. Kontroluj częstotliwość wniosków u źródła.

Elegancka obsługa błędów

  • Obsługa błędu HTTP 429: aplikacja musi być przygotowana na obsługę błędów 429 Too Many Requests (quota/request_rate_too_high).
  • Wzrastający czas do ponowienia z losowym opóźnieniem: podczas ponawiania nieudanych żądań (zwłaszcza po otrzymaniu kodu 429) używaj wzrastającego czasu do ponowienia (wydłużaj czas oczekiwania) i dodawaj „losowe opóźnienie” (losowe opóźnienie). Jitter zapobiega „burzom ponownych prób”, w których wiele instancji klienta ponawia próbę w tym samym czasie, ponownie przeciążając serwer.
  • Uwzględniaj wskazówki dotyczące ponawiania: jeśli odpowiedź interfejsu API zawiera szczegóły lub nagłówki ponawiania, użyj ich, aby określić, kiedy wznowić wywołania.

Minimalizowanie zbędnych połączeń

  • Zapobiegaj nieaktualnym wywołaniom (404 NOT_FOUND): unikaj wysyłania próśb o zasoby, które już nie istnieją, i ich usuwania. Nawet nieudane wywołania zużywają limit interfejsu API. Monitoruj NOT_FOUND błędy w Diagnostyce interfejsu API Merchant Center, aby wykrywać nieaktualne śledzenie stanu lub niepotrzebne odpytywanie.
  • Sprawdź przed aktualizacją: zanim wyślesz prośbę o aktualizację, sprawdź, czy dane rzeczywiście się zmieniły. Unikaj wysyłania aktualizacji, które zapisują te same wartości.
  • Używaj buforowania: w odpowiednich przypadkach buforuj lokalnie odpowiedzi odczytu (np. szczegóły produktu, ustawienia), aby uniknąć powtarzających się wywołań get lub list w przypadku niezmienionych danych.
  • Konta zaawansowane i subkonta: jeśli masz konto zaawansowane, uwierzytelnij się na poziomie konta zaawansowanego, jeśli chcesz, aby połączenia były uwzględniane w puli wspólnej kont zaawansowanych.
  • Użyj listSubaccounts: w przypadku kont zaawansowanych użyj accounts.listSubaccounts zamiast accounts.list. Limit accounts.list jest naliczany na użytkownika wywołującego (a nie na identyfikator MC) i nie jest widoczny w standardowej diagnostyce. listSubaccounts wlicza się do limitu MCA.
Wstecz
Overview
Dalej
Merchant Center limits