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

Minhaz Kazi, Chuyên gia hỗ trợ nhà phát triển chuyên trách về Google Analytics – Tháng 2 năm 2023

Nếu đang phát triển ứng dụng bằng Google Analytics Data API, bạn phải hiểu cách hoạt động của các hạn mức và giới hạn đối với API. Nếu được thiết kế tốt, người dùng ít có khả năng đạt đến giới hạn hạn mức. Một số các phương pháp hay nhất có liên quan cũng dẫn đến các truy vấn có hiệu suất cao đến API. Điều này có thể 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. Bài viết này thảo luận về hệ thống hạn mức và để 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 cho API bảo vệ hệ thống khỏi việc xử lý nhiều dữ liệu hơn mức nó có thể xử lý trong khi đảm bảo phân bổ công bằng các tài nguyên hệ thống. API Dữ liệu cho Google Tài sản Analytics 4 sử dụng hệ thống bộ chứa mã thông báo để quản lý hạn mức API. Người nhận hiểu khái niệm: hãy tưởng tượng có một chiếc thùng có thể chứa tối đa số lượng mã thông báo. Trước tiên, mọi yêu cầu API sẽ được kiểm tra bộ chứa. Nếu không có mã thông báo còn lại, thì 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. Mã thông báo được bổ sung vào bộ chứa đến mức tối đa tại thời điểm cố định khoảng thời gian.

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

• Thời gian thực (cho runRealtimeReport)
• Phễu (cho runFunnelReport)
• Lõi (đối với tất cả các phương thức 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:

1. Trên mỗi tài sản mỗi ngày
2. Trên mỗi thuộc tính mỗi giờ
3. Mỗi dự án một thuộc tính mỗi giờ
4. Số yêu cầu đồng thời trên mỗi tài sản
5. Số lỗi máy chủ trên mỗi dự án mỗi thuộc tính mỗi giờ

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

Hạn mức Trên mỗi dự án mỗi tài sản mỗi giờ đảm bảo việc hết 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 của ứng dụng. Ở đây, dự án tham chiếu đến dự án GCP trong ứng dụng của bạn. Hạn mức Trên mỗi tài sản mỗi giờ là thường gấp bốn lần hạn mức Mỗi dự án mỗi tài sản mỗi giờ. Cuối cùng người dùng, mỗi tài sản phải được truy cập bởi ít nhất 4 dự án khác nhau trước khi có thể bị hết hạn mức Trên mỗi tài sản mỗi giờ. Thực thi hạn mức ở cả hai ở cấp dự án và cấp tài sản giúp đảm bảo rằng các vấn đề về hạn mức sẽ được giới hạn ở mộ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.

Cảnh báo: Nhà phát triển không nên phân đoạn mã thông báo hạn mức trên nhiều dự án API. Đây là hành vi vi phạm Điều khoản dịch vụ về các API của Google.

Hạn mức Lỗi máy chủ cho biết các phản hồi của API có 500 hoặc Mã 503. Nếu ứng dụng của bạn tạo quá nhiều lỗi trong khi khi truy cập vào một tài sản, việc này sẽ gây ra lỗi Lỗi máy chủ trên mỗi dự án trong mỗi tài sản mỗi giờ.

Tất cả mã thông báo hạn mức sẽ được bổ sung vào giới hạn theo định kỳ. Tham khảo Hạn mức Google Analytics Data API để biết thông tin mới nhất về hạn mức. Ví dụ: Các phương thức Chính nhận 1.250 mã thông báo hạn mức trong phần Trên mỗi dự án mỗi tài sản mỗi giờ bộ chứa. Giả sử một yêu cầu trung bình từ ứng dụng của bạn sử dụng 10 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ố tiền đó (1250 yêu cầu Chính) cho mọi Analytics tài sản 360. Giới hạn mã thông báo hạn mức cao hơn là một trong những các lợi ích của tài sản Analytics 360.

Vì việc sử dụng 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, khó dự đoán chính xác mức sử dụng mã thông báo trước khi yêu cầu thực thi. Các yếu tố sau thường làm tăng độ phức tạp của 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 trong phạm vi 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 kết quả sử dụng mã thông báo hoàn toàn khác nhau bởi vì lượng số của các phương diện có thể hoặc lưu lượng truy cập có thể khác nhau. Tuy nhiên, có thể có mức lưu lượng truy cập tương tự và có cấu hình tương tự để 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 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.

Lưu ý: Nếu trước đây đã sử dụng API Báo cáo cho Universal Analytics, bạn sẽ nhận thấy rằng hạn mức được thực thi của API Báo cáo tại dự án Ứng dụng/API cấp độ. Nhưng đối với Data API, biện pháp thực thi diễn ra tại tài sản Google Analytics cũng như ở cấp dự án API.

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

Để theo dõi hạn mức sử dụng 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ề PropertyQuota cùng với phản hồi của API. Đối tượng PropertyQuota sẽ chứa số tiền tiêu thụ và trạng thái hạn mức còn lại cho cả năm . Dưới đây là ví dụ về nội dung và phản hồi của 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 yêu cầu Data API thành công, bạn có thể biết số tiền hạn mức yêu cầu đã tiêu thụ và hạn mức còn lại cho tài sản. Đó là cũng có thể hiển thị thông tin này cho người dùng thông qua ứng dụng của bạn .

Lưu ý: Trong giai đoạn hiện tại của Data API, bạn cần thực thi thành công một Yêu cầu API để lấy lại đối tượng PropertyQuota. Nếu cơ sở lưu trú đã hết bộ chứa mã thông báo hạn mức, yêu cầu của bạn sẽ không thành công với lỗi 429 và phản hồi sẽ không chứa đối tượng PropertyQuota. Nếu bạn bị ảnh hưởng bởi điều này và cho rằng ứng dụng của bạn sẽ được hưởng lợi từ việc có một cách riêng để truy cập thông tin hạn mức, +1 yêu cầu tính năng này trên công cụ theo dõi lỗi.

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 để khai thác tối đa Data API. Ngoài ra việc nâng cấp tài sản lên phiên bản 360 có thể làm tăng số lượng truy cập được qua API.

Các phương pháp hay nhất

Thông thường, 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 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ẽ có lợi cho cả khả năng hữu dụng lẫn quản lý hạn mức cho ứng dụng của bạn. Google Analytics sẽ tự 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 sẽ vẫn phải chịu mã thông báo hạn mức. Theo lưu phản hồi API vào bộ nhớ đệm, bạn có thể giảm đáng kể số lần yêu cầu. Ví dụ: dữ liệu trong ngày cho các tài sản chuẩn có thể có 4 giờ hoặc thời gian hết hạn bộ nhớ đệm cao hơn. Xem phần Độ mới của dữ liệu cho Google Số liệu phân tích.
• Yêu cầu hợp nhất: 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 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 theo một phương diện, hãy cân nhắc hợp nhất chúng thành một yêu cầu duy nhất.
• Đơn giản hoá yêu cầu: Giới hạn lượng dữ liệu tối thiểu cho yêu cầu của bạn yêu cầu của ứng dụng và người dùng. Có quá nhiều hàng/cột hoặc tiêu chí 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ụ: thay đổi phạm vi ngày từ 28 ngày thành 365 ngày ngày có thể sử dụng 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 dateHour thay vì dateHourMinute).
• Cách sử dụng hiệu quả limit: Thay đổi limit trong API yêu cầu giảm số hàng được trả về không ảnh hưởng đáng kể đến đã tiêu thụ mã thông báo hạn mức. Ví dụ: Bạn có thể tạo 5 yêu cầu có giới hạn là 10.000 hàng tiêu thụ 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 là 50 nghìn.
• Sử dụng đúng danh mục phương pháp: Như đã đề cập ở trên, hạn mức trong 3 loại phương pháp. Sử dụng đúng phương pháp trường hợp sử dụng có thể 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 pháp Core, hãy dùng phương thức runFunnelReport để tạo phễu.
• Cập nhật chế độ cài đặt mặc định: Khi soạn thảo hoặc tuỳ chỉnh báo cáo trên nền tảng, người dùng có thể không cập nhật các tuỳ chọn mặc định do và chỉ thay đổi chúng 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. điều này sẽ tiêu tốn nhiều hạn mức hơn mức cần thiết một cách thường xuyên. Cân nhắc việc giới hạn 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 các giá trị mặc định mà người dùng có thể thay đổi.
• Xếp hạng các yêu cầu và tải từng phần: Hãy chú ý đến vấn đề đồng thời Giới hạn mã thông báo số yêu cầu trên mỗi tài sản. Ứng dụng của bạn không nên gửi đi quá nhiều yêu cầu cùng một lúc. Nếu ứng dụng của bạn có số lượng lớn về các 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 phân trang giao diện người dùng, tải từng phần và xếp hàng yêu cầu bằng hàm mũ thời gian đợi để thử lại. Sử dụng phương thức returnPropertyQuota để tích cực giám sát việc sử dụng mã thông báo Yêu cầu đồng thời trên mỗi thuộc tính của ứng dụng.

Quản lý trải nghiệm người dùng và kỳ vọ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 mã thông báo cao. Ví dụ: truy vấn có nhiều phương diện có số lượng giá trị riêng biệt cao hoặc có có thể dùng một 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 các truy vấn đó có thể ngăn người dù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 truy vấn.
• Đối với các giải pháp báo cáo tuỳ chỉnh, hãy cung cấp cách để người dùng nắm được 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ê việ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 người dùng hành động.
• Vì tài sản Google Analytics 360 được nhân 5 – 10 lần hạn mức so với hạn mức so với tài sản chuẩn, bạn có thể linh hoạt hơn nhờ Google Analytics 360 thuộc tính.

Data API không thể áp dụng cho việc tăng hạn mức API vượt quá giới hạn mặc định Google Analytics 4. Google Analytics 360 cung cấp hạn mức cao hơn cho Tài sản Google Analytics 4. Nếu người dùng của bạn sắp đạt đến giới hạn hạn mức sau khi triển khai các phương pháp hay nhất, họ nên cân nhắc nâng cấp tài sản lê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. Nhờ đó, người dùng có thể xuất dữ liệu ở cấp sự kiện với BigQuery và tiến hành phân tích của riêng mình.

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 đặt câu hỏi trên Stack Overflow. Nếu bạn có yêu cầu cụ thể về tính năng liên quan đến Dữ liệu API, bạn có thể đăng chúng lên công cụ theo dõi lỗi của chúng tôi.