Сегментация

Сегментацию, доступную в пользовательском интерфейсе Google Ads в виде отдельного меню, можно реализовать в Google Ads API, просто добавив соответствующее поле в запрос. Например, добавление segments.device в запрос приводит к созданию отчета со строкой для каждой комбинации устройства и указанного ресурса в предложении FROM , а статистические значения (показы, клики, конверсии и т. д.) распределяются между ними.

Хотя в пользовательском интерфейсе Google Рекламы одновременно можно использовать только один сегмент, с помощью API вы можете указать несколько сегментов в одном запросе.

SELECT
  campaign.name,
  campaign.status,
  segments.device,
  metrics.impressions
FROM campaign

Результаты отправки этого запроса в GoogleAdsService.SearchStream будут выглядеть примерно так:

{
  "results":[
    {
      "campaign":{
        "resourceName":"customers/1234567890/campaigns/111111111",
        "name":"Test campaign",
        "status":"ENABLED"
      },
      "metrics":{
        "impressions":"10922"
      },
      "segments":{
        "device":"MOBILE"
      }
    },
    {
      "campaign":{
        "resourceName":"customers/1234567890/campaigns/111111111",
        "name":"Test campaign",
        "status":"ENABLED"
      },
      "metrics":{
        "impressions":"28297"
      },
      "segments":{
        "device":"DESKTOP"
      }
    },
    ...
  ]
}

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

Неявная сегментация

Каждый отчет изначально сегментируется по ресурсу, указанному в предложении FROM . Поле имя_ресурса ресурса в предложении FROM возвращается, и метрики сегментируются по нему, даже если поле имя_ресурса явно не включено в запрос. Например, если вы укажете ad_group в качестве ресурса в предложении FROM , автоматически будет возвращено ad_group.resource_name , и метрики будут неявно сегментироваться по нему на уровне ad_group.

Итак, для этого запроса

SELECT metrics.impressions
FROM ad_group

вы получите такую ​​строку JSON:

{
  "results":[
    {
      "adGroup":{
        "resourceName":"customers/1234567890/adGroups/2222222222"
      },
      "metrics":{
        "impressions":"237"
      }
    },
    {
      "adGroup":{
        "resourceName":"customers/1234567890/adGroups/33333333333"
      },
      "metrics":{
        "impressions":"15"
      }
    },
    {
      "adGroup":{
        "resourceName":"customers/1234567890/adGroups/44444444444"
      },
      "metrics":{
        "impressions":"0"
      }
    }
  ]
}

Обратите внимание, что поле resource_name adGroup всегда возвращается, поскольку ad_group была указана как ресурс в предложении FROM .

Выбираемые поля сегмента

Не все поля сегмента можно выбрать для данного ресурса в предложении FROM . В качестве примера мы продолжим выполнять запросы к ресурсу ad_group . Чтобы поле сегмента можно было выбрать из ресурса ad_group, это поле должно существовать в списке Segments для ad_group. Список Segments – это желтая часть таблицы доступных полей на странице метаданных ресурса ad_group .

Сегментировать ресурсы

При выборе некоторых ресурсов у вас может быть возможность неявно присоединиться к связанным ресурсам, выбрав их поля рядом с полями ресурса в предложении FROM . Эти связанные ресурсы можно найти в списке Attributed Resources ресурса на странице метаданных предложения FROM . В случае с ресурсом ad_group вы увидите, что вы также можете выбирать поля из ресурса campaign . Поле имя_ресурса любого Attributed Resources с хотя бы одним полем в предложении SELECT будет автоматически возвращено, даже если поле имя_ресурса не включено в запрос явно.

Подобно выбору полей Attributed Resource , вы также можете выбрать поля Segmenting Resource . Если данный ресурс имеет список Segmenting Resources на своей странице метаданных, то выбор полей из одного из этих перечисленных ресурсов приведет к дальнейшей сегментации запроса по возвращаемому имя_ресурса этого Segmenting Resource . Например, вы обнаружите, что ресурс campaign указан как Segmenting Resource для ресурса campaign_budget . Выбор любого поля кампании, например campaign.name , из ресурса Campamp_budget не только приведет к возврату поля Campamp.name, но и к возврату и сегментированию поля campaign.resource_name .

Возможность выбора между сегментами и показателями

Данное поле сегмента может быть несовместимо с некоторыми другими полями сегмента или с некоторыми полями показателей. Чтобы определить, какие поля сегментов совместимы друг с другом, вы можете просмотреть список сегментов selectable_with в предложении SELECT .

В случае с ресурсом ad_group вы можете выбрать более 50 доступных сегментов. Однако список selectable_with для segments.hotel_check_in_date представляет собой гораздо меньший набор совместимых сегментов. Это означает, что если вы добавите поле segments.hotel_check_in_date в предложение SELECT , вы ограничите доступные сегменты, которые вам осталось выбрать, до пересечения этих двух списков.

При добавлении некоторых сегментов показатели в сводной строке могут уменьшиться.
Когда segments.keyword.info.match_type добавляется в запрос с FROM ad_group_ad , этот сегмент сообщает запросу, что ему нужно получать только те строки данных, которые содержат ключевые слова, и удалять все строки, не связанные с ключевым словом. В этом случае метрики будут ниже, поскольку будут исключены любые метрики, не относящиеся к ключевым словам.

Правила для сегментов в предложении WHERE

Если сегмент находится в предложении WHERE , он также должен находиться в предложении SELECT . Исключением из этого правила являются следующие сегменты даты, которые называются основными сегментами даты :

  • segments.date
  • segments.week
  • segments.month
  • segments.quarter
  • segments.year

Правила для полей основного сегмента даты

Сегменты segments.date , segments.week , segments.month , segments.quarter и segments.year функционируют следующим образом:

  • Эти сегменты можно фильтровать в предложении WHERE , не отображая их в предложении SELECT .

  • Если какой-либо из этих сегментов находится в предложении SELECT , в предложении WHERE должен быть указан конечный диапазон дат, состоящий из основных сегментов дат (сегменты дат не обязательно должны совпадать с теми, которые указаны в SELECT ).

Примеры

Недопустимо: поскольку segments.date находится в предложении SELECT , вам необходимо указать конечный диапазон дат в предложении WHERE для segments.date , segments.week , segments.month , segments.quarter или segments.year .
SELECT
  campaign.name,
  metrics.clicks,
  segments.date
FROM campaign
Действительно: этот запрос возвращает названия кампаний и количество кликов, полученных за указанный диапазон дат. Обратите внимание, что segments.date не обязательно должен присутствовать в предложении SELECT .
SELECT
  campaign.name,
  metrics.clicks
FROM campaign
WHERE segments.date > '2020-01-01'
  AND segments.date < '2020-02-01'
Действительно: этот запрос возвращает названия кампаний и клики, сегментированные по дате, для всех дней в диапазоне дат.
SELECT
  campaign.name,
  metrics.clicks,
  segments.date
FROM campaign
WHERE segments.date > '2020-01-01'
  AND segments.date < '2020-02-01'
Действительно: этот запрос возвращает названия кампаний и клики, сегментированные по месяцам, для всех дней в диапазоне дат.
SELECT
  campaign.name,
  metrics.clicks,
  segments.month
FROM campaign
WHERE segments.date > '2020-01-01'
  AND segments.date < '2020-02-01'
Действительно: этот запрос возвращает названия кампаний и клики, сегментированные по кварталам, а затем по месяцам для всех месяцев в диапазоне года.
SELECT
  campaign.name,
  metrics.clicks,
  segments.quarter,
  segments.month
FROM campaign
WHERE segments.year > 2015
  AND segments.year < 2020

search_term_view

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

{
  "results":[
    {
      "searchTermView":{
        "resourceName":"customers/1234567890/searchTermViews/111111111~2222222222~Z29vZ2xlIHBob3RvcyBpb3M",
        "searchTerm":"google photos"
      },
      "metrics":{
        "impressions":"3"
      },
      "segments":{
        "date":"2015-06-15"
      }
    },
    {
      "searchTermView":{
        "resourceName":"customers/1234567890/searchTermViews/111111111~33333333333~Z29vZ2xlIHBob3RvcyBpb3M",
        "searchTerm":"google photos"
      },
      "metrics":{
        "impressions":"2"
      },
      "segments":{
        "date":"2015-06-15"
      }
    }
  ]
}

Хотя два возвращенных объекта в этом примере кажутся дубликатами, имена их ресурсов на самом деле разные, особенно в части «группа объявлений». Это означает, что поисковый запрос «Google Фото» относится к двум группам объявлений (идентификаторы 2222222222 и 33333333333 ) в одну и ту же дату (15.06.2015). Таким образом, можно сделать вывод, что API работал как задумано и в данном случае не возвращал повторяющиеся объекты.