Dùng thử máy chủ MCP cho Google Analytics. Cài đặt từ GitHub và xem thông báo để biết thêm thông tin chi tiết.

Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

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

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

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

Tất cả yêu cầu gửi đến Google Analytics Data API phiên bản 1 đều cần có 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.
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ủa Google Cloud cụ thể 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 hiện hành của 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 đến phương thức Core sẽ tính vào hạn mức Core. Các yêu cầu API đến phương thức Realtime sẽ tính phí theo hạn mức Realtime. Các yêu cầu API đến phương thức Phễu sẽ tính vào hạn mức Phễu. Các yêu cầu API đến các phương thức của Chat sẽ tính vào hạn mức của 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ố mã thông báo chính cho mỗi tài sản mỗi giờ	40.000	400.000
Số mã thông báo chính 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 chính cho mỗi tài sản	10	50
Lỗi phía máy chủ chính trên 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 trên mỗi tài sản	10	50
Lỗi phía máy chủ theo thời gian thực trên mỗi dự án, mỗi tài sản, mỗi giờ	10	50
Số mã thông báo phễu cho mỗi tài sản mỗi ngày	200.000	2.000.000
Mã thông báo phễu trên mỗi tài sản mỗi giờ	40.000	400.000
Mã thông báo phễu 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 trên phễu cho mỗi tài sản	10	50
Lỗi phía 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
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 phía máy chủ chỉ bị tính phí khi một yêu cầu dẫn đến lỗi phía 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 đều sử dụng hạn mức cho cả Số mã thông báo mỗi tài sản mỗi giờ và Số mã thông báo mỗi dự án 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 chat của Ask Advisor) 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í chịu ảnh hưởng của một tổ hợp các 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 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: Các 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ố 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 của 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 số dư remaining 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 tiết hoặc tạm dừng các công việc không khẩn cấp trong 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.
Truy vấn liên quan đến lô: 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 mức hao tổn khứ hồi HTTP (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: Chỉ giới hạn các yêu cầu đối với 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: Đưa các yêu cầu vào hàng đợi hoặc giới hạn kích thước nhóm worker để số lượng yêu cầu đang xử lý luôn thấp hơn giới hạn concurrentRequests (10 đối với phiên bản Standard, 50 đối với 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à trả về lỗi 429 RESOURCE_EXHAUSTED, 500 INTERNAL hoặc 503 UNAVAILABLE, hãy thử lại bằng thuật toán thời gian đợi luỹ thừa bị cắt bớt như mô tả trong phần Phản hồi lỗi.

Giám sát và sử dụng mã thông báo trò chuyện

Đối với các yêu cầu của tính năng Ask Advisor chat, token thể hiện chi phí tính toán, suy luận và truy xuất dữ liệu cơ bản của mô hình. Mức tiêu thụ token của Gemini Chat 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.
Mã thông báo đầu vào và đầu ra của mô hình: Khối lượng dữ liệu theo bối 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ả tìm được.
Độ trễ thực thi: Thời gian xử lý cần thiết cho việc 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.