Сегментация

Сегментацию, доступную в пользовательском интерфейсе 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 работал как задумано и в данном случае не возвращал повторяющиеся объекты.

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