Podstawową funkcją wielu aplikacji Google Ads jest pobieranie danych z konta na potrzeby takich przypadków użycia jak analiza danych, zapytania klientów i sprawdzanie zgodności z zasadami. Podczas pobierania danych należy zoptymalizować ich wykorzystanie, aby nie przeciążać serwerów Google, ponieważ może to spowodować ograniczenie szybkości. Więcej informacji znajdziesz w instrukcjach dotyczących ograniczania szybkości i utrzymywania aktualnego adresu e-mail kontaktowego.
Zasady Google dotyczące wykorzystania zasobów w przypadku raportów
Aby zapewnić stabilność serwerów, interfejs Google Ads API ogranicza żądania o wzorcach GoogleAdsService.Search i GoogleAdsService.SearchStream, które zużywają nadmierną ilość zasobów API. Jeśli zostanie ograniczone określone zapytanie, inne usługi, metody i wzorce zapytań będą nadal działać bez zmian. W przypadku ograniczonych żądań występują te błędy:
| Wersja interfejsu API | Kod błędu |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| >= v18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTIONlub QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION w zależności od czasu, przez jaki zasoby były intensywnie wykorzystywane. |
Aby ułatwić Ci identyfikowanie i monitorowanie drogich zgłoszeń, zwrócimy też dane o kosztach poszczególnych zgłoszeń.
| Metoda | Pole Koszt |
|---|---|
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 kont
- Widoki i kolumny pobierane w raportach
- obciążenie serwerów interfejsu Google Ads API;
Aby ułatwić Ci śledzenie kosztownych zapytań, publikujemy początkowe zagregowane statystyki dotyczące zużycia zasobów przez różne wzorce zapytań, które występują na naszych serwerach. Będziemy okresowo publikować zaktualizowane liczby, aby pomóc Ci w dostosowywaniu zapytań.
| Przedział czasu | Średnia (p50). | P70 (umiarkowanie wysoki) | P95 (bardzo wysoki) |
|---|---|---|---|
| Krótkoterminowe (5 min) | 6000 | 30000 | 1800000 |
| Długoterminowe (24 godziny). | 16000 | 90000 | 8400000 |
Załóżmy na przykład, że używasz wzoru 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"
Wykonujesz to zapytanie na wielu kontach klientów w przypadku kilku dat, modyfikując je w celu zastąpienia różnych wartości w filtrze segments.date. W tabeli poniżej podano liczbę raportów, które możesz uruchomić w danym przedziale czasowym, aby wykorzystanie zasobów mieściło się w różnych zbiornikach wykorzystania zasobów.
| Przedział czasu | Średnia | Umiarkowanie wysoki | Bardzo wysoka |
|---|---|---|---|
| Krótkoterminowe (5 min) | 10 | 50 | 3000 |
| Długoterminowe (24 godziny). | 26 | 150 | 14000 |
Uruchomienie tego wzoru zapytania 10 razy w ciągu 5 minut byłoby uznane za średnie wykorzystanie, natomiast uruchomienie 3000 raportów w ciągu 5 minut byłoby uznane za bardzo intensywne wykorzystanie.
Istnieje kilka strategii optymalizacji wykorzystania zasobów przez raporty. W dalszej części tego przewodnika omawiamy niektóre z tych strategii.
Dane w pamięci podręcznej
Szczegóły elementów pobierane z serwerów interfejsu API powinny być przechowywane w pamięci podręcznej w formie bazy danych, zamiast wywoływać serwer za każdym razem, gdy są potrzebne. Dotyczy to zwłaszcza elementów, do których często się odwołujesz lub które rzadko się zmieniają. Używaj zdarzeń zmiany change-event i stanu zmiany change-status, aby wykrywać obiekty, które uległy zmianie od ostatniej synchronizacji wyników.
Optymalizowanie częstotliwości generowania raportów
Google Ads ma opublikowane wytyczne dotyczące aktualności danych i częstotliwości ich aktualizowania. Na podstawie tych wskazówek możesz określić, jak często pobierać raporty.
Jeśli musisz regularnie aktualizować konta, zalecamy ograniczenie liczby takich kont do niewielkiego zbioru, np. tylko do 20 najważniejszych kont Google Ads. Pozostałe dane mogą być aktualizowane 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. Ważnym czynnikiem jest tu limit konta.
Rozważ na przykład ten kod, który pobiera statystyki dotyczące konkretnych grup reklam i aktualizuje tabelę bazy danych ze statystykami:
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 maksymalnie 20 tys. grup reklam na kampanię i 10 tys. kampanii na konto. Jeśli ten kod jest uruchamiany na dużym koncie Google Ads, może przeciążyć serwery interfejsu Google Ads API, co spowoduje ograniczenie szybkości i przepustowości.
Lepszym rozwiązaniem jest wygenerowanie pojedynczego raportu i przetworzenie go lokalnie. Poniżej przedstawiono jedno z takich podejść z wykorzystaniem 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);
}
Dzięki temu zmniejsza się obciążenie serwerów interfejsu Google Ads API, ponieważ generowana jest mniejsza liczba raportów.
Jeśli raport jest zbyt duży, aby można było go przechowywać w pamięci, możesz podzielić zapytanie na mniejsze grupy, dodając klauzulę LIMIT w takiej postaci:
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 grupowania elementów i zmniejszania liczby zapytań raportujących. Więcej informacji znajdziesz w przewodniku po etykietach.
Optymalizacja danych pobieranych przez usługę
Podczas generowania raportów należy zwracać uwagę na kolumny uwzględniane w zapytaniach. Rozważ ten przykład, w którym zadanie jest zaplanowane do wykonywania 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, więc pobieranie ich co godzinę jest bardzo nieefektywne. Możesz przechowywać te wartości w lokalnej bazie danych i uruchamiać raport change-event lub change-status, aby pobierać zmiany raz lub dwa razy dziennie.
W niektórych przypadkach możesz zmniejszyć liczbę pobieranych wierszy, stosując odpowiednie filtry.
Usuwanie nieużywanych kont
Jeśli Twoja aplikacja zarządza kontami klientów innych firm, musisz ją opracować z myślą o utracie klientów. Powinieneś regularnie porządkować procesy i magazyny 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:
- Anuluj autoryzację, którą klient przyznał Twojej aplikacji w celu zarządzania jego kontem.
- Zatrzymaj wywołania interfejsu API na kontach Google Ads klienta. Dotyczy to w szczególności zadań offline, takich jak zadania cron i przepływy danych, które są przeznaczone do działania bez udziału użytkownika.
- Jeśli klient cofnie autoryzację, Twoja aplikacja powinna odpowiednio zareagować na tę sytuację i nie wysyłać nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
- Jeśli klient anulował swoje konto Google Ads, wykryj to i unikaj wysyłania nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
- Po odpowiednim czasie usuń z bazy danych lokalnej dane pobrane z kont Google Ads klienta.