Podstawową funkcją wielu aplikacji Google Ads jest pobieranie danych na koncie na potrzeby analizy danych, zapytań klientów i sprawdzania zgodności z zasadami. Podczas pobierania danych zoptymalizuj ich wykorzystanie, aby nie przeciążać serwerów Google i nie ryzykować ograniczenia liczby żądań. Więcej informacji znajdziesz w przewodnikach dotyczących ograniczania liczby żądań i aktualizowania adresu e-mail do kontaktu.
Zasady Google dotyczące wykorzystania zasobów na potrzeby raportów
Aby zapewnić stabilność swoich serwerów, interfejs Google Ads API ogranicza
GoogleAdsService.Search i
GoogleAdsService.SearchStream wzorce zapytań, które zużywają nadmierną
ilość zasobów interfejsu API. Jeśli dany wzorzec zapytania zostanie ograniczony, inne usługi, metody i wzorce zapytań będą nadal działać bez zmian. W przypadku ograniczonych żądań zwracane są te błędy:
| Kod błędu |
|---|
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION lub QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION w zależności od czasu trwania wysokiego wykorzystania zasobów. |
Jeśli wystąpią te błędy, odczekaj 5 minut przed ponowieniem żądań, które zakończyły się niepowodzeniem z powodu błędu QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, oraz 30 minut w przypadku żądań, które zakończyły się niepowodzeniem z powodu błędu QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.
Aby ułatwić Ci identyfikowanie i monitorowanie kosztownych raportów, będziemy też zwracać dane o kosztach poszczególnych raportów.
| Metoda | Pole kosztów |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
Dane o kosztach zwracane przez te pola zależą od różnych czynników, takich jak:
- rozmiar konta,
- widoki i kolumny pobierane w raportach,
- obciążenie serwerów interfejsu Google Ads API.
Aby ułatwić Ci śledzenie kosztownych zapytań, publikujemy wstępne zbiorcze statystyki dotyczące wykorzystania zasobów przez różne wzorce zapytań, które widzimy na naszych serwerach. Będziemy okresowo publikować zaktualizowane dane, aby pomóc Ci w dostosowywaniu zapytań.
| Przedział czasu | Średnia (50 centyl). | 70 centyl (umiarkowanie wysoki) | 95 centyl (bardzo wysoki) |
|---|---|---|---|
| Krótkoterminowo (5 min) | 6000 | 30000 | 1800000 |
| Długoterminowo (24 godz.) | 16000 | 90000 | 8400000 |
Załóżmy na przykład, że używasz wzorca zapytania, który zużywa 600 jednostek zasobów na raport.
SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
segments.date = "YYYY-MM-DD"
To zapytanie jest wykonywane na wielu kontach klientów w przypadku kilku pojedynczych dat przez modyfikowanie zapytania w celu zastąpienia różnych wartości filtra segments.date. W tabeli poniżej znajdziesz liczbę raportów, które możesz wygenerować w danym przedziale czasu, tak aby wykorzystanie zasobów mieściło się w różnych zakresach.
| Przedział czasu | Średnia | Umiarkowanie wysoka | Bardzo wysoka |
|---|---|---|---|
| Krótkoterminowo (5 min) | 10 | 50 | 3000 |
| Długoterminowo (24 godz.) | 26 | 150 | 14000 |
Wykonanie tego wzorca zapytania 10 razy w ciągu 5 minut będzie liczone jako średnie wykorzystanie, a wygenerowanie 3000 raportów w ciągu 5 minut będzie liczone jako bardzo wysokie wykorzystanie.
Istnieje kilka strategii optymalizacji wykorzystania zasobów przez raporty. W dalszej części tego przewodnika omówimy niektóre z nich.
Zapisywanie danych w pamięci podręcznej
Szczegóły jednostek pobierane z serwerów interfejsu API należy zapisywać w pamięci podręcznej w lokalnej bazie danych, zamiast wywoływać serwer za każdym razem, gdy potrzebujesz danych, szczególnie w przypadku jednostek, do których często sięga się lub które rzadko się zmieniają. Jeśli to możliwe, używaj zdarzeń zmiany i stanu zmiany, aby wykryć, które obiekty uległy zmianie od czasu ostatniej synchronizacji wyników.
Optymalizacja częstotliwości generowania raportów
Google Ads opublikowało wytyczne dotyczące częstotliwości aktualizacji danych i częstotliwości ich aktualizacji. Na podstawie tych wytycznych określ, jak często chcesz pobierać raporty.
Jeśli musisz regularnie aktualizować konta, zalecamy ograniczenie ich liczby do niewielkiego zestawu, np. tylko do 20 najpopularniejszych kont Google Ads. Pozostałe konta można aktualizować rzadziej, np. raz lub dwa razy dziennie.
Optymalizacja rozmiaru raportów
Aplikacja powinna pobierać duże partie danych, zamiast generować dużą liczbę małych raportów. Czynnikiem, który ma wpływ na ten wybór, są limity kont.
Rozważmy na przykład ten kod, który pobiera statystyki dotyczące konkretnych grup reklam i aktualizuje tabelę statystyk w bazie danych:
List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
foreach (long adGroupId in adGroupIds)
{
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
"ad_group.id = ${adGroupId}";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
InsertRowsIntoStatsTable(adGroupId, rows);
}
Ten kod działa dobrze na małym koncie testowym. Google Ads obsługuje jednak do 20 tys. grup reklam na kampanię i 10 tys. kampanii na konto. Jeśli ten kod zostanie uruchomiony na dużym koncie Google Ads, może przeciążyć serwery interfejsu Google Ads API, co spowoduje ograniczenie liczby żądań.
Lepszym rozwiązaniem jest wygenerowanie jednego raportu i przetworzenie go lokalnie. Poniżej przedstawiamy jedno z takich rozwiązań, które korzysta z mapy w pamięci.
Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Zmniejsza to obciążenie serwerów interfejsu Google Ads API ze względu na mniejszą liczbę generowanych raportów.
Jeśli okaże się, że raport jest zbyt duży, aby zmieścić się w pamięci, możesz też podzielić zapytanie na mniejsze grupy, dodając klauzulę LIMIT w ten sposób:
SELECT
ad_group.id,
ad_group.name,
metrics.clicks,
metrics.cost_micros,
metrics.impressions,
segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
AND ad_group.id IN (id1, id2, ...)
LIMIT 100000
Etykiety to kolejny sposób na grupowanie jednostek i zmniejszanie liczby zapytań raportowania. Więcej informacji znajdziesz w przewodniku po etykietach.
Optymalizacja pobieranych danych
Podczas generowania raportów pamiętaj o kolumnach, które uwzględniasz w zapytaniach. Rozważmy ten przykład, który jest zaplanowany do uruchamiania co godzinę:
SELECT
customer.id,
customer.currency_code,
campaign.id,
campaign.name,
ad_group.id,
ad_group.name,
ad_group_criterion.keyword.match_type,
ad_group_criterion.keyword.text,
ad_group_criterion.criterion_id,
ad_group_criterion.quality_info.creative_quality_score,
ad_group_criterion.system_serving_status,
ad_group_criterion.negative,
ad_group_criterion.quality_info.quality_score,
ad_group_criterion.quality_info.search_predicted_ctr,
ad_group_criterion.quality_info.post_click_quality_score,
metrics.historical_landing_page_quality_score,
metrics.search_click_share,
metrics.historical_creative_quality_score,
metrics.clicks,
metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS
Jedynymi kolumnami, które mogą się zmieniać co godzinę, są metrics.clicks i metrics.impressions. Wszystkie pozostałe kolumny są aktualizowane rzadko lub wcale, dlatego pobieranie ich co godzinę jest bardzo nieefektywne. Możesz przechowywać te
wartości w lokalnej bazie danych i generować raport o zdarzeniach zmiany lub
stanie zmiany, aby pobierać zmiany raz lub dwa razy dziennie.
W niektórych przypadkach możesz zmniejszyć liczbę pobieranych wierszy, stosując odpowiednie filtry.
Zwalnianie miejsca przez nieużywane konta
Jeśli Twoja aplikacja zarządza kontami klientów zewnętrznych, musisz ją opracować z uwzględnieniem rezygnacji klientów. Okresowo zwalniaj miejsce w procesach i magazynach danych, aby usuwać konta klientów, którzy nie korzystają już z Twojej aplikacji. Podczas czyszczenia nieużywanych kont Google Ads pamiętaj o tych wskazówkach:
- Odwołaj autoryzację, którą klient przyznał Twojej aplikacji do zarządzania jego kontem.
- Przestań wykonywać wywołania interfejsu API na kontach Google Ads klienta. Dotyczy to zwłaszcza zadań offline, takich jak zadania crona i potoki danych, które są przeznaczone do działania bez interwencji użytkownika.
- Jeśli klient odwoła autoryzację, Twoja aplikacja powinna prawidłowo obsłużyć tę sytuację i unikać wysyłania nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
- Jeśli klient zlikwidował konto Google Ads, musisz to wykryć i unikać wysyłania nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
- Po odpowiednim czasie usuń z lokalnej bazy danych dane pobrane z kont Google Ads klienta.