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á mứ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ề việc 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 sử dụng tài nguyên của Google đối với báo cáo

Để đảm bảo tính ổn định của máy chủ, API Google Ads sẽ điều tiết GoogleAdsService.SearchGoogleAdsService.SearchStream các mẫu truy vấn tiêu thụ quá nhiều tài nguyên API. Nếu một mẫu truy vấn cụ thể bị điều tiết, thì 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 đây sẽ xảy ra đối với các 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.

Nếu bạn gặp phải các lỗi này, hãy đợi 5 phút trước khi thử lại các yêu cầu không thành công với QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION và 30 phút đối với các yêu cầu không thành công với QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Để 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
  • Mức tải trên 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 đang 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 máy chủ. Chúng tôi sẽ định kỳ xuất bản các số liệu cập nhật để giúp bạn tinh chỉnh các truy vấn.

Khoảng thời gian Mức 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 nhiều 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 Mức 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 3000 báo cáo trong 5 phút sẽ được tính là mức sử dụng rất cao.

Có nhiều 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 đề cập đến một số chiến lược này.

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

Bạn nên lưu chi tiết về 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 bạn cần dữ liệu, đặc biệt là đối với các thực thể thường xuyên được truy cập hoặc ít thay đổi. Hãy sử dụng sự kiện thay đổitrạng thái thay đổi nếu có thể để phát hiện những đối tượng đã thay đổi kể từ lần gần đây 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 bạn 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. Bạn có thể cập nhật các tài khoản còn lại với tần suất thấp hơn, ví dụ: một hoặc hai lần mỗi 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à hạn mức tài khoản.

Ví dụ: hãy xem xét 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 máy chủ Google Ads API, dẫn đến việc giới hạn tốc độ và điều tiết.

Một cách tiếp cận tốt hơn là chạy một báo cáo duy nhất và xử lý báo cáo đó cục bộ. Một cách tiếp cận như vậy bằng cách sử dụng bản đồ trong bộ nhớ được minh hoạ.

  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 làm giảm tải trên 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 trong bộ nhớ, bạn cũng có thể chia truy vấn thành các nhóm nhỏ hơn bằng cách thêm 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 các cột mà bạn đưa vào truy vấn. Hãy xem 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 ít khi được cập nhật 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 sự kiện thay đổi hoặc trạng thái thay đổi để 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 sử dụng

Nếu ứng dụng của bạn quản lý tài khoản khách hàng bên thứ ba, thì bạn cần phát triển ứng dụng của mình có tính đến 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 lưu trữ dữ liệu để xoá các 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 sử dụng, hãy lưu ý đến hướng dẫn sau:

  • Thu hồi 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 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 công việc ngoại tuyến như công việc cron và quy trình dữ liệu được thiết kế để chạy mà không cần sự can thiệp của người dùng.
  • Nếu khách hàng thu hồi quyền của họ, thì ứng dụng của bạn sẽ xử lý tình huống 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 của họ, thì bạn nên phát hiện tài khoả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 mà 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ộ sau một khoảng thời gian thích hợp.