Эффективно управляйте данными

Основная функция многих приложений Google Ads — извлечение данных аккаунта для таких целей, как анализ данных, обработка запросов клиентов и проверка соответствия политике. При извлечении данных следует оптимизировать использование ресурсов, чтобы не перегружать серверы Google и не подвергать их риску ограничения скорости. Подробнее см. в руководствах по ограничению скорости и поддержанию актуальности контактного адреса электронной почты .

Изучите политику использования ресурсов Google для отчетов

Для обеспечения стабильности работы своих серверов Google Ads API ограничивает шаблоны запросов GoogleAdsService.Search и GoogleAdsService.SearchStream , потребляющие чрезмерное количество ресурсов API. Если конкретный шаблон запроса ограничен, другие сервисы, методы и шаблоны запросов продолжат работать без изменений. Для ограниченных запросов возникают следующие ошибки:

Код ошибки
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

Метрика стоимости, возвращаемая этими полями, зависит от различных факторов, таких как

  • Размер ваших счетов
  • Представления и столбцы, которые вы выбираете в своих отчетах
  • Нагрузка на серверы API Google Ads.

Чтобы помочь вам отслеживать дорогостоящие запросы, мы публикуем предварительную агрегированную статистику потребления ресурсов различными шаблонами запросов, которые мы наблюдаем на наших серверах. Мы будем периодически публиковать обновлённые данные, чтобы помочь вам оптимизировать запросы.

Временное окно Среднее (стр. 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, в локальной базе данных, а не вызывать сервер каждый раз, когда вам нужны данные, особенно для сущностей, к которым часто обращаются или которые изменяются редко. Используйте change-event и change-status везде, где это возможно, чтобы определить, какие объекты изменились с момента последней синхронизации результатов.

Оптимизируйте частоту запуска отчетов

Google Ads опубликовала рекомендации по актуальности данных и частоте их обновления. Эти рекомендации помогут вам определить, как часто следует получать отчёты.

Если вам необходимо регулярно обновлять аккаунты, рекомендуем ограничить их количество, например, двадцатью первыми аккаунтами 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 Реклама поддерживает до 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);
  }

Это снижает нагрузку на серверы API Google Ads за счет меньшего количества запускаемых отчетов.

Если вы обнаружите, что отчет слишком велик для хранения в памяти, вы также можете разбить запрос на более мелкие группы, добавив предложение 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 Ads клиентов. Это особенно касается офлайн-заданий, таких как cron-задания и конвейеры данных, которые работают без вмешательства пользователя.
  • Если клиент отозвал свою авторизацию, ваше приложение должно корректно обработать ситуацию и избежать отправки недействительных вызовов API на серверы API Google.
  • Если клиент удалил свой аккаунт Google Ads, вам следует обнаружить это и избегать отправки недействительных вызовов API на серверы API Google.
  • По истечении соответствующего периода времени удалите данные, загруженные из аккаунтов Google Ads клиентов, из вашей локальной базы данных.