Квоты

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

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

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

Квоты Merchant API управляются через группы квот.

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

  • Один метод на группу. Некоторые группы квот применяются к одному методу API. Например, у метода listing data sources 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, который вы планируете использовать. Эти сведения можно найти в методе list для квот. Подробную информацию вы найдете в разделе Мониторинг и видимость.

Обновить правила

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

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

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

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

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

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

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

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

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

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

  • Отдельные аккаунты. Если вызов API выполняется из отдельного аккаунта, то запрос учитывается в квоте этого аккаунта.
    • Пример. Продавец Shoe Store A (идентификатор аккаунта: 12345) проходит аутентификацию с помощью собственного сервисного аккаунта, чтобы вызвать products.insert, нацеленный на его собственный аккаунт (accounts/12345). Квота расходуется из пула квот Shoe Store A.
  • Расширенные аккаунты. При аутентификации в качестве расширенного аккаунта квота расходуется из его пула, даже если вы работаете с дочерним аккаунтом.
    • Пример. Агентство 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, который учитывается в квоте расширенных аккаунтов.
  • Методы Issueresolution. Эти методы всегда учитываются в квоте аккаунта, проблемы которого запрашиваются, даже если запрос аутентифицируется другим аккаунтом.

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

  • Сервисы сравнения цен (ССЦ). Это сайты, на которых собраны предложения товаров и которые направляют пользователей на сайты розничных продавцов для совершения покупок. При вызовах 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. Вы можете запросить увеличение лимита товаров, фидов или дочерних аккаунтов в Merchant Center.

  • 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 для расширенных аккаунтов). Вы можете запросить только временное увеличение квоты для особых случаев, например для запуска на новом рынке или в сезоны высокого трафика. Мы не увеличиваем квоты для этих типов ресурсов на постоянной основе.
  • Для всех остальных ресурсов без автоматических квот запрашивайте увеличение квот по мере необходимости.

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

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

Следуя этим рекомендациям, вы сможете обеспечить бесперебойную работу интеграции, избежать непредвиденных ошибок, связанных с квотами, и эффективно использовать ресурсы 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 списывается с вызывающего пользователя (не с идентификатора MC) и не отображается в стандартной диагностике. listSubaccounts учитывается в квоте мультиаккаунта.
Назад
Overview
Далее
Merchant Center limits