효율적인 데이터 관리

많은 Google Ads 애플리케이션의 핵심 기능은 데이터 분석, 고객 문의, 정책 준수 여부 확인과 같은 사용 사례를 위해 계정 데이터를 가져오는 것입니다. 데이터를 가져오는 동안 Google 서버에 과부하가 걸리거나 비율 제한이 적용되지 않도록 사용량을 최적화해야 합니다. 자세한 내용은 비율 제한 및 최신 연락처 이메일 주소 유지에 관한 가이드를 참고하세요.

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

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

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에서는 서버에서 확인되는 다양한 쿼리 패턴의 리소스 사용량에 관한 초기 집계 통계를 게시하고 있습니다. 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 서버에 오버로드가 발생하여 비율 제한 및 제한이 발생할 수 있습니다.

단일 보고서를 실행하고 로컬에서 처리하는 것이 좋습니다. 인메모리 맵을 사용하는 이러한 접근 방식 중 하나가 나와 있습니다.

  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

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

가져오는 항목 최적화

보고서를 실행할 때는 쿼리에 포함하는 열에 유의해야 합니다. 1시간마다 실행되도록 예약된 다음 예시를 고려해 보세요.

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

1시간마다 변경될 수 있는 열은 metrics.clicks 및 metrics.impressions뿐입니다. 다른 모든 열은 자주 업데이트되지 않거나 전혀 업데이트되지 않으므로 시간별로 가져오는 것은 매우 비효율적입니다. 이러한 값을 로컬 데이터베이스에 저장하고 change-event 또는 change-status 보고서를 실행하여 하루에 한 번 또는 두 번 변경사항을 다운로드할 수 있습니다.

경우에 따라 적절한 필터를 적용하여 다운로드하는 행 수를 줄일 수 있습니다.

사용하지 않는 계정 정리

애플리케이션에서 서드 파티 고객 계정을 관리하는 경우 고객 이탈을 염두에 두고 애플리케이션을 개발해야 합니다. 더 이상 애플리케이션을 사용하지 않는 고객의 계정을 삭제하려면 주기적으로 프로세스와 데이터 스토어를 정리해야 합니다. 사용하지 않는 Google Ads 계정을 정리할 때는 다음 안내를 참고하세요.

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