Pobieranie danych geograficznych na potrzeby eksperymentów

W przypadku automatycznego lub masowego pobierania danych na potrzeby eksperymentów geograficznych musisz używać interfejsu Google Ads API, aby pobierać dane o kosztach i wydatkach. Następnie łączysz te dane z surowymi, nieprzefiltrowanymi i nieprzypisanymi danymi o konwersjach lub przychodach z wewnętrznego systemu CRM, punktu sprzedaży lub wewnętrznych baz danych sprzedaży.

Zalecana architektura przepływu pracy interfejsu API

Aby dokładnie pobierać dane kampanii i dane o kosztach według segmentów geograficznych, postępuj zgodnie z tą architekturą:

• Usługa: użyj GoogleAdsService, a konkretnie metody Search lub SearchStream.

• Zasób: zapytanie geographic_view, aby sprawdzić, gdzie użytkownik znajdował się fizycznie lub czym się interesował, co jest zwykle standardem w przypadku eksperymentów geograficznych. Możesz też wysłać zapytanie location_view, aby sprawdzić skuteczność na podstawie konkretnych lokalizacji docelowych kampanii.

  Uwaga: nie używaj campaign_location_target_report, ponieważ ten starszy raport interfejsu AdWords API został wycofany.

• Pola do uwzględnienia:

  • campaign.id
  • segments.date
  • segments.geo_target_city (lub regionu albo kraju, w zależności od stopnia szczegółowości eksperymentu geograficznego)
  • metrics.cost_micros

• Przykładowe zapytanie GAQL: w przypadku eksperymentu geograficznego reklamodawcy pobierają dane o kosztach za pomocą interfejsu Google Ads API, a nie przypisane konwersje (które powinny pochodzić z wewnętrznego systemu CRM lub systemów innych firm). Możesz użyć tego zapytania:

  SELECT
    campaign.id,
    segments.date,
    segments.geo_target_city,
    metrics.cost_micros
  FROM geographic_view
  WHERE segments.date DURING LAST_30_DAYS
  

  Uwaga: geographic_view zwraca tylko wiersze dotyczące segmentów geograficznych, które w danym dniu odnotowały wyświetlenia lub wydatki. Aby uwzględnić w ciągach czasowych eksperymentu geograficznego dni i regiony, w których wydatki wynosiły zero, wykonaj w potoku danych lewe złączenie zewnętrzne z pełnym iloczynem kartezjańskim dat i regionów docelowych.

Uwaga: jeśli pobierasz dane o konwersjach z Google Ads, pobierasz konwersje przypisane, co oznacza, że widzisz tylko sprzedaż, którą algorytm Google już przypisał do Twoich reklam. Zdecydowanie odradzamy używanie w eksperymentach geograficznych danych atrybucji, ponieważ logika atrybucji zniekształca pomiar przyczynowo-skutkowy.

Przetwarzanie końcowe i wyodrębnianie danych

• Mapowanie segmentów geograficznych: interfejs API nie zwraca w widokach raportów nazw w formie zwykłego tekstu (np. „Nowy Jork”) ani krótkich kodów (np. „501” lub „ES”). Pola takie jak segments.geo_target_city lub segments.geo_target_country zwracają ciąg znaków nazwy zasobu wskazujący na GeoTargetConstant (np. geoTargetConstants/1023191). Wyodrębnij identyfikator numeryczny (1023191) i wyślij zapytanie do zasobu geo_target_constant:

  SELECT
    geo_target_constant.id,
    geo_target_constant.name,
    geo_target_constant.canonical_name
  FROM geo_target_constant
  WHERE geo_target_constant.id = 1023191
  

  Możesz też wykonać połączenie lokalnie w kodzie, pobierając statyczny plik CSV z celami kierowania geograficznego w sekcji Cele kierowania geograficznego.

• Przeliczanie kosztów: interfejs API zwraca wartości kosztów w mikrojednostkach. Aby uzyskać standardową wartość waluty wymaganą w przesyłanym pliku, musisz podzielić metrics.cost_micros przez 1 000 000.

Identyfikatory lokalizacji geograficznych na potrzeby mutacji kierowania

Podczas wprowadzania zmian w kierowaniu na lokalizację na poziomie kampanii lub grupy reklam reklamodawcy muszą wyszukać i podać dokładny identyfikator GeoTargetConstant (geoTargetConstants/ID) wybranych regionów. Nie możesz przekazywać nieprzetworzonych kodów ISO ani Nielsen.

Typ regionu	Identyfikator wymaganego interfejsu API (GeoTargetConstant)	Starszy format (nie używać)
Region DMA	ID 200501 (Nowy Jork)	Kod Nielsen (np. 501 dla Nowego Jorku)
Kraj	ID 2724 (w Hiszpanii)	Kod ISO (np. "ES" dla Hiszpanii)

Sprawdzone metody i typowe błędy formatowania

• Formatowanie daty: pole segments.date zwraca ciągi dat ISO-8601 w formacie YYYY-MM-DD. W potoku ETL serializuj pola daty jako ciągi znaków YYYY-MM-DD i unikaj otwierania wyeksportowanych plików CSV w aplikacjach do obsługi arkuszy kalkulacyjnych, które automatycznie zmieniają format kolumn daty.
• Zera na początku kodów pocztowych: w całym potoku danych traktuj kody pocztowe (np. 01234) jako ciągi znaków (VARCHAR lub STRING), a nie liczby całkowite, aby zera na początku nie były usuwane.
• Agregacja: jeśli przeprowadzasz badanie obejmujące wiele grup, musisz podać osobne dane o wydatkach dla każdej kampanii eksperymentalnej.
• Łączenie danych o konwersjach: podczas łączenia danych o konwersjach z wewnętrznego systemu CRM lub wewnętrznych baz danych sprzedaży upewnij się, że dane o konwersjach mają te właściwości, aby zapewnić bezproblemowe przetwarzanie danych z interfejsem Google Ads API i eksperymentem geograficznym:
  • Dzienne ciągi czasowe: dane muszą być zagregowane według dnia.
  • Poziom geograficzny: każda konwersja musi być przypisana do dokładnych jednostek geograficznych, które testujesz (np. dopasowanie kodu pocztowego dostawy klienta do rynku docelowego lub klastra kodów pocztowych użytego w projekcie).
  • Wartości brutto: dane muszą być nieujemnymi wartościami bezwzględnymi, takimi jak przychody brutto lub liczba konwersji brutto. Jeśli Twój system CRM śledzi przychody netto z ujemnymi wartościami zwrotów środków, musisz użyć w eksperymencie wartości brutto i zastosować później współczynnik zwrotów.