Сегментация доступна в интерфейсе Google Ads в виде отдельного меню. Вы можете реализовать сегментацию в API Google Ads, добавив соответствующее поле в запрос. Например, предположим, вы добавляете segments.device в запрос. В результате будет создан отчёт со строкой для каждой комбинации устройства и указанного ресурса в предложении FROM , а также статистические значения (показы, клики, конверсии и т. д.), распределенные между ними.
В пользовательском интерфейсе Google Ads можно использовать только один сегмент за раз, но с помощью API можно указать несколько сегментов в одном запросе.
SELECT
campaign.name,
campaign.status,
segments.device,
metrics.impressions
FROM campaign
Результаты отправки этого запроса в GoogleAdsService.SearchStream будут напоминать эту строку JSON:
{
"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 . Возвращается поле resource_name ресурса в предложении FROM , и метрики сегментируются по нему, даже если поле resource_name явно не включено в запрос. Например, если в предложении FROM в качестве ресурса указано ad_group , то автоматически возвращается 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 . Поле resource_name любого Attributed Resources , имеющего хотя бы одно поле в предложении SELECT будет автоматически возвращено, даже если поле resource_name явно не включено в запрос.
Аналогично выбору полей Attributed Resource , вы также можете выбрать поля Segmenting Resource . Если на странице метаданных ресурса есть список Segmenting Resources , то при выборе полей из одного из этих ресурсов запрос будет дополнительно сегментирован по возвращаемому resource_name этого Segmenting Resource . Например, вы обнаружите, что ресурс campaign указан как Segmenting Resource для ресурса campaign_budget . Выбор любого поля кампании, например campaign.name , из ресурса campaign_budget приводит не только к возврату поля campaign.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 > '2024-01-01' AND segments.date < '2024-02-01' |
| Допустимо: этот запрос возвращает названия кампаний и клики, сегментированные по дате для всех дней в диапазоне дат. | SELECT campaign.name, metrics.clicks, segments.date FROM campaign WHERE segments.date > '2024-01-01' AND segments.date < '2024-02-01' |
| Допустимо: этот запрос возвращает названия кампаний и клики, сегментированные по месяцам для всех дней в диапазоне дат. | SELECT campaign.name, metrics.clicks, segments.month FROM campaign WHERE segments.date > '2024-01-01' AND segments.date < '2024-02-01' |
| Допустимо: этот запрос возвращает названия кампаний и клики, сегментированные по кварталам, а затем по месяцам для всех месяцев в годовом диапазоне. | SELECT campaign.name, metrics.clicks, segments.quarter, segments.month FROM campaign WHERE segments.year > 2019 AND segments.year < 2024 |
search_term_view
Ресурс search_term_view также неявно сегментирован по группам объявлений, а не только по поисковому запросу, что отражено в структуре имени ресурса , которое также включает группу объявлений. Поэтому в результатах поиска будут появляться, казалось бы, дублирующиеся строки с теми же поисковыми запросами, но эти строки относятся к другой группе объявлений.
{
"results":[
{
"searchTermView":{
"resourceName":"customers/1234567890/searchTermViews/111111111~2222222222~Z29vZ2xlIHBob3RvcyBpb3M",
"searchTerm":"google photos"
},
"metrics":{
"impressions":"3"
},
"segments":{
"date":"2024-06-15"
}
},
{
"searchTermView":{
"resourceName":"customers/1234567890/searchTermViews/111111111~33333333333~Z29vZ2xlIHBob3RvcyBpb3M",
"searchTerm":"google photos"
},
"metrics":{
"impressions":"2"
},
"segments":{
"date":"2024-06-15"
}
}
]
}
Хотя два возвращённых объекта в этом примере кажутся дубликатами, названия их ресурсов на самом деле различаются, особенно в части «ad group». Это означает, что поисковый запрос «google photos» относится к двум группам объявлений (ID 2222222222 и 33333333333 ) в одну и ту же дату (15.06.2024). Таким образом, можно сделать вывод, что API сработало как задумано и в данном случае не вернуло дубликатов объектов.