Limity

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

Merchant API używa limitów, aby zapewnić stabilne i uczciwe środowisko dla wszystkich użytkowników. Limity uniemożliwiają pojedynczemu użytkownikowi interfejsu API nadmierne obciążanie systemu, co zapewnia wysoką wydajność. Znajomość tych limitów jest kluczowa w zarządzaniu danymi produktów i skalowaniu firmy w Google.

Podstawowe pojęcia

Limity Merchant API są zarządzane 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 dotycząca źródeł danych o produktach accounts.dataSources.list ma własną grupę limitów.
  • Wiele metod na grupę (łączenie): często powiązane metody są łączone w jedną grupę limitów. Wszystkie metody w tej grupie mają te same limity dzienne i na minutę. 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, np. merchant-accounts-write-methods.

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

Wbudowane grupowanie HTTP nie wpływa na limit. Każde pojedyncze żądanie w pakiecie żądań liczy się jako jedno w ramach limitu. Na przykład żądanie zbiorcze zawierające 500 żądań insert jest rozliczane jako 500 pojedynczych żądań metody insert.

Wyjątek w przypadku grupowania w regionie: wyspecjalizowane metody grupowania w regionie (batchCreate, batchUpdate, batchDelete) liczą się 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 powiązaną z każdą metodą interfejsu API, której chcesz używać. Te informacje znajdziesz w metodzie listy limitów. Więcej informacji znajdziesz w sekcji Monitorowanie i widoczność.

Zaktualizuj zasadę

W przypadku aktualizacji Merchant API egzekwuje te zasady:

  • Domyślnie możesz aktualizować produkty maksymalnie 2 razy dziennie. Aby zachować zgodność z limitem na minutę, rozłóż wywołania równomiernie w ciągu dnia.
  • Domyślnie możesz aktualizować subkonta maksymalnie 2 razy dziennie. Dzienny limit aktualizacji subkont to łączny limit oparty na łącznej liczbie dozwolonych subkont.
  • Domyślnie możesz wywoływać metody źródeł 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ń dozwolonych dziennie. Limity dzienne resetują się o 12:00 w południe czasu UTC.
  • Limit na minutę (quotaMinuteLimit): maksymalna liczba żądań dozwolonych na minutę, która kontroluje częstotliwość żądań. Limity na minutę korzystają z okna ruchomego, w którym okres egzekwowania rozpoczyna się w momencie 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 trwało do 10:02:30.
  • Dzienny limit wykorzystania (quotaUsage): liczba żądań, które zostały już wysłane i wliczone do limitu dziennego na bieżący dzień. Jeśli to pole jest puste, oznacza to, że w przypadku tej grupy nie wykorzystano jeszcze żadnego limitu.

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

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

Przydział limitów i hierarchia

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

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

  • Konta samodzielne: w przypadku kont samodzielnych uwierzytelnianie wywołania interfejsu API powoduje, że żądanie jest wliczane do limitu tego konta.
    • Przykład: sprzedawca Sklep z butami A uwierzytelnia się za pomocą własnego konta usługi, aby wywołać metodę products.insert kierowaną na własne konto (accounts/12345). Limit jest wykorzystywany z puli limitów Sklepu z butami A.
  • Konta zaawansowane: uwierzytelnianie jako konto zaawansowane powoduje wykorzystanie limitu z puli konta zaawansowanego, nawet jeśli kierujesz reklamy na subkonto.
    • Przykład: agencja Konto zarządzania sprzedażą detaliczną (identyfikator konta zaawansowanego: 12345) zarządza subkontem Sklep z odzieżą B (identyfikator konta: 11111). Agencja uwierzytelnia się za pomocą własnych danych logowania i wywołuje metodę products.insert kierowaną na Sklep z odzieżą B (accounts/11111). Limit jest wykorzystywany z puli konta nadrzędnego (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 to tak samo jak w przypadku konta samodzielnego, mimo że jest ono zarządzane przez nadrzędne konto zaawansowane.
    • Przykład: w tej samej konfiguracji co wcześniej, jeśli Sklep z odzieżą B (identyfikator konta: 11111) uwierzytelnia się za pomocą danych logowania skonfigurowanych specjalnie dla subkonta, aby wywołać metodę products.insert kierowaną na własne konto (accounts/11111), limit jest wykorzystywany z indywidualnej puli limitów Sklepu z odzieżą B , a pula konta nadrzędnego pozostaje nienaruszona.

Wyjątki od ogólnych reguł

Istnieje kilka wyjątków od ogólnych reguł przydziału 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 na podstawie identyfikatora konta Merchant Center. Wykorzystanie limitu nie będzie widoczne na standardowej stronie diagnostyki interfejsu API Merchant Center. Jeśli masz konto zaawansowane, zalecamy używanie metody accounts.listSubaccounts, która jest wliczana do limitu konta zaawansowanego.
  • Metody Issueresolution: te metody zawsze są wliczane do limitu konta, którego dotyczą problemy, nawet jeśli żądanie jest uwierzytelniane przez inne konto.

Hierarchia przydziału

  • Usługi porównywania cen (CSS): usługi porównywania cen to witryny, które agregują oferty produktów i kierują użytkowników do witryn sprzedawców, gdzie mogą 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, w ramach którego się uwierzytelniasz.

    Przykłady:

    • Grupa usług porównywania cen o nazwie Europe Shopping Group (identyfikator konta: 10001) chce wyświetlić listę powiązanych domen usług porównywania cen. Uwierzytelnienie za pomocą własnych danych logowania w celu wywołania interfejsu API powoduje, że 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 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, na których działa wielu sprzedawców indywidualnych. 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, 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

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

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

Usługi związane z produktami

  • Wszystkie grupy limitów metod powiązanych z zasobami products i productInputs.
  • Dzienny limit wywołań jest zwykle ustawiany na 2-krotność limitu ofert sprzedawcy. Zakłada się, że sprzedawca może potrzebować aktualizować każdy produkt maksymalnie 2 razy dziennie.
  • Poszczególne produkty można aktualizować więcej niż 2 razy, ale łączna liczba dziennych wywołań interfejsu API 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 kontami w Merchant API.
  • Dzienny limit wywołań jest ustawiany na maksymalną liczbę subkont dozwolonych na danym koncie. Umożliwia to maksymalnie 2 wywołania odczytu na subkonto dziennie.

Usługi związane ze źródłami danych

  • Wszystkie grupy limitów metod powiązanych z zasobami związanymi ze źródłami danych w Merchant API, takimi jak list lub create, które konto zaawansowane wykonuje na swoich subkontach.
  • Dzienny limit wywołań jest zwykle ustawiany na 2-krotność liczby subkont konta zaawansowanego. Zakłada się, ż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ą limit domyślny, a wszelkie zwiększenia limitu trzeba zgłaszać ręcznie. Więcej informacji znajdziesz w sekcji Proces 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 pojawią się błędy:

  • 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"
                }
            }
        ]
    }
}
  • Na dzień: 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 są związane z limitami Merchant Center, a nie z limitami Merchant API. Możesz 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 konta, wywołaj 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: identyfikator Merchant Center
  • ACCESS_TOKEN: token autoryzacji do wywołania interfejsu API

Po pomyślnym wysł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 stosuje 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 Kontakt z zespołem pomocy, 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 docelowe i uzasadnienie biznesowe.

  • W przypadku zasobów z automatycznymi limitami (products, accounts i datasources dla kont zaawansowanych): możesz poprosić tylko o tymczasowe zwiększenie limitu w specjalnych sytuacjach, takich jak wprowadzenie produktu na nowy rynek lub w okresach dużego ruchu. 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 upewnić się, że masz wystarczający limit na potrzeby implementacji, i sprawdzić, jak limit jest dostosowywany automatycznie. Użyj metody quotas.list, aby sprawdzić bieżący dzienny limit, limit na minutę i bieżące dzienne wykorzystanie w przypadku 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 rozłożenie żądań: unikaj wysyłania dużych serii żądań. Rozłóż dzienne wywołania interfejsu API równomiernie w ciągu dnia, aby nie przekraczać limitów na minutę (quotaMinuteLimit).
  • Proaktywne ograniczanie: wdroż 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.

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

  • Obsługa kodu 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 wystąpieniu błędu 429) używaj wzrastającego czasu do ponowienia (zwiększającego się czasu oczekiwania) i dodaj „losowe opóźnienie” (losowe opóźnienie). Losowe opóźnienie zapobiega „burzom ponowień”, w których wiele instancji klienta ponawia żądanie dokładnie w tym samym czasie, co powoduje ponowne przeciążenie serwera.
  • Przestrzeganie wskazówek dotyczących ponawiania: jeśli odpowiedź interfejsu API zawiera szczegóły lub nagłówki dotyczące ponawiania, użyj ich, aby określić, kiedy wznowić wywołania.

Minimalizowanie zbędnych wywołań

  • Zapobieganie nieaktualnym wywołaniom (404 NOT_FOUND): unikaj żądania lub usuwania zasobów, które już nie istnieją. Nawet nieudane wywołania zużywają limit interfejsu API. Monitoruj błędy NOT_FOUND w diagnostyce interfejsu API Merchant Center, aby wykrywać śledzenie nieaktualnego stanu lub niepotrzebne sondowanie.
  • Sprawdzanie przed aktualizacją: przed wysłaniem żądania aktualizacji sprawdź, czy dane rzeczywiście się zmieniły. Unikaj wysyłania aktualizacji, które zapisują te same wartości.
  • Używanie pamięci podręcznej: w razie potrzeby zapisuj w pamięci podręcznej 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 wywołania były wliczane do puli współdzielonej konta zaawansowanego.
  • Używanie metody listSubaccounts: w przypadku kont zaawansowanych używaj metody accounts.listSubaccounts zamiast accounts.list. Limit accounts.list jest naliczany na podstawie użytkownika wywołującego (a nie identyfikatora MC) i nie jest widoczny w standardowej diagnostyce. Metoda listSubaccounts jest wliczana do limitu MCA.
Wstecz
Overview
Dalej
Merchant Center limits