Minhaz Kazi ผู้ประสานงานนักพัฒนาซอฟต์แวร์ของ Google Analytics กุมภาพันธ์ 2023
หากคุณพัฒนาแอปพลิเคชันโดยใช้ Data API ของ Google Analytics คุณจะ ควรเข้าใจวิธีการทำงานของโควต้าและขีดจำกัดสำหรับ API หาก แอปพลิเคชันได้รับการออกแบบมาเป็นอย่างดี ผู้ใช้จึงมีแนวโน้มที่จะใช้งานถึงขีดจำกัดโควต้าน้อยลง บางส่วนของ แนวทางปฏิบัติแนะนำที่เกี่ยวข้องยังนำไปสู่การค้นหาที่มีประสิทธิภาพ ใน API ด้วย วิธีนี้ เร่งรายงานและแดชบอร์ดในแอปพลิเคชันของคุณ และเป็นผลให้ ประสบการณ์ของผู้ใช้ที่ดี บทความนี้จะกล่าวถึงระบบโควต้าและ แนวทางปฏิบัติในการใช้งาน Google Analytics Data API
ทำความเข้าใจระบบโควต้าสำหรับ Google Analytics Data API
เนื่องจากนักพัฒนาซอฟต์แวร์และผู้ใช้นับล้านๆ รายใช้ Google Analytics ทำให้โควต้าสำหรับ API คำขอปกป้องระบบจากการประมวลผลข้อมูลมากเกินกว่าที่จะจัดการได้ในขณะที่ เพื่อให้มั่นใจว่าจะมีการกระจายทรัพยากรของระบบอย่างเท่าเทียม API ข้อมูลสำหรับ Google พร็อพเพอร์ตี้ Analytics 4 ใช้ระบบที่เก็บข้อมูลโทเค็นเพื่อจัดการโควต้า API ถึง เข้าใจแนวคิด: ลองนึกภาพว่ามีที่เก็บข้อมูลจำนวนมาก จำนวนโทเค็น คำขอ API จะตรวจสอบที่เก็บข้อมูลก่อน หากไม่มี เหลืออยู่ คำขอจะล้มเหลว มิฉะนั้นจะมีการดำเนินการคำขอ และ จะใช้โทเค็นอย่างน้อย 1 รายการจากที่เก็บข้อมูล ทั้งนี้ขึ้นอยู่กับความซับซ้อน คำขอ ระบบจะเติมโทเค็นในที่เก็บข้อมูลจนถึงค่าสูงสุดที่ระดับคงที่ ช่วงเวลา
มีโควต้า 3 แบบแยกกัน ขึ้นอยู่กับเมธอด Data API ที่คุณใช้ หมวดหมู่:
- เรียลไทม์ (สำหรับ
runRealtimeReport) - Funnel (สำหรับ
runFunnelReport) - Core (สำหรับวิธีการอื่นๆ ทั้งหมด)
และเมธอด Data API จะตรวจสอบที่เก็บข้อมูลหลายรายการสำหรับ โทเค็นโควต้า:
- ต่อพร็อพเพอร์ตี้ต่อวัน
- ต่อพร็อพเพอร์ตี้ต่อชั่วโมง
- ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง
- คำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้
- ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง
ที่เก็บข้อมูลทั้ง 5 รายการนี้จะได้รับการตรวจสอบทุกครั้งที่มีคำขอ Data API เข้ามา หากที่เก็บข้อมูลใดๆ ว่างเปล่า คำขอจะดำเนินการไม่สำเร็จทันที พร้อมข้อผิดพลาด 429 หากไม่มีที่เก็บข้อมูลใดไม่ว่างเปล่า ที่เก็บข้อมูล ระบบจะใช้โทเค็นจากที่เก็บข้อมูลคำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้ และ จากนั้นคำขอ API จะทำงาน ขึ้นอยู่กับความซับซ้อนของคำขอ จะมีการใช้โทเค็นจำนวนหนึ่งจากที่เก็บข้อมูล 3 รายการแรก เมื่อการดำเนินการเสร็จสิ้น คำขอหลายรายการพร้อมกันต่อพร็อพเพอร์ตี้จะ รับโทเค็นเติมเงินในตอนนี้
แต่โควต้าต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมงจะทำให้โควต้าที่หมดลงสำหรับ ผู้ใช้ตั้งแต่ 1 คนขึ้นไปจะไม่ส่งผลกับผู้ใช้คนอื่นๆ ของแอปพลิเคชัน ซึ่ง project อ้างอิงถึงโปรเจ็กต์ GCP ของแอปพลิเคชันของคุณ โควต้าต่อพร็อพเพอร์ตี้ต่อชั่วโมงเท่ากับ ซึ่งโดยทั่วไปจะเป็น 4 เท่าของโควต้าต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง และสุดท้าย พร็อพเพอร์ตี้จะต้องเข้าถึงโดยโปรเจ็กต์ต่างๆ อย่างน้อย 4 โปรเจ็กต์ก่อน คุณสามารถใช้โควต้าต่อพร็อพเพอร์ตี้ต่อชั่วโมงหมดแล้ว การบังคับใช้โควต้าทั้ง ระดับโปรเจ็กต์และพร็อพเพอร์ตี้ช่วยให้แน่ใจว่าปัญหาโควต้าจะจํากัดอยู่ที่รายการเดียว และจะไม่ส่งผลต่อพร็อพเพอร์ตี้อื่นที่แอปพลิเคชันของคุณเข้าถึงอยู่
โควต้าข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์หมายถึงการตอบกลับจาก API ที่มี 500 หรือ รหัส 503 หากแอปพลิเคชันของคุณแสดงข้อผิดพลาดมากเกินไป ในการเข้าถึงพร็อพเพอร์ตี้ใดก็ตาม ข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ต่อโปรเจ็กต์ต่อโปรเจ็กต์ พร็อพเพอร์ตี้ต่อชั่วโมง
ระบบจะเติมโทเค็นโควต้าทั้งหมดให้เท่ากับขีดจำกัดในช่วงเวลาที่ระบุไว้ โปรดดู โควต้า API ข้อมูลของ Google Analytics สำหรับข้อมูลโควต้าที่อัปเดต ตัวอย่างเช่น เมธอดหลักจะได้รับโทเค็นโควต้า 1,250 รายการในต่อโปรเจ็กต์ต่อพร็อพเพอร์ตี้ต่อชั่วโมง สมมติว่าคำขอโดยเฉลี่ยจากแอปพลิเคชันของคุณใช้โควต้า 10 รายการ แอปพลิเคชันของคุณจะสามารถส่งคำขอ 125 แกนต่อชั่วโมงได้เป็นเวลา พร็อพเพอร์ตี้มาตรฐานและ 10 เท่าของจำนวนดังกล่าว (คำขอหลัก 1,250 รายการ) สำหรับ Analytics พร็อพเพอร์ตี้ 360 ขีดจำกัดโทเค็นโควต้าที่สูงกว่าคือหนึ่งในโทเค็นหลัก ประโยชน์ของพร็อพเพอร์ตี้ Analytics 360
เนื่องจากการใช้โทเค็นสำหรับที่เก็บข้อมูล 3 รายการแรกขึ้นอยู่กับความซับซ้อนของ คำขอนั้น จึงเป็นเรื่องยากที่จะคาดการณ์การใช้โทเค็นที่ถูกต้องก่อนส่งคำขอ คำขอต่อไปนี้มักจะเพิ่มความซับซ้อนของคำขอ ส่งผลให้มีการใช้โทเค็น:
- การขอมิติข้อมูลเพิ่มเติม
- กำลังค้นหาช่วงเวลาที่สูงขึ้น
- รวมมิติข้อมูลที่มีจํานวนสมาชิกในเซ็ตสูงกว่า
- การค้นหาพร็อพเพอร์ตี้ที่มีจํานวนเหตุการณ์สูงกว่า
ดังนั้น ข้อความค้นหาเดียวกันสำหรับพร็อพเพอร์ตี้ 2 รายการที่แตกต่างกันอาจส่งผลให้ การใช้โทเค็นที่แตกต่างออกไปอย่างสิ้นเชิง เนื่องจาก Cardinality ของมิติข้อมูลอาจ หรือปริมาณการเข้าชมอาจแตกต่างกัน อย่างไรก็ตาม คุณสามารถคาดหวังว่า พร็อพเพอร์ตี้ที่มีระดับการเข้าชมใกล้เคียงกันและมีการกำหนดค่าคล้ายกัน การใช้โทเค็นที่คล้ายกัน คุณสามารถใช้สมมติฐานนี้เพื่อคาดการณ์การใช้งานโทเค็นของลูกค้า ในขั้นตอนการวางแผนและการออกแบบแอปพลิเคชัน
การตรวจสอบการใช้งานโควต้า
ในการตรวจสอบการใช้โควต้าและแจ้งข้อมูลนั้นแก่ผู้ใช้ของคุณ คุณสามารถเพิ่ม
"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",
...
}
ดังนั้น หลังจากที่ได้รับคำขอ API ข้อมูลสำเร็จแต่ละครั้ง คุณน่าจะได้รับจำนวน โควต้าคำขอที่ใช้ไปและจำนวนโควต้าที่เหลือสำหรับพร็อพเพอร์ตี้ ใช่เลย ที่สามารถแสดงข้อมูลนี้ต่อผู้ใช้ผ่านทางแอปพลิเคชันของคุณได้ ของ Google
การจัดการโควต้า
ขอแนะนำให้นำแนวทางปฏิบัติแนะนำในการจัดการโควต้าไปใช้ตามรายละเอียดด้านล่าง การใช้งาน Data API ให้เกิดประโยชน์สูงสุด และ การอัปเกรดพร็อพเพอร์ตี้เป็น 360 สามารถเพิ่มปริมาณ ข้อมูลที่เข้าถึงผ่าน API
แนวทางปฏิบัติแนะนำ
คุณลดการใช้โควต้าของแอปพลิเคชันได้ 2 วิธีอย่างกว้างๆ ดังนี้
- การส่งคำขอ API น้อยลง
- การส่งคำขอ API ที่ซับซ้อนน้อยลง
โปรดคำนึงถึงหลักการ 2 ข้อต่อไปนี้ แนวทางปฏิบัติที่คุณนำไปใช้ได้มีดังนี้
- การแคช: การใช้เลเยอร์การแคชจะเป็นประโยชน์ต่อทั้งความสามารถในการใช้งานและ การจัดการโควต้าสำหรับแอปพลิเคชันของคุณ ตัว Google Analytics เองจะแคช คำขอ API แต่คำขอที่ซ้ำกันจะยังคงก่อให้เกิดโทเค็นโควต้า โดย ที่แคชการตอบกลับของ API ไว้ คุณจะสามารถลดจำนวนการแสดงผล คำขอ เช่น ข้อมูลระหว่างวันสำหรับพร็อพเพอร์ตี้มาตรฐานอาจมี ชั่วโมงหรือเวลาหมดอายุของแคชที่สูงกว่า โปรดดูความใหม่ของข้อมูลสำหรับ Google Analytics
- การรวมคำขอ: ลองรวมคำขอ API หลายรายการเข้าด้วยกันเป็นคำขอเดียว เช่น คำขอข้อมูล 5 รายการภายในกรอบเวลา 2 วันใช้ได้ 3 ครั้ง โทเค็นโควต้าเมื่อเทียบกับคำขอ 1 รายการสำหรับกรอบเวลา 10 วัน หากคุณมี มีคำขอหลายรายการที่แตกต่างกันเพียงมิติข้อมูลเดียวเท่านั้น ให้พิจารณารวม ไว้ในคำขอเดียว
- ลดความซับซ้อนของคำขอ: จำกัดคำขอให้มีจำนวนข้อมูลขั้นต่ำที่สุด
ที่จำเป็นสำหรับแอปพลิเคชันและผู้ใช้ของคุณ แถว/คอลัมน์จำนวนมาก หรือ
เกณฑ์ตัวกรองที่ซับซ้อนจะใช้โทเค็นโควต้ามากขึ้น ช่วงวันที่ยาวขึ้น
มักมีราคาแพงกว่า (เช่น เปลี่ยนช่วงวันที่จาก 28 วันเป็น 365 วัน
วันจะใช้โทเค็นโควต้าได้ 3 เท่า) คุณสามารถพิจารณาใช้
มิติข้อมูลที่มีจํานวนสมาชิกในเซ็ตต่ำกว่าเมื่อเป็นไปได้ (เช่น คําขอ
dateHourแทนdateHourMinute) - การใช้งาน
limitอย่างมีประสิทธิภาพ: การเปลี่ยนแปลงlimitใน API คำขอลดจำนวนแถวที่แสดงผลไม่มีผลอย่างมีนัยสำคัญ โทเค็นโควต้าที่ใช้ไป ตัวอย่างเช่น คำขอ 5 รายการที่มีการจำกัด 10, 000 แถวสามารถ ใช้โทเค็นโควต้า 5 เท่า เมื่อเทียบกับคําขอ 1 รายการที่มีขีดจํากัด 50,000 รายการ - การใช้หมวดหมู่วิธีการที่ถูกต้อง: ดังที่กล่าวไว้ข้างต้น ขีดจำกัดโควต้าคือ
ซึ่งแบ่งออกเป็น 3 หมวดหมู่ ดังนี้ การใช้วิธีที่เหมาะสมสำหรับทางขวา
Use Case สามารถบันทึกโควต้าในหมวดหมู่อื่นๆ ได้ ตัวอย่างเช่น แทนที่จะแสดง
สร้างช่องทางของคุณเองในแอปพลิเคชัน โดยใช้ข้อมูลจากเมธอดหลัก
ใช้เมธอด
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 หากคุณมีคำขอฟีเจอร์ที่เจาะจงเกี่ยวกับข้อมูล API ได้โดยโพสต์ไว้ในเครื่องมือติดตามปัญหา