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, chẳng hạn 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, hãy xem hướng dẫn về giới hạn tốc độ và duy trì một đị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 cho báo cáo của Google

Để đảm bảo sự ổn định của máy chủ, API Google Ads sẽ điều tiết những mẫu truy vấn GoogleAdsService.SearchGoogleAdsService.SearchStream 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, 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 được gửi cho các yêu cầu bị điều tiết:

Phiên bản API Mã lỗi
<= phiên bản 16 QuotaError.RESOURCE_EXHAUSTED
>= phiên bản 17 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 tài nguyên cao.

Để 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ề chỉ số chi phí cho từng báo cáo riêng lẻ.

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

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

  • Quy mô của các tài khoản
  • Chế độ xem và cột mà bạn tìm nạp trong báo cáo
  • Tải dữ liệu 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 phát hành số liệu thống kê tổng hợp ban đầu về mức sử dụng 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 cập nhật để giúp bạn tinh chỉnh truy vấn của mình.

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, mẫu này 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 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 thấy số lượng báo cáo bạn có thể chạy trong một khoảng thời gian nhất định, sao cho mức sử dụng tài nguyên phù hợp với nhiều bộ chứa mức sử dụng tài nguyên.

Khoảng thời gian Trung bình Tương đối 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ột 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 trong 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ố này.

Lưu dữ liệu của bạn vào bộ nhớ đệm

Bạn nên lưu thông tin về thực thể vào bộ nhớ đệm từ các máy chủ API 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 các thực thể thường xuyên được truy cập hoặc các thực thể ít thay đổi. Sử dụng các thuộc tính change-event (sự kiện thay đổi) và change-status khi 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 đã phát hành 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 trong số đó ở 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 số lầ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 nhiều dữ liệu thay vì chạy nhiều báo cáo nhỏ. Một yếu tố ảnh hưởng đến lựa chọn này là các giới hạn về tài khoản.

Ví dụ: hãy xem xét mã sau đây để lấy 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 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, mã này có thể làm quá tải các máy chủ API Google Ads, dẫn đến giới hạn số lượng yêu cầu và điều tiết.

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

  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 trên máy chủ API Google Ads do số lượng báo cáo đang chạy thấp hơn.

Nếu thấy báo cáo quá lớn nên không thể chứa 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ệ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. Xem hướng dẫn về nhãn để tìm hiểu thêm.

Tối ưu hoá nội dung 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 của mình. 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 không được cập nhật thường xuyên hoặc hoàn toàn không được cập nhật. Vì vậy, việc tìm nạp hằng giờ sẽ không 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 (sự kiện thay đổi) 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ố hàng tải xuống bằng cách áp dụng các bộ lọc phù 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 của nhà quảng cáo bên thứ ba, thì bạn cần phát triển ứng dụng chú trọng đến việc khách hàng rời bỏ ứng dụng. Bạn nên dọn dẹp các quy trình và kho dữ liệu theo định kỳ để xoá tài khoản cho những khách hàng không còn sử dụng ứng dụng của bạn. Khi dọn dẹp các tài khoản Google Ads không sử dụng, hãy lưu ý 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, chẳng hạn như tác vụ định kỳ 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 thông tin cho phép, thì ứng dụng của bạn nên xử lý trường hợp này một cách linh hoạt và tránh gửi 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 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ộ của bạn sau một khoảng thời gian thích hợp.