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 để sử dụng như phân tích dữ liệu, thắc mắc 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 bị quá tải hoặc có nguy cơ bị giới hạn số lần yêu cầu. Để biết thêm chi tiết, hãy xem hướng dẫn về giới hạn tỷ lệ 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 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
GoogleAdsService.Search và
GoogleAdsService.SearchStream mẫu truy vấn sử dụng quá nhiều
số lượng tài nguyên API. Nếu một mẫu truy vấn cụ thể bị điều tiết, phương thức
các dịch vụ, phương thức và mẫu truy vấn sẽ tiếp tục hoạt động không bị ảnh hưởng. Chiến lược phát hành đĩa đơn
các lỗi sau đây được tạo ra cho các yêu cầu được đ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
dựa trên khoảng thời gian 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 của mình, 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à 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
- Chế độ xem và cột bạn tìm nạp trong báo cáo của mình
- 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 đang xuất bản số liệu thống kê về việc tiêu thụ tài nguyên của nhiều mẫu truy vấn mà chúng tôi nhận thấy các máy chủ của chúng tôi. Chúng tôi sẽ định kỳ đăng các số liệu cập nhật để giúp bạn tinh chỉnh truy vấn của bạn.
| 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 sử dụng 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 segments.date
. Bảng sau đây trình bày số lượng báo cáo mà bạn có thể chạy trong một
khoảng thời gian sao cho mức sử dụng tài nguyên của bạn phù hợp với 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 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ó một số chiến lược để tối ưu hoá việc sử dụng tài nguyên . Phần còn lại của hướng dẫn này trình bày một vài chiến lược nêu trên.
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ể mà bạn tìm nạp từ máy chủ API vào bộ nhớ đệm trong một thay vì gọi máy chủ mỗi khi bạn cần dữ liệu, đặc biệt đối với các thực thể thường xuyên được truy cập hoặc thay đổi thường xuyên. Sử dụng các thuộc tính change-event và change-status trong đó có thể phát hiện những đối tượng nào đã thay đổi kể từ lần đồng bộ hoá kết quả gần nhất.
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à cách thức thường xuyên dữ liệu được cập nhật. Bạn nên sử dụng hướng dẫn này để xác định cách thường xuyên để 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 đó vào một tập hợp nhỏ, ví dụ: chỉ 20 tài khoản Google Ads hàng đầu tài khoản. Phần còn lại có thể được cập nhật ở tần suất thấp hơn, chẳng hạn như một lần hoặc hai lần một ngày.
Tối ưu hoá kích thước của 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 một số báo cáo nhỏ. Một yếu tố ảnh hưởng đến lựa chọn này là tài khoản .
Ví dụ: hãy xem xét mã sau đây lấy số liệu thống kê cho quảng cáo cụ thể nhóm 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 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. Nếu mã này chạy trên một tài khoản Google Ads lớn, nó 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.
Bạn nên 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 như vậy bằng cách sử dụng bản đồ trong bộ nhớ.
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 các máy chủ API Google Ads do có ít báo cáo hơn đang chạy.
Nếu thấy báo cáo quá lớn nên không thể lưu vào bộ nhớ, bạn cũng có thể tạo
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 báo cáo truy vấn. Xem hướng dẫn về nhãn để tìm hiểu thêm.
Tối ưu hoá dữ liệu bạn tìm nạp
Khi chạy báo cáo, bạn nên chú ý đến những cột có trong báo cáo truy vấn của bạn. Hãy xem xét ví dụ sau, đượ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ó thể 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 được cập nhật ở
tất cả, vì vậy việc tìm nạp chúng hằng giờ là rất không hiệu quả. Bạn có thể lưu trữ những
các giá trị trong cơ sở dữ liệu cục bộ và chạy sự kiện thay đổi hoặc
báo cáo trạng thái thay đổi để tải các thay đổi xuống 1 hoặc 2 lần mỗi ngày.
Trong một số trường hợp, bạn có thể giảm số 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 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ải phát triển ứng dụng, đồng thời chú ý đến việc rời bỏ khách hàng. Bạn nên định kỳ dọn dẹp các quy trình và kho dữ liệu của bạn để xoá tài khoản cho những khách hàng không sử dụng ứng dụng của bạn lâu hơn. Khi dọn dẹp các tài khoản Google Ads không dùng đến, hãy giữ cho hãy lưu ý các hướng dẫn sau:
- Thu hồi quyền quản lý mà khách hàng đã cung cấp cho bạn tài khoản của mình.
- Ngừng thực hiện lệnh gọi API đến tài khoản Google Ads của khách hàng. Trường hợp này áp dụng đặc biệt là các công việc ngoại tuyến như công việc cron và đường ống 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 sự cho phép của họ, thì ứng dụng của bạn sẽ xử lý linh hoạt tình huống và tránh gửi lệnh gọi API không hợp lệ tới 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 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ộ sau một khoảng thời gian thích hợp.