Efektywnie zarządzaj danymi

Podstawową funkcją wielu aplikacji Google Ads jest pobieranie danych konta na potrzeby analizy danych, zapytań klientów i kontroli zgodności z zasadami. Podczas pobierania danych należy optymalizować wykorzystanie zasobów, aby nie przeciążać serwerów Google, ani ryzyko ograniczenia szybkości przesyłania danych. Więcej informacji znajdziesz w przewodnikach dotyczących ograniczania liczby żądań i utrzymywania aktualnego kontaktowego adresu e-mail.

Omówienie zasad Google dotyczących wykorzystania zasobów na potrzeby raportów

Aby zapewnić stabilność serwerów, interfejs Google Ads API ogranicza wzorce zapytań GoogleAdsService.Search i GoogleAdsService.SearchStream, które zużywają nadmierną ilość zasobów interfejsu API. Jeśli ograniczony jest konkretny wzorzec zapytań, inne usługi, metody i wzorce zapytań będą działać bez zmian. W przypadku ograniczonych żądań wysyłane są te błędy:

Wersja interfejsu API	Kod błędu
<= wersja 16	QuotaError.RESOURCE_EXHAUSTED
>= wersja 17	QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION lub QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION w zależności od czasu trwania dużego wykorzystania zasobów.

Aby pomóc Ci zidentyfikować i monitorować drogie raporty, w poszczególnych raportach zwracamy też dane o kosztach.

Metoda	Pole kosztu
GoogleAdsService.Search	SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream	SearchGoogleAdsStreamResponse.query_resource_consumption

Wskaźnik kosztów zwracany przez te pola zależy od różnych czynników, takich jak

• rozmiar Twoich kont,
• Widoki i kolumny pobierane w raportach
• Obciążenie serwerów interfejsu Google Ads API.

Aby pomóc w śledzeniu drogich zapytań, publikujemy wstępne statystyki zbiorcze dotyczące zużycia zasobów przez różne wzorce zapytań widoczne na naszych serwerach. Co jakiś czas będziemy publikować zaktualizowane dane, aby pomóc Ci doprecyzować zapytania.

Przedział czasu	Średnia (p50).	P70 (Średnio wysoki)	P95 (bardzo wysoka)
Krótkie (5 minut)	6000	30000	1800000
Długoterminowo (24 godziny).	16000	90000	8400000

Załóżmy na przykład, że używasz poniższego 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"

Aby uruchomić to zapytanie dla wielu kont klientów dla kilku poszczególnych dat, zmodyfikuj zapytanie tak, aby zastępowało różne wartości filtra segments.date. W tabeli poniżej znajdziesz liczbę raportów, które możesz uruchomić w danym przedziale czasu, tak aby wykorzystanie zasobów mieściło się w różnych zasobnikach wykorzystania zasobów.

Przedział czasu	Średnia	Umiarkowanie wysoki	Bardzo wysoka
Krótkie (5 minut)	10	50	3000
Długoterminowo (24 godziny).	26	150	14000

Uruchomienie tego wzorca zapytania 10 razy w ciągu 5 minut liczy się jako średnie wykorzystanie, a uruchomienie 3000 raportów w ciągu 5 minut liczy się jako bardzo duże wykorzystanie.

Istnieje kilka strategii optymalizowania wykorzystania zasobów przez raporty. W pozostałej części tego przewodnika omawiamy niektóre z tych strategii.

Przechowywanie danych w pamięci podręcznej

Lepiej buforować szczegóły encji pobrane z serwerów API w lokalnej bazie danych, zamiast wywoływać serwer za każdym razem, gdy potrzebujesz danych, zwłaszcza w przypadku encji, do których często uzyskiwany jest dostęp lub które zmieniają się rzadko. Tam, gdzie to możliwe, używaj parametrów change-event i change-status, gdzie możesz wykryć, które obiekty zmieniły się od ostatniej synchronizacji wyników.

Optymalizacja częstotliwości generowania raportów

W Google Ads opublikowaliśmy wytyczne dotyczące częstotliwości aktualizacji danych. Skorzystaj z tych wskazówek, aby określić, jak często pobierać raporty.

Jeśli musisz regularnie aktualizować konta, zalecamy ograniczenie liczby takich kont do niewielkiej grupy, np. tylko 20 pierwszych kont Google Ads. Pozostałe możesz aktualizować z mniejszą częstotliwością, np. raz lub 2 razy dziennie.

Optymalizacja rozmiaru raportów

Aplikacja powinna pobierać duże wsady danych zamiast generować dużą liczbę małych raportów. Czynnik, który ma wpływ na ten wybór, to limity kont.

Poniżej znajdziesz przykładowy kod, który pobiera statystyki określonych 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 to przeciążyć serwery interfejsu Google Ads API, co doprowadzi do ograniczenia liczby żądań i sprawności.

Lepszym rozwiązaniem jest wygenerowanie jednego raportu i przetwarzanie go lokalnie. Przykładem może być użycie 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ę tworzonych raportów.

Jeśli raport jest za duży, aby zapisać go w pamięci, możesz 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 elementów i zmniejszanie liczby zapytań raportowania. Więcej informacji znajdziesz w przewodniku po etykietach.

Optymalizacja pobieranych treści

Uruchamiając raporty, pamiętaj o kolumnach uwzględnianych w zapytaniach. Przeanalizujmy ten przykład, który jest 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

Jedyne kolumny, które prawdopodobnie będą się zmieniać co godzinę, to metrics.clicks i metrics.impressions. Pozostałe kolumny są aktualizowane rzadko lub wcale, więc pobieranie ich co godzinę jest bardzo mało efektywne. Możesz przechowywać te wartości w lokalnej bazie danych i wygenerować raport zdarzenia zmiany lub zmiany stanu, aby pobierać zmiany raz lub dwa razy dziennie.

W niektórych przypadkach możesz zmniejszyć liczbę pobieranych wierszy, stosując odpowiednie filtry.

Czyszczenie nieużywanych kont

Jeśli Twoja aplikacja służy do zarządzania kontami reklamodawców w firmach zewnętrznych, musisz ją tworzyć z myślą o rezygnacji klientów. Regularnie 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:

• Cofnij upoważnienie klienta do zarządzania jego kontem.
• Zaprzestać wywoływania interfejsu API na kontach Google Ads klienta. Dotyczy to w szczególności zadań offline, takich jak zadania cron i potoki danych, które mają działać bez udziału użytkownika.
• Jeśli klient unieważnił autoryzację, Twoja aplikacja powinna z łatwością rozwiązać problem i nie wysyłać nieprawidłowych wywołań interfejsu API do serwerów interfejsów API Google.
• Jeśli klient zlikwidował swoje konto Google Ads, wykryj to i nie wysyłaj nieprawidłowych wywołań interfejsu API do serwerów interfejsu API Google.
• Po upływie odpowiedniego czasu usuń z lokalnej bazy danych dane pobrane z kont Google Ads klienta.