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

Lưu ý: Phần này đề cập đến một thay đổi sắp tới trong API Google Ads. Hãy xem bài đăng trên blog để tìm hiểu thêm.

Để đảm bảo sự ổn định của máy chủ, API Google Ads sẽ điều tiết các mẫu truy vấn GoogleAdsService.Search và GoogleAdsService.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ẽ đượ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 17	QuotaError.RESOURCE_EXHAUSTED
>= phiên bản 18	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ề 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ố như

• Quy mô tài khoản của bạn
• Chế độ xem và cột mà bạn tìm nạp trong báo cáo
• Mức 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ẽ 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 máy chủ. Chúng tôi sẽ định kỳ công bố số liệu cập nhật để giúp bạn điều chỉnh các cụm từ tìm kiếm.

Khoảng thời gian	Trung bình (p50).	P70 (Trung bình 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 cho 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	Trung bình 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 sử dụng tài nguyên của báo cáo. Phần còn lại của hướng dẫn này sẽ trình bày 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 thông tin chi tiết về thực thể mà bạn tìm nạp từ máy chủ API vào 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 thay đổi không thường xuyên. Sử dụng change-event và change-status khi có thể để phát hiện những đối tượng đã thay đổi kể từ lần đồng bộ hoá kết quả gần đây nhất.

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

Google Ads đã phát hành 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ỏ, chẳng hạn như chỉ 20 tài khoản Google Ads hàng đầu. Phần 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ỗ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à giới hạn 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 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.

Bạn nên chạy một báo cáo duy nhất 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 làm giảm tải trên máy chủ API Google Ads do số lượng báo cáo đang 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 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á nội dung 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 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

Chỉ có 2 cột có khả năng thay đổi mỗi giờ là metrics.clicks và metrics.impressions. Tất cả các cột khác được cập nhật không thường xuyên hoặc không hề được cập nhật, vì vậy, việc tìm nạp các cột này hằng giờ sẽ rất 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 (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 tải xuống bằng cách áp dụng 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ải phát triển ứng dụng của mình với sự cân nhắc về tỷ lệ 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. Khi dọn dẹp các tài khoản Google Ads không dùng đến, hãy lưu ý các 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 người dùng can thiệp.
• Nếu khách hàng thu hồi quyền uỷ quyền, thì ứng dụng của bạn phải xử lý tình huống một cách linh hoạt 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, bạn nên phát hiện điều này 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.