Segmentacja jest dostępna w interfejsie Google Ads jako osobne menu. Segmentację w interfejsie Google Ads API możesz wdrożyć, dodając odpowiednie pole do zapytania. Załóżmy na przykład, że do zapytania dodasz segments.device
. W wyniku tego otrzymasz raport z wierszem dla każdej kombinacji urządzenia i określonego zasobu w klauzuli FROM
oraz wartości statystyczne (wyświetlenia, kliknięcia, konwersje itp.) podzielone między te kombinacje.
W interfejsie Google Ads można używać tylko jednego segmentu naraz, ale za pomocą interfejsu API możesz określić wiele segmentów w tym samym zapytaniu.
SELECT
campaign.name,
campaign.status,
segments.device,
metrics.impressions
FROM campaign
Wyniki wysłania tego zapytania do
GoogleAdsService.SearchStream
będą przypominać ten ciąg 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"
}
},
...
]
}
W tym przykładowym wyniku atrybuty pierwszego i drugiego obiektu, w tym nazwa zasobu, są takie same. Wyświetlenia są podzielone według urządzenia, dlatego w przypadku tej samej kampanii można zwrócić co najmniej 2 obiekty.
Niejawny podział na segmenty
Każdy raport jest początkowo segmentowany według zasobu określonego w klauzuli FROM
. Pole resource_name
zasobu w klauzuli FROM
jest zwracane, a dane są według niego segmentowane, nawet jeśli pole resource_name nie jest jawnie uwzględnione w zapytaniu. Jeśli na przykład w klauzuli FROM
jako zasób podasz ad_group
, automatycznie zostanie zwrócona wartość ad_group.resource_name
, a dane będą niejawnie segmentowane względem niej na poziomie grupy reklam.
W przypadku tego zapytania
SELECT metrics.impressions
FROM ad_group
Otrzymasz ciąg JSON podobny do tego:
{
"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"
}
}
]
}
Pole resource_name
w adGroup
jest zawsze zwracane, ponieważ ad_group
jest określone jako zasób w klauzuli FROM
.
Pola segmentu, które można wybrać
Nie wszystkie pola segmentu można wybrać w przypadku danego zasobu w klauzuli FROM
.
Załóżmy na przykład, że nadal wysyłasz zapytania z zasobu ad_group
. Aby pole segmentu można było wybrać z zasobu ad_group
, musi ono znajdować się na liście Segments
w przypadku ad_group. Segments
lista to żółta część tabeli dostępnych pól na stronie metadanych zasobu ad_group
.
Segmentowanie zasobów
W przypadku niektórych zasobów możesz mieć możliwość niejawnego łączenia z powiązanymi zasobami przez wybranie ich pól obok pól zasobu w klauzuli FROM
. Te powiązane zasoby znajdziesz na liście Attributed Resources
na stronie metadanych klauzuli FROM
. W przypadku zasobu ad_group
zobaczysz, że możesz też wybrać pola z zasobu campaign
. Pole resource_name
dowolnego elementu Attributed Resources
z co najmniej 1 polem w klauzuli SELECT
będzie automatycznie zwracane, nawet jeśli pole resource_name nie jest jawnie uwzględnione w zapytaniu.
Podobnie jak w przypadku pól Attributed Resource
, możesz też wybrać pola Segmenting Resource
. Jeśli dany zasób ma Segmenting Resources
listę na stronie metadanych, wybranie pól z jednego z tych zasobów spowoduje dalsze segmentowanie zapytania według zwróconego resource_name
tego Segmenting Resource
. Na przykład zasób campaign
jest wymieniony jako Segmenting Resource
w przypadku zasobu campaign_budget
. Wybranie dowolnego pola kampanii, np. campaign.name
, z zasobu campaign_budget
powoduje nie tylko zwrócenie pola campaign.name
, ale też zwrócenie i segmentowanie pola campaign.resource_name
.
Możliwość wyboru segmentów i danych
Dane segmentu mogą być niezgodne z niektórymi innymi danymi segmentu lub z niektórymi danymi. Aby sprawdzić, które pola segmentu są ze sobą zgodne, zapoznaj się z listą segmentów selectable_with
w klauzuli SELECT
.
W przypadku zasobu ad_group
dostępnych jest ponad 50 segmentów, które możesz wybrać. Jednak lista selectable_with
dla segments.hotel_check_in_date
to znacznie mniejszy zbiór zgodnych segmentów. Oznacza to, że jeśli dodasz pole
segments.hotel_check_in_date
do klauzuli SELECT
, ograniczysz dostępne segmenty, które możesz wybrać, do przecięcia tych 2 list.
Gdy dodasz niektóre segmenty, wartości w wierszu podsumowania mogą się zmniejszyć. Gdy do zapytania z tabelą FROM ad_group_ad
dodasz tabelę segments.keyword.info.match_type
, ten segment informuje zapytanie, że ma tylko pobrać wiersze danych zawierające słowa kluczowe i usunąć wszystkie wiersze, które nie są powiązane ze słowem kluczowym. W takim przypadku dane będą niższe, ponieważ nie obejmują żadnych danych innych niż dane dotyczące słów kluczowych.
Reguły dotyczące segmentów w klauzuli WHERE
Jeśli segment znajduje się w klauzuli WHERE
, musi też znajdować się w klauzuli SELECT
. Wyjątek od tej reguły stanowią te segmenty dat, które są nazywane podstawowymi segmentami dat:
segments.date
segments.week
segments.month
segments.quarter
segments.year
Reguły dotyczące pól podstawowego segmentu danych
Segmenty segments.date
, segments.week
, segments.month
, segments.quarter
i segments.year
działają w ten sposób:
Te segmenty można filtrować w klauzuli
WHERE
bez pojawiania się w klauzuliSELECT
.Jeśli którykolwiek z tych segmentów znajduje się w klauzuli
SELECT
, w klauzuliWHERE
musi być określony skończony zakres dat składający się z podstawowych segmentów dat. Segmenty dat nie muszą być takie same jak te określone wSELECT
.
Przykłady
Nieprawidłowe: ponieważ segments.date znajduje się w klauzuli SELECT , musisz określić skończony zakres dat w klauzuli WHERE dla segments.date , segments.week , segments.month , segments.quarter lub segments.year .
|
SELECT campaign.name, metrics.clicks, segments.date FROM campaign |
Prawidłowe: to zapytanie zwraca nazwy kampanii i kliknięcia uzyskane w określonym zakresie dat. Pamiętaj, że w klauzuli SELECT nie musi się pojawiać segments.date .
|
SELECT campaign.name, metrics.clicks FROM campaign WHERE segments.date > '2024-01-01' AND segments.date < '2024-02-01' |
Prawidłowe: to zapytanie zwraca nazwy kampanii i kliknięcia podzielone według daty dla wszystkich dni w zakresie dat. |
SELECT campaign.name, metrics.clicks, segments.date FROM campaign WHERE segments.date > '2024-01-01' AND segments.date < '2024-02-01' |
Prawidłowe: to zapytanie zwraca nazwy kampanii i kliknięcia podzielone na miesiące we wszystkich dniach w zakresie dat. |
SELECT campaign.name, metrics.clicks, segments.month FROM campaign WHERE segments.date > '2024-01-01' AND segments.date < '2024-02-01' |
Prawidłowe: to zapytanie zwraca nazwy kampanii i kliknięcia podzielone na kwartały, a następnie na miesiące w zakresie roku. |
SELECT campaign.name, metrics.clicks, segments.quarter, segments.month FROM campaign WHERE segments.year > 2019 AND segments.year < 2024 |
search_term_view
Zasób
search_term_view
jest też niejawnie segmentowany według grupy reklam, a nie tylko wyszukiwanego hasła, co odzwierciedla struktura jego nazwy zasobu, która zawiera też grupę reklam. Dlatego w wynikach możesz zobaczyć pozornie zduplikowane wiersze z tymi samymi hasłami, ale te wiersze należą do różnych grup reklam.
{
"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"
}
}
]
}
Chociaż w tym przykładzie zwrócone obiekty wydają się duplikatami, ich nazwy zasobów są w rzeczywistości różne, zwłaszcza w części „grupa reklam”. Oznacza to, że termin „zdjęcia google” jest przypisany do 2 grup reklam (o identyfikatorach 2222222222
i 33333333333
) w tym samym dniu (15 czerwca 2024 r.).
Możemy więc stwierdzić, że interfejs API działał zgodnie z przeznaczeniem i w tym przypadku nie zwrócił zduplikowanych obiektów.