GitHub Copilot Enterprise: Panduan untuk 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. Ini dirancang untuk perusahaan yang mengoperasikan lingkungan engineering berskala besar, bukan untuk developer individu atau tim kecil.

Dua kapabilitas yang paling penting dalam praktiknya:

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

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

Perusahaan yang memperoleh nilai paling besar 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 gambaran yang lebih luas tentang ekosistem GitHub, saya sarankan membaca panduan kami Pengantar Produk GitHub.

Perbedaan Enterprise dengan Business dan Pro+

GitHub Copilot Enterprise memperluas langganan Business dengan fitur tambahan seperti:

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

Enterprise memerlukan GitHub Enterprise Cloud selain langganan Copilot Enterprise itu sendiri. Ini menambah biaya per pengguna, jadi pastikan organisasi Anda memang membutuhkan 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 seluruh 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 meliputi:

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

Perlu dicatat bahwa ini tidak serta merta meningkatkan performa Copilot. Menurut saya, pembedaan ini penting karena banyak tim awalnya membeli berlebihan. Mereka menganggap Enterprise sama dengan “Copilot yang lebih baik,” padahal kenyataannya Enterprise terutama menambahkan peranti tata kelola dan pengukuran.

Copilot Spaces: Konteks Kustom untuk Organisasi Anda

Copilot Spaces menyelesaikan salah satu kelemahan terbesar pada asisten coding AI yang bersifat umum.

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

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

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 rentang konten organisasi yang lebih luas dibandingkan sistem Knowledge Bases yang lebih 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 menyediakan penjelasan arsitektur dan panduan onboarding. Pull request membuka akses ke diskusi review dan keputusan engineering historis. Kombinasi tersebut memberikan Copilot kesadaran yang lebih baik tentang praktik pengembangan di organisasi Anda.

Satu poin yang halus tetapi penting adalah bahwa Spaces bukan sekadar basis data vektor yang ditempelkan ke GitHub. Spaces menyertakan kontrol berbagi dan alur kerja tata kelola organisasi yang dirancang untuk lingkungan enterprise.

Penghentian Knowledge Bases

GitHub menghentikan fitur Copilot Knowledge Bases yang 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 lawas yang merujuk ke 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 mengelola puluhan atau ratusan Spaces di berbagai tim.

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

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

Menyiapkan sebuah Space

Membuat Space umumnya mengikuti alur kerja berikut:

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

3. Pilih repository 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 chat

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

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

Misalnya:

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, biasanya masalahnya adalah salah satu dari:

• Repository yang kurang
• Kualitas dokumentasi buruk
• Izin yang salah
• Waktu pengindeksan tidak memadai

Berbagi dan kontrol akses

Spaces mendukung dua model visibilitas utama:

• Individual Spaces
• Organization-wide Spaces

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

Private Spaces cocok untuk tim eksperimental atau inisiatif internal yang sensitif. Organization-wide Spaces masuk akal untuk standar engineering, dokumentasi onboarding, atau kerangka kerja perusahaan secara luas.

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

Mengorganisasi Spaces berdasarkan 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 secara berbeda.

Satu Space per tim

Berguna saat grup engineering beroperasi relatif independen.

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 mempertahankan Space terpisah yang dibagikan untuk:

• Panduan keamanan
• Konvensi penulisan kode
• Alur kerja deployment
• Standar arsitektur

Dalam praktiknya, pendekatan hibrida biasanya paling berhasil. Setiap tim bisa mendapatkan space sendiri, dengan space standar yang lebih besar dibagikan di antara 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 tahun 2026. 

Tanpa pengukuran yang jelas, organisasi dengan cepat kehilangan visibilitas apakah adopsi Copilot berhasil. Pimpinan membutuhkan bukti bahwa investasi tersebut meningkatkan alur kerja developer, bukan sekadar menambah item langganan baru.

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

Contoh Copilot Usage Metrics Dashboard dari github.blog

Apa yang diukur oleh API

Usage Metrics API mengekspos beberapa kategori telemetri operasional.

Metrik umum meliputi:

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

Ini memberikan gambaran yang jauh lebih bernuansa daripada sekadar jumlah kursi.

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

Transisi API 2026

GitHub menghentikan beberapa 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 melakukan versioning pada API ini jika terjadi perubahan yang memutus kompatibilitas.

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

Melakukan Query ke Usage Metrics API

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

Autentikasi dan izin

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 dengan akses terperinci (fine-grained).

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

• Untuk token akses fine-grained, Anda harus memastikan menggunakan GitHub app user access token atau installation access token dengan set izin Enterprise Copilot metrics enterprise permissions (read).

Biasanya, penggunaan token fine-grained 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 menyertakan YOUR_TOKEN untuk bearer auth dan memilih DAY untuk hari spesifik yang Anda inginkan 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 berbatas waktu, yang berarti akan kedaluwarsa segera setelah diambil. Alur kerja Anda harus mengambil URL unduhan dan langsung menarik file pada run yang sama; Anda tidak dapat menyimpan URL tersebut untuk digunakan nanti.

Respons yang Anda dapatkan mungkin hanya berisi download_links dan report_day, tetapi ini adalah skema lengkap yang memungkinkan:

{
  "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 yang serupa, kecuali akan ada response_start_day dan response_end_day.

Struktur laporan tingkat organisasi

Laporan JSON untuk laporan satu hari dan 28 hari tingkat organisasi 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 terlihat, ini memberi Anda 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 level yang sangat tinggi.

Endpoint umum meliputi:

• 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 di tingkat departemen

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

Laporan tingkat pengguna satu hari

Contoh pemanggilan 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 pemanggilan 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 tersedia, yang memetakan setiap pengguna ke keanggotaan tim mereka. Endpoint ini tidak berisi metrik penggunaan; tujuannya adalah berfungsi sebagai kunci penghubung saat Anda ingin mengagregasi data per pengguna berdasarkan tim.

Struktur laporan tingkat pengguna

Tingkat detail di dalam laporan ini jauh lebih tinggi, mengingat laporan ini mengarah 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 berharga sebagai sinyal adopsi tingkat tim. Tingkat penerimaan dan jumlah penggunaan adalah sinyal operasional, bukan pengukuran kualitas developer.

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

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

Membangun Alur 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 paling besar dari Copilot Enterprise biasanya membangun pipeline pelaporan ringan yang menggabungkan telemetri penggunaan dengan metrik engineering internal.

Metrik kunci untuk membuktikan ROI

Tidak semua metrik Copilot sama pentingnya. Metrik yang paling berguna biasanya 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, yang menjadi alasan tepat mengapa 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 yang ringan sering kali terlihat seperti ini:

1. Pemanggilan API terjadwal
2. Menyimpan respons di database atau spreadsheet
3. Mengonversi data menjadi tabel pelaporan
4. Memvisualisasikan metrik di platform BI yang sudah ada

Teknologinya sendiri kurang penting dibanding konsistensinya.

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

Contoh arsitektur:

GitHub API

  ↓

Skrip Python Terjadwal

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Penutup

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

Organisasi yang memperoleh hasil terkuat dari Copilot Enterprise cenderung memiliki pola umum:

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

Pola pikir itu 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.