GitHub Copilot Enterprise: Panduan Spaces dan Usage Metrics API

Apa Itu GitHub Copilot Enterprise?

GitHub Copilot Enterprise berada di puncak hierarki paket Copilot GitHub.

Dibandingkan dengan GitHub Copilot Business atau Pro+, Enterprise sangat berfokus pada tata kelola, konteks organisasi, dan kapabilitas pengukuran. Paket ini dirancang untuk perusahaan yang mengoperasikan lingkungan rekayasa berskala besar, bukan untuk pengembang individu atau tim kecil.

Dua kapabilitas yang paling penting dalam praktiknya:

1. Konteks organisasi kustom melalui Spaces
2. Telemetri tingkat organisasi melalui Usage Metrics API

Kedua fitur tersebut menggeser Copilot dari sekadar “pelengkap pintar” menjadi sesuatu yang lebih mendekati platform AI rekayasa internal.

Perusahaan yang memperoleh nilai terbesar dari GitHub Copilot Enterprise memperlakukannya sebagai komponen kunci infrastruktur internal. Mereka mengonfigurasi konteks organisasi dengan cermat, mengukur adopsi secara berkelanjutan, dan menyesuaikan kebijakan berdasarkan data penggunaan, bukan asumsi.

Untuk tinjauan lebih luas tentang ekosistem GitHub, saya sarankan membaca panduan kami Pengantar Produk GitHub.

Perbedaan Enterprise dengan Business dan Pro+

GitHub Copilot Enterprise mengembangkan langganan Business dengan fitur tambahan seperti:

• Metri penggunaan tingkat organisasi
• Kontrol tata kelola yang diperluas
• Pewarisan kebijakan di seluruh perusahaan
• Alokasi permintaan premium yang lebih besar (1.000 vs 300 pada tingkat Business)
• Akses dan manajemen model tambahan

Enterprise memerlukan GitHub Enterprise Cloud selain langganan Copilot Enterprise itu sendiri. Ini menambah biaya per pengguna, jadi pastikan organisasi Anda benar-benar memerlukan tata kelola, telemetri, dan administrasi tingkat enterprise.

Catatan: Pelanggan Business mengakses Usage Metrics API di tingkat organisasi (/orgs/{org}/…). Pelanggan Enterprise juga mengakses laporan agregat tingkat enterprise (/enterprises/{enterprise}/…) yang mencakup semua organisasi dalam satu tampilan.

Untuk siapa GitHub Copilot Enterprise

GitHub Copilot Enterprise menargetkan organisasi yang sudah mengoperasikan lingkungan GitHub yang matang.

Pelanggan Enterprise yang umum mencakup:

• Organisasi rekayasa berskala besar
• Industri teregulasi
• Kelompok platform engineering multi-tim
• Perusahaan dengan standar pengembangan internal
• Organisasi yang memerlukan tata kelola terpusat

Perlu dicatat bahwa ini tidak secara inheren meningkatkan kinerja Copilot. Menurut saya perbedaan ini penting karena banyak tim awalnya membeli berlebihan. Mereka berasumsi Enterprise sama dengan “Copilot yang lebih baik,” padahal kenyataannya Enterprise terutama menambahkan perangkat tata kelola dan pengukuran.

Copilot Spaces: Konteks Kustom untuk Organisasi Anda

Copilot Spaces mengatasi salah satu kelemahan terbesar pada asisten pengodean AI yang bersifat umum.

Secara default, Copilot memahami pengetahuan pemrograman publik dengan cukup baik. Copilot tidak otomatis memahami API internal Anda, keputusan arsitektur, konvensi pengodean, alur kerja deployment, atau dokumentasi onboarding Anda.

Spaces menyediakan konteks organisasi terkurasi yang dapat dirujuk Copilot selama percakapan dan bantuan pengodean.

Secara praktis, Spaces membantu Copilot menjawab pertanyaan seperti:

• “Bagaimana kami menstrukturkan handler API secara internal?”
• “Library autentikasi apa yang direkomendasikan tim platform kami?”
• “Alur kerja deployment mana yang harus digunakan microservice ini?”
• “Konvensi penamaan apa yang diikuti tim backend kami?”

Dukungan yang diberikan Spaces

Spaces mendukung cakupan konten organisasi yang lebih luas dibandingkan sistem Knowledge Bases yang lama.

Jenis konten yang didukung meliputi:

• Berkas kode
• Dokumentasi Markdown
• Berkas JSON
• Berkas yang diunggah
• Gambar
• GitHub Issues
• Pull request

Setiap jenis konten berkontribusi secara berbeda.

Berkas kode membantu Copilot memahami pola implementasi. Berkas Markdown memberikan penjelasan arsitektur dan panduan onboarding. Pull request menampilkan diskusi ulasan dan keputusan rekayasa historis. Kombinasi tersebut memberi Copilot kesadaran yang lebih baik terhadap praktik pengembangan organisasi Anda.

Satu poin yang halus namun penting adalah Spaces bukan sekadar basis data vektor yang disematkan ke GitHub. Spaces mencakup kontrol berbagi dan alur kerja tata kelola organisasi yang dirancang untuk lingkungan enterprise.

Sunset Knowledge Bases

GitHub menghentikan fitur Copilot Knowledge Bases lama pada 1 November 2025.

Spaces menggantikan Knowledge Bases dengan:

• Dukungan konten yang lebih luas
• Kontrol berbagi yang lebih baik
• Peningkatan administrasi
• Manajemen tingkat organisasi yang lebih fleksibel

Anda masih akan menemukan dokumentasi dan posting blog usang yang merujuk Knowledge Bases. Berhati-hatilah saat mengikuti tutorial lama karena banyak endpoint dan alur kerja yang berubah selama periode transisi 2025 hingga 2026.

Membuat dan Mengonfigurasi Copilot Spaces

Dari perspektif administrasi, Copilot Spaces cukup mudah dibuat. Tantangannya muncul saat mengelolanya dalam jumlah puluhan atau ratusan di seluruh tim.

Struktur yang Anda pilih di awal cenderung menetap. Saya telah melihat organisasi tanpa sengaja menciptakan “kekacauan dokumentasi” di dalam Spaces karena tidak ada yang menetapkan aturan kepemilikan sejak awal.

Siapa pun dapat membuat Copilot Space, jadi mari kita coba membuatnya di repo pribadi kita. Langkah-langkah ini serupa di tingkat Enterprise, dengan beberapa halaman yang berbeda.

Menyiapkan sebuah Space

Membuat sebuah Space umumnya mengikuti alur kerja ini:

1. Arahkan ke halaman Copilot Spaces di area administrasi Enterprise Anda
2. Buat Space baru

3. Pilih repositori dan sumber konten, termasuk MCP dan alat berguna lainnya

4. Penambahan sumber dapat dilakukan dengan mengklik tombol “+ Add sources” di sisi kanan

5. Anda dapat memilih untuk membagikan space atau mengatur pengaturan berbagi pada tahap ini

6. Verifikasi bahwa Copilot dapat merujuk konten selama interaksi percakapan

Catatan untuk pengguna enterprise: administrator Anda dapat mematikan pembagian Spaces pribadi. Jadi jika Anda menggunakan akun sendiri, hal itu dapat memengaruhi kemampuan Anda untuk membagikan Copilot Space yang tidak menggunakan repositori milik enterprise.

Setelah penyiapan, administrator harus menguji Space dengan prompt yang praktis.

Sebagai contoh:

How does our authentication middleware handle token refresh logic?

Atau:

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

Jika Copilot tidak dapat menjawab dengan akurat, masalahnya biasanya salah satu dari:

• Repositori yang hilang
• Kualitas dokumentasi yang buruk
• Perizinan yang tidak tepat
• Waktu pengindeksan yang belum cukup

Berbagi dan kontrol akses

Spaces mendukung dua model visibilitas utama:

• Individual Spaces
• Organization-wide Spaces

Anggota suatu enterprise dapat memiliki space individual mereka yang dikelola oleh pengaturan enterprise yang lebih besar. Admin enterprise juga dapat mengelola secara terpusat kebijakan pratinjau dan ketersediaan fitur. 

Spaces privat cocok untuk tim eksperimental atau inisiatif internal yang sensitif. Spaces seluruh organisasi masuk akal untuk standar rekayasa, dokumentasi onboarding, atau kerangka kerja perusahaan yang digunakan bersama.

Salah satu kesalahan yang sering saya lihat adalah terlalu memusatkan. Satu Space perusahaan yang sangat besar dapat menjadi bising dan sulit digunakan Copilot secara efektif.

Mengorganisasi Spaces per tim atau domain

Tidak ada struktur organisasi yang benar secara universal.

Pola umum mencakup satu space per tim, satu space per area produk, atau space standar bersama. Masing-masing memiliki cakupan berbeda dan pada dasarnya menggunakan pengaturan space yang sama dengan cara yang berbeda.

Satu Space per tim

Berguna ketika kelompok rekayasa beroperasi relatif mandiri.

Contoh:

• Platform engineering
• Data engineering
• Pengembangan mobile

Satu Space per area produk

Berguna untuk organisasi yang terstruktur berdasarkan produk alih-alih departemen.

Contoh:

• Pembayaran
• Analitik
• Infrastruktur
• Platform pelanggan

Space standar bersama

Banyak organisasi memelihara Space bersama terpisah untuk:

• Panduan keamanan
• Konvensi pengodean
• Alur kerja deployment
• Standar arsitektur

Dalam praktiknya, pendekatan hibrida biasanya bekerja paling baik. Setiap tim mungkin mendapatkan space sendiri, dengan space standar yang lebih besar dibagikan di antara tim-tim.

Copilot Usage Metrics API

Spaces menyelesaikan masalah konteks. Usage Metrics API menyelesaikan masalah pengukuran. API ini menggantikan beberapa sistem telemetri lama yang dihentikan GitHub selama konsolidasi API 2026. 

Tanpa pengukuran yang jelas, organisasi cepat kehilangan visibilitas apakah adopsi Copilot berhasil. Pimpinan menginginkan bukti bahwa investasi tersebut meningkatkan alur kerja pengembang, bukan sekadar menambah satu baris langganan lagi.

Dasbor ini mencapai ketersediaan umum pada Februari 2026 dan dapat diakses melalui akun enterprise Anda → AI Controls → Copilot → Metrics → Copilot usage metrics pada tab Insights.

Contoh Copilot Usage Metrics Dashboard dari github.blog

Apa yang diukur API

Usage Metrics API memaparkan beberapa kategori telemetri operasional.

Metri umum meliputi:

• Pengguna aktif
• Baris kode yang disarankan vs Baris kode yang diterima
• Pola penggunaan IDE
• Penggunaan model
• Interaksi agen
• Rincian bahasa

Ini memberi organisasi gambaran yang jauh lebih bernuansa dibanding hitungan kursi sederhana.

Sebuah tim dengan 100 kursi yang ditetapkan tetapi hanya 15 pengguna aktif memiliki profil adopsi yang sangat berbeda dari tim dengan penggunaan harian yang konsisten dan tingkat penerimaan yang tinggi.

Transisi API 2026

GitHub menghentikan banyak API telemetri sebelumnya (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) selama periode transisi 2025 hingga 2026, dengan penghentian penuh pada April 2026.

Ini mencakup:

• Legacy Metrics API
• Feature Engagement API
• Direct Data Access API

Endpoint Usage Metrics yang lebih baru, tersedia sejak Februari 2026, mengonsolidasikan sistem pelaporan tersebut ke dalam model yang lebih terpadu, termasuk versi API untuk mengantisipasi perubahan yang memutus kompatibilitas.

Ini penting karena banyak posting blog lama dan contoh GitHub masih merujuk endpoint yang sudah deprecated. Setiap kali Anda bekerja dengan Usage Metrics API, selalu verifikasi dokumentasi terhadap referensi API terbaru GitHub sebelum membangun otomatisasi di sekitarnya.

Melakukan Query ke Usage Metrics API

Sekarang setelah kita memahami tujuan usage metrics API, mari bahas bagaimana kita benar-benar menggunakannya dalam praktik.

Autentikasi dan perizinan

Endpoint GitHub Copilot Usage Metrics umumnya mengharuskan Anda menyiapkan beberapa izin untuk Personal Access Token (PAT) Anda. Ini dapat dilakukan melalui PAT klasik atau PAT bertingkat-halus (fine-grained).

• Untuk PAT klasik, Anda perlu meminta admin enterprise memberikan izin berikut: manage_billing:copilot dan read:org. 

• Untuk token akses bertingkat-halus, Anda harus memastikan menggunakan token akses pengguna aplikasi GitHub atau token akses instalasi dengan set izin Enterprise Copilot metrics enterprise permissions (read).

Biasanya, penggunaan token bertingkat-halus lebih disukai karena mengurangi paparan izin yang tidak perlu.

Endpoint tingkat organisasi

Dua laporan tingkat organisasi yang paling umum adalah:

• organization-1-day

• organization-28-day

Laporan tingkat organisasi satu hari

Laporan satu hari cocok untuk pemantauan operasional dan analisis tren jangka pendek. Data historis tersedia sejak 10 Oktober 2025, dan dapat diakses hingga satu tahun dari tanggal saat ini.

Perintah curl di bawah ini akan memanggil API metrik laporan satu hari dan mengembalikan respons JSON dengan tautan unduhan untuk laporan penggunaan. Anda harus memastikan untuk menyertakan YOUR_TOKEN untuk auth bearer dan memilih DAY untuk hari spesifik yang Anda inginkan untuk laporan dalam format 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"

URL dalam download_links ditandatangani dan dibatasi waktu, yang berarti akan kedaluwarsa segera setelah diambil. Alur kerja Anda harus mengambil URL unduhan dan segera menarik file dalam run yang sama; Anda tidak dapat menyimpan URL ini untuk digunakan nanti.

Respons yang Anda dapatkan mungkin hanya berisi download_links dan report_day, tetapi berikut skema potensial penuhnya:

{
  "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"
  ]
}

Laporan tingkat organisasi 28 hari

Laporan 28 hari membantu mengidentifikasi pola adopsi yang lebih luas dan perubahan penggunaan jangka panjang. Perintahnya sangat mirip, dengan sedikit perubahan untuk menggunakan API 28 hari.

Contoh permintaan:

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

Anda akan mendapatkan respons serupa, kecuali akan ada response_start_day dan response_end_day.

Struktur laporan tingkat organisasi

Laporan JSON untuk baik laporan organisasi satu hari maupun 28 hari mungkin terlihat seperti ini:

[
  {
    "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"
  }
]

Seperti yang Anda lihat, ini memberi gambaran tingkat tinggi tentang pengguna dalam organisasi tertentu, tim mereka, dan tag tim mereka. 

Endpoint tingkat pengguna

Laporan tingkat pengguna memberikan visibilitas adopsi yang lebih terperinci. Ini berarti Anda dapat memahami bagaimana individu menggunakan Copilot pada tingkat yang sangat tinggi.

Endpoint umum mencakup:

• users-1-day

• users-28-day

• user-teams-1-day

Laporan-laporan ini membantu administrator mengidentifikasi:

• Pengguna yang sangat aktif
• Tim dengan adopsi rendah
• Peluang pelatihan
• Tren penggunaan tingkat departemen

Permintaan ini sangat mirip dengan laporan satu hari dan 28 hari tingkat organisasi; hanya saja mengarah ke API yang berbeda.

Laporan tingkat pengguna satu hari

Contoh panggilan API users-1-day:

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"

Laporan tingkat pengguna 28 hari

Contoh panggilan API users-28-day:

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

Laporan tingkat user-teams satu hari

Endpoint user-teams-1-day juga ada, yang memetakan setiap pengguna ke keanggotaan tim mereka. Endpoint ini tidak memuat metrik penggunaan; tujuannya adalah berfungsi sebagai kunci join saat Anda ingin mengagregasi data per pengguna berdasarkan tim.

Struktur laporan tingkat pengguna

Tingkat detail di dalam laporan-laporan ini jauh lebih tinggi, mengingat laporan menunjuk pada data penggunaan pengguna tertentu:

[{
  "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
}]

Metrik ini paling bernilai sebagai sinyal adopsi tingkat tim. Tingkat penerimaan dan jumlah penggunaan adalah sinyal operasional, bukan pengukuran kualitas pengembang.

Untuk metrik potensial penuh yang mungkin Anda lihat, kunjungi dokumentasi data usage metrics GitHub untuk metrik terukur yang paling mutakhir.

Laporan tingkat pengguna mencakup data interaksi CLI. Jika tim Anda menggunakan Copilot melalui command line, Tutorial GitHub Copilot CLI kami membahas penyiapan dan alur kerja umum.

Membangun Alur Kerja Pelaporan Copilot

Memanggil API secara manual berguna untuk eksperimen dan memahami skema. Agar dapat ditindaklanjuti, lebih baik membuat alur kerja otomatis.

Tim yang memperoleh nilai terbesar dari Copilot Enterprise biasanya membangun pipeline pelaporan ringan yang menggabungkan telemetri penggunaan dengan metrik rekayasa internal.

Metrik kunci untuk membuktikan ROI

Tidak semua metrik Copilot sama pentingnya. Metrik yang paling berguna cenderung mencakup:

• Pertumbuhan pengguna aktif
• Tren tingkat penerimaan
• Kode yang disarankan versus yang dipertahankan
• Peningkatan waktu siklus PR
• Frekuensi keterlibatan IDE

GitHub telah menerbitkan tolok ukur seperti:

• 55% penyelesaian tugas lebih cepat
• 88% tingkat retensi kode

Angka-angka tersebut menunjukkan peningkatan produktivitas yang signifikan. Hasil Anda akan bervariasi menurut tim dan alur kerja, itulah tepatnya alasan Usage Metrics API ada. Tim infrastruktur backend mungkin berinteraksi dengan Copilot secara berbeda dari tim prototyping frontend.

Dari data mentah ke dasbor tim

Alur kerja pelaporan ringan sering kali terlihat seperti ini:

1. Panggilan API terjadwal
2. Simpan respons di basis data atau spreadsheet
3. Transformasi data menjadi tabel pelaporan
4. Visualisasikan metrik di platform BI yang sudah ada

Tumpukan teknologinya kurang penting dibanding konsistensinya.

Bahkan alur kerja sederhana yang menggunakan skrip Python terjadwal dan ekspor CSV pun dapat memberikan visibilitas operasional yang berguna.

Contoh arsitektur:

GitHub API

  ↓

Skrip Python Terjadwal

  ↓

PostgreSQL / CSV / Spreadsheet

 ↓

Power BI / Tableau / Looker

Pemikiran Akhir

GitHub Copilot Enterprise pada dasarnya adalah membangun infrastruktur Anda untuk kode yang siap AI. Spaces menyediakan konteks organisasi yang membuat Copilot lebih berguna di lingkungan rekayasa nyata. Usage Metrics API menyediakan telemetri yang diperlukan untuk memahami apakah adopsi berjalan sukses.

Organisasi yang mendapatkan hasil paling kuat dari Copilot Enterprise cenderung berbagi pola umum:

• Mereka mengkurasi konteks internal dengan cermat
• Mereka memantau adopsi secara berkelanjutan
• Mereka menempatkan tata kelola Copilot secara serius
• Mereka mengukur hasil alih-alih mengasumsikan peningkatan produktivitas

Pola pikir tersebut jauh lebih penting daripada sekadar menetapkan kursi.

Jika Anda ingin memperdalam keterampilan Copilot dan AI, saya sarankan mengikuti kursus Software Development with GitHub Copilot atau jalur keterampilan lengkap AI for Software Engineering.