ขีดจํากัดและโควต้าของ Data API

ขีดจำกัดและโควต้าต่อไปนี้มีผลกับ Data API

วิธีใช้โควต้า

คำขอทั้งหมดที่ส่งไปยัง Google Analytics Data API v1 ต้องใช้โปรเจ็กต์ Google Cloud และขึ้นอยู่กับโควต้าที่ระบุไว้ในหน้านี้ ระบบจะใช้โควต้าไม่ว่าจะใช้วิธีใดในการระบุโปรเจ็กต์ที่เรียกใช้ ซึ่งรวมถึงวิธีต่อไปนี้

  • คำขอที่ตรวจสอบสิทธิ์ด้วยข้อมูลเข้าสู่ระบบ OAuth 2.0
  • คำขอที่ตรวจสอบสิทธิ์โดยใช้คีย์ API เท่านั้น

ระบบจะใช้คีย์ API เพื่อเชื่อมโยงคำขอกับโปรเจ็กต์ที่อยู่ในระบบคลาวด์ Google Cloud ที่เฉพาะเจาะจงเพื่อวัตถุประสงค์ด้านโควต้าและการเรียกเก็บเงิน การเรียก API ทั้งหมดที่ทำโดยใช้ข้อมูลเข้าสู่ระบบหรือคีย์ API จากโปรเจ็กต์จะนับรวมในโควต้าที่เกี่ยวข้องของโปรเจ็กต์และพร็อพเพอร์ตี้ Google Analytics

หมวดหมู่โควต้า

Data API มีหมวดหมู่โควต้าคำขอ 4 หมวดหมู่ ได้แก่ Core, Realtime, Funnel และ Chat

คำขอ API ไปยังเมธอด Core จะเรียกเก็บโควต้า Core คำขอ API ไปยังเมธอด Realtime จะใช้โควต้า Realtime คำขอ API ไปยังเมธอด Funnel จะใช้โควต้า Funnel คำขอ API ไปยังเมธอด Chat จะเรียกเก็บโควต้า Chat คำขอแต่ละรายการจะใช้โควต้าเพียงประเภทเดียวเท่านั้น

หมวดหมู่โควต้า เมธอดของ API
หลัก runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports
เรียลไทม์ runRealtimeReport
Funnel runFunnelReport
แชท properties.chat

โควต้าพร็อพเพอร์ตี้ Analytics

คำขอทั้งหมดจะใช้โควต้าพร็อพเพอร์ตี้

ชื่อโควต้า ขีดจํากัดของพร็อพเพอร์ตี้มาตรฐาน ขีดจํากัดของพร็อพเพอร์ตี้ Analytics 360
โทเค็นหลักต่อพร็อพเพอร์ตี้ต่อวัน 200,000 2,000,000
โทเค็นหลักต่อพร็อพเพอร์ตี้ต่อชั่วโมง 40,000 400,000
โทเค็นหลักต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 14,000 140,000
คำขอหลายรายการพร้อมกันหลักต่อพร็อพเพอร์ตี้ 10 50
ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์หลักต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 10 50
โทเค็นแบบเรียลไทม์ต่อพร็อพเพอร์ตี้ต่อวัน 200,000 2,000,000
โทเค็นแบบเรียลไทม์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 40,000 400,000
โทเค็นแบบเรียลไทม์ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 14,000 140,000
คำขอหลายรายการพร้อมกันแบบเรียลไทม์ต่อพร็อพเพอร์ตี้ 10 50
ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์แบบเรียลไทม์ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 10 50
โทเค็น Funnel ต่อพร็อพเพอร์ตี้ต่อวัน 200,000 2,000,000
โทเค็น Funnel ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 40,000 400,000
โทเค็น Funnel ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 14,000 140,000
คำขอ Funnel หลายรายการพร้อมกันต่อพร็อพเพอร์ตี้ 10 50
ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ Funnel ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง 10 50
โทเค็นแชทต่อพร็อพเพอร์ตี้ต่อวัน 3,750,000 3,750,000
โทเค็นแชทต่อพร็อพเพอร์ตี้ต่อชั่วโมง 500,000 500,000
  • ระบบจะวัดคำขอหลายรายการพร้อมกันตามจำนวนคำขอที่ดำเนินการพร้อมกัน หากต้องการลดการเกิดขึ้นพร้อมกันของคำขอ ให้รอให้คำขอก่อนหน้าเสร็จสมบูรณ์ก่อนที่จะส่งคำขอเพิ่มเติม
  • ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์คือรหัส 500 และ 503 ระบบจะเรียกเก็บเงินโควต้าข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์เมื่อคำขอส่งผลให้เกิดข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์เท่านั้น เมื่อโควต้าข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์สำหรับคู่โปรเจ็กต์และพร็อพเพอร์ตี้หมดลง ระบบจะบล็อกคำขอทั้งหมดที่ส่งไปยังพร็อพเพอร์ตี้จากโปรเจ็กต์ ดูรายการการตอบกลับข้อผิดพลาดทั้งหมดได้ที่การตอบกลับข้อผิดพลาด
  • คำขอแต่ละรายการจะใช้โควต้าทั้งโทเค็นต่อพร็อพเพอร์ตี้ต่อชั่วโมงและโทเค็นต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง ซึ่งหมายความว่าต้องมีโปรเจ็กต์มากกว่า 3 โปรเจ็กต์ที่เข้าถึงพร็อพเพอร์ตี้ 1 รายการก่อนที่โควต้า "โทเค็นต่อพร็อพเพอร์ตี้ต่อชั่วโมง" จะหมดลงก่อนโควต้า "โทเค็นต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง"

พร็อพเพอร์ตี้ได้รับอนุญาตให้ส่งคําขอที่อาจถึงเกณฑ์ได้ 120 รายการต่อชั่วโมง มิติข้อมูล userAgeBracket, userGender, brandingInterest, audienceId และ audienceName อาจมีการกำหนดเกณฑ์ขั้นต่ำ เราได้นําเกณฑ์มาใช้เพื่อป้องกันไม่ให้ผู้ที่ดูรายงานคาดการณ์ถึงข้อมูลประชากรหรือความสนใจของผู้ใช้แต่ละรายได้

โควต้าโทเค็นของพร็อพเพอร์ตี้

ระบบจะใช้โทเค็นกับคําขอแต่ละรายการที่ส่งไปยัง Google Analytics Data API v1 จำนวนโทเค็นที่เรียกเก็บจะขึ้นอยู่กับความซับซ้อนของคำขอ แม้ว่าคำขอส่วนใหญ่จะเรียกเก็บโทเค็น 10 รายการหรือน้อยกว่า แต่คำขอที่ซับซ้อนกว่า (เช่น คำถาม Ask Advisor chat) จะใช้โทเค็นมากกว่า

ปัจจัยที่มีผลต่อการใช้โทเค็น

ค่าใช้จ่ายโทเค็นที่แน่นอนสำหรับคำขอจะกำหนด ณ เวลาที่ดำเนินการ ทำให้การคำนวณล่วงหน้าอย่างแม่นยำเป็นเรื่องที่ท้าทาย ค่าใช้จ่ายจะขึ้นอยู่กับปัจจัยหลายอย่างรวมกันที่เกี่ยวข้องกับคําขอและข้อมูลที่เกี่ยวข้องในพร็อพเพอร์ตี้ Google Analytics ปัจจัยเหล่านี้อาจส่งผลให้ต้นทุนสูงขึ้น

  • จำนวนแถว: ขอแถวจำนวนมากขึ้น
  • จำนวนมิติข้อมูลและเมตริก: การรวมมิติข้อมูลและเมตริกจำนวนมากขึ้น
  • ความซับซ้อนของตัวกรอง: การใช้นิพจน์ตัวกรองที่ซับซ้อน
  • ความยาวของช่วงวันที่: การค้นหาในช่วงวันที่ที่ยาวนานขึ้น
  • จำนวนสมาชิกในเซ็ตของข้อมูล: มิติข้อมูลที่มีจำนวนสมาชิกในเซ็ตสูง (ค่าที่ไม่ซ้ำกันจำนวนมาก เช่น pagePath, มิติข้อมูลที่กำหนดเอง) อาจเพิ่มต้นทุนโทเค็นอย่างมาก
  • ปริมาณเหตุการณ์ของพร็อพเพอร์ตี้: การค้นหาในพร็อพเพอร์ตี้ที่มีปริมาณเหตุการณ์สูงกว่าอาจใช้โทเค็นมากกว่าการค้นหาเดียวกันในพร็อพเพอร์ตี้ที่มีข้อมูลน้อยกว่า

การตรวจสอบการใช้งานโทเค็น

วิธีที่มีประสิทธิภาพที่สุดในการกำหนดต้นทุนโทเค็นสำหรับการเรียก API ที่เฉพาะเจาะจงคือการรวมพารามิเตอร์ "returnPropertyQuota": true ไว้ในเนื้อหาคำขอ (รองรับใน runReport, batchRunReports, runPivotReport, batchRunPivotReports, runRealtimeReport และ runFunnelReport) จากนั้นการตอบกลับจาก API จะรวมออบเจ็กต์ PropertyQuota ซึ่งจะแสดงรายละเอียดโทเค็นที่คำขอที่เฉพาะเจาะจงนั้นใช้และยอดคงเหลือของโควต้าที่เหลืออยู่

ตัวอย่างคำขอที่มี 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
}
ตัวอย่างเพย์โหลดการตอบกลับ propertyQuota

เมื่อตั้งค่า "returnPropertyQuota": true การตอบกลับจะมีออบเจ็กต์ propertyQuota ซึ่งแต่ละฟิลด์จะมี QuotaStatus ที่มีจำนวนเต็ม consumed และ 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
    }
  }
}

แต่ละช่องใน propertyQuota จะสอดคล้องกับโควต้าในโควต้าพร็อพเพอร์ตี้ Analytics ระบบจะหักการเรียกเก็บเงินโทเค็นของคำขอ API รายการเดียวพร้อมกันจาก tokensPerDay, tokensPerHour และ tokensPerProjectPerHour หากที่เก็บโควต้าใดเหลือ 0 คำขอที่ส่งไปยังพร็อพเพอร์ตี้นั้นในภายหลังจะแสดงข้อผิดพลาด 429 RESOURCE_EXHAUSTED

แนวทางปฏิบัติแนะนำเพื่อหลีกเลี่ยงข้อผิดพลาด 429 RESOURCE_EXHAUSTED
  • ตรวจสอบยอดคงเหลือของ remaining แบบไดนามิก: ตรวจสอบ propertyQuota.tokensPerProjectPerHour.remaining และ propertyQuota.tokensPerHour.remaining ในการตอบกลับ และจำกัดหรือหยุดงานเบื้องหลังที่ไม่เร่งด่วนชั่วคราวเมื่อโทเค็นที่เหลือต่ำกว่าเกณฑ์ความปลอดภัย
  • คำค้นหาที่เกี่ยวข้องแบบกลุ่ม: ใช้ batchRunReports หรือ batchRunPivotReports เพื่อจัดกลุ่มรายงานสูงสุด 5 รายการในการเรียก HTTP ครั้งเดียว และลดค่าใช้จ่ายเพิ่มเติมในการส่งไปกลับของ HTTP (โปรดทราบว่ารายงานแต่ละรายการในกลุ่มยังคงนับแยกกันตามโควต้าโทเค็นและ concurrentRequests)
  • ลดความซับซ้อนและจำนวนสมาชิกในเซ็ตของคำค้นหา: จำกัดคำขอให้มีเฉพาะมิติข้อมูลและเมตริกที่คุณต้องการ ย่อ dateRanges หากเป็นไปได้ และหลีกเลี่ยงการรวมมิติข้อมูล High Cardinality หลายรายการ (เช่น pagePath หรือ fullPageUrl) ในคำค้นหาแบบสำรวจความคิดเห็นที่ทำบ่อยๆ
  • ควบคุมการเกิดขึ้นพร้อมกันของคำขอ: จัดคิวคำขอหรือจำกัดขนาดพูลผู้ปฏิบัติงานเพื่อให้คำขอที่อยู่ระหว่างดำเนินการต่ำกว่าขีดจำกัด concurrentRequests (10 สำหรับ Standard, 50 สำหรับ Analytics 360)
  • ใช้ Exponential Backoff ที่มีขีดจำกัดการลองใหม่: หากคำขอล้มเหลวโดยมีข้อผิดพลาด 429 RESOURCE_EXHAUSTED, 500 INTERNAL หรือ 503 UNAVAILABLE ให้ลองใหม่โดยใช้ Exponential Backoff ที่ถูกตัดทอนตามที่อธิบายไว้ในการตอบกลับข้อผิดพลาด

การใช้และการตรวจสอบโทเค็นของ Chat

สำหรับคำขอ Ask Advisor chat โทเค็นจะแสดงถึงต้นทุนการคำนวณ การให้เหตุผล และการดึงข้อมูลที่เกี่ยวข้องของโมเดล การใช้โทเค็นของ Chat ได้รับอิทธิพลจากปัจจัยต่อไปนี้

  • ขอบเขตการค้นหาและการวิเคราะห์: ความซับซ้อนและความกว้างของการวิเคราะห์ที่ขอ
  • โทเค็นอินพุตและเอาต์พุตของโมเดล: ปริมาณข้อมูลตามบริบทที่ประมวลผลและคำบรรยายคำตอบที่สร้างขึ้น
  • โทเค็นการคิด: ขั้นตอนการให้เหตุผลของโมเดลที่จำเป็นต่อการสังเคราะห์ข้อมูล
  • เวลาในการตอบสนองของการดำเนินการ: เวลาในการประมวลผลที่จำเป็นสำหรับการสำรวจข้อมูลแบบหลายขั้นตอน

หากต้องการตรวจสอบการใช้โทเค็นแชท ให้ตั้งค่า "returnPropertyQuota": true ใน ChatRequest การตอบกลับจะมีออบเจ็กต์ PropertyChatQuota ซึ่งมีช่อง tokensPerDay และ tokensPerHour พร้อมยอดคงเหลือที่ใช้ไปและยอดคงเหลือที่เหลืออยู่