Quản lý hạn mức cho Google Analytics Data API

Minhaz Kazi, Người hỗ trợ nhà phát triển, Google Analytics – Tháng 2 năm 2023

Nếu đang phát triển các ứng dụng bằng [Google Analytics Data API], bạn nên hiểu cách hoạt động của hạn mức và giới hạn đối với API này. 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 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 cao cho API. Điều này có thể giúp tăng 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 trình bày 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 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 đối với các yêu cầu API sẽ bảo vệ hệ thống khỏi việc xử lý nhiều dữ liệu hơn mức có thể xử lý, đồng thời đảm bảo phân phối công bằng tài nguyên hệ thống. Data API cho tài sản Google Analytics 4 sử dụng hệ thống thùng đựng thẻ để quản lý hạn mức API. Để hiểu rõ khái niệm này, hãy tưởng tượng có một vùng chứa có thể chứa tối đa một số lượng mã thông báo. Mọi yêu cầu API sẽ kiểm tra vùng chứa trước. 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ẽ tiêu thụ một hoặc nhiều mã thông báo từ nhóm 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 nhóm đến mức tối đa trong các khoảng thời gian cố định.

Tuỳ thuộc vào phương thức Data API mà bạn đang sử dụng, có 3 danh mục hạn mức riêng biệt:

Và các phương thức Data API sẽ kiểm tra nhiều nhóm để biết [mã thông báo hạn mức][Hạn mức Data API của Google Analytics]:

  1. Mỗi tài sản mỗi ngày
  2. Mỗi tài sản mỗi giờ
  3. Mỗi dự án mỗi tài sản mỗi giờ
  4. Số yêu cầu đồng thời trên mỗi tài sản
  5. Lỗi máy chủ cho mỗi dự án, mỗi tài sản, mỗi giờ

Năm bộ chứa này được kiểm tra bất cứ khi nào có yêu cầu API dữ liệu cho một tài sản. Nếu bất kỳ nhóm nào không có dữ liệu, yêu cầu sẽ ngay lập tức không thành công với lỗi 429. Nếu không có nhóm nào trống, thì một mã thông báo sẽ được sử dụng từ nhóm Số yêu cầu đồng thời cho mỗi tài sản, sau đó yêu cầu API sẽ được thực thi. Dựa trên độ phức tạp của yêu cầu, một số lượng mã thông báo nhất định sẽ được sử 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 cho mỗi tài sản cũng sẽ được cấp lại mã thông báo vào thời điểm này.

Hạn mức Mỗi dự án, mỗi tài sản, mỗi giờ đảm bảo rằng việc một hoặc nhiều người dùng sử dụng hết hạn mức sẽ không ảnh hưởng đến những người dùng khác của ứng dụng. Ở đây, project đề cập đến dự án GCP của ứng dụng. Hạn mức Mỗi tài sản mỗi giờ thường gấp 4 lần hạn mức Mỗi dự án mỗi tài sản 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 tài sản trước khi hạn mức Mỗi tài sản mỗi giờ có thể bị cạn kiệt. Việc thực thi hạn mức ở cả cấp dự án và tài sản đảm bảo rằng các vấn đề về hạn mức chỉ giới hạn ở một tài sản duy nhất và sẽ không ảnh hưởng đến những tài sản 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 ra quá nhiều lỗi trong khi truy cập vào một tài sản, thì ứng dụng đó sẽ vượt quá hạn mức Số lỗi máy chủ trên mỗi dự án, mỗi tài sản, mỗi giờ.

Tất cả mã thông báo hạn mức đều được bổ sung đến hạn mức ở các khoảng thời gian đã nêu. Tham khảo [Hạn mức Google Analytics Data API] để biết thông tin hạn mức mới nhất. Ví dụ: Các phương thức Core nhận được 1.250 mã thông báo hạn mức trong nhóm Mỗi dự án, mỗi tài sản,mỗi giờ. Giả sử một yêu cầu trung bình từ ứng dụng của bạn tiêu thụ 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 Core mỗi giờ cho một tài sản chuẩn và gấp 10 lần số lượng đó (1.250 yêu cầu Core) cho bất kỳ tài sản Analytics 360 nào. Hạn mức mã thông báo 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 nhóm đầu tiên phụ thuộc vào độ 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 hiện yêu cầu. Những yếu tố sau đây thường làm tăng độ phức tạp của một yêu cầu, do đó 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 phạm vi thời gian cao hơn
  • Bao gồm các 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 tài sản khác nhau có thể dẫn đến mứ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 phương diện có thể khác nhau hoặc lưu lượng truy cập có thể khác nhau. Tuy nhiên, bạn có thể dự kiến những tài sản có mức lưu lượng truy cập và cấu hình tương tự sẽ có mức 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 mức sử dụng mã thông báo của khách hàng trong giai đoạn lập kế hoạch và thiết kế ứng dụng.

Giám sát mức sử dụng hạn mức

Để theo dõi mức sử dụng hạn mức và truyền tải thông tin đó đến 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 số lượng tiêu thụ và trạng thái hạn mức còn lại cho cả 5 nhóm. Sau đây là ví dụ về nội dung yêu cầu và phản hồi:

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 yêu cầu Data API thành công, bạn có thể biết được yêu cầu API đó đã sử dụng bao nhiêu hạn mức và tài sản còn lại bao nhiêu hạn mức. 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 về quản lý hạn mức như được trình bày chi tiết bên dưới để khai thác tối đa Data API. Ngoài ra, nâng cấp tài sản 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ó 2 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ãy ghi nhớ 2 nguyên tắc này, sau đây là những phương pháp bạn có thể triển khai:

  • Bộ nhớ đệm: Việc triển khai một lớp 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 của bạn. Bản thân Google Analytics sẽ lưu vào bộ nhớ đệm các yêu cầu API của bạn, nhưng các yêu cầu lặp lại vẫn sẽ tiêu tốn 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 của bộ nhớ đệm là 4 giờ trở lên. Xem bài viết Độ mới của dữ liệu đối với Google Analytics.
  • Hợp nhất các yêu cầu: Hãy thử 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 dữ liệu trong khung thời gian 2 ngày có thể sử dụng gấp 3 lần số lượng 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 ở một phương diện duy nhất, hãy cân nhắc việ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á các yêu cầu: Giới hạn yêu cầu của bạn ở mức dữ liệu tối thiểu mà ứng dụng và người dùng yêu cầu. Số lượng lớn hàng/cột hoặc tiêu chí lọc phức tạp sẽ tiêu 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ụ: 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 các 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 dateHour thay vì dateHourMinute).
  • Sử dụng hiệu quả limit: Việc thay đổi limit trong yêu cầu API để giảm số lượng hàng được trả về không ảnh hưởng đáng kể đến số lượng mã thông báo hạn mức đã sử dụng. Ví dụ: 5 yêu cầu có giới hạn 10.000 hàng có thể tiêu thụ gấp 5 lần mã thông báo hạn mức so với 1 yêu cầu có giới hạn 50.000 hàng.
  • Sử dụng đúng danh mục phương thức: Như đã đề cập ở trên, hạn mức được phân bổ cho 3 danh mục phương thức. Việc sử dụng đúng phương thức cho đúng trường hợp sử dụng có thể giúp bạn tiết kiệm hạn mức cho 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 cách sử dụ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ạo 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 lựa chọn mặc định do ứng dụng của bạn cung cấp và chỉ thay đổi các lựa 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ẽ dẫn đến việc sử dụng hạn mức nhiều hơn mức cần thiết một cách thường xuyên. Hãy cân nhắc việc giới hạn các dải 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 các 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 chế độ mặc định mà người dùng có thể thay đổi.
  • Xếp hàng yêu cầu và tải chậm: Hãy lưu ý đến hạn mức mã thông báo Số yêu cầu đồng thời trên mỗi tài sản. Ứng dụng của bạn không được 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ó nhiều phần tử trên giao diện người dùng dẫn đến một số lượng đáng kể 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 chậm và xếp hàng các yêu cầu với thuật toán thời gian đợi luỹ thừa để thử lại. Sử dụng phương thức returnPropertyQuota để tích cực giám sát mức sử dụng mã thông báo Số yêu cầu đồng thời trên mỗi tài sản của ứng dụng.

Quản lý trải nghiệm và kỳ vọng của người dùng

  • Đưa ra ý 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ụ: những 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 đưa ra cảnh báo và lời nhắc xác nhận cho những truy vấn như vậy có thể giúp người dùng không thực hiện những 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 cho các truy vấn của mình.
  • Đối với các giải pháp báo cáo tùy chỉnh, hãy cung cấp cho người dùng cách hiểu được mức sử dụng truy vấn của từng phần tử trong báo cáo. Ví dụ: bạn có thể cung cấp một chế độ xem gỡ lỗi liệt kê mức sử dụng mã thông báo hạn mức cho từng phần tử báo cáo.
  • Đưa ra ý kiến phản hồi về loại lỗi hạn mức cụ thể 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 cao hơn 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.

Data API cho Google Analytics 4 không có hạn mức API cao hơn hạn mức mặc định. Google Analytics 360 cung cấp hạn mức cao hơn cho các tài sản Google Analytics 4. Nếu người dùng vẫn vượt quá 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 nâng cấp tài sản của mình lên phiên bản 360. Một lựa chọn khác cho người dùng là sử dụng tính năng BigQuery Export của Google Analytics. Nhờ đó, người dùng có thể xuất dữ liệu ở cấp sự kiện sang BigQuery và chạy quy trình phân tích của riêng họ.

Nếu bạn có thêm câu hỏi về hạn mức Data API, hãy truy cập vào GA Discord hoặc đặt câu 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, bạn có thể đăng yêu cầu đó trên công cụ theo dõi vấn đề của chúng tôi.