Efektywnie zarządzaj danymi

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 należy zoptymalizować 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 utrzymywania aktualnego kontaktowego adresu e-mail.

Zasady użytkowania 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 jest ograniczany, inne usługi, metody i wzorce zapytań działają 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 pomóc Ci w identyfikowaniu i monitorowaniu 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 konta;
  • widoki i kolumny pobierane w raportach;
  • obciążenie serwerów interfejsu Google Ads API.

W tabeli poniżej znajdziesz zbiorcze statystyki dotyczące wykorzystania zasobów przez różne wzorce zapytań na serwerach interfejsu Google Ads API, które pomogą Ci śledzić i dostosowywać kosztowne zapytania:

Przedział czasu Średnia (p50) P70 (umiarkowanie wysoka) P95 (bardzo wysoka)
Krótkoterminowe (5 minut) 6000 30000 1800000
Długoterminowe (24 godziny) 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 dat, ponieważ zapytanie jest modyfikowane 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ótkoterminowe (5 minut) 10 50 3000
Długoterminowe (24 godziny) 26 150 14000

Wykonanie tego wzorca zapytania 10 razy w ciągu 5 minut będzie traktowane jako średnie wykorzystanie, a wygenerowanie 3000 raportów w ciągu 5 minut będzie traktowane 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.

Buforowanie danych

Szczegóły jednostek pobierane z serwerów interfejsu API należy buforować w lokalnej bazie danych, zamiast za każdym razem, gdy potrzebujesz danych, wywoływać serwer. Dotyczy to zwłaszcza jednostek, do których często się uzyskuje dostęp 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 możesz określić, jak często 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 2 razy dziennie.

Optymalizacja 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 kont.

Przeanalizujmy 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 prawidłowo na małym koncie testowym. Google Ads obsługuje jednak do 20 tys. grup reklam w kampanii i 10 tys. kampanii na koncie. 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 znajdziesz przykład takiego rozwiązania, 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(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 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 zmniejszenie liczby zapytań raportowania. Więcej informacji znajdziesz w przewodniku po etykietach.

Optymalizacja pobieranych danych

Podczas generowania raportów należy pamiętać o kolumnach, które są uwzględniane w zapytaniach. Przeanalizujmy 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 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 rezygnacji klientów. Okresowo czyść 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:

  • Odwołaj autoryzację, którą klient przyznał Twojej aplikacji na zarządzanie jego kontem.
  • Przestań wysyłać wywołania interfejsu API na konta Google Ads klienta. Dotyczy to zwłaszcza zadań offline, takich jak zadania crona i potoki danych, które są zaprojektowane 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 na serwery interfejsu API Google.
  • Jeśli klient zlikwidował konto Google Ads, musisz wykryć zlikwidowane konta i unikać wysyłania nieprawidłowych wywołań interfejsu API na serwery interfejsu API Google.
  • Po upływie odpowiedniego czasu usuń z lokalnej bazy danych dane pobrane z kont Google Ads klienta.
Wstecz
Monitorowanie
Dalej
Ograniczenia liczby żądań