Läs varje funktionskategori som ett eget engagemangstal, inte som en del av en summa. En person kan finnas i flera kategorier. Spara rapportens scope, start- och slutdag samt råvärdena, skilj noll från saknat eller null och välj sedan en avgränsad insats som kan jämföras mot nästa likvärdiga 28-dagarsfönster.
Två dagar betyder återkommande användning i just det här måttet
I en changelogpost den 17 september 2026 beskriver GitHub ett nytt feature-engagement-mått i Copilot impact dashboard. En aktiv användare räknas för en inkluderad funktion om personen har använt funktionen under minst två dagar i den rullande 28-dagarsperioden. Det är alltså varken antal klick, antal prompts eller ett bevis på daglig användning.
Samma uppdelning läggs i objektet copilot_feature_engagement i 28-dagarsrapporter på enterprise- och organisationsnivå. Objektet innehåller dashboardens aktiva total och engagemangstal per funktion. GitHub listar sju kategorier: code completion, agent edit, passiv Copilot code review, aktiv Copilot code review, Copilot cloud agent, Copilot CLI och Copilot app.
Listan ser ut som en fördelning men är inte ömsesidigt uteslutande. Samma utvecklare kan ha återkommit till exempelvis code completion, agent edit och CLI under perioden och räknas då i tre rader. Om du summerar raderna och kallar resultatet användare har du därför skapat dubbel- eller trippelräkning. Använd i stället varje rad som en separat fråga: hur många av den relevanta aktiva populationen återkom till just denna funktion?
Håll aktiv och passiv code review isär
Code review-raderna kräver särskild försiktighet. Aktiv Copilot code review betyder enligt GitHub att användaren manuellt begärde en Copilot-granskning eller tillämpade ett förslag från granskningen. Passiv code review betyder att Copilot automatiskt tilldelades att granska användarens pull request utan att användaren aktivt interagerade med granskningen.
Passiv exponering visar alltså att arbetsflödet nådde en pull request, inte att utvecklaren läste, värderade eller använde återkopplingen. Om passiv review är hög och aktiv review låg är det en hypotesgenerator: granskningen kan vara lätt att missa, ge svagt relevanta förslag eller sakna ett tydligt ansvar i teamet. Måttet avgör inte vilken förklaring som stämmer.
Gör därför inte en utbildningsinsats enbart för att stapeln är låg. Ta ett avgränsat stickprov av pull requests och dokumentera om review begärdes, om en kommentar visades och om ett förslag tillämpades. AI-kreatörs tidigare genomgång av Copilot code review för stora och botskapade pull requests visar hur ett sådant prov kan hålla kostnad, täckning och mänsklig merge-grind åtskilda.
Spara fönstret innan du jämför
GitHubs REST-dokumentation har separata endpoints för den senaste kompletta 28-dagarsrapporten: /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest och /orgs/{org}/copilot/metrics/reports/organization-28-day/latest. Svaret ger nedladdningslänkar samt rapportens start- och slutdag. Rapporten slutar på den senaste dag vars data har bearbetats, vilket inte behöver vara kalenderdagen då du hämtar den.
Spara därför minst fem saker tillsammans: enterprise eller organisation, report_start_day, report_end_day, hämtningstid och det oförändrade feature-engagement-objektet. Dokumentera även om värdet kommer från dashboard eller API. Då kan nästa mätning jämföras med rätt scope och du slipper tolka en förskjuten period som en plötslig beteendeförändring.
| Fält | Spara | Undvik |
|---|---|---|
| Scope | Enterprise- eller organisations-id | Blanda organisationsrad med enterprisetotal |
| Fönster | Startdag och slutdag för 28 dagar | Anta att hämtningens datum är slutdagen |
| Total | Dashboardens aktiva basvärde | Återskapa unika personer genom att summera funktioner |
| Funktion | Rått tal och kategori | Slå ihop aktiv och passiv review |
| Tillgänglighet | 0, null eller saknat exakt som levererat | Ersätta allt tomt med noll |
Rätt läsbehörighet krävs för rapporterna, och policyn Copilot usage metrics måste vara aktiverad. Om objektet saknas ska du därför kontrollera behörighet, policy, scope och rapportperiod innan du felsöker teamets beteende. Ett tekniskt frånvarovärde är inte ett adoptionsresultat.
GitHub anger att copilot_feature_engagement kan saknas eller vara null när beräkningen inte är tillgänglig. För det närliggande fältet users_in_phase_28d betyder utelämnat att populationen inte mättes, medan 0 betyder att den mättes och inte innehöll några användare. Behåll den skillnaden i både kalkylblad och dashboard; annars kan ett mätfel bli en falsk nollpunkt.
Bygg ett basvärde som går att använda
Börja med en tabell där varje funktionsrad har samma rapportfönster och samma scope. Lägg till en kolumn för tolkning, men skriv observation före förklaring. ”12 engagerade i CLI under perioden” är en observation. ”Teamet behöver CLI-utbildning” är en hypotes som kräver kontext om vilka roller som förväntas använda CLI och om funktionen faktiskt ingår i deras arbetsflöde.
Välj sedan en avgränsad insats. Om agent edit är låg kan du exempelvis prova en 30-minuters genomgång med ett namngivet team och ett definierat repository. Om aktiv code review är låg men passiv hög kan du i stället prova en synlig rutin i pull request-mallen. Ändra inte samtidigt modellpolicy, utbildning och repositoryinställningar; då kan nästa 28-dagarsfönster inte knytas till en viss insats.
Anteckna före insatsen målgrupp, startdatum, vilken funktion som ska påverkas och vad som räknas som ett meningsfullt utfall. Ett praktiskt kriterium kan vara att funktionsraden ökar utan att den passiva review-raden misstolkas som aktiv. Använd inte totalsumman över funktioner som mål. Den kan öka bara för att samma personer breddar sin användning, vilket kan vara värdefullt men inte betyder att fler unika användare har tillkommit.
Koppla måttet till ett beslut, inte till en topplista
Ett högt tal är inte automatiskt bra och ett lågt tal är inte automatiskt ett problem. Cloud agent kan vara irrelevant för ett team som inte delegerar ärenden, medan code completion kan vara centralt. Börja därför med önskat arbetsflöde och använd feature engagement för att kontrollera om funktionen återkommer där den förväntas.
Policyn avgör dessutom vilka erfarenheter som över huvud taget är tillgängliga. Om du först behöver verifiera vilka modeller en enterprise- eller organisationspolicy öppnar, använd arbetsflödet i AI-kreatörs guide till Copilots globala modellpolicy. Blanda inte ihop en otillgänglig funktion med en tillgänglig funktion som användarna har valt bort.
Efter nästa kompletta fönster jämför du samma scope och samma kategorier. Redovisa förändringen som ett funktionsmått och behåll rådata. Om rapportens objekt saknas, perioden skiljer sig eller en policy ändrades mitt i fönstret ska jämförelsen märkas som ofullständig. Det är en bättre slutsats än ett precist procenttal byggt på olika populationer.
null och saknat behåller olika betydelse.Källor
- GitHub Changelog: Copilot impact dashboard now shows feature engagement – publiceringsdatum, tvådagarsdefinitionen, de sju funktionskategorierna, överlapp, code review-definitioner och tomvärden.
- GitHub Docs: REST API endpoints for Copilot usage metrics – 28-dagarsendpoints, rapportfönster, behörigheter och policykrav.
- GitHub Docs: Data available in Copilot usage metrics – rapportens startdag, slutdag, skapandetid och dagliga aggregat.
Uppgifterna kontrollerades mot GitHubs primärkällor den 18 september 2026. Basvärdestabellen, stickprovet och beslutsordningen är AI-kreatörs metod, inte GitHub-krav.