13 ตัวชี้วัดที่สำคัญ สำหรับบริษัท API

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

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

ใครสนใจเกี่ยวกับเมตริก API?

โดยทั่วไปมีบางทีมที่ใส่ใจเกี่ยวกับเมตริก API:

• การจัดการผลิตภัณฑ์ : ผู้จัดการผลิตภัณฑ์ API รับผิดชอบเกี่ยวกับฟีเจอร์โรดแมป API เพื่อให้แน่ใจว่ามีการสร้างปลายทาง API ที่ถูกต้อง พวกเขายังต้องสร้างสมดุลระหว่างความต้องการของลูกค้า (ไม่ว่าจะภายในหรือภายนอก) กับเวลาด้านวิศวกรรมและข้อจำกัดส่วนบุคคล
• ธุรกิจ/การเติบโต : ทีมงานที่ต้องเผชิญกับธุรกิจ เช่น การตลาดและการขาย ไม่ได้คิดในแง่ของปลายทาง API แต่พวกเขาส่วนใหญ่สนใจในการปรับใช้ของลูกค้าและสร้างความมั่นใจว่าลูกค้าจะใช้ API ได้สำเร็จ พวกเขายังยินดีที่รู้ว่าผู้ใช้มาจากไหนและคนใดที่อาจเป็นโอกาสในการขายใหม่
• วิศวกรรมแอปพลิเคชัน/แพลตฟอร์ม : นักพัฒนา API มีหน้าที่ในการเพิ่มคุณสมบัติใหม่ให้กับ API ในขณะที่แก้ไขข้อบกพร่องของปัญหาเฉพาะแอปพลิเคชันในตรรกะทางธุรกิจของ API ผลิตภัณฑ์เหล่านี้อาจเป็น API-as-a-Service, ปลั๊กอิน, การผสานรวมสำหรับพันธมิตร, API ที่รวมอยู่ในผลิตภัณฑ์ขนาดใหญ่ หรือประเภทอื่นๆ
• โครงสร้างพื้นฐาน/DevOps : ทีมโครงสร้างพื้นฐานและ DevOps ใช้เมตริกเพื่อให้แน่ใจว่าเซิร์ฟเวอร์กำลังทำงานและจัดสรรทรัพยากรอย่างจำกัดอย่างถูกต้อง ข้อมูลนี้อาจเป็นประโยชน์สำหรับทีมวิศวกรหลายทีม

ตัวชี้วัด API โครงสร้างพื้นฐาน

ต่อไปนี้คือเมตริก API โครงสร้างพื้นฐานที่เป็นประโยชน์บางส่วนที่ควรพิจารณาติดตาม ตัวชี้วัดเหล่านี้จำนวนมากเป็นจุดสนใจของเครื่องมือ Application Performance Monitoring (APM) และบริษัทตรวจสอบโครงสร้างพื้นฐาน เช่น Datadog

1: เวลาทำงาน

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

แน่นอนว่าการเปลี่ยนจากสี่เป็นห้าเก้านั้นยากกว่าการเปลี่ยนจากสองถึงสามเก้า ซึ่งเป็นเหตุผลที่คุณจะไม่เห็นห้าเก้ายกเว้นการบริการที่สำคัญต่อภารกิจ (และมีราคาแพง) ที่สุด

จากที่กล่าวมา บริการบางอย่างอาจมีเวลาทำงานที่ต่ำลงได้จริง ในขณะเดียวกันก็รับประกันการจัดการการหยุดทำงานที่ราบรื่นโดยไม่ส่งผลกระทบต่อบริการของคุณ เวลาทำงานโดยทั่วไปจะวัดผ่านบริการ ping หรือการทดสอบ สังเคราะห์เช่น ผ่านPingdomหรือUptimeRobot คุณสามารถกำหนดค่าโพรบให้ทำงานในช่วงเวลาที่กำหนด เช่น ทุกนาที เพื่อโพรบปลายทางเฉพาะเช่น/healthหรือ /statusปลายทางนี้ควรมีการทดสอบการเชื่อมต่อพื้นฐาน เช่น กับที่เก็บข้อมูลสำรองหรือบริการอื่นๆ คุณสามารถเผยแพร่ตัวชี้วัดเหล่านี้บนเว็บไซต์ของคุณได้อย่างง่ายดายโดยใช้เครื่องมืออย่างStatuspage.io

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

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

2: การใช้งาน CPU

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

เมื่อทำการดีบัก API ในเครื่อง คุณสามารถดูระบบและประมวลผลการใช้งาน CPU ได้อย่างง่ายดายผ่านตัวจัดการงานบน Windows (หรือ ตัว ตรวจสอบกิจกรรมบน Mac ) อย่างไรก็ตาม คุณอาจไม่ต้องการเป็น SSH และเรียกใช้topคำสั่งบนเซิร์ฟเวอร์ นี่คือจุดที่ผู้ให้บริการ APM หลายรายมีประโยชน์ โดยทั่วไป APM จะรวมเอเจนต์ที่คุณสามารถฝังในแอปพลิเคชันของคุณหรือบนเซิร์ฟเวอร์ที่ดักจับเมทริกการใช้ CPU และหน่วยความจำ นอกจากนี้ยังสามารถดำเนินการตรวจสอบเฉพาะแอปพลิเคชันอื่นๆ เช่น การทำโปรไฟล์เธรด

เมื่อดูการใช้งาน CPU จำเป็นต้องดูการใช้งานต่อ CPU เสมือน (เช่น เธรดจริง) การใช้งานที่ไม่สมดุลอาจบ่งบอกว่าแอปพลิเคชันมีเธรดไม่ถูกต้องหรือเธรดพูลที่มีขนาดไม่ถูกต้อง

ผู้ให้บริการ APM หลายรายทำให้คุณสามารถแท็กแอปพลิเคชันที่มีหลายชื่อได้ คุณจึงสามารถดำเนินการควบรวมได้ ตัวอย่างเช่น คุณอาจต้องการแบ่งเมตริก VM แต่ละรายการ เช่น_my-api-westus-vm0_, _my-api-westus-vm1_, _my-api-eastus-vm0_ฯลฯ ในขณะที่รวมข้อมูลเหล่านี้ในแอปเดียวที่เรียก_my-api_ว่า

3: การใช้หน่วยความจำ

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

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

ตัววัด API ของแอปพลิเคชัน

4: คำขอต่อนาที (RPM)

RPM (คำขอต่อนาที) เป็นตัวชี้วัดประสิทธิภาพที่มักใช้ในการเปรียบเทียบ HTTP หรือเซิร์ฟเวอร์ฐานข้อมูล โดยปกติ RPM แบบ end-to-end ของคุณจะต่ำกว่า RPM ที่โฆษณามาก ซึ่งทำหน้าที่เป็นขอบเขตบนสำหรับ API “Hello World” แบบธรรมดามากกว่า เนื่องจากเซิร์ฟเวอร์จะไม่พิจารณาเวลาแฝงที่เกิดขึ้นสำหรับการดำเนินการ I/O กับฐานข้อมูล บริการของบุคคลที่สาม ฯลฯ

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

RPM ของคุณอาจแตกต่างกันไปตามวันในสัปดาห์หรือแม้กระทั่งชั่วโมงของวัน โดยเฉพาะอย่างยิ่งหากผู้บริโภคของคุณมีการใช้งานน้อยลงในช่วงกลางคืนและวันหยุดสุดสัปดาห์ บางสถานการณ์รับประกันการติดตามตัววัดแอปพลิเคชันที่ละเอียดมากขึ้น เช่น RPS (คำขอต่อวินาที) หรือ QPS (คำค้นหาต่อวินาที)

5: เวลาแฝงเฉลี่ยและสูงสุด

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

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

เนื่องจากปลายทางที่มีปัญหาอาจถูกซ่อนไว้เมื่อดูเฉพาะเวลาแฝงรวม จึงจำเป็นต้องพิจารณาการแยกย่อยของเวลาในการตอบสนองตามเส้นทาง ภูมิศาสตร์ และฟิลด์อื่นๆ ตัวอย่างเช่น คุณอาจมีPOST /checkoutปลายทางที่เวลาแฝงเพิ่มขึ้นอย่างช้าๆ เมื่อเวลาผ่านไป ซึ่งอาจเกิดจากขนาดตาราง SQL ที่เพิ่มขึ้นเรื่อยๆ ซึ่งไม่ได้รับการจัดทำดัชนีอย่างถูกต้อง อย่างไรก็ตาม เนื่องจากมีการโทรไปที่ ในปริมาณน้อย ปลายทาง POST /checkoutของคุณจึงปิดบังปัญหานี้ไว้GET /itemsซึ่งเรียกว่ามากกว่าจุดสิ้นสุดการชำระเงิน ในทำนองเดียวกัน หากคุณมี GraphQL API คุณจะต้องดูเวลาแฝงเฉลี่ยต่อการดำเนินการของ GraphQL

เราใส่เวลาแฝงไว้ภายใต้แอปพลิเคชัน/วิศวกรรม แม้ว่าทีม DevOps/โครงสร้างพื้นฐานจำนวนมากจะพิจารณาเวลาแฝงด้วย โดยปกติ บุคลากรด้านโครงสร้างพื้นฐานจะพิจารณาเวลาแฝงโดยรวมของชุด VM เพื่อให้แน่ใจว่า VM จะไม่โอเวอร์โหลด แต่จะไม่เจาะลึกลงไปในเมตริกเฉพาะแอปพลิเคชัน เช่น ต่อเส้นทาง

6: ข้อผิดพลาดต่อนาที

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

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

คุณสามารถเจาะลึกเพิ่มเติมเพื่อดูว่าข้อผิดพลาดเหล่านี้มาจากไหน ข้อผิดพลาด มากมาย401 Unauthorizedจากพื้นที่ทางภูมิศาสตร์หนึ่งๆ อาจบอกเป็นนัยว่าบอทกำลังพยายามแฮ็ค API ของคุณ

ตัวชี้วัดผลิตภัณฑ์ API

API ไม่ได้เป็นเพียงคำศัพท์ทางวิศวกรรมที่เกี่ยวข้องกับไมโครเซอร์วิสและ SOA อีกต่อไป API-as-a-productกลายเป็นเรื่องธรรมดามากขึ้น โดยเฉพาะอย่างยิ่งในหมู่บริษัท B2B ที่ต้องการรวมการแข่งขันกับพันธมิตรรายใหม่และช่องทางรายได้ บริษัทที่ขับเคลื่อนด้วย API จำเป็นต้องพิจารณามากกว่าแค่เมตริกทางวิศวกรรม เช่น ข้อผิดพลาดและเวลาในการตอบสนอง เพื่อทำความเข้าใจว่า API ของพวกเขาถูกนำไปใช้อย่างไร (หรือเหตุใดจึงไม่นำมาใช้อย่างรวดเร็วตามที่วางแผนไว้) บทบาทของการรับรองคุณสมบัติที่เหมาะสมนั้นขึ้นอยู่กับตัวจัดการผลิตภัณฑ์ APIซึ่งเป็นบทบาทใหม่ที่บริษัท B2B จำนวนมากกำลังเร่งดำเนินการ

7: การเติบโตของการใช้ API

สำหรับผู้จัดการผลิตภัณฑ์จำนวนมาก การใช้ API (ร่วมกับผู้บริโภคที่ไม่ซ้ำ) เป็นมาตรฐานทองคำในการวัดการนำ API ไปใช้ API ไม่ควรปราศจากข้อผิดพลาด แต่ควรแสดงให้เห็นถึงการเติบโตเมื่อเวลาผ่านไป ต่างจากคำขอต่อนาที การใช้ API ควรวัดในช่วงเวลาที่นานขึ้น เช่น วันหรือเดือน เพื่อทำความเข้าใจแนวโน้มที่แท้จริง หากวัดการเติบโตของ API แบบเดือนต่อเดือน เราแนะนำให้เลือก 28 วัน เนื่องจากจะขจัดความลำเอียงที่เกิดจากการใช้งานช่วงสุดสัปดาห์เทียบกับวันธรรมดา และความแตกต่างในจำนวนวันต่อเดือน ตัวอย่างเช่น กุมภาพันธ์อาจมีเพียง 28 วัน ในขณะที่เดือนก่อนหน้ามี 31 วันเต็ม ทำให้เดือนกุมภาพันธ์มีการใช้งานน้อยลง

8: ผู้บริโภค API ที่ไม่ซ้ำ

เนื่องจากการใช้ API ที่เพิ่มขึ้นในหนึ่งเดือนอาจมาจากบัญชีลูกค้าเพียงบัญชีเดียว การวัดจำนวนลูกค้ารายเดือนที่ไม่ซ้ำจึงเป็นสิ่งสำคัญ การตรวจสอบผู้ใช้ที่ใช้งานรายเดือน (MAU) สามารถให้สถานะโดยรวมของการได้มาซึ่งลูกค้าใหม่และการเติบโต ทีมแพลตฟอร์มจำนวนมากเชื่อมโยง API MAU กับเว็บ MAU เพื่อรับสถานะผลิตภัณฑ์ที่สมบูรณ์ หาก Web MAU เติบโตเร็วกว่า API MAU มาก อาจหมายถึงช่องทางที่รั่วในระหว่างการรวมหรือใช้งานโซลูชันใหม่ โดยเฉพาะอย่างยิ่งเมื่อผลิตภัณฑ์หลักของบริษัทคือ API เป็นกรณีนี้สำหรับบริษัท B2B และ SaaS หลายแห่ง ในทางกลับกัน API MAU สามารถสัมพันธ์กับการใช้ API เพื่อทำความเข้าใจว่าการใช้งาน API ที่เพิ่มขึ้นมาจากไหน (ลูกค้าใหม่เทียบกับลูกค้าปัจจุบัน)

9: ลูกค้าอันดับสูงสุดตามการใช้งาน API

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

ซึ่งหมายความว่าการติดตามว่าลูกค้า 10 อันดับแรกของคุณกำลังทำอะไรกับ API ของคุณเป็นสิ่งสำคัญ คุณสามารถแยกย่อยเพิ่มเติมตามปลายทางที่พวกเขากำลังเรียกและวิธีที่พวกเขากำลังเรียก พวกเขาใช้จุดปลายเฉพาะมากกว่าผู้ใช้ที่ไม่ใช่ผู้ใช้ระดับสูงหรือไม่? บางทีพวกเขาอาจพบช่วงเวลา “อ่าฮะ” กับ API ของคุณ ในขณะที่ผู้บริโภครายอื่นไม่พบ สำหรับบริษัท API

10: การรักษา API ไว้

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

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

11: ถึงเวลาสู่ Hello World ครั้งแรก (TTFHW)

TTFHW เป็น KPI ที่สำคัญไม่เพียงแต่ติดตามความสมบูรณ์ของผลิตภัณฑ์ API ของคุณเท่านั้น แต่ยังรวมถึงประสบการณ์นักพัฒนาซอฟต์แวร์ (DX) โดยรวมของคุณด้วย โดยเฉพาะอย่างยิ่งหาก API ของคุณเป็นแพลตฟอร์มเปิดที่ดึงดูดนักพัฒนาและพันธมิตรบุคคลที่สาม คุณต้องการให้แน่ใจว่าพวกเขาสามารถเริ่มต้นใช้งานได้โดยเร็วที่สุด TTFHW วัดระยะเวลาที่ใช้ตั้งแต่การเข้าชมหน้า Landing Page ครั้งแรกไปจนถึงธุรกรรมครั้งแรกผ่านแพลตฟอร์ม API ของคุณ นี่คือการตลาดสำหรับการติดตามตัววัดข้ามสายงาน เอกสาร บทช่วยสอน สำหรับ API เอง

12: การเรียก API ต่อธุรกรรมทางธุรกิจ

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

13: SDK และการนำเวอร์ชันมาใช้

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

ธุรกิจและการเติบโต

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

สรุป: ติดตามเมตริก API ที่เหมาะสม

สำหรับทุกคนที่สร้างและทำงานกับ API การติดตามเมตริก API ที่ถูกต้องเป็นสิ่งสำคัญ บริษัทส่วนใหญ่จะไม่เปิดตัวเว็บหรือผลิตภัณฑ์มือถือใหม่หากไม่มีเครื่องมือทางวิศวกรรมและเครื่องมือผลิตภัณฑ์ที่เหมาะสม ในทำนองเดียวกัน คุณคงไม่อยากเปิด API ใหม่โดยไม่มีวิธีติดตามเมตริก API ที่ถูกต้อง

บางครั้ง KPI สำหรับทีมหนึ่งสามารถผสมผสานกับอีกทีมหนึ่งได้ ตามที่เราเห็นด้วยตัวชี้วัดการใช้งาน API นอกจากนี้ยังสามารถดูเมตริกพื้นฐานเดียวกันได้หลายวิธีอีกด้วย อย่างไรก็ตาม ทีมควรจดจ่อกับการดูตัวชี้วัดที่เหมาะสมสำหรับทีมของตน ตัวอย่างเช่น ผู้จัดการผลิตภัณฑ์ไม่ควรกังวลเกี่ยวกับการใช้งาน CPU มากนัก เช่นเดียวกับที่ทีมโครงสร้างพื้นฐานไม่ควรกังวลเกี่ยวกับการเก็บรักษา API

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

สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ เพราะเป็นราคาที่สุด คุ้มที่สุด

เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA ให้คำปรึกษาด้านวางระบบจัดการเอกสารอิเล็กทรอนิกส์  EDMS โดยทีมงานผู้เชี่ยวชาญจาก K&O

ที่มีประสบการณ์มากว่า 15 ปี รวมถึงซอฟต์แวร์ระดับโลก ติดต่อ 0 2 – 8 6 0 – 6 6 5 9 หรือ E m a i l : c s @ k o . i n . t h

หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699

• Facebook
• Twitter
• Line