Efektywnie zarządzaj danymi

Podstawową funkcją wielu aplikacji Google Ads jest pobieranie danych konta do wykorzystania takich jak analiza danych, zapytania klientów i sprawdzenie zgodności z zasadami. Podczas pobierania danych należy zoptymalizować wykorzystanie, by nie przeciążać serwerów Google, lub ryzyko ograniczenia liczby żądań. Więcej informacji znajdziesz w przewodnikach na temat ograniczanie stawek i utrzymywanie aktualny kontaktowy adres e-mail.

Zasady użytkowania zasobów Google na potrzeby raportów

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

Wersja interfejsu API Kod błędu
<= v17 QuotaError.RESOURCE_EXHAUSTED
>= v18 QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION lub QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION w zależności w czasie ich dużego wykorzystania.

Aby ułatwić wykrywanie i monitorowanie kosztownych raportów, wyświetlamy również danych o kosztach w poszczególnych raportach.

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

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

  • Rozmiar Twoich kont
  • Widoki i kolumny pobrane w raportach
  • Obciążenie serwerów interfejsu Google Ads API.

Aby ułatwić śledzenie drogich zapytań, publikujemy początkowe zbiorcze dane, statystyk dotyczących zużycia zasobów przez różne wzorce zapytań, które obserwujemy na na naszych serwerach. Będziemy okresowo publikować zaktualizowane dane, aby pomóc w ich dostosowywaniu zapytania.

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 uruchamiasz następujący wzorzec zapytania, który wykorzystuje 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 dla wielu kont klientów dla kilku indywidualnych dat Modyfikując zapytanie, zastępując różne wartości parametru segments.date filtr. W tabeli poniżej znajdziesz liczbę raportów, które możesz wygenerować w ramach przedział czasu, w którym wykorzystanie zasobów mieści się w różnych przedziałach czasowych. zasobników.

Przedział czasu Średnia Umiarkowanie wysoka Bardzo wysoka
Krótkoterminowe (5 min) 10 50 3000
Długoterminowe (24 godziny). 26 150 14000

Wykonanie tego wzorca zapytania 10 razy w ciągu 5 minut zostanie uznane za średnią a wygenerowanie 3000 raportów w ciągu 5 minut liczy się jako bardzo wysokie wykorzystanie.

Istnieje kilka strategii optymalizacji wykorzystania zasobów raportów. Niektóre z nich omawiamy w dalszej części tego przewodnika.

Buforowanie danych

Szczegóły jednostki pobranej z serwerów API należy zapisać w pamięci podręcznej w lokalizacji lokalnej do bazy danych zamiast wywoływać serwer za każdym razem, gdy potrzebne są dane, zwłaszcza w przypadku jednostek, które są często otwierane lub zmieniają się niezbyt często. Użyj parametrów change-event i change-status, gdzie: jest możliwe wykrycie, które obiekty zmieniły się od czasu ostatniej synchronizacji wyników.

Zoptymalizuj częstotliwość generowania raportów

W Google Ads znajdziesz opublikowane wskazówki dotyczące częstotliwości aktualizacji danych i sposobu ich publikowania dane są często aktualizowane. Wykorzystaj te wskazówki, aby określić, przy pobieraniu raportów.

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

Optymalizowanie rozmiaru raportów

Twoja aplikacja powinna pobierać duże partie danych zamiast uruchamiać dużą liczby małych raportów. Czynnikiem, który wpływa na ten wybór, jest konto .

Rozważ na przykład poniższy kod, który pobiera statystyki konkretnej reklamy grup i zaktualizować 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 działa na dużym koncie Google Ads, może przeciążyć serwery interfejsu Google Ads API co prowadzi do ograniczenia szybkości.

Lepszym sposobem jest wygenerowanie pojedynczego raportu i przetworzenie go lokalnie. Jeden takiego podejścia przy użyciu mapy pamięci wewnętrznej.

  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ę raportów. przed uruchomieniem.

Jeśli okaże się, że raport jest za duży, aby zapisać go w pamięci, możesz również podzielić podziel zapytanie na mniejsze grupy, dodając klauzulę LIMIT podobną do tej:

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 encji i zmniejszania liczby raportów zapytań. Więcej informacji znajdziesz w przewodniku po etykietach.

Optymalizuj pobierane dane

Podczas generowania raportów pamiętaj o kolumnach uwzględnianych w kolumnie zapytania. Weźmy pod uwagę przykład, który jest zaplanowany co godz.:

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 mogą zmieniać się co godzinę, to metrics.clicks i metrics.impressions Wszystkie inne kolumny są aktualizowane sporadycznie lub nie są wszystkie dane, więc pobieranie ich co godzinę jest bardzo mało wydajne. Możesz przechowywać te dane w lokalnej bazie danych i uruchomić zdarzenie zmiany lub zmiany stanu, by pobrać zmiany raz lub dwa razy dziennie.

W niektórych przypadkach możesz zmniejszyć liczbę pobieranych wierszy, stosując odpowiednich filtrów.

Wyczyść nieużywane konta

Jeśli Twoja aplikacja zarządza kontami reklamodawców zewnętrznych, musisz: tworzyć aplikacje z myślą o rezygnacjach klientów. Należy okresowo uporządkuj procesy i magazyny danych, aby usunąć konta klientów, którzy nie dłużej korzystać z aplikacji. Podczas czyszczenia nieużywanych kont Google Ads zachowaj ciąg pamiętaj o tych wskazówkach:

  • Unieważnij autoryzację, którą klient nadał Twojej aplikacji do zarządzania jego konto.
  • Zatrzymać wywoływanie interfejsu API na kontach Google Ads klienta. Dotyczy zwłaszcza w zadaniach offline, takich jak zadania cron i potoki danych, zaprojektowanych tak, aby działać bez interwencji użytkownika.
  • Jeśli klient anulował autoryzację, aplikacja powinna bezproblemowo poradzić sobie z sytuacją i nie wysyłaj nieprawidłowych wywołań interfejsu API do Serwery interfejsów API Google.
  • Jeśli klient zlikwidował konto Google Ads, wykryj go i unikaj wysyłania nieprawidłowych wywołań interfejsu API do serwerów API Google.
  • Usuń dane pobrane z kont Google Ads klienta ze swojego w lokalnej bazie danych po upływie odpowiedniego czasu.
Wstecz
Monitoring
Dalej
Ograniczenia liczby żądań