Квоты

В этом документе перечислены квоты, которые применяются к Merchant API.

В Merchant API используются квоты, чтобы обеспечить стабильную и справедливую работу для всех пользователей. Квоты не позволяют одному пользователю API создавать чрезмерную нагрузку на систему, обеспечивая высокую производительность. Знать квоты необходимо, чтобы управлять данными и развивать бизнес в Google.

Общие понятия

Квоты Merchant API управляются с помощью групп квот.

Методы API сопоставляются с группами квот. Структура этого сопоставления может быть разной:

  • Один метод на группу. Некоторые группы квот применяются к одному методу API. Например, у метода accounts.dataSources.list есть собственная группа квот.
  • Несколько методов в группе (объединение). Часто связанные методы объединяются в одну группу квот. Все методы в этой группе имеют одинаковые ограничения на количество запросов в день и в минуту. Примеры:
    • Группировка всех операций чтения для связанных методов и ресурсов, например merchant-accounts-read-methods.
    • Группировка всех операций записи для связанных методов и ресурсов, например merchant-accounts-write-methods.

Каждый вызов метода учитывается один раз, независимо от его типа. Запрос list, содержащий 250 объектов, учитывается как один запрос, а не как 250 запросов get.

Встроенная пакетная обработка HTTP не влияет на квоту. Каждый отдельный запрос в пакете учитывается как один запрос в рамках квоты. Например, пакетный запрос, содержащий 500 запросов insert, будет оплачиваться как 500 отдельных запросов метода insert.

Исключение для пакетной обработки в определенном регионе. Специализированные методы пакетной обработки в определенном регионе (batchCreate, batchUpdate, batchDelete) считаются одним вызовом API в группе квот merchant_regions независимо от количества операций в регионе, содержащихся в полезной нагрузке.

Чтобы эффективно управлять интеграцией, вам нужно ознакомиться с квотами, связанными с каждым методом API, который вы планируете использовать. Эти сведения можно найти в методе списка квот. Подробную информацию вы найдете в разделе Мониторинг и видимость.

Правила обновления

Merchant API обеспечивает соблюдение следующих правил в отношении обновлений:

  • По умолчанию вы можете обновлять информацию о товарах до двух раз в день. Чтобы соблюдать квоту на количество минут, равномерно распределите звонки в течение дня.
  • По умолчанию вы можете обновлять дочерние аккаунты не более двух раз в день. Ваша ежедневная квота на обновление дочерних аккаунтов – это совокупный лимит, основанный на общем количестве разрешенных дочерних аккаунтов.
  • По умолчанию методы источников данных для дочерних аккаунтов, например list или create, можно вызывать не более двух раз в день для каждого дочернего аккаунта.

Квоты на частоту запросов

В каждой группе квот есть два типа лимитов (и ежедневное использование):

  • Дневной лимит (quotaLimit). Максимальное количество запросов, разрешенное в день. Дневные квоты сбрасываются в 12:00 пополудни UTC.
  • Лимит в минуту (quotaMinuteLimit). Максимальное количество запросов, разрешенное в минуту. Этот параметр контролирует скорость запросов. Квоты в минуту используют скользящее окно, в котором период действия начинается с момента первого вызова API для определенного метода и ресурса. Например, если вы сделаете вызов в 10:01:30, то квота на минуту для этого метода будет действовать до 10:02:30.
  • Ежедневное использование (quotaUsage). Количество запросов, которые уже были сделаны и учтены в дневном ограничении за текущий день. Если поле отсутствует, значит для этой группы ещё не использовалась квота.

Три поля, описанные выше (quotaLimit, quotaMinuteLimit и quotaUsage), можно найти в ответе метода quotas.list.

Конкретные значения дневных и минутных лимитов значительно различаются в разных группах квот. Операции с большим ожидаемым объемом или низкой системной стоимостью, например чтение данных о товарах, обычно имеют более высокие лимиты. В то же время для более сложных или конфиденциальных операций, например изменения аккаунта, могут быть установлены более низкие лимиты.

Распределение квот и иерархия

В этом разделе рассказывается, от чьего имени Merchant API отслеживает и применяет использование квоты:

Как правило, квота взимается с пользователя, который отправляет запрос к API.

  • Отдельные аккаунты. Если для аутентификации вызова API используется отдельный аккаунт, запрос учитывается в квоте этого аккаунта.
    • Пример. Продавец Магазин обуви А (идентификатор аккаунта: 12345) проходит аутентификацию с помощью собственного сервисного аккаунта, чтобы вызвать метод products.insert, предназначенный для его аккаунта (accounts/12345). Квота расходуется из пула квот Магазина обуви А.
  • Расширенные аккаунты. При аутентификации в качестве расширенного аккаунта квота расходуется из пула расширенного аккаунта, даже если целевым является дочерний аккаунт.
    • Пример. Агентство Retail Management Account (идентификатор расширенного аккаунта: 12345) управляет дочерним аккаунтом Clothing Store B (идентификатор аккаунта: 11111). Агентство проходит аутентификацию с помощью собственных учетных данных и вызывает products.insert, предназначенный для магазина одежды Б (accounts/11111). Квота расходуется из пула родительского агентства (идентификатор расширенного аккаунта: 12345), а не из пула дочернего аккаунта.
  • Дочерние аккаунты. Если вызовы API аутентифицируются с помощью учетных данных дочернего аккаунта, квота списывается из индивидуального пула этого аккаунта. Он работает так же, как обычный аккаунт, хотя им управляет родительский расширенный аккаунт.
    • Пример. Если Магазин одежды Б (идентификатор аккаунта: 11111) проходит аутентификацию с помощью учетных данных, настроенных специально для его дочернего аккаунта, чтобы вызвать products.insert, предназначенный для его собственного аккаунта (accounts/11111), квота расходуется из индивидуального пула квот Магазина одежды Б, а пул родительского агентства остается нетронутым.

Исключения из общих правил

Существует несколько исключений из общих правил распределения квот:

  • Accounts.list: Квота для этого метода взимается с аутентифицированного пользователя или сервисного аккаунта, выполняющего вызов, а не с идентификатора аккаунта Merchant Center. Использование квоты не будет отображаться на стандартной странице диагностики Merchant Center API. Если у вас расширенный аккаунт, рекомендуем использовать метод accounts.listSubaccounts, который учитывается в квоте расширенных аккаунтов.
  • Методы устранения проблем: эти методы всегда учитываются в квоте аккаунта, для которого запрашиваются проблемы, даже если запрос аутентифицируется другим аккаунтом.

Иерархия распределения

  • Сервисы сравнения цен (ССЦ) – это сайты, на которых собраны предложения товаров и с которых пользователи переходят на сайты продавцов, чтобы совершить покупку. При вызовах API квоты применяются к определенной группе ССЦ, домену ССЦ, аккаунту или дочернему аккаунту, для которых вы проходите аутентификацию.

    Примеры:

    • Группа ССЦ Europe Shopping Group (идентификатор аккаунта: 10001) хочет создать список связанных с ней доменов ССЦ. При аутентификации с помощью собственных учетных данных для выполнения этого вызова API квота расходуется непосредственно из пула квот Europe Shopping Group.
    • Домен ССЦ TopDeals CSS (идентификатор аккаунта: 20002) проходит аутентификацию, чтобы вызвать метод, предназначенный для одного из связанных аккаунтов продавца (accounts/30003), и назначить ярлык. Квота расходуется из пула квот ССЦ TopDeals, а не из пула аккаунта продавца.

  • Торговые площадки. Это онлайн-платформы, на которых размещаются товары нескольких продавцов. Они работают как специальные расширенные аккаунты, в которых можно создавать отдельные дочерние аккаунты для каждого продавца.

На схеме ниже показана иерархия групп ССЦ, ССЦ, торговых площадок, расширенных аккаунтов, отдельных аккаунтов и дочерних аккаунтов.

Группа ССЦ – это общий уровень аутентификации, в рамках которого могут быть отдельные ССЦ, аккаунты в них и дочерние аккаунты как самый низкий уровень.

Автоматическая корректировка квоты

В Merchant API есть система автоматического управления квотами для определенных сервисов. Она корректирует лимиты квот для растущих продавцов в зависимости от использования, количества предложений и размера аккаунта. Merchant API пересчитывает эти квоты ежедневно.

В автоматическую корректировку квот входят следующие группы:

Сервисы для работы с товарами

  • Все группы квот для методов, связанных с ресурсами products и productInputs.
  • Дневная квота на звонки обычно в два раза больше квоты на предложения. Это означает, что продавцу может потребоваться обновлять информацию о каждом товаре до двух раз в день.
  • Отдельные товары можно обновлять чаще, но общее количество вызовов API в день не должно превышать дневную квоту.

Сервисы аккаунтов

  • Все группы квот для методов, связанных с различными детализированными ресурсами, относящимися к аккаунту, в Merchant API.
  • Дневная квота на вызовы установлена на уровне максимального количества дочерних аккаунтов, разрешенного для этого аккаунта. Это позволяет выполнять до двух вызовов чтения в день для каждого дочернего аккаунта.

Сервисы источников данных

  • Все группы квот для методов, связанных с ресурсами источников данных в Merchant API, например list или create, которые расширенный аккаунт выполняет в своих дочерних аккаунтах.
  • Квота на количество вызовов в день обычно в два раза превышает количество дочерних аккаунтов, связанных с расширенным аккаунтом. При этом предполагается, что продавец может обновлять источники данных каждого дочернего аккаунта до двух раз в день.

Автоматическая корректировка квот предусмотрена только для сервисов, описанных выше. Для других сервисов установлена квота по умолчанию, и ее можно увеличить только вручную. Подробнее о процессе увеличения квоты…

Что происходит при превышении квот

Если квота превышена, в ответах API и на странице диагностики в аккаунте Merchant Center будут появляться ошибки:

  • В минуту: 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"
                }
            }
        ]
    }
}
  • В день: 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"
                }
            }
        ]
    }
}

Ошибки, перечисленные ниже, связаны с ограничениями Merchant Center и не имеют отношения к квотам Merchant API. Вы можете запросить увеличение лимита товаров, фидов или дочерних аккаунтов.

  • too_many_items: превышена квота продавца
  • too_many_subaccounts: достигнуто максимальное количество дочерних аккаунтов

Мониторинг и видимость

Чтобы проверить текущие квоты на вызовы и использование для аккаунта, вызовите quotas.list с названием аккаунта.

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

Замените следующее:

  • ACCOUNT_ID – идентификатор Merchant Center.
  • ACCESS_TOKEN – токен авторизации для вызова API.

При успешном выполнении запроса API возвращает список ресурсов quotaGroups, содержащих ресурс name группы квот, различные квоты и методы, к которым применяется квота группы.

{
    "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"
        }
    ]
}

Как увеличить квоту

Чтобы запросить увеличение квоты, откройте форму обращения в службу поддержки, выберите "Запрос на увеличение квоты" в поле "Проблема или вопрос" и заполните все обязательные поля, в том числе идентификатор Merchant Center, целевые методы и обоснование.

  • Для ресурсов с автоматическими квотами (products, accounts и datasources для продвинутых аккаунтов): вы можете запросить только временное увеличение квоты для особых случаев, например при запуске на новом рынке или в сезон повышенного спроса. Мы не принимаем запросы на постоянное увеличение квоты для этих типов ресурсов.
  • Для всех остальных ресурсов без автоматических квот запрашивайте увеличение квот по мере необходимости.

Мы рекомендуем периодически проверять квоты, чтобы убедиться, что их достаточно для вашей реализации, и посмотреть, как они корректируются автоматически. Используйте метод quotas.list, чтобы посмотреть текущий дневной лимит, лимит в минуту и текущее дневное использование для каждой группы методов API.

Рекомендации

Следуя этим рекомендациям, вы сможете обеспечить бесперебойную работу интеграции, избежать неожиданных ошибок, связанных с квотами, и эффективно использовать ресурсы Merchant Center.

Оптимизация распределения запросов

  • Отправляйте запросы равномерно. Не отправляйте сразу много запросов. Распределите ежедневные вызовы API равномерно в течение дня, чтобы не превышать поминутные лимиты квоты (quotaMinuteLimit).
  • Проактивное ограничение частоты запросов. Реализуйте в приложении клиентское ограничение частоты запросов. Не полагайтесь только на серверы Google для отклонения избыточного трафика. Контролируйте частоту запросов в источнике.

Корректная обработка ошибок

  • Обрабатывайте ошибку HTTP 429. Ваше приложение должно быть готово к обработке ошибок 429 Too Many Requests (quota/request_rate_too_high).
  • Экспоненциальная выдержка с добавлением случайности. При повторной отправке неудачных запросов (особенно после ошибки 429) используйте экспоненциальную выдержку (увеличивая время ожидания) и добавьте случайную задержку. Джиттер предотвращает "штормы повторных попыток", когда несколько экземпляров клиента пытаются повторно подключиться к серверу в одно и то же время, снова перегружая его.
  • Учитывайте подсказки о повторных попытках. Если в ответе API содержатся сведения или заголовки, связанные с повторными попытками, используйте их, чтобы определить, когда возобновить вызовы.

Как сократить количество лишних звонков

  • Предотвращайте устаревшие вызовы (404 NOT_FOUND). Не запрашивайте и не удаляйте ресурсы, которые больше не существуют. Даже неудачные вызовы расходуют квоту API. Отслеживайте NOT_FOUND ошибки в разделе "Диагностика API" в Merchant Center, чтобы выявлять устаревшие данные или ненужные опросы.
  • Проверяйте данные перед обновлением. Прежде чем отправлять запрос на обновление, убедитесь, что данные действительно изменились. Не отправляйте обновления с одинаковыми значениями.
  • Используйте кеширование. Кешируйте ответы на запросы чтения (например, сведения о товарах, настройки) локально, когда это возможно, чтобы избежать повторяющихся вызовов get или list для неизмененных данных.
  • Расширенные аккаунты и дочерние аккаунты. Если у вас расширенный аккаунт, выполните аутентификацию на уровне расширенного аккаунта, чтобы звонки учитывались в общем пуле расширенного аккаунта.
  • Используйте listSubaccounts. В расширенных аккаунтах вместо accounts.list используйте accounts.listSubaccounts. Квота accounts.list списывается с вызывающего пользователя (а не с идентификатора клиента) и не видна в стандартной диагностике. listSubaccounts учитывается в квоте мультиаккаунта.
Назад
Overview
Далее
Merchant Center limits