GitHub Copilot Enterprise: Spaces और Usage Metrics API के लिए एक गाइड

GitHub Copilot Enterprise क्या है?

GitHub Copilot Enterprise GitHub के Copilot प्लान पदानुक्रम के शीर्ष पर बैठता है।

GitHub Copilot Business या Pro+ की तुलना में, Enterprise का फोकस गवर्नेंस, संगठनात्मक संदर्भ, और मापन क्षमताओं पर अधिक है। यह व्यक्तिगत डेवलपर्स या छोटी टीमों के बजाय बड़े इंजीनियरिंग परिवेश चलाने वाली कंपनियों के लिए बनाया गया है।

व्यवहार में दो क्षमताएँ सबसे अधिक मायने रखती हैं:

1. Spaces के माध्यम से कस्टम संगठनात्मक संदर्भ
2. Usage Metrics API के माध्यम से संगठन-व्यापी टेलीमेट्री

ये दोनों फीचर Copilot को “स्मार्ट ऑटोकम्प्लीट” से आगे बढ़ाकर एक आंतरिक AI इंजीनियरिंग प्लेटफ़ॉर्म के करीब ले जाते हैं।

वे कंपनियाँ जो GitHub Copilot Enterprise से सबसे अधिक मूल्य प्राप्त कर रही हैं, इसे आंतरिक अवसंरचना के एक प्रमुख घटक की तरह मानती हैं। वे संगठनात्मक संदर्भ को सावधानी से कॉन्फ़िगर करती हैं, अपनाने को निरंतर मापती हैं, और अनुमान के बजाय उपयोग डेटा के आधार पर नीतियाँ समायोजित करती हैं।

GitHub के इकोसिस्टम पर व्यापक नज़र के लिए, मैं हमारा Introduction to GitHub Products गाइड पढ़ने की सलाह देता हूँ।

Enterprise, Business और Pro+ से कैसे अलग है

GitHub Copilot Enterprise, Business सब्सक्रिप्शन का विस्तार करते हुए अतिरिक्त सुविधाएँ देता है, जैसे:

• संगठन-स्तरीय उपयोग मेट्रिक्स
• विस्तारित गवर्नेंस नियंत्रण
• एंटरप्राइज़-व्यापी नीति उत्तराधिकार
• बड़ी प्रीमियम अनुरोध आवंटन (Business टियर में 300 की तुलना में 1,000)
• अतिरिक्त मॉडल एक्सेस और प्रबंधन

Enterprise के लिए Copilot Enterprise सब्सक्रिप्शन के साथ GitHub Enterprise Cloud की भी आवश्यकता होती है। यह प्रति उपयोगकर्ता अतिरिक्त लागत जोड़ता है, इसलिए सुनिश्चित करें कि आपके संगठन को वास्तव में गवर्नेंस, टेलीमेट्री और एंटरप्राइज़-स्तरीय प्रशासन की ज़रूरत है।

नोट: Business सब्सक्राइबर्स संगठन स्तर पर Usage Metrics API तक पहुँचते हैं (/orgs/{org}/…)। Enterprise सब्सक्राइबर्स अतिरिक्त रूप से एंटरप्राइज़-व्यापी समग्र रिपोर्ट्स (/enterprises/{enterprise}/…) तक पहुँचते हैं जो सभी संगठनों को एक दृश्य में कवर करती हैं।

GitHub Copilot Enterprise किसके लिए है

GitHub Copilot Enterprise उन संगठनों को लक्षित करता है जो पहले से परिपक्व GitHub वातावरण चला रहे हैं।

आम Enterprise ग्राहक इनमें शामिल हैं:

• बड़ी इंजीनियरिंग संगठन
• विनियमित उद्योग
• मल्टी-टीम प्लेटफ़ॉर्म इंजीनियरिंग समूह
• आंतरिक डेवलपमेंट मानकों वाली कंपनियाँ
• केंद्रीकृत गवर्नेंस की आवश्यकता वाले संगठन

ध्यान दें कि यह अपने आप Copilot के प्रदर्शन में सुधार नहीं करता। मेरा मानना है कि यह अंतर इसलिए महत्वपूर्ण है क्योंकि कई टीमें शुरुआत में ज़रूरत से ज़्यादा ख़रीद लेती हैं। वे मान लेती हैं कि Enterprise का मतलब “बेहतर Copilot” है, जबकि वास्तविकता यह है कि Enterprise मुख्य रूप से गवर्नेंस और मापन टूलिंग जोड़ता है।

Copilot Spaces: आपके संगठन के लिए कस्टम संदर्भ

Copilot Spaces सामान्यीकृत AI कोडिंग असिस्टेंट्स की सबसे बड़ी कमजोरियों में से एक को हल करते हैं।

बॉक्स से बाहर, Copilot सार्वजनिक प्रोग्रामिंग ज्ञान को ठीक-ठाक समझता है। यह अपने-आप आपके आंतरिक APIs, आर्किटेक्चर निर्णयों, कोडिंग कन्वेंशंस, डिप्लॉयमेंट वर्कफ़्लो या ऑनबोर्डिंग दस्तावेज़ों को नहीं समझता।

Spaces एक चयनित संगठनात्मक संदर्भ प्रदान करते हैं जिसे Copilot बातचीत और कोडिंग सहायता के दौरान संदर्भित कर सकता है।

व्यावहारिक रूप से, Spaces Copilot को ऐसे सवालों के जवाब देने में मदद करते हैं:

• “हम आंतरिक रूप से API हैंडलर्स को कैसे संरचित करते हैं?”
• “हमारी प्लेटफ़ॉर्म टीम कौन-सी ऑथेंटिकेशन लाइब्रेरी की अनुशंसा करती है?”
• “इस माइक्रोसर्विस को कौन-सा डिप्लॉयमेंट वर्कफ़्लो उपयोग करना चाहिए?”
• “हमारी बैकएंड टीम कौन-सी नेमिंग कन्वेंशंस का पालन करती है?”

Spaces क्या सपोर्ट करते हैं

Spaces पुराने Knowledge Bases सिस्टम की तुलना में संगठनात्मक सामग्री की व्यापक श्रेणी का समर्थन करते हैं।

समर्थित सामग्री प्रकारों में शामिल हैं:

• कोड फ़ाइलें
• Markdown प्रलेखन
• JSON फ़ाइलें
• अपलोड की गई फ़ाइलें
• छवियाँ
• GitHub Issues
• Pull requests

हर सामग्री प्रकार अलग तरीके से योगदान देता है।

कोड फ़ाइलें Copilot को इम्प्लीमेंटेशन पैटर्न समझने में मदद करती हैं। Markdown फ़ाइलें आर्किटेक्चर के स्पष्टीकरण और ऑनबोर्डिंग गाइडेंस देती हैं। Pull requests समीक्षा चर्चाओं और ऐतिहासिक इंजीनियरिंग निर्णयों को उजागर करते हैं। यह संयोजन Copilot को आपके संगठन की डेवलपमेंट प्रथाओं के प्रति बेहतर जागरूकता देता है।

एक सूक्ष्म लेकिन महत्वपूर्ण बात यह है कि Spaces सिर्फ GitHub से जुड़े वेक्टर डेटाबेस नहीं हैं। इनमें एंटरप्राइज़ वातावरण के लिए डिज़ाइन किए गए साझा करने के नियंत्रण और संगठनात्मक गवर्नेंस वर्कफ़्लो शामिल हैं।

Knowledge Bases का सनसेट

GitHub ने पुराने Copilot Knowledge Bases फ़ीचर को 1 नवंबर, 2025 को सनसेट कर दिया।

Spaces ने Knowledge Bases को निम्न के साथ प्रतिस्थापित किया:

• विस्तृत कंटेंट सपोर्ट
• बेहतर शेयरिंग नियंत्रण
• सुधरा हुआ प्रशासन
• अधिक लचीला संगठन-स्तरीय प्रबंधन

आपको अब भी Knowledge Bases का उल्लेख करने वाला पुराना प्रलेखन और ब्लॉग पोस्ट मिलेंगे। पुराने ट्यूटोरियल्स का पालन करते समय सावधान रहें क्योंकि 2025 से 2026 के संक्रमण काल में कई एंडपॉइंट्स और वर्कफ़्लो बदल गए थे।

Copilot Spaces बनाना और कॉन्फ़िगर करना

प्रशासनिक दृष्टिकोण से, Copilot Spaces बनाना काफ़ी सीधा है। चुनौती तब आती है जब आपको उन्हें टीमों के बीच दर्जनों या सैकड़ों की संख्या में प्रबंधित करना होता है।

जो संरचना आप शुरू में चुनते हैं, वही टिक जाती है। मैंने देखा है कि संगठनों ने अनजाने में Spaces के अंदर “प्रलेखन बिखराव” बना लिया क्योंकि शुरुआत में किसी ने स्वामित्व नियम तय नहीं किए।

कोई भी Copilot Space बना सकता है, तो आइए अपने पर्सनल रिपो में एक बनाकर देखते हैं। एंटरप्राइज़ स्तर पर भी ये चरण मिलते-जुलते हैं, बस कुछ अलग पेज होते हैं।

एक Space सेट करना

एक Space बनाने का वर्कफ़्लो आमतौर पर इस प्रकार होता है:

1. अपने Enterprise प्रशासन क्षेत्र में Copilot Spaces पेज पर जाएँ
2. एक नया Space बनाएँ

3. रिपॉज़िटरीज़ और कंटेंट स्रोत चुनें, जिनमें MCPs और अन्य उपयोगी टूल शामिल हैं

4. स्रोत जोड़ना दाईं ओर “+ Add sources” बटन पर क्लिक करके किया जा सकता है

5. आप इस चरण में स्पेस साझा करने या शेयरिंग सेटिंग्स सेट करने का विकल्प चुन सकते हैं

6. सत्यापित करें कि Copilot चैट इंटरैक्शन के दौरान कंटेंट को संदर्भित कर सकता है

एंटरप्राइज़ उपयोगकर्ताओं के लिए नोट: आपका प्रशासक व्यक्तिगत Spaces के साझा करने को बंद कर सकता है। इसलिए यदि आप अपना खुद का खाता उपयोग कर रहे हैं, तो यह ऐसे Copilot Space को साझा करने की आपकी क्षमता को प्रभावित कर सकता है जो एंटरप्राइज़ की रिपॉज़िटरीज़ का उपयोग नहीं करता।

सेटअप के बाद, प्रशासकों को व्यावहारिक प्रॉम्प्ट्स के साथ Space का परीक्षण करना चाहिए।

उदाहरण के लिए:

How does our authentication middleware handle token refresh logic?

या:

Show me an example of how our backend services structure database migrations.

यदि Copilot सटीक जवाब नहीं दे पाता, तो आमतौर पर समस्या इन में से किसी एक की होती है:

• रिपॉज़िटरीज़ का अभाव
• खराब प्रलेखन गुणवत्ता
• गलत अनुमतियाँ
• अपर्याप्त इंडेक्सिंग समय

शेयरिंग और एक्सेस नियंत्रण

Spaces दो मुख्य दृश्यता मॉडल का समर्थन करते हैं:

• व्यक्तिगत Spaces
• संगठन-व्यापी Spaces

एंटरप्राइज़ के सदस्य अपनी व्यक्तिगत स्पेसेज़ को बड़े एंटरप्राइज़ सेटिंग्स द्वारा मैनेज करा सकते हैं। एंटरप्राइज़ एडमिन्स पूर्वावलोकन और फ़ीचर उपलब्धता नीतियों को भी केंद्रीकृत रूप से प्रबंधित कर सकते हैं। 

प्राइवेट Spaces प्रयोगात्मक टीमों या संवेदनशील आंतरिक पहल के लिए अच्छी तरह काम करते हैं। संगठन-व्यापी Spaces इंजीनियरिंग मानकों, ऑनबोर्डिंग प्रलेखन, या कंपनी-व्यापी फ़्रेमवर्क्स के लिए उपयुक्त हैं।

एक आम गलती जो मैं अक्सर देखता हूँ, वह है अतिसंकेन्द्रीयकरण। एक ही, बहुत बड़ा कंपनी-व्यापी Space शोरगुल वाला हो सकता है और Copilot के लिए प्रभावी ढंग से उपयोग करना कठिन बना सकता है।

टीम या डोमेन के अनुसार Spaces को व्यवस्थित करना

कोई एक सार्वभौमिक रूप से सही संगठनात्मक संरचना नहीं है।

आम पैटर्न में प्रति टीम एक स्पेस, प्रति प्रोडक्ट क्षेत्र एक स्पेस, या साझा मानक स्पेस शामिल हैं। प्रत्येक का दायरा अलग होता है और मूल रूप से वही सेटिंग्स स्पेस अलग तरह से उपयोग करता है।

प्रति टीम एक Space

जब इंजीनियरिंग समूह अपेक्षाकृत स्वतंत्र रूप से काम करते हैं तो उपयोगी।

उदाहरण:

• प्लेटफ़ॉर्म इंजीनियरिंग
• डेटा इंजीनियरिंग
• मोबाइल डेवलपमेंट

प्रति प्रोडक्ट क्षेत्र एक Space

जब संगठन विभागों के बजाय प्रोडक्ट्स के आसपास संरचित हों तो उपयोगी।

उदाहरण:

• Payments
• Analytics
• Infrastructure
• Customer platform

साझा मानक Space

कई संगठन निम्न के लिए एक अलग साझा स्पेस बनाए रखते हैं:

• सुरक्षा दिशा-निर्देश
• कोडिंग कन्वेंशंस
• डिप्लॉयमेंट वर्कफ़्लो
• आर्किटेक्चर मानक

व्यवहार में, हाइब्रिड तरीके अक्सर सबसे अच्छे काम करते हैं। हर टीम को अपना स्पेस मिल सकता है, जबकि बड़े मानक स्पेसेज़ टीमों के बीच साझा किए जाते हैं।

Copilot Usage Metrics API

Spaces संदर्भ की समस्या हल करते हैं। Usage Metrics API मापन की समस्या हल करता है। इसने कई पुराने टेलीमेट्री सिस्टम्स को प्रतिस्थापित किया जिन्हें GitHub ने 2026 API समेकन के दौरान सेवानिवृत्त कर दिया। 

स्पष्ट माप के बिना, संगठन जल्दी ही इस दृश्यता को खो देते हैं कि Copilot अपनाना सफल हो रहा है या नहीं। नेतृत्व यह साक्ष्य चाहता है कि निवेश डेवलपर वर्कफ़्लो में सुधार कर रहा है, न कि केवल एक और सब्सक्रिप्शन लाइन आइटम जोड़ रहा है।

डैशबोर्ड फरवरी 2026 में सामान्य उपलब्धता में पहुँचा और आपके एंटरप्राइज़ अकाउंट → AI Controls → Copilot → Metrics → Insights टैब में Copilot usage metrics के माध्यम से सुलभ है।

github.blog से Copilot Usage Metrics डैशबोर्ड उदाहरण

API क्या मापता है

Usage Metrics API कई श्रेणियों की परिचालन टेलीमेट्री उजागर करता है।

आम मेट्रिक्स में शामिल हैं:

• सक्रिय उपयोगकर्ता
• सुझाए गए कोड की पंक्तियाँ बनाम स्वीकृत पंक्तियाँ
• IDE उपयोग पैटर्न
• मॉडल उपयोग
• एजेंट इंटरैक्शन
• भाषा ब्रेकडाउन

यह संगठनों को साधारण सीट काउंट्स की तुलना में अधिक सूक्ष्म तस्वीर देता है।

100 असाइन की गई सीटों वाली टीम लेकिन केवल 15 सक्रिय उपयोगकर्ता, उस टीम से बहुत अलग अपनाने की प्रोफ़ाइल रखती है जिसमें लगातार दैनिक उपयोग और उच्च स्वीकृति दरें हैं।

2026 API ट्रांज़िशन

GitHub ने 2025 से 2026 के संक्रमण काल के दौरान कई पहले के टेलीमेट्री APIs (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) को रिटायर कर दिया, और अप्रैल 2026 तक उन्हें पूरी तरह सनसेट कर दिया।

इनमें शामिल थे:

• लीगेसी Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

नए Usage Metrics एंडपॉइंट्स, जो फरवरी 2026 से उपलब्ध हैं, ने उन रिपोर्टिंग सिस्टम्स को एक अधिक एकीकृत मॉडल में समेकित किया, जिसमें ब्रेकिंग परिवर्तनों की स्थिति में इन APIs का वर्शनिंग शामिल है।

यह इसलिए महत्वपूर्ण है क्योंकि कई पुराने ब्लॉग पोस्ट और GitHub उदाहरण अब भी अप्रचलित एंडपॉइंट्स का संदर्भ देते हैं। जब भी आप Usage Metrics API के साथ काम करें, ऑटोमेशन बनाने से पहले हमेशा GitHub के नवीनतम API संदर्भों के साथ प्रलेखन की पुष्टि करें।

Usage Metrics API को क्वेरी करना

अब जब हम usage metrics API के उद्देश्य को समझ गए हैं, तो बात करते हैं कि हम इसे व्यवहार में कैसे उपयोग करते हैं।

प्रमाणीकरण और अनुमतियाँ

GitHub Copilot Usage Metrics एंडपॉइंट्स आम तौर पर आपके Personal Access Token (PAT) के लिए कुछ अनुमतियाँ सेट करने की आवश्यकता रखते हैं। यह क्लासिक PAT या फ़ाइन-ग्रेन्ड PAT, दोनों के माध्यम से किया जा सकता है।

• क्लासिक PATs के लिए, आपको अपने एंटरप्राइज़ एडमिन से निम्न अनुमतियाँ दिलवानी होंगी: manage_billing:copilot और read:org। 

• फ़ाइन-ग्रेन्ड एक्सेस टोकन्स के लिए, सुनिश्चित करें कि आप GitHub ऐप यूज़र एक्सेस टोकन या इंस्टॉलेशन एक्सेस टोकन का उपयोग कर रहे हैं, जिसमें Enterprise Copilot metrics enterprise permissions (read) परमिशन सेट हो।

आम तौर पर, फ़ाइन-ग्रेन्ड टोकन्स का उपयोग वरीय होता है क्योंकि वे अनावश्यक अनुमति एक्सपोज़र को कम करते हैं।

संगठन-स्तरीय एंडपॉइंट्स

दो सबसे आम संगठन-स्तरीय रिपोर्ट्स हैं:

• organization-1-day

• organization-28-day

वन-डे संगठन-स्तरीय रिपोर्ट

वन-डे रिपोर्ट परिचालन मॉनिटरिंग और अल्पकालिक रुझान विश्लेषण के लिए अच्छी है। ऐतिहासिक डेटा 10 अक्टूबर, 2025 तक उपलब्ध है, और वर्तमान तिथि से एक वर्ष तक एक्सेस किया जा सकता है।

नीचे दिया गया curl कमांड वन-डे रिपोर्ट मेट्रिक API को कॉल करेगा और उपयोग रिपोर्ट्स के डाउनलोड लिंक के साथ JSON प्रतिक्रिया लौटाएगा। आपको bearer auth के लिए YOUR_TOKEN शामिल करना होगा और रिपोर्ट के लिए इच्छित DAY को YYYY-MM-DD फ़ॉर्मेट में चुनना होगा।

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

download_links के अंदर URLs साइन किए हुए और समय-सीमित होते हैं, यानी वे प्राप्ति के तुरंत बाद समाप्त हो जाते हैं। आपके वर्कफ़्लो को डाउनलोड URL फ़ेच करना होगा और उसी रन में तुरंत फ़ाइल खींचनी होगी; आप इन URLs को बाद के लिए स्टोर नहीं कर सकते।

आपको मिलने वाली प्रतिक्रिया में केवल download_links और report_day हो सकते हैं, लेकिन यह पूर्ण संभावित स्कीमा है:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28-दिवसीय संगठन-स्तरीय रिपोर्ट

28-दिवसीय रिपोर्ट व्यापक अपनाने के पैटर्न और दीर्घकालिक उपयोग परिवर्तनों की पहचान करने में मदद करती है। कमांड बहुत समान हैं, बस 28-दिवसीय API का उपयोग करने के लिए एक छोटा-सा बदलाव है।

उदाहरण अनुरोध:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

आपको समान प्रतिक्रिया मिलेगी, फर्क सिर्फ इतना होगा कि उसमें response_start_day और response_end_day होगा।

संगठन-स्तरीय रिपोर्ट संरचना

संगठनात्मक वन-डे और 28-दिवसीय दोनों रिपोर्ट्स के लिए JSON कुछ इस तरह दिख सकता है:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

जैसा कि आप देख सकते हैं, यह आपको किसी विशेष संगठन के भीतर उपयोगकर्ताओं, उनकी टीम और उनकी टीम टैग्स का उच्च-स्तरीय अवलोकन देता है। 

यूज़र-स्तरीय एंडपॉइंट्स

यूज़र-स्तरीय रिपोर्ट्स अधिक सूक्ष्म अपनाने की दृश्यता प्रदान करती हैं। इसका मतलब है कि आप उच्च स्तर पर समझ सकते हैं कि व्यक्ति Copilot का उपयोग कैसे कर रहे हैं।

आम एंडपॉइंट्स में शामिल हैं:

• users-1-day

• users-28-day

• user-teams-1-day

ये रिपोर्ट्स प्रशासकों को निम्न की पहचान करने में मदद करती हैं:

• अत्यंत सक्रिय उपयोगकर्ता
• कम अपनाने वाली टीमें
• प्रशिक्षण के अवसर
• विभाग-स्तरीय उपयोग रुझान

ये अनुरोध संगठन-स्तरीय वन-डे और 28-दिवसीय रिपोर्ट्स के बहुत समान हैं; वे बस अलग API की ओर इशारा करते हैं।

वन-डे यूज़र-स्तरीय रिपोर्ट

उदाहरण users-1-day API कॉल:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28-दिवसीय यूज़र-स्तरीय रिपोर्ट

उदाहरण users-28-day API कॉल:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

वन-डे यूज़र-टीम्स-स्तरीय रिपोर्ट

एक user-teams-1-day एंडपॉइंट भी मौजूद है, जो प्रत्येक उपयोगकर्ता को उनकी टीम सदस्यताओं से मैप करता है। इसमें स्वयं कोई उपयोग मेट्रिक्स नहीं होते; इसका उद्देश्य तब जॉइन की के रूप में काम करना है जब आप टीम द्वारा प्रति-उपयोगकर्ता डेटा को एकत्र करना चाहें।

यूज़र-स्तरीय रिपोर्ट संरचना

इन रिपोर्ट्स के अंदर विवरण का स्तर कहीं अधिक है, क्योंकि वे किसी विशेष उपयोगकर्ता के उपयोग डेटा की ओर संकेत करती हैं:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

ये मेट्रिक्स टीम-स्तरीय अपनाने के संकेत के रूप में सबसे मूल्यवान हैं। स्वीकृति दरें और उपयोग गणना परिचालन संकेतक हैं, न कि डेवलपर गुणवत्ता के मापन।

आप किन-किन संभावित मेट्रिक्स को देख सकते हैं, उसकी पूरी सूची के लिए GitHub usage metrics डेटा प्रलेखन देखें, जहाँ नवीनतम मापे गए मेट्रिक्स उपलब्ध हैं।

यूज़र-स्तरीय रिपोर्ट्स में CLI इंटरैक्शन डेटा शामिल होता है। यदि आपकी टीमें कमांड लाइन के माध्यम से Copilot का उपयोग करती हैं, तो हमारा GitHub Copilot CLI Tutorial setup और सामान्य वर्कफ़्लो कवर करता है।

Copilot रिपोर्टिंग वर्कफ़्लो बनाना

मैन्युअल रूप से API कॉल करना प्रयोग और स्कीमा समझने के लिए उपयोगी है। क्रियान्वयन योग्य होने के लिए, एक स्वचालित वर्कफ़्लो बनाना बेहतर है।

Copilot Enterprise से सबसे अधिक मूल्य पाने वाली टीमें आमतौर पर हल्की-फुल्की रिपोर्टिंग पाइपलाइन्स बनाती हैं जो उपयोग टेलीमेट्री को आंतरिक इंजीनियरिंग मेट्रिक्स के साथ संयोजित करती हैं।

ROI सिद्ध करने के लिए प्रमुख मेट्रिक्स

हर Copilot मेट्रिक समान रूप से महत्वपूर्ण नहीं होता। सबसे उपयोगी मेट्रिक्स में आमतौर पर ये शामिल होते हैं:

• सक्रिय उपयोगकर्ता वृद्धि
• स्वीकृति दर रुझान
• सुझाए गए बनाम बनाए रखे गए कोड
• PR साइकल टाइम में सुधार
• IDE एंगेजमेंट की आवृत्ति

GitHub ने निम्न जैसे बेंचमार्क प्रकाशित किए हैं:

• 55% तेज़ टास्क पूर्णता
• 88% कोड रिटेंशन दरें

ये आँकड़े उल्लेखनीय उत्पादकता सुधार दिखाते हैं। आपके परिणाम टीम और वर्कफ़्लो के अनुसार बदलेंगे—यही कारण है कि Usage Metrics API मौजूद है। एक बैकएंड इन्फ्रास्ट्रक्चर टीम, फ्रंटएंड प्रोटोटाइपिंग टीम से अलग तरीके से Copilot से इंटरैक्ट कर सकती है।

कच्चे डेटा से टीम डैशबोर्ड तक

एक हल्का रिपोर्टिंग वर्कफ़्लो अक्सर इस तरह दिखता है:

1. निर्धारित API कॉल
2. प्रतिक्रियाएँ डेटाबेस या स्प्रेडशीट में स्टोर करें
3. डेटा को रिपोर्टिंग टेबल्स में ट्रांसफॉर्म करें
4. मौजूदा BI प्लेटफ़ॉर्म में मेट्रिक्स को विज़ुअलाइज़ करें

स्वयं स्टैक से ज़्यादा महत्त्व निरंतरता का है।

यहाँ तक कि निर्धारित Python स्क्रिप्ट्स और CSV एक्सपोर्ट्स का एक सरल वर्कफ़्लो भी उपयोगी परिचालन दृश्यता दे सकता है।

उदाहरण आर्किटेक्चर:

GitHub API

  ↓

निर्धारित Python स्क्रिप्ट

  ↓

PostgreSQL / CSV / स्प्रेडशीट

  ↓

Power BI / Tableau / Looker

अंतिम विचार

GitHub Copilot Enterprise वास्तव में आपके AI-तैयार कोड के लिए अवसंरचना बनाने के बारे में है। Spaces वह संगठनात्मक संदर्भ प्रदान करते हैं जो वास्तविक इंजीनियरिंग परिवेश में Copilot को अधिक उपयोगी बनाता है। Usage Metrics API वह टेलीमेट्री प्रदान करता है जो यह समझने के लिए आवश्यक है कि अपनाना सफल हो रहा है या नहीं।

वे संगठन जो Copilot Enterprise से सबसे मज़बूत परिणाम प्राप्त कर रहे हैं, आम तौर पर एक सामान्य पैटर्न साझा करते हैं:

• वे आंतरिक संदर्भ को सावधानी से क्यूरेट करते हैं
• वे अपनाने की निरंतर निगरानी करते हैं
• वे Copilot गवर्नेंस को गंभीरता से लेते हैं
• वे उत्पादकता लाभ मान लेने के बजाय परिणामों को मापते हैं

यह मानसिकता महज़ सीटें असाइन करने की तुलना में कहीं अधिक मायने रखती है।

यदि आप अपनी Copilot और AI कौशल को गहरा करना चाहते हैं, तो मैं हमारा Software Development with GitHub Copilot कोर्स या पूरा AI for Software Engineering स्किल ट्रैक लेने की सलाह देता हूँ।