효율적인 데이터 관리

많은 Google Ads 애플리케이션의 핵심 기능은 사용할 계정 데이터를 검색하는 것입니다. 데이터 분석, 고객 쿼리, 정책 준수 확인 등 여러 가지 지원 사례에 활용할 수 있습니다. 데이터를 가져오는 동안 과부하가 발생하지 않도록 사용량을 최적화해야 합니다. 속도 제한의 위험이 있을 수 있습니다. 자세한 내용은 속도 제한과 최신 연락처 이메일 주소가 필요합니다.

보고서에 관한 Google의 리소스 사용 정책 이해하기

서버의 안정성을 보장하기 위해 Google Ads API는 GoogleAdsService.Search 및 과도하게 소비하는 GoogleAdsService.SearchStream 쿼리 패턴 많은 API 리소스를 제공합니다 특정 쿼리 패턴이 제한되면 서비스, 메서드, 쿼리 패턴은 영향을 받지 않고 계속 작동합니다. 이 제한된 요청에 대해 다음 오류가 발생합니다.

API 버전 오류 코드
v17 이하 QuotaError.RESOURCE_EXHAUSTED
v18 이상 QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION 또는 다음 경우에 따라 QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION 리소스 사용량이 많을 때 실행할 수 있습니다

비용이 많이 드는 보고서를 식별하고 모니터링할 수 있도록 비용 측정항목을 수동으로 살펴봐야 합니다.

메서드 비용 필드
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

이러한 필드에서 반환되는 비용 측정항목은

  • 계정 규모
  • 보고서에서 가져온 보기와 열
  • Google Ads API 서버의 로드

비용이 많이 드는 쿼리를 추적할 수 있도록 초기 집계를 게시하고 있습니다. Google Cloud에서 제공하는 다양한 쿼리 패턴의 리소스 사용과 관련된 있습니다. Google은 데이터를 세부적으로 조정하는 데 도움이 되도록 정기적으로 업데이트된 수치를 게시합니다. 할 수 있습니다.

기간 보통 (p50). P70 (보통) P95 (매우 높음)
단기 (5분) 6000 30000 1800000
장기적 (24시간). 16000 90000 8400000

예를 들어 다음과 같이 쿼리 패턴을 실행한다고 가정해 보겠습니다. 보고서당 리소스 600개

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

개별 날짜의 여러 고객 계정에 대해 이 쿼리를 실행합니다. segments.date의 다른 값을 대체하도록 쿼리를 수정합니다. 필터를 적용합니다. 다음 표는 주어진 기간 동안 실행할 수 있는 보고서 수를 보여줍니다. 다양한 리소스 사용량에 맞춰 리소스 사용량이 조정되는 기간 버킷과 동기화할 수 있습니다

기간 평균 다소 높음 매우 많음
단기 (5분) 10 50 3000
장기적 (24시간). 26 150 14000

이 쿼리 패턴을 5분에 10회 실행하면 평균으로 집계됩니다. 5분에 보고서 3, 000개를 실행하면 사용량이 매우 높은 것으로 계산됩니다.

운영 체제의 리소스 소비를 최적화하기 위한 몇 가지 전략이 있습니다. 있습니다. 이 가이드의 나머지 부분에서는 이러한 전략 중 일부를 다룹니다.

데이터 캐시

API 서버에서 가져온 항목 세부정보를 로컬 데이터가 필요할 때마다 서버를 호출하는 대신 특히 액세스 빈도가 높거나 자주 발생하지 않습니다. change-event 및 change-status를 사용하는 경우 마지막으로 결과를 동기화한 후 변경된 객체를 감지할 수 있습니다.

보고서 실행 빈도 최적화

Google Ads에서는 데이터 업데이트와 그 방법에 대한 게시된 가이드라인을 데이터가 자주 업데이트됩니다 이 가이드를 사용하여 보고서를 가져오는 경우가 많죠

계정을 정기적으로 업데이트해야 하는 경우 이러한 계정 수를 작은 집합으로 분류합니다(예: 상위 20개 Google Ads 계정만). 있습니다. 나머지는 더 낮은 빈도(예: 한 번 또는 하루에 두 번

보고서 크기 최적화

애플리케이션은 대규모 데이터 배치 대신 대규모 데이터 배치를 가져와야 합니다. 사용할 수 있습니다. 이러한 선택을 할 때 중요한 요소는 계정과 한도를 준수합니다.

예를 들어 특정 광고의 통계를 가져오는 다음 코드를 통계 데이터베이스 테이블을 그룹화하고 업데이트합니다.

  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);
  }

이 코드는 소규모 테스트 계정에서 사용할 수 있습니다. 하지만 Google Ads에서는 최대 캠페인당 광고그룹 20,000개 및 계정당 캠페인 10,000개 이 코드가 대규모 Google Ads 계정에 대해 실행되기 때문에 Google Ads API 서버에 과부하가 발생할 수 있습니다. 비율 제한 및 제한으로 이어집니다

더 나은 접근 방식은 단일 보고서를 실행하고 로컬에서 처리하는 것입니다. 1개 인메모리 맵을 사용하는 방법을 보여줍니다

  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);
  }

이렇게 하면 보고서 수가 적어 Google Ads API 서버의 로드가 줄어듭니다. 있습니다

보고서가 너무 커서 메모리에 보관할 수 없는 경우 다음과 같이 LIMIT 절을 추가하여 쿼리를 더 작은 그룹으로 축소합니다.

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

라벨은 항목을 그룹화하고 보고 수를 줄이는 또 다른 방법입니다. 쿼리합니다. 자세한 내용은 라벨 가이드를 참고하세요.

가져오는 항목 최적화

보고서를 실행할 때는 할 수 있습니다. 다음 예시를 참조하세요. 시간:

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

유일하게 매시간 변경될 수 있는 열은 metrics.clicks 및 metrics.impressions입니다. 다른 모든 열은 자주 업데이트되지 않거나 다음 위치에서 업데이트되지 않습니다. 매시간 가져오는 것은 매우 비효율적입니다. 이러한 데이터를 값을 저장하고 change-event 또는 change-status 보고서를 사용하여 하루에 한두 번 변경사항을 다운로드할 수 있습니다.

경우에 따라 선택할 수 있습니다.

사용하지 않는 계정 삭제하기

애플리케이션에서 서드 파티 광고주 계정을 관리하는 경우 고객 이탈을 염두에 두고 애플리케이션을 개발해야 합니다 주기적으로 프로세스 및 데이터 저장소를 정리하여 데이터를 제공하지 않는 고객의 계정을 더 오래 사용할 수 있습니다 사용하지 않는 Google Ads 계정을 정리할 때는 다음 지침을 따르세요.

  • 고객이 관리 애플리케이션에 부여한 승인 취소 계정을 만들 수 있습니다.
  • 고객의 Google Ads 계정에 대한 API 호출을 중지합니다. 적용 대상은 다음과 같습니다. 특히 크론 작업과 데이터 파이프라인 같은 오프라인 작업에 사용자 개입 없이 실행되도록 설계됩니다
  • 고객이 승인을 취소한 경우 애플리케이션에서 상황을 적절하게 처리하고 잘못된 API 호출을 API 서버입니다
  • 고객이 Google Ads 계정을 해지한 경우 Google의 API 서버로 잘못된 API 호출을 보내지 않도록 해야 합니다.
  • Google Ads 계정에서 다운로드한 데이터를 로컬 데이터베이스에 저장하는 것입니다
이전
모니터링
다음
비율 제한