Limity

W tym dokumencie znajdziesz limity, które obowiązują w interfejsie 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ą pojedynczej metody interfejsu API. Na przykład metoda wyświetlania listy źródeł danych accounts.dataSources.list ma własną grupę limitów.
  • Wiele metod na grupę (grupowanie): często powiązane metody są grupowane 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, takich jak 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 jest liczone raz, niezależnie od typu. Żądanie list dotyczące 250 elementów jest liczone tylko raz, a nie jako 250 żądań get.

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

Wyjątek dotyczący grupowania w regionie dedykowanym: specjalistyczne metody grupowania w regionie (batchCreate, batchUpdate, batchDelete) są liczone jako pojedyncze wywołanie interfejsu API w grupie limitów merchant_regions, niezależnie od liczby operacji w regionie zawartych w ładunku.

Aby skutecznie zarządzać integracją, sprawdź konkretną grupę limitów powiązaną z każdą metodą interfejsu API, której chcesz używać. Te informacje znajdziesz w metodzie list 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 nie przekroczyć limitu na minutę, rozłóż wywołania równomiernie w ciągu dnia.
  • Domyślnie subkonta możesz aktualizować tylko 2 razy dziennie. Dzienny limit aktualizacji subkont to łączny limit oparty na łącznej liczbie dozwolonych subkont.
  • Domyślnie możesz wywoływać metody źródła danych dla subkont, takie jak list lub create, maksymalnie 2 razy dziennie na subkonto.

Limity liczby żądań

Każda grupa limitów ma 2 rodzaje limitów (i dziennego wykorzystania):

  • Limit dzienny (quotaLimit): maksymalna liczba żądań dozwolona dziennie. Dzienne limity są resetowane o 12:00 czasu UTC.
  • Limit na minutę (quotaMinuteLimit): maksymalna liczba żądań dozwolonych na minutę, która kontroluje częstotliwość żądań. Limity na minutę korzystają z okresu obserwacji, w którym okres egzekwowania zaczyna się od momentu pierwszego wywołania interfejsu API dla danej metody i zasobu. Jeśli na przykład wywołasz metodę o 10:01:30, okno limitu na minutę dla tej metody będzie obowiązywać do 10:02:30.
  • Dzienne wykorzystanie (quotaUsage): liczba żądań, które zostały już wysłane i wliczone do limitu dziennego na dany dzień. Jeśli brakuje pola, oznacza to, że nie wykorzystano jeszcze żadnego limitu dla tej grupy.

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

Konkretne limity dzienne i minutowe różnią się znacznie między różnymi grupami limitów. Operacje o wyższej oczekiwanej liczbie lub niższym koszcie systemowym, takie jak odczytywanie danych produktów, zwykle mają wyższe limity. Z kolei bardziej intensywne lub poufne operacje, takie jak modyfikacje konta, mogą mieć niższe limity.

Przydział i hierarchia limitów

W tej sekcji wyjaśniamy, w czyim imieniu 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 żądanie jest wliczane do limitu tego konta.
    • Przykład: sprzedawca Sklep obuwniczy A (identyfikator konta: 12345) uwierzytelnia się za pomocą własnego konta usługi, aby wywołać metodę products.insert kierowaną na jego własne konto (accounts/12345). Limit jest wykorzystywany z puli limitów Sklepu obuwniczego A.
  • Konta zaawansowane: uwierzytelnianie jako konto zaawansowane powoduje wykorzystanie limitu z puli konta zaawansowanego, nawet jeśli celem jest subkonto.
    • Przykład: agencja Retail Management Account (identyfikator konta zaawansowanego: 12345) zarządza subkontem Clothing Store B (identyfikator konta: 11111). Agencja uwierzytelnia się przy użyciu własnych danych logowania i wywołuje products.insert, kierując na Sklep odzieżowy B (accounts/11111). Limit jest wykorzystywany z puli agencji nadrzędnej (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 z indywidualnej puli tego subkonta. Działa ono tak samo jak samodzielne konto, 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 subkonta, aby wywołać metodę products.insert kierowaną na jego własne konto (accounts/11111), limit jest wykorzystywany z indywidualnej puli limitów Sklepu odzieżowego B, a pula agencji nadrzędnej pozostaje nienaruszona.

Wyjątki od ogólnych zasad

Od ogólnych zasad przydzielania limitów obowiązuje kilka wyjątków:

  • Accounts.list: limit dla tej metody jest naliczany na podstawie uwierzytelnionego użytkownika lub konta usługi, które wykonuje wywołanie, 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 wliczają się do limitu konta, którego problemy są zgłaszane, nawet jeśli żądanie jest uwierzytelniane przez inne konto.

Hierarchia alokacji

  • Usługi porównywania cen: usługi porównywania cen to witryny, które agregują oferty produktów i kierują użytkowników do witryn sprzedawców, aby mogli dokonać 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, które uwierzytelniasz.

    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. Dzięki uwierzytelnieniu za pomocą własnych danych logowania w celu wywołania 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 sprzedawców (accounts/30003) w celu przypisania etykiety. Limit jest wykorzystywany z puli limitów TopDeals CSS, a nie z puli konta sprzedawcy.

  • Platformy handlowe: platformy handlowe to platformy internetowe, które umożliwiają sprzedawcom indywidualnym udostępnianie swoich produktów. Działają one jako specjalne konta zaawansowane, które umożliwiają tworzenie indywidualnych subkont dla każdego sprzedawcy.

Poniższy diagram przedstawia hierarchię grup usług porównywania cen, usług porównywania cen, platform handlowych, kont zaawansowanych, samodzielnych kont i subkont.

Grupa usług porównywania cen to nadrzędny poziom uwierzytelniania, który może obejmować poszczególne usługi porównywania cen, konta w tych usługach i subkonta jako najbardziej indywidualny poziom.

Automatyczne dostosowywanie limitów

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

Grupy limitów uwzględnione w automatycznym dostosowywaniu 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 ustawiony na dwukrotność liczby 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 nie może przekroczyć dziennego limitu wywołań.

Usługi związane z kontami

  • Wszystkie grupy limitów metod zwią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 dozwoloną na tym koncie. Pozwala to na maksymalnie 2 wywołania odczytu na subkonto dziennie.

Usługi źródeł danych

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

Automatyczne dostosowywanie limitów dotyczy tylko usług opisanych wcześniej. Inne usługi mają domyślny limit, a o jego zwiększenie trzeba poprosić ręcznie. Więcej informacji znajdziesz w sekcji Proces zwiększania limitu.

Co się stanie, gdy limity zostaną przekroczone

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

  • Na 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"
                }
            }
        ]
    }
}

Te błędy dotyczą limitów Merchant Center i nie są związane 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ę subkont

Monitorowanie i widoczność

Aby sprawdzić bieżące limity wywołań i wykorzystanie na koncie, wywołaj metodę quotas.list, podając 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 wywołania interfejsu API.

Po pomyślnym przesłaniu żądania interfejs API zwraca listę zasobów quotaGroups zawierających zasób name grupy limitów, różne limity i metody, do których ma zastosowanie 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 pomocy, w wymaganym polu „Na czym polega problem lub pytanie” wybierz „Prośba o zwiększenie limitu” i wypełnij wszystkie wymagane pola, w tym identyfikator w Merchant Center, metody kierowania [reklam] i uzasadnienie biznesowe.

  • W przypadku zasobów z automatycznymi limitami (products, accounts i datasources na kontach zaawansowanych): możesz poprosić o tymczasowe zwiększenie limitu tylko w szczególnych sytuacjach, takich jak wprowadzenie produktu na nowy rynek lub w okresach wzmożonych zakupów. Nie akceptujemy próśb o stałe zwiększenie limitów dla tych typów zasobów.
  • W przypadku wszystkich innych zasobów bez automatycznych limitów: w razie potrzeby poproś o zwiększenie limitów.

Zalecamy okresowe sprawdzanie limitów, aby upewnić się, że są one wystarczające dla Twojej implementacji, i zobaczyć, jak są automatycznie dostosowywane. Użyj metody quotas.list, aby sprawdzić aktualny dzienny limit wykorzystania, limit minutowy i bieżące dzienne wykorzystanie dla każdej grupy metod interfejsu API.

Sprawdzone metody

Wdrożenie tych sprawdzonych metod pomoże 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: wdrożenie ograniczania liczby żądań po stronie klienta w aplikacji. Nie polegaj wyłącznie na serwerach Google w kwestii odrzucania nadmiernego ruchu. Kontroluj częstotliwość wniosków u źródła.

Prawidłowa obsługa błędów

  • Obsługa błędu HTTP 429: aplikacja musi być przygotowana do obsługi 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 błędzie 429) używaj wzrastającego czasu do ponowienia (coraz dłuższych czasów oczekiwania) i dodaj losowe opóźnienie. Wahania zapobiegają „lawinom ponownych prób”, gdy wiele instancji klienta ponawia próbę w tym samym czasie, co powoduje ponowne przeciążenie serwera.
  • Uwzględniaj wskazówki dotyczące ponawiania prób: jeśli odpowiedź interfejsu API zawiera szczegóły lub nagłówki dotyczące ponawiania prób, użyj ich, aby określić, kiedy wznowić wywołania.

Minimalizowanie zbędnych wywołań

  • Zapobieganie nieaktualnym wywołaniom (błąd 404 NOT_FOUND): unikaj żądania lub usuwania zasobów, które już nie istnieją. Nawet nieudane wywołania zużywają limit interfejsu API. Sprawdzaj błędy NOT_FOUND w Diagnostyce interfejsu API w Merchant Center, aby wykrywać śledzenie stanu nieaktualnych danych lub niepotrzebne odpytywanie.
  • Weryfikacja 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 pamięci podręcznej: w razie potrzeby przechowuj odpowiedzi na żądania odczytu (np. szczegóły produktu, ustawienia) lokalnie w pamięci podręcznej, 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 wywołania były wliczane do wspólnej puli kont zaawansowanych.
  • Użyj listSubaccounts: w przypadku kont zaawansowanych użyj accounts.listSubaccounts zamiast accounts.list. Limit accounts.list jest naliczany dla użytkownika wywołującego (nie dla identyfikatora MC) i nie jest widoczny w standardowej diagnostyce. listSubaccounts wlicza się do limitu konta MCA.
Wstecz
Overview
Dalej
Merchant Center limits