Efektywnie zarządzaj danymi

Podstawową funkcją wielu aplikacji Google Ads jest pobieranie danych na koncie na potrzeby takich zastosowań jak analiza danych, zapytania klientów i kontrole zgodności z zasadami. Podczas pobierania danych należy zoptymalizować 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 utrzymywania aktualnego kontaktowego adresu e-mail.

Zasady użytkowania zasobów w przypadku raportów

Aby zapewnić stabilność serwerów, interfejs Google Ads API ogranicza wzorce zapytań GoogleAdsService.Search i GoogleAdsService.SearchStream, które zużywają nadmierne ilości zasobów interfejsu API. Jeśli dany wzorzec zapytania jest ograniczony, inne usługi, metody i wzorce zapytań nadal działają bez zmian. W przypadku ograniczonych żądań występują 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, zanim ponownie spróbujesz wysłać żądania, które nie powiodły się z powodu błędu QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, i 30 minut w przypadku żądań, które nie powiodły się z powodu błędu QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Aby ułatwić Ci identyfikowanie i monitorowanie kosztownych raportów, zwracamy też dane o kosztach poszczególnych raportów:

Metoda Pole kosztu
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, które pobierasz w raportach;
  • obciążenie serwerów interfejsu Google Ads API,

W tabeli poniżej znajdziesz zagregowane statystyki dotyczące wykorzystania zasobów przez różne wzorce zapytań na serwerach interfejsu Google Ads API. Pomogą Ci one śledzić i optymalizować kosztowne zapytania:

Przedział czasu Średnia (p50) P70 (umiarkowanie wysoka) 95 centyl (bardzo wysoki)
Krótkoterminowe (5 min) 6000 30000 1800000
Długoterminowe (24 godziny) 16 000 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'

Możesz uruchomić to zapytanie dla wielu kont klientów i kilku różnych dat, modyfikując je tak, aby zastąpić różne wartości filtra segments.date. W tabeli poniżej znajdziesz informacje o liczbie raportów, które możesz wygenerować w danym przedziale czasu, tak aby wykorzystanie zasobów mieściło się w różnych przedziałach wykorzystania zasobów.

Przedział czasu Przeciętna Umiarkowanie wysoka Bardzo wysoka
Krótkoterminowe (5 min) 10 50 3000
Długoterminowe (24 godziny) 26 150 14000

Uruchomienie tego wzorca zapytania 10 razy w ciągu 5 minut będzie uznane za średnie wykorzystanie, natomiast uruchomienie 3000 raportów w ciągu 5 minut będzie uznane za bardzo wysokie wykorzystanie.

Istnieje kilka strategii optymalizacji wykorzystania zasobów przez raporty. W dalszej części tego przewodnika omówimy niektóre z tych strategii.

Zapisywanie danych w pamięci podręcznej

Szczegóły encji pobrane z serwerów interfejsu API należy przechowywać w pamięci podręcznej w lokalnej bazie danych, zamiast wywoływać serwer za każdym razem, gdy potrzebne są dane, zwłaszcza w przypadku encji, do których często uzyskuje się dostęp lub które rzadko się zmieniają. Używaj change-event i change-status, gdy to możliwe, aby wykrywać, które obiekty uległy zmianie od ostatniej synchronizacji wyników.

Optymalizowanie częstotliwości generowania raportów

Google Ads udostępnia wytyczne dotyczące częstotliwości aktualizacji danych. Na podstawie tych wskazówek możesz określić, jak często chcesz 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 mogą być aktualizowane rzadziej, na przykład raz lub 2 razy dziennie.

Optymalizowanie rozmiaru raportów

Aplikacja powinna pobierać duże partie danych, zamiast generować dużą liczbę małych raportów. Czynnikiem, który wpływa na ten wybór, są limity na koncie.

Spójrz na przykład na ten kod, który pobiera statystyki konkretnych grup reklam i aktualizuje tabelę bazy danych statystyk:

  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 000 grup reklam na kampanię i 10 000 kampanii na konto. Jeśli więc ten kod zostanie uruchomiony na dużym koncie Google Ads, może przeciążyć serwery interfejsu Google Ads API, co doprowadzi do ograniczenia liczby żądań i ograniczenia przepustowości.

Lepszym rozwiązaniem jest wygenerowanie jednego raportu i przetworzenie go lokalnie. Poniżej przedstawiamy jedno z takich podejść, które wykorzystuje mapę 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(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

Zmniejsza to obciążenie serwerów interfejsu Google Ads API, ponieważ generowanych jest mniej raportów.

Jeśli raport jest za duży, aby zmieścić się w pamięci, możesz też podzielić zapytanie na mniejsze grupy, dodając klauzulę LIMIT, na przykład tak:

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ń raportowania. Więcej informacji znajdziesz w przewodniku po etykietach.

Optymalizacja pobieranych danych

Podczas generowania raportów należy zwracać uwagę na kolumny, które uwzględniasz w zapytaniach. Rozważmy ten przykład, który ma być uruchamiany 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 generować raport zdarzeń zmiany lub stanu zmiany, aby pobierać zmiany raz lub 2 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 zewnętrznych, musisz ją opracować z uwzględnieniem odpływu klientów. Należy okresowo czyścić procesy i magazyny danych, aby usuwać konta klientów, którzy nie korzystają już z aplikacji. Podczas porządkowania nieużywanych kont Google Ads pamiętaj o tych wskazówkach:

  • Anuluj autoryzację, którą klient udzielił Twojej aplikacji, aby zarządzać jego kontem.
  • Przestań wykonywać wywołania interfejsu API na kontach Google Ads klienta. Dotyczy to zwłaszcza zadań offline, takich jak zadania cron i potoki danych, które są zaprojektowane do działania bez interwencji użytkownika.
  • Jeśli klient wycofał autoryzację, 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 zlikwidował swoje konto Google Ads, musisz wykryć zlikwidowane konta i unikać wysyłania nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
  • Po odpowiednim czasie usuń z lokalnej bazy danych informacje pobrane z kont Google Ads klienta.
Wstecz
Monitorowanie
Dalej
Ograniczenia liczby żądań