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