การจัดการโควต้าสำหรับ Data API ของ Google Analytics

Minhaz Kazi ผู้ประสานงานนักพัฒนาซอฟต์แวร์ Google Analytics – กุมภาพันธ์ 2023

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

ทําความเข้าใจระบบโควต้าสําหรับ Google Analytics Data API

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

โควต้ามี 3 หมวดหมู่แยกกัน โดยขึ้นอยู่กับวิธี Data API ที่คุณใช้

• เรียลไทม์ (สำหรับ runRealtimeReport)
• Funnel (สำหรับ runFunnelReport)
• หลัก (สำหรับวิธีการอื่นๆ ทั้งหมด)

และเมธอด Data API จะตรวจสอบที่เก็บข้อมูลหลายรายการสำหรับ [โทเค็นโควต้า][โควต้า Data API ของ Google Analytics] ดังนี้

1. ต่อพร็อพเพอร์ตี้ต่อวัน
2. ต่อพร็อพเพอร์ตี้ต่อชั่วโมง
3. ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง
4. คำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้
5. ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง

ระบบจะตรวจสอบ 5 กลุ่มนี้ทุกครั้งที่มีคำขอ Data API สำหรับพร็อพเพอร์ตี้ เข้ามา หากมีที่เก็บข้อมูลใดที่ว่างเปล่า คำขอจะล้มเหลวทันที พร้อมข้อผิดพลาด 429 หากถังใดถังหนึ่งไม่ว่าง ระบบจะใช้โทเค็นเดียวจากถังคำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้ แล้วจึงดำเนินการคำขอ API ระบบจะใช้โทเค็นจำนวนหนึ่งจากแต่ละ 3 บัคเก็ตแรกเมื่อการดำเนินการเสร็จสมบูรณ์ โดยขึ้นอยู่กับความซับซ้อนของคำขอ คำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้จะได้รับการเติมโทเค็นในเวลานี้ด้วย

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

คำเตือน: เราไม่แนะนำให้นักพัฒนาแอปกระจายโทเค็นโควต้าในโปรเจ็กต์ API หลายรายการ การกระทำนี้ละเมิดข้อกำหนดในการให้บริการของ Google APIs

โควต้าข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์หมายถึงการตอบกลับจาก API ที่มีรหัส 500 หรือ 503 หากแอปพลิเคชันสร้างข้อผิดพลาดมากเกินไปขณะ เข้าถึงพร็อพเพอร์ตี้ ระบบจะใช้โควต้าข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ต่อโปรเจ็กต์ต่อ พร็อพเพอร์ตี้ต่อชั่วโมงจนหมด

ระบบจะเติมโทเค็นโควต้าทั้งหมดให้ถึงขีดจำกัดตามช่วงเวลาที่ระบุ ดูข้อมูลโควต้าที่อัปเดตได้ที่[โควต้า Data API ของ Google Analytics] เช่น วิธีการหลักจะได้รับโทเค็นโควต้า 1,250 รายการในที่เก็บข้อมูลต่อโปรเจ็กต์ ต่อพร็อพเพอร์ตี้ ต่อชั่วโมง หากสมมติว่าคำขอเฉลี่ยจากแอปพลิเคชันของคุณใช้โทเค็นโควต้า 10 รายการ แอปพลิเคชันจะส่งคำขอ Core ได้ 125 รายการต่อชั่วโมงสำหรับ พร็อพเพอร์ตี้มาตรฐาน และ 10 เท่าของจำนวนดังกล่าว (คำขอ Core 1, 250 รายการ) สำหรับพร็อพเพอร์ตี้ Analytics 360 ขีดจํากัดโทเค็นโควต้าที่สูงขึ้นเป็นหนึ่งในข้อได้เปรียบที่สําคัญของพร็อพเพอร์ตี้ Analytics 360

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

• การขอเพิ่มมิติข้อมูล
• การค้นหาช่วงเวลาที่สูงขึ้น
• รวมมิติข้อมูลที่มี High Cardinality
• การค้นหาพร็อพเพอร์ตี้ที่มีจํานวนเหตุการณ์สูงกว่า

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

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

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

หากต้องการตรวจสอบการใช้โควต้าและสื่อสารข้อมูลดังกล่าวกับผู้ใช้ปลายทาง คุณสามารถเพิ่ม "returnPropertyQuota": true ลงในเนื้อหาคำขอ API ได้ ซึ่งจะแสดงผลออบเจ็กต์ PropertyQuota พร้อมกับการตอบกลับของ API ออบเจ็กต์ PropertyQuota จะมีจำนวนการใช้งานและสถานะโควต้าที่เหลือสำหรับทั้ง 5 บัคเก็ต ตัวอย่างเนื้อหาคำขอและการตอบกลับมีดังนี้

คำขอ

{
  "dimensions": [
    {
      "name": "medium"
    }
  ],
  "metrics": [
    {
      "name": "activeUsers"
    }
  ],
  "dateRanges": [
    {
      "startDate": "yesterday",
      "endDate": "yesterday"
    }
  ],
  "returnPropertyQuota": true
}

คำตอบ

{
  "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",
  ...
}

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

หมายเหตุ: ในระยะปัจจุบันของ Data API คุณต้องดำเนินการคำขอ API ให้สำเร็จเพื่อรับออบเจ็กต์ PropertyQuota หากพร็อพเพอร์ตี้ใช้ Bucket โทเค็นโควต้าจนหมดแล้ว คำขอจะล้มเหลวพร้อมข้อผิดพลาด 429 และการตอบกลับจะไม่มีออบเจ็กต์ PropertyQuota หากคุณได้รับผลกระทบจาก ปัญหานี้และคิดว่าแอปพลิเคชันของคุณจะได้รับประโยชน์จากการมีวิธีแยกต่างหากในการ เข้าถึงข้อมูลโควต้า โปรด +1 คำขอฟีเจอร์นี้ในเครื่องมือติดตามปัญหา

การจัดการโควต้า

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

แนวทางปฏิบัติแนะนำ

โดยทั่วไปแล้ว คุณลดการใช้โควต้าสำหรับแอปพลิเคชันได้ 2 วิธีดังนี้

• ส่งคำขอ API น้อยลง
• การส่งคำขอ API ที่ซับซ้อนน้อยกว่า

เมื่อคำนึงถึงหลักการทั้ง 2 ข้อนี้แล้ว แนวทางปฏิบัติที่คุณนำไปใช้ได้มีดังนี้

• การแคช: การใช้เลเยอร์การแคชจะช่วยเพิ่มทั้งความสามารถในการใช้งานและ การจัดการโควต้าสำหรับแอปพลิเคชัน Google Analytics จะแคชคําขอ API ของคุณ แต่คําขอที่ส่งซ้ำจะยังคงใช้โทเค็นโควต้า การแคชการตอบกลับจาก API จะช่วยลดจำนวนคำขอที่ซ้ำกันได้อย่างมาก ตัวอย่างเช่น ข้อมูลระหว่างวันสําหรับพร็อพเพอร์ตี้มาตรฐานอาจมีเวลาหมดอายุของแคช 4 ชั่วโมงขึ้นไป ดูความใหม่ของข้อมูลสําหรับ Google Analytics
• การผสานคำขอ: ลองผสานคำขอ API หลายรายการเป็นรายการเดียว เช่น คำขอข้อมูล 5 รายการภายในกรอบเวลา 2 วันอาจใช้โทเค็นโควต้า 3 เท่า เมื่อเทียบกับคำขอ 1 รายการภายในกรอบเวลา 10 วัน หากคุณมีคำขอหลายรายการที่แตกต่างกันเพียงมิติข้อมูลเดียว ให้พิจารณารวมคำขอเหล่านั้นเป็นคำขอเดียว
• การทำให้คำขอเป็นเรื่องง่าย: จำกัดคำขอของคุณให้มีข้อมูลขั้นต่ำ ที่แอปพลิเคชันและผู้ใช้ต้องการ แถว/คอลัมน์จำนวนมากหรือ เกณฑ์ตัวกรองที่ซับซ้อนจะใช้โทเค็นโควต้ามากขึ้น โดยปกติแล้ว ช่วงวันที่ที่ยาวขึ้น จะมีค่าใช้จ่ายสูงกว่า (เช่น การเปลี่ยนช่วงวันที่จาก 28 วันเป็น 365 วัน อาจใช้โทเค็นโควต้า 3 เท่า) นอกจากนี้ คุณยังพิจารณาใช้ มิติข้อมูลที่มีจำนวนคาร์ดินาลิตีต่ำกว่าได้ทุกเมื่อที่เป็นไปได้ (เช่น ขอ dateHour แทน dateHourMinute)
• การใช้งาน limit อย่างมีประสิทธิภาพ: การเปลี่ยน limit ในคำขอ API เพื่อลดจำนวนแถวที่แสดงจะไม่ส่งผลต่อโทเค็นโควต้าที่ใช้ไปอย่างมีนัยสำคัญ เช่น คำขอ 5 รายการที่มีขีดจำกัด 10,000 แถวอาจใช้โทเค็นโควต้า 5 ครั้งเมื่อเทียบกับคำขอ 1 รายการที่มีขีดจำกัด 50,000 รายการ
• การใช้หมวดหมู่เมธอดที่เหมาะสม: ดังที่กล่าวไว้ข้างต้น โควต้าจะกระจายอยู่ในหมวดหมู่เมธอด 3 หมวดหมู่ การใช้วิธีที่เหมาะสมสำหรับกรณีการใช้งานที่ถูกต้องจะช่วยประหยัดโควต้าในหมวดหมู่อื่นๆ ได้ ตัวอย่างเช่น แทนที่จะ สร้าง Funnel ของคุณเองในแอปพลิเคชันโดยใช้ข้อมูลจากเมธอดหลัก ให้ใช้เมธอด runFunnelReport ในการสร้าง Funnel
• อัปเดตการตั้งค่าเริ่มต้น: เมื่อสร้างหรือปรับแต่งรายงานที่กำหนดเองในแพลตฟอร์ม ผู้ใช้อาจไม่อัปเดตตัวเลือกเริ่มต้นที่แอปพลิเคชันแสดง และเปลี่ยนเฉพาะตัวเลือกที่รันไทม์ หากแอปพลิเคชันมี ช่วงวันที่เริ่มต้นเป็น 365 วัน และผู้ใช้มักจะดูรายงาน 28 วัน การดำเนินการนี้จะทำให้ใช้โควต้ามากกว่าที่จำเป็นเป็นประจำ พิจารณาจำกัดช่วงและการเลือกในการตั้งค่าเริ่มต้น และอนุญาตให้ผู้ใช้เลือกการตั้งค่าที่เหมาะสมที่สุดสำหรับกรณีการใช้งานของตน หรือในบางกรณี คุณยังจำกัดค่าเริ่มต้นที่ผู้ใช้เปลี่ยนได้ด้วย
• การจัดคิวคำขอและการโหลดแบบ Lazy Loading: โปรดคำนึงถึงขีดจำกัดโทเค็นคำขอพร้อมกันต่อพร็อพเพอร์ตี้ แอปพลิเคชันของคุณไม่ควรส่งคำขอมากเกินไปพร้อมกัน หากแอปพลิเคชันมีองค์ประกอบ UI จำนวนมาก ซึ่งส่งผลให้มีคำขอ API จำนวนมาก ให้ลอง แบ่งหน้า UI, การโหลดแบบ Lazy Loading และจัดคิวคำขอด้วย Exponential Backoff สำหรับการลองอีกครั้ง ใช้returnPropertyQuotaเพื่อตรวจสอบการใช้โทเค็นคำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้ของแอปพลิเคชันอย่างเข้มงวด

การจัดการประสบการณ์และความคาดหวังของผู้ใช้

• แสดงความคิดเห็นของผู้ใช้ก่อนที่ผู้ใช้จะเรียกใช้การค้นหาที่มีการใช้โทเค็นสูง เช่น คำค้นหาที่มีมิติข้อมูล High Cardinality หลายรายการหรือมีกรอบเวลาขนาดใหญ่อาจใช้โทเค็นจำนวนมาก การแสดงคำเตือนและข้อความแจ้งให้ยืนยันสำหรับการค้นหาดังกล่าวจะช่วยป้องกันไม่ให้ผู้ใช้ทำการเปลี่ยนแปลงที่ไม่จำเป็นกับรายงาน และช่วยจำกัดขอบเขตของการค้นหา
• สำหรับโซลูชันการรายงานที่กำหนดเอง ให้ระบุวิธีที่ผู้ใช้จะเข้าใจ การใช้งานคําค้นหาของแต่ละองค์ประกอบในรายงาน เช่น คุณสามารถระบุ มุมมองการแก้ไขข้อบกพร่องที่แสดงการใช้โทเค็นโควต้าสำหรับองค์ประกอบรายงานแต่ละรายการได้
• แสดงความคิดเห็นเกี่ยวกับข้อผิดพลาดเกี่ยวกับโควต้าประเภทที่เฉพาะเจาะจงและกำหนดการดำเนินการของผู้ใช้
• เนื่องจากพร็อพเพอร์ตี้ Google Analytics 360 มีโควต้าสูงกว่าพร็อพเพอร์ตี้มาตรฐาน 5-10 เท่า คุณจึงมีความยืดหยุ่นมากขึ้นเมื่อใช้พร็อพเพอร์ตี้ Google Analytics 360

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

หากมีคำถามเพิ่มเติมเกี่ยวกับโควต้า Data API โปรดไปที่ GA Discord หรือถามใน Stack Overflow หากมีคำขอฟีเจอร์ที่เฉพาะเจาะจงเกี่ยวกับ Data API คุณสามารถโพสต์คำขอเหล่านั้นในIssue Trackerของเรา