GitHub erweitert das Copilot Impact Dashboard um Feature Engagement. Unternehmen sehen nun, wie viele aktive Nutzer einzelne Copilot-Funktionen regelmäßig verwenden. Die Auswertung trennt Code Completion, Agent Edit, passive und aktive Copilot Code Reviews, Cloud Agent, Copilot CLI und Copilot App. Damit wird aus einer allgemeinen Adoptionszahl ein genaueres Bild der Arbeitsweisen – aber noch kein Beweis für Produktivität oder Qualität.
Bestätigt ist: Als engagiert für eine Funktion gilt ein aktiver Nutzer, wenn er sie an mindestens zwei Tagen innerhalb eines 28-Tage-Zeitraums verwendet hat. Dieselbe aggregierte Aufschlüsselung steht in 28-Tage-Berichten für Enterprises und Organisationen zur Verfügung. Ergänzend meldet users_in_phase_28d die vollständige rollierende 28-Tage-Population jeder AI-Adoption-Phase zum jeweiligen Berichtstag.
Was GitHub jetzt je Funktion sichtbar macht
Das Feld copilot_feature_engagement enthält den aktiven Gesamtwert und die Engagement-Zahlen. totals_by_feature gliedert diese nach den einzelnen Copilot-Erlebnissen. Das erlaubt eine operative Frage: Welche Funktionen sind wiederkehrender Bestandteil der Entwicklungsarbeit, und welche werden trotz Bereitstellung nur selten an mehreren Tagen verwendet?
- Code Completion: wiederkehrende Nutzung von Vorschlägen während der Codeerstellung.
- Agent Edit: Nutzung agentischer Bearbeitungsfunktionen im Entwicklungsablauf.
- Aktives Code Review: Der Nutzer fordert eine Copilot-Prüfung manuell an oder übernimmt einen Review-Vorschlag.
- Passives Code Review: Copilot wird automatisch einem Pull Request zugewiesen, ohne dass der Nutzer aktiv mit dem Review interagiert.
- Cloud Agent: wiederkehrende Nutzung der cloudbasierten Agentenfunktion.
- Copilot CLI und Copilot App: Nutzung der jeweiligen Oberfläche als eigene Funktionsgruppen.
Die Trennung zwischen aktivem und passivem Review ist besonders wichtig. Ein hoher passiver Wert kann aus einer automatischen Zuweisung entstehen und darf nicht wie eine bewusste Nutzung interpretiert werden. Ein aktiver Wert zeigt dagegen eine manuelle Anfrage oder die Anwendung eines Vorschlags. Auch daraus folgt noch nicht, ob das Review Fehler verhindert oder Zeit spart; dafür sind ergänzende Prozesskennzahlen nötig.
28-Tage-Population und Tagesaktivität nicht verwechseln
GitHub ergänzt die AI-Adoption-Phasen um users_in_phase_28d. Dieses Feld zeigt die vollständige rollierende 28-Tage-Population einer Phase am jeweiligen Tag. Das bestehende total_engaged_users berichtet weiterhin nur die Personen dieser Phase, die am Berichtstag aktiv waren. Beide Werte beantworten unterschiedliche Fragen: Der erste beschreibt die breitere Population, der zweite die Tagesaktivität.
Für die Unternehmenssteuerung verhindert diese Trennung Fehlalarme. Ein ruhiger Tag kann wenig Tagesaktivität zeigen, obwohl die 28-Tage-Population stabil ist. Umgekehrt kann eine kurzfristige Kampagne die Tagesnutzung erhöhen, ohne dass sich regelmäßige Arbeitsweisen etabliert haben. Die Quelle liefert Definitionen und Zählweise; wie gut eine Adoption ist, muss jedes Unternehmen anhand seiner Ziele bestimmen.
Vier Schritte für ein belastbares Copilot-Adoptionsreporting
1. Zugriff und Messgrundlage klären
Die Copilot Usage Metrics Policy muss aktiviert sein. Zugriff haben laut GitHub unter anderem Enterprise Owner, Billing Manager, Organization Owner und benutzerdefinierte Rollen mit View Copilot Metrics. Legen Sie fest, wer die aggregierten Daten auswertet, welche Entscheidungen damit getroffen werden und welche Interpretationen ausdrücklich unzulässig sind.
2. Funktionen einzeln statt als Rangliste bewerten
Definieren Sie pro Funktion den vorgesehenen Arbeitsablauf. Code Completion kann breit relevant sein, während Cloud Agent oder CLI nur bestimmte Rollen adressieren. Eine geringere Reichweite ist deshalb nicht automatisch ein Problem. Vergleichen Sie die beobachtete Nutzung mit der tatsächlich berechtigten und geschulten Zielgruppe, nicht pauschal mit allen Lizenzinhabern.
3. Ursachen mit Prozessdaten prüfen
Wenn Agent Edit oder aktive Reviews hinter den Erwartungen bleiben, kommen mehrere Ursachen infrage: fehlendes Training, unpassende Konfiguration, eingeschränkte Berechtigungen oder schlicht ein geringer Bedarf. Verbinden Sie das Dashboard mit Interviews, Supportanfragen und technischen Betriebsdaten. Das Feature Engagement liefert einen Hinweis, aber keine Diagnose.
4. Wirkung getrennt messen
Ergänzen Sie je Arbeitsweise passende Ergebniskennzahlen: Durchlaufzeit, Review-Dauer, Nacharbeitsquote, Fehler nach dem Merge oder erfolgreiche Agentenabschlüsse. Änderungen sollten über vergleichbare Zeiträume und Teams betrachtet werden. Nur so lässt sich unterscheiden, ob eine häufiger genutzte Funktion tatsächlich bessere Prozesse erzeugt oder lediglich mehr Interaktionen.
Checkliste gegen typische Auswertungsfehler
- Funktionswerte nicht summieren, weil Nutzer in mehreren Kategorien erscheinen können.
- Passive Reviews nicht als bewusste Nutzerinteraktion darstellen.
- 28-Tage-Population und am Berichtstag aktive Nutzer getrennt beschriften.
- Eine ausgelassene Phase nicht als Null interpretieren: users_in_phase_28d fehlt, wenn die Population nicht gemessen wurde.
- Null bedeutet gemessen, aber keine Nutzer; ein fehlendes oder null gesetztes Feature-Objekt kann eine nicht verfügbare Berechnung anzeigen.
- Aggregierte Daten nicht zur Leistungsbewertung einzelner Entwickler umdeuten.
Entscheidungsrahmen für Training, Konfiguration und Portfolio
Breite regelmäßige Nutzung mit guten Ergebniskennzahlen spricht dafür, eine Funktion zu standardisieren und verlässlich zu betreiben. Geringe Nutzung bei klarem Bedarf spricht eher für gezieltes Enablement oder eine Konfigurationsprüfung. Hohe passive Review-Werte bei wenig aktiver Interaktion können Anlass sein, Zuweisung, Review-Prozess und Erwartungen zu untersuchen. Eine Funktion ohne relevanten Geschäftsanwendungsfall muss dagegen nicht durch Schulungen künstlich verbreitet werden.
Für Geschäftsführung und IT-Leitung entsteht ein besserer Blick auf die Tiefe des Copilot-Rollouts. Die Kernfrage verschiebt sich von „Wie viele Lizenzen sind aktiv?“ zu „Welche KI-gestützten Arbeitsweisen werden regelmäßig genutzt, und welche Wirkung erzielen sie?“ Das Dashboard liefert für den ersten Teil eine belastbarere Grundlage. Der zweite Teil bleibt Aufgabe eines unternehmenseigenen Messmodells.
Ein monatliches Review sollte daher Feature Engagement, AI-Adoption-Phasen, Zielgruppen und Prozesswirkung gemeinsam betrachten. So lassen sich Trainingsbudgets, Konfigurationen und weitere Rolloutschritte nachvollziehbar priorisieren, ohne aus überlappenden Nutzerzahlen oder automatischer Zuweisung eine übertriebene Erfolgsgeschichte abzuleiten.