Copilot Cloud Agent Metriği: Kullanımı Ölçmek Kolaylaştı

Q: API Çağrısı Nasıl Görünüyor?

Örnek bir API response'u kabaca böyle bir şeye benziyor: { "date": "2026-04-10", "total_active_users": 342, "daily_active_copilot_cloud_agent_users": 47, "weekly_active_copilot_cloud_agent_users": 128, "monthly_active_copilot_cloud_agent_users": 215, "monthly_active_agent_users": 189 } Burada monthly_active_agent_users IDE agent mode kullanıcılarını gösteriyor. Yeni eklenen monthly_active_copilot_cloud_agent_users işe bulut tarafındaki ajan kullanımına ait. İkisi farklı şeyler — biri IDE'd

⏱️ 8 dk okuma📅 11 Nisan 2026👁️ 1 görüntülenme

Bir süredir kafama takılan bir şey var: Enterprise seviyede Copilot kullanıyorsanız, kaç kişi bu “cloud agent” özelliğini gerçekten aktif olarak kullanıyor — bunu nasıl ölçüyorsunuz? Yöneticilere rapor sunma zamanı geldiğinde, “Copilot’a şu kadar para ödüyoruz, ama bunu kim kullanıyor ki?” sorusu mutlaka çıkıyor ortaya. Elinizde somut bir sayı olmadığında o toplantıda epeyce sıkışıyorsunuz. İşte tam bu noktada GitHub, beklediğimiz bir güncellemeyi sessiz sedasız yayınladı.

Copilot Usage Metrics API artık cloud agent aktif kullanıcı sayılarını toplu şekilde raporlayabiliyor. Günlük, haftalık ve aylık aktif kullanıcı sayıları için üç yeni alan eklendi. Kağıt üstünde bakınca küçük bir değişiklik gibi görünüyor — ama dur bir saniye, neden önemli olduğunu anlamak için biraz geriye gitmek lazım.

İsim Değişikliği Meselesi: Coding Agent mı, Cloud Agent mı?

Eh, GitHub, “Copilot coding agent” ismini “Copilot cloud agent” olarak değiştirdi. Geçen hafta dokümantasyona bakarken fark ettim bunu, “Ne zaman oldu bu?” dedim kendi kendime. Mevcut API şemalarındaki eski alan adları da önümüzdeki haftalarda güncellenecekmiş. Yanı otomasyon scriptleriniz varsa bu isimlendirme değişikliğini yakından takip etmeniz şart — yoksa bir gün API çağrılarınız boş dönmeye başlar, sız de kara kara “Ne oldu ya?” diye düşünürsünüz. Yaşanmış şeyler bunlar.

Bi saniye — İsim değişikliğinin arkasında aslında mantıklı bir neden var. “Coding agent” denince insanlar bunu yalnızca kod yazmayla ilişkilendiriyordu, hani otomatik olarak öyle bir çağrışım yapıyor. Oysa bu ajan çok daha geniş bir şey — pull request oluşturuyor, issue çözüyor, test yazıyor, bunların hepsini bulut tarafında otonom olarak yapıyor. “Cloud agent” ismi bence daha doğru bir tanım. Yine de geçiş döneminde dokümantasyonda bir karışıklık yaşanacağını şimdiden söyleyeyim, hazırlıklı olun.

İşte tam da bu noktada devreye giriyor.

Gelen Üç Yeni Alan Ne İşe Yarıyor?

API’ye eklenen bu alanlar hem 1 günlük hem de 28 günlük raporlarda, enterprise ve organization seviyesinde kullanılabiliyor. Tablo halinde göstereyim, böyle daha net oluyor:

Alan Adı	Ne Dönduruyor?
`daily_active_copilot_cloud_agent_users`	O gün cloud agent’ı kullanan benzersiz kullanıcı sayısı
`weekly_active_copilot_cloud_agent_users`	Son 7 günlük pencerede kullanan benzersiz kullanıcı sayısı
`monthly_active_copilot_cloud_agent_users`	Son 28 günlük pencerede kullanan benzersiz kullanıcı sayısı

Şunu atlamamak lazım: Bu alanlar nullable. Veri varsa sayıyı dönduruyor — sıfır dahil — yoksa null geliyor. Bu ayrım gerçekten önemli, çünkü sıfır ile null aynı şey değil. Sıfır “kimse kullanmamış” anlamına geliyor, null işe “bu dönem için cloud agent verisi hiç mevcut değil” demek. 2024’ün sonlarında bir müşteride buna benzer nullable bir alan yüzünden dashboard’lar yanlış grafik çiziyordu, hatayı bulmamız iki gün sürdü — o yüzden parse ederken dikkatli olun.

API Çağrısı Nasıl Görünüyor?

Örnek bir API response’u kabaca böyle bir şeye benziyor:

{
"date": "2026-04-10",
"total_active_users": 342,
"daily_active_copilot_cloud_agent_users": 47,
"weekly_active_copilot_cloud_agent_users": 128,
"monthly_active_copilot_cloud_agent_users": 215,
"monthly_active_agent_users": 189
}

Burada monthly_active_agent_users IDE agent mode kullanıcılarını gösteriyor. Yeni eklenen monthly_active_copilot_cloud_agent_users işe bulut tarafındaki ajan kullanımına ait. İkisi farklı şeyler — biri IDE’de lokal çalışıyor, diğeri GitHub’ın bulut altyapısında. Bu ayrımı görebilmek baya iş görüyor açıkçası.

Gerçek Hayatta Bu Neden Lazım?

Dürüst olayım. Bireysel geliştirici olarak bu metrikler size pek bir şey ifade etmeyebilir. Ama bir IT yöneticisi, bir FinOps uzmanı ya da enterprise admin olarak bakarsanız? Altın madeni (ki bu çoğu kişinin gözünden kaçıyor)

Geçtiğimiz ay bir finans kuruluşuyla oturuyorduk — 800’den fazla geliştirici lisansı almışlar Copilot Enterprise için, ciddi bir yatırım. CFO toplantıda direkt sormuş: “Bu yatırımın geri dönüşü ne?” İşte tam o anda elinizde bu tür metrikler olması gerekiyor, yoksa o soruya verecek somut bir cevabınız olmuyor. Daha öncesinde kullanıcı bazlı verileri tek tek toplayıp kendiniz aggregate etmeniz gerekiyordu — hem API rate limit’e takılıyordunuz hem de zahmetli bir işti bu.

Artık tek bir API çağrısıyla “Bu ay kaç kişi cloud agent kullanmış?” sorusunun cevabını alabiliyorsunuz. Basit ama güçlü.

Küçük bir detay: Ha, bir de şunu söleyeyim — bu metrikler yalnızca “kaç kişi kullanmış” sorusunu cevaplamıyor. Daha açık söyleyeyim, günlük, haftalık ve aylık sayıları yan yana koyarak adopsiyon trendlerini de görebiliyorsunuz. Mesela diyelim ki günlük aktif kullanıcı 20, ama aylık 200. Bu ne anlama geliyor? İnsanlar belki deneyip bırakıyor. Ya da tam tersi senaryoya bakın — günlük 150, aylık 160 işe kullanım bayağı düzenli ve yapışkan demek. Bu tür analiz, rollout stratejinizi şekillendirirken gerçekten kıymetli oluyor.

Bunu biraz açayım. Azure MCP Server 2.0: Kendi Sunucunuzda Ajan Otomasyonu yazımızda bu konuya da değinmiştik.

Küçük Takım vs Enterprise: Farklı Perspektifler

İnanın, 10 kişilik bir startup ekibindeyseniz bu metriklere pek ihtiyacınız yok açıkçası. Zaten herkesin ne yaptığını biliyorsunuzdur, Slack’te sorup öğrenirsiniz. Basit.

Ama enterprise tarafı farklı bir oyun. 2026 Şubat’ında bir telekom firmasında Copilot kullanım analizi yapıyorduk — 3 farklı organization, 12 ekip, 400’den fazla geliştirici. Kullanım verilerini toplamak için custom script yazmıştık, user-level API’yi çağırıp sonra gruplamayı kendimiz yapıyorduk. Çalışıyordu evet,. Her ay güncellememiz gerekiyordu, rate limit sorunları çıkıyordu, zaman zaman tutarsız sonuçlar geliyordu (ben de ilk duyduğumda şaşırmıştım). Neyse uzatmayalım — zahmetliydi, bu kadar.

Bu yeni aggregate alanlar o derdin büyük kısmını ortadan kaldırıyor. Tek çağrı, hazır sayı. Güzel.

Mevcut Metriklerle Birlikte Kullanmak

GitHub’ın Copilot metrik ekosistemi artık epey genişledi. Şu ana kadar şunlar vardı:

monthly_active_agent_users — IDE’deki agent mode kullananlar
used_copilot_coding_agent — Kullanıcı bazlı flag (evet/hayır)
PR bazlı Copilot etkisi metrikleri (bunları daha önce GitHub Copilot’un PR Etkisi Ölçülüyor: Yeni Metrikler yazımda detaylıca ele almıştım)
Code review metrikleri (Copilot Code Review Metrikleri: Aktif mi Pasif mi? yazısına da bakabilirsiniz)

Eh, Yeni eklenen üç alan bunların yanına güzelce oturuyor. Puzzle’ın eksik parçası tamamlandı gibi bir his var — IDE tarafında kim kullanıyor, bulut tarafında kim kullanıyor, PR’lara etkisi ne, hepsini artık bir arada görebiliyorsunuz.

Eleştirel Bakış: Her Şey Güllük Gülistanlık mı?

Hayır. Birkaç eksiği var bu güncellemenin, açık konuşayım. Daha fazla bilgi için GitHub’da “Low Quality” Etiketi: Moderasyonda Küçük Ama Yerinde Bir Hamle yazımıza bakabilirsiniz. Bu konuyla ilgili copilot konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.

Birincisi, yalnızca aktif kullanıcı sayısı veriliyor. Ne tür görevler için kullanıldı, başarılı mı oldu, kaç task tamamlandı — bunların hiçbiri yok. “47 kişi kullandı” diyorsunuz, tamam, ama bu 47 kişi ne yaptı? Verimli mıydı? Bilemiyorsunuz. Adoption metriği var, productivity metriği yok. Hmm… Aslında bu ikisi farklı şeyler ama yöneticiler ikisini birlikte görmek istiyor genelde, bu gerçek. Microsoft Foundry Mart 2026: Sahadan İlk İzlenimler yazımızda bu konuya da değinmiştik.

İkincisi, isimlendirme geçişi. Eski coding_agent alanları hâlâ aktif, yeni cloud_agent alanları da eklendi. Geçiş döneminde ikisi birden API yanıtında yer alacak. Otomasyon scriptlerinde karışıklık çıkması kaçınılmaz — “Hangi alana bakacağım?” sorusu bir süre havada kalacak (şaşırtıcı ama gerçek)

Üçüncüsü — ve bu beni gerçekten hayal kırıklığına uğrattı — team bazlı kırılım yok (ciddiyim). Enterprise ve organization seviyesinde var ama belirli bir team’in kullanımını ayrı göremiyorsunuz (ciddiyim). Büyük organizasyonlarda ciddi bir eksiklik bu. Daha fazla bilgi için GitHub’un Mart 2026 Dersi: Dayanıklılık Kağıt Üstünde Değil yazımıza bakabilirsiniz.

💡 Bilgi: API şemasındaki isimlendirme geçişi birkaç hafta sürecek. Mevcut coding_agent alanlarını kullanan entegrasyonlarınız varsa, hem eski hem yeni alan adlarını destekleyecek şekilde kodunuzu güncelleyin. Deprecation tarihi henüz açıklanmadı ama hazırlıklı olmakta fayda var.

Pratikte Ne Yapmalısınız?

Enterprise veya organization admin’iyseniz birkaç somut adım önereyim:

1. Dashboard’unuzu güncelleyin. Zaten bir Copilot kullanım dashboard’unuz varsa — Power BI, Grafana, ne kullanıyorsanız — bu üç yeni alanı ekleyin. Haftalık ve aylık trendleri yan yana göstermek yönetime rapor sunarken gerçekten işe yarıyor.

2. Null kontrolü yapın. API’den gelen veride null ile 0 ayrımını mutlaka handle edin. Null geldiğinde “veri yok” gösterin, 0 geldiğinde “kimse kullanmamış” gösterin (yanlış duymadınız). Bu ikisi birbirinden çok farklı hikayeler anlatıyor.

3. Eski. Yeni alan adlarını birlikte destekleyin. Geçiş döneminde eski coding_agent alanları yanıtta yer almaya devam edecek. Her iki versiyonu da okuyabilen bir parser yazın, yoksa geçiş sırasında verileriniz kopabilir.

4. Trend analizi yapın. Sadece anlık sayılara bakmayın. Haftalık veya aylık rakamı günlüğe böldüğünüzde “stickiness” hakkında güzel bir fikir ediniyorsunuz. Oran yüksekse kullanım düzenli demek, düşükse insanlar deneyip bırakıyor demek. Bu basit hesap aslında çok şey söylüyor.

Geçen ay bir e-ticaret firmasında tam da böyle bir dashboard kurmuştuk. Copilot lisans maliyetini aktif kullanıcı sayısına bölerek “kişi başı maliyet” hesapladık (kendi tecrübem). CFO bunu görünce “Tamam, yatırıma devam edelim” dedi. Sayılar konuşuyor işte — başka bir şeye gerek kalmıyor.

Limit Konusuyla Bağlantı

Bir de şunu belirteyim — Copilot cloud agent kullanımının limit tarafı da var. GitHub son dönemde plan bazlı kullanım limitleri getirdi. Copilot’ta Yeni Limitler: Ne Değişti, Ne Beklemeli? yazımda bunları detaylıca anlattım. Aktif kullanıcı sayısını metriklerle takip ederken bu limitleri de göz önünde bulundurmanız gerekiyor — kullanım artarsa plan yükseltme ihtiyacı da kaçınılmaz olarak artıyor ve FinOps açısından bunu önceden görmek istiyorsunuz, sonradan sürprizle karşılaşmak yerine.

Sıkça Sorulan Sorular

Copilot cloud agent ile IDE agent mode arasındaki fark ne?

Cloud agent, GitHub’ın bulut altyapısında otonom olarak çalışıyor — PR oluşturma, issue çözme gibi görevleri kendi başına yapabiliyor. IDE agent mode işe VS Code veya Visual Studio gibi editörlerde, yerel ortamınızda çalışan ajan modu (bizzat test ettim). İkisi farklı metriklerle takip ediliyor.

API’den null değer gelirse ne anlama geliyor?

Null, o dönem için hiç cloud agent verisi olmadığını gösteriyor (ki bu çoğu kişinin gözünden kaçıyor). Bu, “sıfır kullanıcı” demek değil — kendi adıma konuşayım — — veri henüz mevcut değil anlamına geliyor. Sıfır işe gerçekten kimsenin kullanmadığını ifade ediyor. E peki, sonuç ne oldu? Bu ayrımı dashboard’larınızda mutlaka ayırın.

Bu metrikler hangi plan seviyelerinde kullanılabiliyor?

Kısacası, copilot Usage Metrics API, enterprise ve organization seviyesinde erişilebilir (ciddiyim). Free veya individual planlarda bu aggregate metriklere erişemezsiniz. Enterprise admin veya organization owner yetkisi gerekiyor.

Eski “coding_agent” alan adları ne zaman kalkacak?

GitHub, isimlendirme geçişinin birkaç hafta süreceğini söyledi ama kesin bir deprecation tarihi henüz verilmedi. Yeni entegrasyonlarda cloud_agent isimlerini kullanmanızı, eski entegrasyonları da zamanla güncellemenizi öneririm.

Team bazlı kırılım yapabilir mıyım?

İnanın, Şu an için hayır. Metrikler enterprise ve organization seviyesinde toplu olarak sunuluyor. Team bazlı detaya ihtiyacınız varsa, user-level API’deki used_copilot_coding_agent flag’ını kullanarak kendi gruplama mantığınızı yazmanız gerekiyor (bizzat test ettim)