在 Google Ads 使用者介面中,區隔功能會以獨立的選單提供,只要在查詢中加入適當的欄位,即可在 Google Ads API 中實作。舉例來說,如果在查詢中加入 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
子句中指定的資源進行區隔。系統會傳回 FROM
子句中資源的 resource_name 欄位,並根據該欄位區隔指標,即使查詢中未明確納入 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"
}
}
]
}
請注意,由於 ad_group
已在 FROM
子句中指定為資源,因此系統一律會傳回 adGroup
的 resource_name
欄位。
可選取的區隔欄位
在 FROM
子句中,並非所有區隔欄位都能選取特定資源。舉例來說,我們會繼續從 ad_group
資源進行查詢。如要從 ad_group 資源選取區隔欄位,該欄位必須存在於 ad_group 的 Segments
清單中。Segments
清單是 ad_group
資源中繼資料頁面上可用欄位表格的黃色部分。
區隔資源
從部分資源中選取時,您可以選擇在 FROM
子句中選取相關資源的欄位,藉此隱含地彙整相關資源。這些相關資源可在 FROM
子句中繼資料頁面中的資源 Attributed Resources
清單中找到。在 ad_group
資源的情況下,您可以從 campaign
資源中選取欄位。即使查詢中未明確加入 resource_name 欄位,系統仍會自動傳回 SELECT
子句中至少包含 1 個欄位的任何 Attributed Resources
的 resource_name 欄位。
與選取 Attributed Resource
欄位類似,您也可以選取 Segmenting Resource
欄位。如果特定資源在中繼資料頁面上有 Segmenting Resources
清單,從清單中的某個資源選取欄位,就會導致查詢進一步依據該 Segmenting Resource
傳回的 resource_name 進行區隔。舉例來說,您會發現 campaign
資源會列為 campaign_budget
資源的 Segmenting Resource
。從 campaign_budget 資源選取任何廣告活動欄位 (例如 campaign.name
) 時,系統不僅會傳回 campaign.name 欄位,也會傳回 campaign.resource_name
欄位,並據此進行區隔。
區隔和指標之間的選取性
特定區隔欄位可能與部分其他區隔欄位或部分指標欄位不相容。如要找出哪些區隔欄位彼此相容,您可以查看 SELECT
子句中區隔的 selectable_with
清單。
以 ad_group
資源為例,您可以選取 50 多個可用區隔。不過,segments.hotel_check_in_date
的 selectable_with
清單是相容的細目項目組合,規模較小。也就是說,如果您將 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
中指定的日期區隔相同)。
範例
無效:由於 SELECT 子句包含 segments.date ,因此您需要在 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"
}
}
]
}
雖然這個範例中傳回的兩個物件似乎是重複的,但實際上資源名稱有所不同,尤其是「廣告群組」部分。這表示搜尋字詞「google photos」會歸因於同一天 (2024-06-15) 的兩個廣告群組 (ID 2222222222
和 33333333333
)。因此,我們可以得出結論,在這種情況下,API 運作正常,且不會傳回重複的物件。