Основная функция многих приложений Google Рекламы – получение данных аккаунта для анализа, обработки запросов клиентов, проверки соблюдения правил и т. д. При получении данных оптимизируйте их использование, чтобы не перегружать серверы Google и не рисковать ограничением частоты запросов. Дополнительную информацию можно найти в руководствах по ограничению частоты запросов и поддержанию актуальности контактного электронного адреса.
Политика использования ресурсов для отчетов
Чтобы обеспечить стабильность серверов, Google Ads API ограничивает шаблоны запросов GoogleAdsService.Search и GoogleAdsService.SearchStream, которые потребляют слишком много ресурсов API. Если ограничение применяется к определенному шаблону запроса, то другие сервисы, методы и шаблоны запросов продолжают работать без изменений. При этом возникают следующие ошибки:
| Код ошибки |
|---|
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
или QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION
в зависимости от того, как долго ресурсы используются слишком активно. |
Если вы столкнулись с этими ошибками, подождите 5 минут, прежде чем повторно отправлять запросы, которые не удалось выполнить из-за ошибки QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, и 30 минут для запросов, которые не удалось выполнить из-за ошибки QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.
Чтобы вам было проще выявлять и отслеживать отчеты, требующие больших затрат, мы также возвращаем показатель стоимости для отдельных отчетов:
| Метод | Поле "Стоимость" |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption
|
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption
|
Показатель стоимости, возвращаемый этими полями, зависит от различных факторов, таких как:
- Размер аккаунтов.
- представления и столбцы, которые вы запрашиваете в отчетах;
- нагрузка на серверы Google Ads API;
В таблице ниже приведена агрегированная статистика по потреблению ресурсов серверов Google Ads API различными шаблонами запросов. Она поможет вам отслеживать и оптимизировать ресурсоемкие запросы.
| Временной период | Среднее (p50) | 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, в локальной базе данных, а не запрашивать их с сервера каждый раз, когда они вам нужны. Это особенно важно для объектов, к которым часто обращаются или которые редко меняются. По возможности используйте change-event и change-status, чтобы определить, какие объекты изменились с момента последней синхронизации результатов.
Оптимизируйте частоту создания отчетов
В Google Рекламе есть опубликованные рекомендации по актуальности данных и частоте их обновления. Используйте эти рекомендации, чтобы определить, как часто нужно запрашивать отчеты.
Если вам нужно регулярно обновлять аккаунты, рекомендуем ограничить их количество, например обновлять только 20 основных аккаунтов Google Рекламы. Остальные можно обновлять реже, например один или два раза в день.
Оптимизируйте размер отчетов
Приложение должно получать большие пакеты данных, а не выполнять большое количество небольших отчетов. При выборе также следует учитывать лимиты в аккаунтах.
Например, следующий код извлекает статистику для определенных групп объявлений и обновляет таблицу базы данных статистики:
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 Реклама поддерживает до 20 000 групп объявлений в кампании и до 10 000 кампаний в аккаунте. Поэтому, если этот код выполняется в большом аккаунте Google Рекламы, он может перегрузить серверы Google Ads API, что приведет к ограничению частоты запросов и регулированию трафика.
Лучше создать один отчет и обработать его локально. Ниже показан один из таких подходов с использованием карты в памяти.
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(customerId, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
foreach (GoogleAdsRow row in rows)
{
long adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
{
InsertRowsIntoStatsTable(entry.Key, entry.Value);
}
Это снижает нагрузку на серверы 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 Рекламы клиентов, из своей локальной базы данных по истечении разумного периода времени.