Minhaz Kazi, Chuyên gia hỗ trợ nhà phát triển, Google Analytics – Tháng 2 năm 2023
Nếu đang phát triển ứng dụng bằng Google Analytics Data API, thì bạn nên hiểu cách các hạn mức và giới hạn dành cho API hoạt động. Nếu ứng dụng của bạn được thiết kế tốt, thì người dùng ít có khả năng đạt đến giới hạn hạn mức. Một số phương pháp hay nhất có liên quan cũng dẫn đến các truy vấn hiệu suất đến API. Điều này có thể đẩy nhanh tốc độ báo cáo và trang tổng quan trong ứng dụng của bạn, đồng thời mang lại trải nghiệm người dùng mong muốn hơn. Bài viết này thảo luận về hệ thống hạn mức và các phương pháp hay nhất để triển khai Google Analytics Data API.
Tìm hiểu về hệ thống hạn mức cho Google Analytics Data API
Vì Google Analytics được hàng triệu nhà phát triển và người dùng sử dụng, nên hạn mức cho các yêu cầu API sẽ ngăn hệ thống xử lý nhiều dữ liệu hơn mức có thể xử lý, trong khi vẫn đảm bảo phân bổ tài nguyên hệ thống một cách công bằng. Data API cho các tài sản Google Analytics 4 sử dụng hệ thống nhóm mã thông báo để quản lý hạn mức API. Để hiểu khái niệm này, hãy tưởng tượng có một bộ chứa có thể chứa tối đa số mã thông báo. Trước tiên, mọi yêu cầu API sẽ kiểm tra bộ chứa. Nếu không còn mã thông báo nào, yêu cầu sẽ không thành công. Nếu không, yêu cầu sẽ được thực thi và sẽ sử dụng một hoặc nhiều mã thông báo từ bộ chứa tuỳ thuộc vào độ phức tạp của yêu cầu. Các mã thông báo được bổ sung vào bộ chứa tới mức tối đa tại các khoảng thời gian cố định.
Tuỳ thuộc vào phương thức Data API bạn đang sử dụng, sẽ có 3 danh mục hạn mức riêng biệt:
- Thời gian thực (cho
runRealtimeReport) - Phễu (cho
runFunnelReport) - Cốt lõi (đối với tất cả các phương pháp khác)
Và các phương thức Data API sẽ kiểm tra nhiều bộ chứa cho mã thông báo hạn mức:
- Một cơ sở lưu trú/ngày
- Trên mỗi cơ sở lưu trú/giờ
- Trên mỗi dự án/thuộc tính/giờ
- Số yêu cầu đồng thời trên mỗi tài sản
- Số lỗi máy chủ trên mỗi dự án trên mỗi thuộc tính mỗi giờ
5 bộ chứa này được kiểm tra bất cứ khi nào có yêu cầu Data API cho một tài sản. Nếu bất kỳ bộ chứa nào đang trống, yêu cầu sẽ ngay lập tức không thành công kèm theo lỗi 429. Nếu không có bộ chứa nào bị trống, thì hệ thống sẽ sử dụng một mã thông báo duy nhất từ bộ chứa Số yêu cầu đồng thời trên mỗi thuộc tính và sau đó, yêu cầu API sẽ được thực thi. Tuỳ vào độ phức tạp của yêu cầu, một lượng mã thông báo nhất định sẽ được dùng từ mỗi nhóm (trong số 3 nhóm đầu tiên) sau khi quá trình thực thi hoàn tất. Số yêu cầu đồng thời trên mỗi thuộc tính cũng sẽ nhận được mã thông báo được bổ sung vào thời điểm này.
Hạn mức Trên mỗi dự án mỗi thuộc tính mỗi giờ đảm bảo việc giảm hạn mức cho một hoặc nhiều người dùng sẽ không ảnh hưởng đến những người dùng khác trong ứng dụng của bạn. Ở đây, dự án đề cập đến dự án GCP của ứng dụng. Hạn mức Trên mỗi thuộc tính mỗi giờ thường gấp 4 lần hạn mức Trên mỗi dự án cho mỗi thuộc tính mỗi giờ. Vì vậy, đối với người dùng cuối, ít nhất 4 dự án khác nhau phải truy cập vào một thuộc tính trước khi có thể dùng hết hạn mức Trên mỗi thuộc tính mỗi giờ. Việc thực thi hạn mức ở cả cấp dự án và cấp tài sản đảm bảo rằng các vấn đề về hạn mức được giới hạn ở một tài sản duy nhất và sẽ không ảnh hưởng đến các thuộc tính khác mà ứng dụng của bạn đang truy cập.
Hạn mức Lỗi máy chủ đề cập đến các phản hồi của API có mã 500 hoặc 503. Nếu ứng dụng của bạn tạo quá nhiều lỗi khi truy cập vào một tài sản, thì ứng dụng sẽ sử dụng hạn mức Lỗi máy chủ trong mỗi dự án trên mỗi thuộc tính mỗi giờ.
Tất cả mã thông báo hạn mức đều được bổ sung vào hạn mức theo khoảng thời gian đã nêu. Hãy tham khảo bài viết Hạn mức API Dữ liệu của Google Analytics để biết thông tin mới nhất về hạn mức. Ví dụ: phương thức Core nhận được 1.250 mã thông báo hạn mức trong bộ chứa Mỗi dự án mỗi thuộc tính mỗi giờ. Giả sử một yêu cầu trung bình từ ứng dụng của bạn sử dụng 10 mã thông báo hạn mức, thì ứng dụng của bạn sẽ có thể thực hiện 125 yêu cầu Lõi mỗi giờ cho một tài sản chuẩn và gấp 10 lần số lượng đó (1250 yêu cầu Core) cho bất kỳ tài sản Analytics 360 nào. Giới hạn mã thông báo hạn mức cao hơn là một trong những lợi ích chính của tài sản Analytics 360.
Vì mức tiêu thụ mã thông báo cho 3 bộ chứa đầu tiên phụ thuộc vào mức độ phức tạp của yêu cầu, nên rất khó để dự đoán chính xác mức sử dụng mã thông báo trước khi thực thi yêu cầu. Những cách sau thường làm tăng độ phức tạp của yêu cầu, từ đó dẫn đến việc sử dụng mã thông báo:
- Yêu cầu thêm phương diện
- Truy vấn khoảng thời gian cao hơn
- Bao gồm những phương diện có số lượng giá trị riêng biệt cao hơn
- Truy vấn một tài sản có số lượng sự kiện cao hơn
Do đó, cùng một truy vấn cho hai thuộc tính khác nhau có thể dẫn đến việc sử dụng mã thông báo hoàn toàn khác nhau vì số lượng giá trị riêng biệt của các phương diện có thể thay đổi hoặc lưu lượng truy cập có thể khác nhau. Tuy nhiên, bạn có thể thấy các thuộc tính có mức lưu lượng truy cập và cấu hình tương tự sẽ có cách sử dụng mã thông báo tương tự. Bạn có thể sử dụng giả định này để dự đoán việc sử dụng mã thông báo của khách hàng trong các giai đoạn lập kế hoạch và thiết kế ứng dụng.
Giám sát việc sử dụng hạn mức
Để giám sát việc sử dụng hạn mức và truyền tải thông tin đó cho người dùng cuối, bạn có thể thêm "returnPropertyQuota": true vào nội dung yêu cầu API. Thao tác này sẽ trả về đối tượng PropertyQuota cùng với phản hồi của API. Đối tượng PropertyQuota sẽ chứa lượng tiêu thụ và trạng thái hạn mức còn lại cho cả 5 bộ chứa. Dưới đây là ví dụ về nội dung và phản hồi cho yêu cầu:
Yêu cầu
{
"dimensions": [
{
"name": "medium"
}
],
"metrics": [
{
"name": "activeUsers"
}
],
"dateRanges": [
{
"startDate": "yesterday",
"endDate": "yesterday"
}
],
"returnPropertyQuota": true
}
Đáp
{
"dimensionHeaders": [
{
"name": "medium"
}
],
"metricHeaders": [
{
"name": "activeUsers",
"type": "TYPE_INTEGER"
}
],
...
"propertyQuota": {
"tokensPerDay": {
"consumed": 1,
"remaining": 24997
},
"tokensPerHour": {
"consumed": 1,
"remaining": 4997
},
"concurrentRequests": {
"consumed": 0,
"remaining": 10
},
"serverErrorsPerProjectPerHour": {
"consumed": 0,
"remaining": 10
},
"potentiallyThresholdedRequestsPerHour": {
"consumed": 0,
"remaining": 120
},
"tokensPerProjectPerHour": {
"consumed": 1,
"remaining": 1247
}
},
"kind": "analyticsData#runReport",
...
}
Do đó, sau mỗi lần thành công yêu cầu API Dữ liệu, bạn có thể biết hạn mức mà yêu cầu đã sử dụng và hạn mức còn lại cho tài sản. Bạn cũng có thể hiển thị thông tin này cho người dùng thông qua giao diện ứng dụng.
Quản lý hạn mức
Bạn nên triển khai các phương pháp hay nhất để quản lý hạn mức được nêu chi tiết bên dưới để tận dụng tối đa Data API. Ngoài ra, việc nâng cấp các thuộc tính lên phiên bản 360 có thể làm tăng lượng dữ liệu được truy cập thông qua API.
Các phương pháp hay nhất
Có hai cách để giảm mức sử dụng hạn mức cho ứng dụng của bạn:
- Gửi ít yêu cầu API hơn
- Gửi các yêu cầu API ít phức tạp hơn
Hãy ghi nhớ hai nguyên tắc này, sau đây là các phương pháp mà bạn có thể triển khai:
- Lưu vào bộ nhớ đệm: Việc triển khai lớp lưu vào bộ nhớ đệm sẽ mang lại lợi ích cho cả khả năng hữu dụng và việc quản lý hạn mức cho ứng dụng. Google Analytics sẽ lưu các yêu cầu API của bạn vào bộ nhớ đệm, nhưng các yêu cầu lặp lại vẫn sẽ phát sinh mã thông báo hạn mức. Bằng cách lưu phản hồi của API vào bộ nhớ đệm, bạn có thể giảm đáng kể số lượng yêu cầu lặp lại. Ví dụ: dữ liệu trong ngày cho các tài sản chuẩn có thể có thời gian hết hạn bộ nhớ đệm là từ 4 giờ trở lên. Xem bài viết Độ mới của dữ liệu trong Google Analytics.
- Hợp nhất yêu cầu: Cố gắng hợp nhất nhiều yêu cầu API thành một yêu cầu duy nhất. Ví dụ: 5 yêu cầu về dữ liệu trong khung thời gian 2 ngày có thể sử dụng gấp 3 lần mã thông báo hạn mức so với 1 yêu cầu trong khung thời gian 10 ngày. Nếu bạn có nhiều yêu cầu chỉ khác nhau về một chiều, hãy cân nhắc hợp nhất các yêu cầu đó thành một yêu cầu duy nhất.
- Đơn giản hoá yêu cầu: Giới hạn các yêu cầu ở lượng dữ liệu tối thiểu mà ứng dụng và người dùng của bạn cần có. Số lượng lớn hàng/cột hoặc tiêu chí bộ lọc phức tạp sẽ tốn nhiều mã thông báo hạn mức hơn. Phạm vi ngày dài hơn thường tốn kém hơn (ví dụ: việc thay đổi phạm vi ngày từ 28 ngày thành 365 ngày có thể tiêu tốn gấp 3 lần mã thông báo hạn mức). Bạn cũng có thể cân nhắc sử dụng phương diện có số lượng giá trị riêng biệt thấp hơn bất cứ khi nào có thể (ví dụ: yêu cầu
dateHourthay vìdateHourMinute). - Cách sử dụng
limithiệu quả: Việc thay đổilimittrong yêu cầu API để giảm số lượng hàng được trả về không ảnh hưởng đáng kể đến mã thông báo hạn mức đã tiêu thụ. Ví dụ: 5 yêu cầu có giới hạn 10 nghìn hàng có thể sử dụng mã thông báo hạn mức gấp 5 lần so với 1 yêu cầu có giới hạn 50 nghìn hàng. - Sử dụng đúng danh mục phương thức: Như đã đề cập ở trên, hạn mức được trải rộng trên ba danh mục phương thức. Việc sử dụng phương thức phù hợp cho đúng trường hợp sử dụng có thể giúp tiết kiệm hạn mức trên các danh mục khác. Ví dụ: thay vì tạo phễu của riêng bạn trong ứng dụng bằng dữ liệu từ các phương thức Core, hãy sử dụng phương thức
runFunnelReportđể tạo phễu. - Cập nhật chế độ cài đặt mặc định: Khi tác giả hoặc tuỳ chỉnh báo cáo trên nền tảng của bạn, người dùng có thể không cập nhật các tuỳ chọn mặc định mà ứng dụng của bạn đưa ra mà chỉ thay đổi các tuỳ chọn đó trong thời gian chạy. Nếu ứng dụng của bạn có phạm vi ngày mặc định là 365 ngày và người dùng thường xem báo cáo 28 ngày, thì điều này sẽ thường xuyên sử dụng nhiều hạn mức hơn yêu cầu. Hãy cân nhắc việc giới hạn các phạm vi và lựa chọn trong chế độ cài đặt mặc định, đồng thời cho phép người dùng chọn chế độ cài đặt tối ưu cho trường hợp sử dụng của họ. Hoặc trong một số trường hợp, bạn cũng có thể giới hạn những giá trị mặc định mà người dùng có thể thay đổi.
- Yêu cầu xếp hàng và tải từng phần: Hãy lưu ý đến giới hạn mã thông báo Số yêu cầu đồng thời trên mỗi thuộc tính. Ứng dụng của bạn không nên gửi quá nhiều yêu cầu cùng một lúc. Nếu ứng dụng của bạn có một số lượng lớn thành phần trên giao diện người dùng dẫn đến một số lượng lớn các yêu cầu API, hãy cân nhắc việc phân trang giao diện người dùng, tải từng phần và xếp hàng các yêu cầu bằng thời gian đợi luỹ thừa để thử lại. Sử dụng phương thức
returnPropertyQuotađể theo dõi chặt chẽ mức sử dụng mã thông báo Số yêu cầu đồng thời trên mỗi thuộc tính của ứng dụng.
Quản lý các kỳ vọng và trải nghiệm người dùng
- Hãy cung cấp ý kiến phản hồi cho người dùng trước khi họ chạy các truy vấn có khả năng sử dụng nhiều mã thông báo. Ví dụ: các truy vấn có nhiều phương diện có số lượng giá trị riêng biệt cao hoặc có khung thời gian lớn có thể sử dụng một số lượng lớn mã thông báo. Việc cung cấp cảnh báo và lời nhắc xác nhận cho các truy vấn đó có thể ngăn người dùng thực hiện các thay đổi không cần thiết đối với báo cáo và giúp họ giới hạn phạm vi truy vấn.
- Đối với các giải pháp báo cáo tuỳ chỉnh, hãy cung cấp cho người dùng một cách để hiểu cách sử dụng truy vấn của từng phần tử trong báo cáo của họ. Ví dụ: bạn có thể cung cấp khung hiển thị gỡ lỗi liệt kê hạn mức sử dụng mã thông báo cho từng phần tử báo cáo.
- Cung cấp ý kiến phản hồi về loại lỗi cụ thể về hạn mức và quy định hành động của người dùng.
- Vì tài sản Google Analytics 360 có hạn mức gấp 5 đến 10 lần so với tài sản chuẩn, nên bạn sẽ linh hoạt hơn khi sử dụng tài sản Google Analytics 360.
Việc tăng hạn mức API vượt quá giới hạn mặc định không áp dụng cho Data API cho Google Analytics 4. Google Analytics 360 cung cấp các hạn mức có giới hạn cao hơn cho các tài sản Google Analytics 4. Nếu người dùng của bạn đạt đến hạn mức ngay cả sau khi triển khai các phương pháp hay nhất, thì họ nên cân nhắc việc nâng cấp các tài sản lên phiên bản 360. Một lựa chọn khác cho người dùng là sử dụng BigQuery Export của Google Analytics. Điều đó sẽ cho phép người dùng xuất dữ liệu cấp sự kiện sang BigQuery và chạy bản phân tích của riêng họ.
Nếu bạn có câu hỏi khác về hạn mức Data API, hãy truy cập vào GA Discord hoặc hỏi trên Stack Overflow. Nếu có yêu cầu cụ thể về tính năng liên quan đến Data API, thì bạn có thể đăng các yêu cầu đó trên công cụ theo dõi lỗi của chúng tôi.