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

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

Ознакомьтесь с политикой Google по использованию ресурсов для отчетов.

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

При возникновении этих ошибок подождите 5 минут, прежде чем повторять запросы, завершившиеся ошибкой QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION , и 30 минут для запросов, завершившихся ошибкой QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION .

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

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

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

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

В качестве примера предположим, что вы выполняете следующий запрос, который потребляет 600 единиц ресурсов на каждый отчет.

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

Вы можете выполнить этот запрос для нескольких учетных записей клиентов за несколько отдельных дат, изменив запрос и заменив значения фильтра segments.date на другие. В следующей таблице показано количество отчетов, которые можно запустить за заданный временной интервал, чтобы уложиться в различные категории использования ресурсов.

Выполнение этого шаблона запроса 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 Ads поддерживает до 20 000 групп объявлений на кампанию и 10 000 кампаний на аккаунт. Поэтому, если этот код будет запущен на большом аккаунте Google Ads, он может перегрузить серверы API Google Ads, что приведет к ограничению скорости запросов и замедлению работы сервиса.

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

  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 Ads следует учитывать следующие рекомендации:

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