Quản lý dữ liệu một cách hiệu quả

Một chức năng cốt lõi của nhiều ứng dụng Google Ads là truy xuất dữ liệu tài khoản cho các trường hợp sử dụng như phân tích dữ liệu, truy vấn của khách hàng và kiểm tra việc tuân thủ chính sách. Trong khi tìm nạp dữ liệu, bạn nên tối ưu hoá việc sử dụng để không làm quá tải máy chủ của Google hoặc có nguy cơ bị giới hạn tốc độ. Để biết thêm thông tin chi tiết, hãy xem hướng dẫn về giới hạn tốc độ và duy trì địa chỉ email liên hệ mới nhất.

Tìm hiểu chính sách của Google về việc sử dụng tài nguyên cho báo cáo

Để đảm bảo tính ổn định của các máy chủ, API Google Ads sẽ điều tiết các mẫu truy vấn GoogleAdsService.SearchGoogleAdsService.SearchStream sử dụng quá nhiều tài nguyên API. Nếu một mẫu truy vấn cụ thể bị điều tiết, các dịch vụ, phương thức và mẫu truy vấn khác sẽ tiếp tục hoạt động mà không bị ảnh hưởng. Các lỗi sau sẽ xảy ra đối với những yêu cầu bị điều tiết:

Mã lỗi
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION hoặc QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION tuỳ thuộc vào thời lượng sử dụng nhiều tài nguyên.

Để giúp bạn xác định và theo dõi các báo cáo tốn kém, chúng tôi cũng sẽ trả về một chỉ số chi phí cho từng báo cáo.

Phương thức Trường chi phí
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

Chỉ số chi phí do các trường này trả về phụ thuộc vào nhiều yếu tố, chẳng hạn như

  • Quy mô tài khoản của bạn
  • Các chế độ xem và cột mà bạn tìm nạp trong báo cáo
  • Tải trên các máy chủ API Google Ads.

Để giúp bạn theo dõi các truy vấn tốn kém, chúng tôi sẽ xuất bản số liệu thống kê tổng hợp ban đầu về mức tiêu thụ tài nguyên của nhiều mẫu truy vấn mà chúng tôi thấy trên các máy chủ của mình. Chúng tôi sẽ định kỳ xuất bản các số liệu mới nhất để giúp bạn tinh chỉnh các cụm từ tìm kiếm.

Khoảng thời gian Trung bình (p50). P70 (Khá cao) P95 (Rất cao)
Ngắn hạn (5 phút) 6000 30000 1800000
Dài hạn (24 giờ). 16000 90000 8400000

Ví dụ: giả sử bạn đang chạy một mẫu truy vấn như sau, tiêu thụ 600 đơn vị tài nguyên cho mỗi báo cáo.

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

Bạn chạy truy vấn này cho nhiều tài khoản khách hàng trong một số ngày riêng lẻ bằng cách sửa đổi truy vấn để thay thế các giá trị khác nhau cho bộ lọc segments.date. Bảng sau đây cho biết số lượng báo cáo mà bạn có thể chạy trong một khoảng thời gian nhất định để mức sử dụng tài nguyên của bạn phù hợp với nhiều nhóm mức sử dụng tài nguyên.

Khoảng thời gian Trung bình Khá cao Rất cao
Ngắn hạn (5 phút) 10 50 3000
Dài hạn (24 giờ). 26 150 14000

Việc chạy mẫu truy vấn này 10 lần trong 5 phút sẽ được tính là mức sử dụng trung bình, trong khi việc chạy 3.000 báo cáo trong 5 phút sẽ được tính là mức sử dụng rất cao.

Có một số chiến lược để tối ưu hoá mức tiêu thụ tài nguyên của báo cáo. Phần còn lại của hướng dẫn này trình bày một số chiến lược trong số đó.

Lưu dữ liệu vào bộ nhớ đệm

Bạn nên lưu chi tiết thực thể mà bạn tìm nạp từ máy chủ API vào bộ nhớ đệm trong cơ sở dữ liệu cục bộ thay vì gọi máy chủ mỗi khi cần dữ liệu, đặc biệt là đối với những thực thể thường xuyên được truy cập hoặc ít thay đổi. Sử dụng change-eventchange-status (nếu có thể) để phát hiện những đối tượng đã thay đổi kể từ lần gần nhất bạn đồng bộ hoá kết quả.

Tối ưu hoá tần suất chạy báo cáo

Google Ads đã xuất bản các nguyên tắc về độ mới của dữ liệu và tần suất cập nhật dữ liệu. Bạn nên sử dụng hướng dẫn này để xác định tần suất tìm nạp báo cáo.

Nếu cần cập nhật tài khoản thường xuyên, bạn nên giới hạn số lượng tài khoản đó ở một nhóm nhỏ, ví dụ: chỉ 20 tài khoản Google Ads hàng đầu. Các thông tin còn lại có thể được cập nhật với tần suất thấp hơn, ví dụ: một hoặc hai lần một ngày.

Tối ưu hoá kích thước báo cáo

Ứng dụng của bạn nên tìm nạp các lô dữ liệu lớn thay vì chạy một số lượng lớn báo cáo nhỏ. Một yếu tố ảnh hưởng đến lựa chọn này là giới hạn tài khoản.

Ví dụ: hãy xem xét đoạn mã sau đây để kéo số liệu thống kê cho các nhóm quảng cáo cụ thể và cập nhật bảng cơ sở dữ liệu số liệu thống kê:

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

Mã này hoạt động tốt trên một tài khoản thử nghiệm nhỏ. Tuy nhiên, Google Ads hỗ trợ tối đa 20.000 nhóm quảng cáo cho mỗi chiến dịch và 10.000 chiến dịch cho mỗi tài khoản. Vì vậy, nếu mã này chạy trên một tài khoản Google Ads lớn, thì mã này có thể làm quá tải các máy chủ API Google Ads, dẫn đến việc giới hạn tốc độ và điều tiết.

Cách tốt hơn là chạy một báo cáo duy nhất và xử lý báo cáo đó trên thiết bị. Một phương pháp như vậy sử dụng bản đồ trong bộ nhớ sẽ được trình bày.

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

Điều này giúp giảm tải cho các máy chủ Google Ads API do số lượng báo cáo được chạy ít hơn.

Nếu thấy báo cáo quá lớn để lưu trữ trong bộ nhớ, bạn cũng có thể chia nhỏ truy vấn thành các nhóm nhỏ hơn bằng cách thêm một mệnh đề LIMIT như sau:

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

Nhãn là một cách khác để nhóm các thực thể và giảm số lượng truy vấn báo cáo. Hãy xem hướng dẫn về nhãn để tìm hiểu thêm.

Tối ưu hoá những gì bạn tìm nạp

Khi chạy báo cáo, bạn nên lưu ý đến những cột mà bạn đưa vào các truy vấn. Hãy xem xét ví dụ sau đây được lên lịch chạy mỗi giờ:

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

Các cột duy nhất có khả năng thay đổi mỗi giờ là metrics.clicksmetrics.impressions. Tất cả các cột khác đều được cập nhật không thường xuyên hoặc không được cập nhật, vì vậy, việc tìm nạp các cột này theo giờ là rất kém hiệu quả. Bạn có thể lưu trữ các giá trị này trong cơ sở dữ liệu cục bộ và chạy báo cáo change-event hoặc change-status để tải các thay đổi xuống một hoặc hai lần mỗi ngày.

Trong một số trường hợp, bạn có thể giảm số lượng hàng mà bạn tải xuống bằng cách áp dụng các bộ lọc thích hợp.

Dọn dẹp các tài khoản không dùng đến

Nếu ứng dụng của bạn quản lý tài khoản khách hàng của bên thứ ba, thì bạn cần phát triển ứng dụng của mình sao cho có thể giảm thiểu tình trạng khách hàng rời bỏ. Bạn nên định kỳ dọn dẹp các quy trình và kho dữ liệu để xoá tài khoản của những khách hàng không còn sử dụng ứng dụng của bạn nữa. Khi dọn dẹp các tài khoản Google Ads không dùng đến, hãy lưu ý hướng dẫn sau:

  • Thu hồi quyền uỷ quyền mà khách hàng đã cấp cho ứng dụng của bạn để quản lý tài khoản của họ.
  • Ngừng thực hiện các lệnh gọi API đến tài khoản Google Ads của khách hàng. Điều này đặc biệt áp dụng cho các tác vụ ngoại tuyến, chẳng hạn như tác vụ định kỳ và quy trình xử lý dữ liệu được thiết kế để chạy mà không cần người dùng can thiệp.
  • Nếu khách hàng thu hồi uỷ quyền, thì ứng dụng của bạn phải xử lý tình huống này một cách thích hợp và tránh gửi các lệnh gọi API không hợp lệ đến máy chủ API của Google.
  • Nếu khách hàng đã huỷ tài khoản Google Ads, thì bạn nên phát hiện và tránh gửi các lệnh gọi API không hợp lệ đến máy chủ API của Google.
  • Xoá dữ liệu bạn đã tải xuống từ tài khoản Google Ads của khách hàng khỏi cơ sở dữ liệu cục bộ của bạn sau một khoảng thời gian thích hợp.