Основная функция многих приложений Google Рекламы — получение данных аккаунта для таких сценариев использования, как анализ данных, запросы клиентов и проверки соблюдения политик. При получении данных вам следует оптимизировать использование, чтобы не перегружать серверы Google и не рисковать ограничением скорости. Дополнительные сведения см. в руководствах по ограничению скорости и поддержанию актуального контактного адреса электронной почты .
Ознакомьтесь с политикой использования ресурсов Google для отчетов.
Чтобы обеспечить стабильность своих серверов, API Google Рекламы ограничивает шаблоны запросов GoogleAdsService.Search
и GoogleAdsService.SearchStream
, которые потребляют чрезмерное количество ресурсов API. Если определенный шаблон запроса регулируется, другие службы, методы и шаблоны запросов продолжат работать без изменений. Для регулируемых запросов выдаются следующие ошибки:
Версия API | Код ошибки |
---|---|
<= v17 | QuotaError.RESOURCE_EXHAUSTED |
>= v18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION или QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION в зависимости от продолжительности интенсивного использования ресурсов. |
Чтобы помочь вам идентифицировать и отслеживать дорогостоящие отчеты, мы также возвращаем показатели стоимости для отдельных отчетов.
Метод | Поле стоимости |
---|---|
GoogleAdsService.Search | SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream | SearchGoogleAdsStreamResponse.query_resource_consumption |
Метрика стоимости, возвращаемая этими полями, зависит от различных факторов, таких как
- Размер ваших счетов
- Представления и столбцы, которые вы получаете в своих отчетах.
- Нагрузка на серверы Google Ads API.
Чтобы помочь вам отслеживать дорогостоящие запросы, мы публикуем первоначальную агрегированную статистику потребления ресурсов различными шаблонами запросов, которые мы видим на наших серверах. Мы будем периодически публиковать обновленные цифры, чтобы помочь вам уточнить ваши запросы.
Временное окно | Средний (р50). | P70 (Умеренно высокий) | P95 (Очень высокий) |
---|---|---|---|
Краткосрочный (5 минут) | 6000 | 30000 | 1800000 |
Долгосрочная (24 часа). | 16000 | 90000 | 8400000 |
В качестве примера предположим, что вы используете следующий шаблон запроса, который потребляет 600 единиц ресурсов на отчет.
SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
segments.date = "YYYY-MM-DD"
Вы запускаете этот запрос для нескольких учетных записей клиентов на несколько отдельных дат, изменяя запрос, чтобы заменить разные значения для фильтра segments.date
. В следующей таблице показано количество отчетов, которые вы можете запустить в заданном временном интервале, чтобы использование ресурсов соответствовало различным сегментам использования ресурсов.
Временное окно | Средний | Умеренно высокий | Очень высокий |
---|---|---|---|
Краткосрочный (5 минут) | 10 | 50 | 3000 |
Долгосрочная (24 часа). | 26 | 150 | 14000 |
Выполнение этого шаблона запроса 10 раз за 5 минут будет считаться средним использованием, тогда как выполнение 3000 отчетов за 5 минут будет считаться очень высоким использованием.
Существует несколько стратегий оптимизации потребления ресурсов ваших отчетов. Остальная часть этого руководства посвящена некоторым из этих стратегий.
Кэшируйте свои данные
Вам следует кэшировать сведения об объекте, которые вы получаете с серверов API, в локальной базе данных, а не вызывать сервер каждый раз, когда вам нужны данные, особенно для объектов, к которым часто обращаются или которые изменяются нечасто. По возможности используйте событие изменения и статус изменения , чтобы определить, какие объекты изменились с момента последней синхронизации результатов.
Оптимизируйте частоту запуска отчетов
Google Реклама опубликовала рекомендации относительно актуальности данных и частоты их обновления. Используйте это руководство, чтобы определить, как часто следует получать отчеты.
Если вам необходимо регулярно обновлять аккаунты, мы рекомендуем ограничить количество таких аккаунтов небольшим набором, например, только двадцаткой лучших аккаунтов Google Ads. Остальные можно обновлять с меньшей частотой, например, один-два раза в день.
Оптимизируйте размер ваших отчетов
Ваше приложение должно получать большие объемы данных, а не создавать большое количество небольших отчетов. Фактором, влияющим на этот выбор, являются ограничения счета .
Например, рассмотрим следующий код, который извлекает статистику для определенных групп объявлений и обновляет таблицу базы данных статистики:
List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
foreach (long adGroupId in adGroupIds)
{
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
"ad_group.id = ${adGroupId}";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
InsertRowsIntoStatsTable(adGroupId, rows);
}
Этот код хорошо работает на небольшом тестовом аккаунте. Однако Google Ads поддерживает до 20 000 групп объявлений на кампанию и 10 000 кампаний на аккаунт. Поэтому, если этот код выполняется для крупной учетной записи Google Рекламы, он может перегрузить серверы API Google Рекламы, что приведет к ограничению и регулированию скорости.
Лучшим подходом было бы запустить один отчет и обработать его локально. Показан один из таких подходов с использованием карты в памяти.
Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Это снижает нагрузку на серверы Google Ads API за счет меньшего количества запускаемых отчетов.
Если вы обнаружите, что отчет слишком велик для хранения в памяти, вы также можете разбить запрос на более мелкие группы, добавив предложение LIMIT
, например:
SELECT
ad_group.id,
ad_group.name,
metrics.clicks,
metrics.cost_micros,
metrics.impressions,
segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
AND ad_group.id IN (id1, id2, ...)
LIMIT 100000
Метки — это еще один способ группировать сущности и сократить количество запросов к отчетам. Дополнительную информацию см. в руководстве по этикеткам .
Оптимизируйте то, что вы получаете
При создании отчетов вам следует помнить о столбцах, которые вы включаете в свои запросы. Рассмотрим следующий пример, запуск которого запланирован каждый час:
SELECT
customer.id,
customer.currency_code,
campaign.id,
campaign.name,
ad_group.id,
ad_group.name,
ad_group_criterion.keyword.match_type,
ad_group_criterion.keyword.text,
ad_group_criterion.criterion_id,
ad_group_criterion.quality_info.creative_quality_score,
ad_group_criterion.system_serving_status,
ad_group_criterion.negative,
ad_group_criterion.quality_info.quality_score,
ad_group_criterion.quality_info.search_predicted_ctr,
ad_group_criterion.quality_info.post_click_quality_score,
metrics.historical_landing_page_quality_score,
metrics.search_click_share,
metrics.historical_creative_quality_score,
metrics.clicks,
metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS
Единственные столбцы, которые могут меняться каждый час, — это metrics.clicks
и metrics.impressions
. Все остальные столбцы обновляются нечасто или вообще не обновляются, поэтому получать их ежечасно крайне неэффективно. Вы можете сохранить эти значения в локальной базе данных и запускать отчет о событиях или статусе изменений, чтобы загружать изменения один или два раза в день.
В некоторых случаях вы можете уменьшить количество загружаемых строк, применив соответствующие фильтры.
Очистите неиспользуемые аккаунты
Если ваше приложение управляет учетными записями сторонних клиентов, вам необходимо разработать приложение с учетом оттока клиентов. Вам следует периодически очищать свои процессы и хранилища данных, чтобы удалять учетные записи клиентов, которые больше не используют ваше приложение. При очистке неиспользуемых аккаунтов Google Рекламы учитывайте следующие рекомендации:
- Отмените разрешение, которое ваш клиент предоставил вашему приложению для управления своей учетной записью.
- Прекратите вызовы API к аккаунтам Google Рекламы клиента. Это особенно относится к автономным заданиям, таким как задания cron и конвейеры данных, которые предназначены для запуска без вмешательства пользователя.
- Если клиент отозвал свою авторизацию, ваше приложение должно корректно справиться с ситуацией и избегать отправки недействительных вызовов API на серверы API Google.
- Если клиент закрыл свой аккаунт Google Рекламы, вам следует обнаружить это и избегать отправки недействительных вызовов API на серверы API Google.
- Удалите данные, которые вы скачали из аккаунтов Google Рекламы клиента, из своей локальной базы данных по истечении соответствующего периода времени.