Copilot Usage Metrics API: Artık Kohortlu AI Adopsiyon Devri

Geçen perşembe bir bankacılık müşterimizde toplantıdaydım. CIO masaya bir Excel attı, “Aşkın bey, biz Copilot lisansını aldık, 320 geliştiriciye dağıttık, ama bana kimse şunu söyleyemiyor: Bu adamlar gerçekten ne yapıyor bununla?” dedi. Active user sayısı %78, kabul oranı %34, falan filan… Rakamlar var. Ama hikâye yok.

İlginç olan şu ki, İşte tam bu noktada GitHub’ın yeni duyurusu fena değil — hatta beklediğimden iyi çıktı. Copilot Usage Metrics API artık her kullanıcıyı bir AI adopsiyon fazına söküyor. Yani sadece “kim aktif” değil, “nasıl olgunlaşıyor” sorusunu da cevaplayabiliyorsunuz. API tarafında ai_adoption_phase diye yeni bir alan geldi, kurum ve org seviyesinde de totals_by_ai_adoption_phase dizisi eklendi.

Bi saniye — Açık konuşayım: Bu özelliği ilk gördüğümde “yine bir vanity metric mi geliyor?” diye düşündüm. Ama API’yi kurcaladıktan sonra fikrim değişti. Hatta biraz şaşırdım, çünkü işin içinden sadece sayı değil, davranış da çıkıyor; aşağıda hem teknik tarafı hem de Türkiye’deki kurumsal yapılarda bunun ne anlama geldiğini anlatacağım.

Dört Faz: Kim Nerede Duruyor?

Şunu fark ettim: Nasıl desem, GitHub kullanıcıları son 28 günlük yuvarlanan pencerede, en az 2 farklı günde hangi Copilot yuzeylerini kullandiklarina bakarak sinifliyor. Mantık basit ama bence iyi düşünülmüş. Tek günlük “denedim sevmedim” olayı disarda kalıyor.

Evet.

• Faz 0 — Kohort yok: Eşik kriterini gecememis. Yani lisansı var, belki ara sıra açmış kapatmış ama düzenli kullanım yok.
• Faz 1 — Code first: Klasik code completion veya IDE’deki agent mode kullanıyor. “Inline suggestion” çağı diyelim.
• Faz iki — Agent first: GitHub tabanlı tek bir agent yüzeyi kullanıyor — cloud agent, Copilot code review veya Copilot CLI’dan biri.
• Faz 3 — Multi-agent: Iki ya da daha fazla agent yüzeyini ya da yeni GitHub Copilot app’i kullanan, işin gerçek anlamda içine girmiş kullanıcılar. (bence en önemlisi)

Bakın, Küçük gibi görünüyor ama değil (yanlış duymadınız). Her ai_adoption_phase değerinin yaninda bir de version alanı var, v1‘den başlıyor. Bu detay önemli — Copilot’un yüzeyi büyüdükçe sınıflandırma mantığı da değişecek, ama eski raporlariniz bozulmayacak. Geçmiş kontekst korunuyor yani; hani raporu yeniden yazmak zorunda kalmıyorsunuz, bu bayağı iş görüyor.

“Active user” rakamı bir vanity metric’tır. “Faz 3’teki kullanıcı oranı” işe gerçek bir adopsiyon göstergesidir. İkisi arasındaki farkı CIO’nuza anlatabildiginiz gün, gerçek FinOps konuşmasına başlamış olursunuz.

Peki Veri Pratikte Nasıl Geliyor?

Kafa karıştırmadan söyleyeyim: Enterprise veya organization seviyesinde rapor çektiğinizde gelen yapı su şekilde oluyor (sadeleştirilmiş örnek):

Bunu biraz açayım.

{
"date": "2026-05-29",
"total_engaged_users": 287,
"totals_by_ai_adoption_phase": [
{
"ai_adoption_phase": {
"phase": 1,
"name": "code_first",
"version": "v1"
},
"total_engaged_users": 192,
"user_initiated_interactions_avg": 14.3,
"code_acceptance_activity_avg": 22.1,
"lines_added_avg": 184,
"pull_requests_created_avg": 3.2,
"median_time_to_merge_avg_hours": 28.4
},
{
"ai_adoption_phase": {
"phase": 3,
"name": "multi_agent",
"version": "v1"
},
"total_engaged_users": 24,
"user_initiated_interactions_avg": 41.7,
"pull_requests_merged_avg": 11.6,
"median_time_to_merge_avg_hours": 9.1
}
]
}

Dikkat edin: bu agregasyon değerleri toplam değil, faz başına kullanıcı ortalaması. Bu nuktayi atlayanlar ilk haftalarda hatalı dashboard kuracak, garanti veriyorum. Geçen yıl başka bir API’de tam bu kafa karışıklığını yaşamıştık; raporlar üç kez yeniden yapıldı, yani is uzadı da uzadı.

BIR UYARI: User-level vs aggregate

Tuhaf ama, User-level raporda her engaged user’in yaninda kendi ai_adoption_phase‘i geliyor. Yani isterseniz CSV’ye dökün, kim hangi fazda tek tek görünüyor. Neden önemli bu? Burada GDPR ve KVKK tarafı önemli — kurumsal müşterilerimde bu veriyi mutlaka anonimleştirilmiş ID ile saklamalarini öneriyorum; yoksa konu hemen performans skoruna kayıyor ve is hukuku tarafında can sıkıcı yerlere gidiyor.

Bunu Türkiye’deki Şirketler Açısından Degerlendirirsek

Acilikla söyleyeyim: Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de Copilot adopsiyonu üç farklı hızda ilerliyor. Bankalar. Büyük holdingler genelde Faz — ki bu tartışılır — 1’de takılıyor — neden? Çünkü ag politikaları, güvenlik kuralları ve eski toolchain’leri agent yuzeylerini denemelerine izin vermiyor. Cloud agent’i açmak için bile aylar süren bir komite süreci işliyor; abartmıyorum, bazen olay orada kilitleniyor.

Tam burada telekom ve e-ticaret tarafı biraz daha rahat hareket ediyor ve Faz 2’ye daha hızlı geçiyor. Bir telekomda çalıştığımız ekipte Copilot code review’u açtık, altı hafta içinde PR review süresi ortalama %38 düştü; rakam böyleydi yani uydurma değil. Faz 3’e geçen ekip işe hâlâ azınlık — Logosoft içinde dahi multi-agent kullanımı %15 civarında. Demek ki bu yeni API ile gerçek bir benchmark’a kavusacagiz.

Küçük bir detay: Peki neden? Çünkü Türkiye’de “lisansı aldık ama kullanmıyorlar” sorunu çok yaygın. Faz 0 oranı yüksek olan kurumlarda işin başı ROI değil, enablement problemi oluyor; (ki bu çoğu kişinin gözünden kaçıyor). Eğitim, demo, internal champion programları… Bu API olmadan önce bunu kanıtlamak zordu; artık CIO’ya rahatça “bakın, kullanicilarinizin %42’si Faz 0’da, sorun lisansta değil eğitimde” diyebilirsiniz.

Hmm, bunu nasıl anlatsamdı…

Enterprise vs Startup: Strateji Nasıl Değişmeli?

Küçük bir ekipseniz (5-20 geliştirici diyelim), bu metriklerle çok uğraşmayın derim. Direkt herkesi Faz 3’e çekmeye çalışın; evet iddialı duruyor ama küçük takımlarda multi-agent workflow’u bayağı iş görüyor ve bazı yerlerde farkı hemen hissettiriyor.

Ama büyük kurumsal yapıdaysanız (200+ geliştirici), strateji neredeyse tamamen farklı oluyor (burada tek tek kişileri kovalamak yerine kohortu izlemek daha mantıklı). Su şekilde bir yol haritası öneriyorum: Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımızda bu konuya da değinmiştik.

1. Ilk 30 gün: Faz dağılımının baseline’ını çıkarın. Hiçbir şeye dokunmayın, sadece ölçün.
2. 30-60 gün: Faz 0’daki kullanıcılara hedefli eğitim verin. “Niye kullanmiyorsun?” anketleri açın.
3. 60-90 gün: Faz 1’deki kullanıcıları seçilmiş takımlarda Faz 2’ye taşıyın. Pilot bölgeler belirleyin.
4. 90+ gün: Multi-agent için internal champion programı kurun. Faz 3’tekilerin başkalarına mentor olmasını sağlayın. — ciddi fark yaratıyor

Şimdi, bi saniye — Bunu daha önce GitHub Copilot’u.NET’te Verimli Kullanma Rehberi yazımdaki pratik örneklerle birlikte kullanan ekiplerde ivme daha hızlı geliyor. Teori tek başına yetmiyor, biraz el kirlenmesi gerekiyor. Daha fazla bilgi için Service Bus Per-Message Settlement: Batch Derdine Son yazımıza bakabilirsiniz.

Maliyet Tarafı: TL Bazında Düşününce

Lafı gevelemeden söyleyeyim: Copilot Business lisansı kullanıcı başına aylık 19 USD, Enterprise işe 39 USD civarında geziniyor. Bugünkü kur ile Enterprise lisansı yaklaşık 1.500 TL/kullanici/ay yapıyor olabilir; kur oynadığı için rakam birebir sabit değil tabi. Resim değişmiyor pek fazla.

Kısa bir not düşeyim buraya. Daha fazla bilgi için PowerToys 0.99 Çıktı: Power Display ve Grab And Move yazımıza bakabilirsiniz.

Kendi deneyimimden konuşuyorum, Bazı yerlerde hesap hemen açılıyor bazılarında işe biraz geç açılıyor ama temel mantık aynı kalıyor: Mesela 300 kişilik bir ekip için yıllık ciddi bir kalem çıkıyor ortaya. Bunun yarısı Faz 0’daysa kayıp hissi daha net oluyor; yani para harcanmış ama davranış değişmemiş oluyor. SPFx Nişan 2026 Yol Haritası: Sahadan İlk Yorumlar yazımızda bu konuya da değinmiştik. PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımızda bu konuya da değinmiştik.

Küçük bir not daha: GitHub’in faturalandırması faz bazlı değil; herkes aynı ücreti ödüyor zaten. Yani Faz 3’teki bir kullanıcı sizin için çok daha değerli olabilir. Maliyet aynı kalır (bu kısım bazen yönetimi şaşırtıyor). ROI hesabını bu mantıkla yapın (yanlış duymadınız)

The Teams Filter Ile Birlesmek

Duyuruda gözden kaçan. Bence en kritik nokta su: Bu kohort verisini teams filter ile birlestirebiliyorsunuz. Yani sadece “kurum geneli Faz 3 oranı %12” değil, doğrudan takıma inip mesela Backend takimi Faz 3 oranı %38 iken Mobile takimi %4 gibi aksiyona dönüşebilir görüntüler çıkarıyorsunuz.

Bunu Power BI’a bağlayıp her takım liderine kendi dashboard’unu vermek bence en çabuk geri dönüş alacağınız işlerden biri oluyor (tabii herkes dashboard’a bakacak diye de garanti yok). Bir müşteride bunu yaptık — takım liderleri kendi siralamalarini görünce hiçbir top-down baskı olmadan adopsiyon kendiliğinden hızlandı; insan psikolojisi işte, garip ama çalışıyor.

Karşılaştırma tablosu: Eski vs Yeni metrik yaklaşımı

Yaklaşım	Eski (sadece active user)	Yeni (faz bazlı)
Anlattığı hikâye	“Kaç kişi açtı?”	“Nasıl olgunlasiyorlar?”
CIO’ya sunum	Mainly vanity metric riski var	Maturity story daha net çıkıyor
Eğitim hedefleme	Genel, herkese aynı şekilde giderdi	Pozisyona göre faz başına ozellestirilir
ROI hesabı	Zayıf kalırdı	Kohort bazlı olduğu için daha sağlam durur
Kıyas analizi	Düz lineer büyüme görülürdü	Faz geçiş hızı izlenir

Ilk Denediğimde Karşılaştığım Sorun

Ilk cagirdigimde tagger...

Sıkça Sorulan Sorular

AI adoption phase verisi geriye dönük da geliyor mu?

Hayır, yani sadece API’nın yeni sürümünden itibaren hesaplanıyor. Son 28 günlük yuvarlanan pencere kullanıldığı için, duyurudan önceki dönemler için faz dağılımı alamıyorsunuz. O yüzden kendi tarihsel kayıtlarınızı tutmaya hemen başlayın — açıkçası bunu geciktirmeyin.

Faz 0’daki kullanıcılar lisansı boşa mı harcıyor?

Şart değil aslında. Hani bazı kullanıcılar yoğun proje dönemlerinde aktif, başka zamanlarda pasif olabiliyor. Tek bir 28 günlük snapshot ile karar vermeyin. Ama üst üste 3 ay Faz 0’da kalan kullanıcılar için ciddi bir konuşma şart — ya enablement yaparsınız ya da lisansı iptal edersiniz (ben de ilk duyduğumda şaşırmıştım). Tecrübeme göre bu konuşmayı ne kadar ertelersen o kadar zor oluyor.

Bu metrikleri Power BI’a nasıl bağlayabilirim?

Yöntemlerden biri şu: REST API çağrısını bir Azure Function veya Logic App ile zamanlanmış olarak çalıştırıp sonucu bir SQL ya da Cosmos DB’ye yazıyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Sonra Power BI’dan o veri kaynağına bağlanıyorsunuz. Doğrudan Power BI’ın web connector’ı ile de çekilebilir mesela, ama açıkçası auth tarafı epey zahmetli olabiliyor.

Geliştirici performansını ölçmek için bu veriyi kullanabilir mıyım?

Bence kesinlikle kullanmayın. Hem KVKK/GDPR riskleri var hem de bu metrikler zaten bireysel performans göstergesi olarak tasarlanmamış. Takım veya departman seviyesinde agregat olarak kullanın. Yani bireysel kullanıma bakmak hem etik dışı hem de yaniltıcı sonuçlar veriyor — ikisi bir arada oldukça tehlikeli bir kombinasyon.

Faz 3’e ulaşmak için hangi yüzeyleri açmam lazım?

En az iki GitHub tabanlı agent yüzeyi açmanız gerekiyor: Copilot cloud agent, Copilot code review, Copilot CLI’dan herhangi ikisi. Ya da yeni GitHub Copilot app’i kullanmak da işe yarıyor (ilk duyduğumda inanamadım). Ama şunu söyleyeyim — kurumsal ağ politikalarınız bunlardan birini engelliyorsa Faz 3’e geçemiyorsunuz. Bu yüzden IT/security ekibiyle bu konuyu önceden konuşmanızı tavsiye ederim, yoksa sonradan sürprizle karşılaşabilirsiniz.

Kaynaklar ve İleri Okuma

GitHub Changelog — Copilot Usage Metrics API Cohorts Duyurusu

Açıkçası, GitHub REST API: Copilot Metrics Resmî Dokümantasyonu

Açıkçası, GitHub Community Discussions — Copilot Adoption Tartışmaları