Сегментация

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

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