Hạn mức và hạn mức Data API

Các hạn mức và giới hạn sau đây áp dụng cho Data API.

Cách áp dụng hạn mức

Tất cả các yêu cầu gửi đến Google Analytics Data API phiên bản 1 đều yêu cầu một dự án trên Google Cloud và phải tuân theo hạn mức được nêu trên trang này. Hạn mức sẽ được sử dụng bất kể phương thức nào được dùng để xác định dự án gọi, bao gồm:

  • Yêu cầu được xác thực bằng thông tin đăng nhập OAuth 2.0.
  • Các yêu cầu chỉ được xác thực bằng khoá API.

Khoá API được dùng để liên kết một yêu cầu với một dự án trên đám mây cụ thể trên Google Cloud cho mục đích hạn mức và thanh toán. Tất cả lệnh gọi API được thực hiện bằng thông tin xác thực hoặc khoá API từ dự án của bạn sẽ được tính vào hạn mức áp dụng cho dự án và tài sản Google Analytics.

Danh mục hạn mức

Data API có 4 danh mục hạn mức yêu cầu: Cốt lõi, Theo thời gian thực, Phễu và Trò chuyện.

Các yêu cầu API đối với phương thức Core sẽ tính hạn mức Core. Các yêu cầu API đến phương thức Realtime sẽ tính vào hạn mức Realtime. Các yêu cầu API đến phương thức Phễu sẽ tính phí hạn mức Phễu. Các yêu cầu API đối với các phương thức Chat sẽ tính hạn mức Chat. Mỗi yêu cầu chỉ sử dụng một loại hạn mức.

Danh mục hạn mức Phương thức API
Core runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports
Theo thời gian thực runRealtimeReport
Phễu runFunnelReport
Trò chuyện properties.chat

Hạn mức tài sản Analytics

Tất cả yêu cầu đều sử dụng hạn mức của tài sản.

Tên hạn mức Giới hạn đối với tài sản chuẩn Giới hạn đối với tài sản Analytics 360
Số mã thông báo cốt lõi cho mỗi tài sản mỗi ngày 200.000 2.000.000
Số lượng mã thông báo cốt lõi cho mỗi tài sản mỗi giờ 40.000 400.000
Số lượng mã thông báo cốt lõi cho mỗi dự án, mỗi tài sản, mỗi giờ 14.000 140.000
Số yêu cầu đồng thời cốt lõi cho mỗi tài sản 10 50
Lỗi máy chủ chính cho mỗi dự án, mỗi tài sản, mỗi giờ 10 50
Số mã thông báo theo thời gian thực cho mỗi tài sản mỗi ngày 200.000 2.000.000
Số mã thông báo theo thời gian thực cho mỗi tài sản mỗi giờ 40.000 400.000
Số mã thông báo theo thời gian thực cho mỗi dự án, mỗi tài sản, mỗi giờ 14.000 140.000
Số yêu cầu đồng thời theo thời gian thực cho mỗi tài sản 10 50
Lỗi máy chủ theo thời gian thực cho mỗi dự án, mỗi tài sản, mỗi giờ 10 50
Mã thông báo phễu cho mỗi tài sản mỗi ngày 200.000 2.000.000
Số mã thông báo phễu trên mỗi tài sản mỗi giờ 40.000 400.000
Số mã thông báo phễu trên mỗi dự án, mỗi tài sản, mỗi giờ 14.000 140.000
Số yêu cầu đồng thời trên phễu cho mỗi tài sản 10 50
Lỗi máy chủ phễu trên mỗi dự án, mỗi tài sản, mỗi giờ 10 50
Số mã thông báo trò chuyện cho mỗi tài sản mỗi ngày 3.750.000 3.750.000
Số lượng mã thông báo trò chuyện cho mỗi tài sản mỗi giờ 500.000 500.000
  • Yêu cầu đồng thời được đo lường bằng số lượng yêu cầu được thực thi đồng thời. Để giảm số lượng yêu cầu đồng thời, hãy đợi các yêu cầu trước đó hoàn tất rồi mới gửi thêm yêu cầu.
  • Lỗi máy chủ là mã 500 và 503. Hạn mức Lỗi máy chủ chỉ bị tính phí khi một yêu cầu dẫn đến lỗi máy chủ. Khi hạn mức Lỗi máy chủ của một cặp dự án và tài sản đã hết, tất cả yêu cầu từ dự án đến tài sản đó sẽ bị chặn. Để xem danh sách đầy đủ các phản hồi lỗi, hãy xem phần Phản hồi lỗi.
  • Mỗi yêu cầu sẽ sử dụng hạn mức cho cả Mã thông báo cho mỗi tài sản mỗi giờ và Mã thông báo cho mỗi dự án cho mỗi tài sản mỗi giờ. Điều này có nghĩa là một tài sản phải được truy cập bởi hơn 3 dự án trước khi hạn mức "Mã thông báo trên mỗi tài sản mỗi giờ" có thể bị hết trước hạn mức "Mã thông báo trên mỗi dự án trên mỗi tài sản mỗi giờ".

Mỗi tài sản được phép gửi 120 yêu cầu có thể đạt đến ngưỡng mỗi giờ. Các phương diện userAgeBracket, userGender, brandingInterest, audienceId và audienceName có thể bị áp dụng ngưỡng. Các ngưỡng được áp dụng để ngăn bất kỳ ai xem báo cáo suy luận ra thông tin nhân khẩu học hoặc mối quan tâm của người dùng cá nhân.

Hạn mức mã thông báo tài sản

Mã thông báo được sử dụng cho mỗi yêu cầu gửi đến Google Analytics Data API phiên bản 1. Số lượng token bị tính phí phụ thuộc vào độ phức tạp của yêu cầu. Mặc dù hầu hết các yêu cầu sẽ tính phí 10 mã thông báo trở xuống, nhưng các yêu cầu phức tạp hơn (chẳng hạn như truy vấn Ask Advisor chat) sẽ tiêu tốn nhiều mã thông báo hơn.

Các yếu tố ảnh hưởng đến mức tiêu thụ mã thông báo

Chi phí mã thông báo chính xác cho một yêu cầu được xác định tại thời điểm thực thi, khiến việc tính toán trước chính xác trở nên khó khăn. Chi phí này chịu ảnh hưởng của nhiều yếu tố liên quan đến chính yêu cầu đó và dữ liệu cơ bản trong tài sản Google Analytics. Các yếu tố sau đây có thể làm tăng chi phí:

  • Số hàng: Yêu cầu số hàng lớn hơn.
  • Số lượng phương diện và chỉ số: Bao gồm nhiều phương diện và chỉ số hơn.
  • Độ phức tạp của bộ lọc: Sử dụng các biểu thức bộ lọc phức tạp.
  • Độ dài phạm vi ngày: Truy vấn trong khoảng thời gian dài hơn.
  • Số lượng giá trị riêng biệt của dữ liệu: Những phương diện có số lượng giá trị riêng biệt cao (nhiều giá trị riêng biệt, chẳng hạn như pagePath, phương diện tuỳ chỉnh) có thể làm tăng đáng kể chi phí mã thông báo.
  • Số lượng sự kiện của tài sản: Các truy vấn trên những tài sản có số lượng sự kiện cao hơn có thể sử dụng nhiều mã thông báo hơn so với cùng một truy vấn trên một tài sản có ít dữ liệu hơn.

Giám sát mức sử dụng mã thông báo

Cách hiệu quả nhất để xác định chi phí mã thông báo cho các lệnh gọi API cụ thể là thêm tham số "returnPropertyQuota": true vào nội dung yêu cầu (được hỗ trợ trong runReport, batchRunReports, runPivotReport, batchRunPivotReports, runRealtimeReport và runFunnelReport). Sau đó, phản hồi của API sẽ bao gồm đối tượng PropertyQuota, trong đó nêu chi tiết số lượng mã thông báo mà yêu cầu cụ thể đó đã sử dụng và số dư hạn mức còn lại.

Ví dụ về yêu cầu có returnPropertyQuota
POST https://analyticsdata.googleapis.com/v1beta/properties/GA_PROPERTY_ID:runReport
{
  "dateRanges": [
    { "startDate": "7daysAgo", "endDate": "yesterday" }
  ],
  "dimensions": [
    { "name": "country" }
  ],
  "metrics": [
    { "name": "activeUsers" }
  ],
  "returnPropertyQuota": true
}
Ví dụ về tải trọng phản hồi propertyQuota

Khi bạn đặt "returnPropertyQuota": true, phản hồi sẽ bao gồm một đối tượng propertyQuota, trong đó mỗi trường chứa một QuotaStatus có các số nguyên consumed và remaining:

{
  "dimensionHeaders": [
    { "name": "country" }
  ],
  "metricHeaders": [
    { "name": "activeUsers", "type": "TYPE_INTEGER" }
  ],
  "rows": [
    {
      "dimensionValues": [{ "value": "United States" }],
      "metricValues": [{ "value": "4820" }]
    }
  ],
  "propertyQuota": {
    "tokensPerDay": {
      "consumed": 1,
      "remaining": 199999
    },
    "tokensPerHour": {
      "consumed": 1,
      "remaining": 39999
    },
    "concurrentRequests": {
      "consumed": 0,
      "remaining": 10
    },
    "serverErrorsPerProjectPerHour": {
      "consumed": 0,
      "remaining": 10
    },
    "potentiallyThresholdedRequestsPerHour": {
      "consumed": 0,
      "remaining": 120
    },
    "tokensPerProjectPerHour": {
      "consumed": 1,
      "remaining": 13999
    }
  }
}

Mỗi trường trong propertyQuota tương ứng với một hạn mức trong Hạn mức tài sản Analytics. Phí mã thông báo của một yêu cầu API được khấu trừ đồng thời từ tokensPerDay, tokensPerHour và tokensPerProjectPerHour. Nếu bất kỳ bộ chứa hạn mức nào còn lại 0, thì các yêu cầu tiếp theo đối với tài sản đó sẽ trả về lỗi 429 RESOURCE_EXHAUSTED.

Các phương pháp hay nhất để tránh lỗi 429 RESOURCE_EXHAUSTED
  • Theo dõi remaining số dư một cách linh động: Kiểm tra propertyQuota.tokensPerProjectPerHour.remaining và propertyQuota.tokensPerHour.remaining trong các phản hồi, đồng thời điều chỉnh hoặc tạm dừng các tác vụ không khẩn cấp ở chế độ nền khi số lượng mã thông báo còn lại giảm xuống dưới ngưỡng an toàn.
  • Phân lô các truy vấn liên quan: Sử dụng batchRunReports hoặc batchRunPivotReports để nhóm tối đa 5 báo cáo trong một lệnh gọi HTTP và giảm chi phí chung của chuyến khứ hồi HTTP (xin lưu ý rằng mỗi báo cáo trong một lô vẫn được tính riêng vào hạn mức mã thông báo và concurrentRequests).
  • Giảm độ phức tạp và số lượng giá trị riêng biệt của truy vấn: Giới hạn yêu cầu chỉ ở những phương diện và chỉ số bạn cần, rút ngắn dateRanges nếu có thể và tránh kết hợp nhiều phương diện có số lượng giá trị riêng biệt cao (chẳng hạn như pagePath hoặc fullPageUrl) trong các truy vấn thăm dò thường xuyên.
  • Kiểm soát số lượng yêu cầu đồng thời: Xếp hàng yêu cầu hoặc giới hạn kích thước nhóm worker để các yêu cầu đang thực hiện nằm dưới giới hạn concurrentRequests (10 cho phiên bản Chuẩn, 50 cho phiên bản Analytics 360).
  • Triển khai thuật toán thời gian đợi luỹ thừa có giới hạn số lần thử lại: Nếu một yêu cầu không thành công với 429 RESOURCE_EXHAUSTED, 500 INTERNAL hoặc 503 UNAVAILABLE, hãy thử lại bằng cách sử dụng thuật toán thời gian đợi luỹ thừa bị cắt như mô tả trong phần Phản hồi lỗi.

Theo dõi và sử dụng mã thông báo trò chuyện

Đối với các yêu cầu của Ask Advisor chat, mã thông báo thể hiện chi phí tính toán, lập luận và truy xuất dữ liệu cơ bản của mô hình. Lượng token tiêu thụ trong cuộc trò chuyện chịu ảnh hưởng của:

  • Phạm vi truy vấn và phân tích: Độ phức tạp và phạm vi của yêu cầu phân tích.
  • Số lượng mã thông báo đầu vào và đầu ra của mô hình: Số lượng dữ liệu theo ngữ cảnh được xử lý và nội dung phản hồi được tạo.
  • Token tư duy:Các bước suy luận của mô hình cần thiết để tổng hợp kết quả.
  • Độ trễ thực thi: Thời gian xử lý cần thiết cho các hoạt động khám phá dữ liệu nhiều bước.

Để theo dõi mức sử dụng mã thông báo trò chuyện, hãy đặt "returnPropertyQuota": true trong ChatRequest. Phản hồi sẽ bao gồm đối tượng PropertyChatQuota chứa các trường tokensPerDay và tokensPerHour với số dư đã sử dụng và số dư còn lại.