That fills an important gap. A suggestion-apply count only covers one way developers act on feedback. The new fields also count fixing the code directly, asking Copilot to make the fix, replying that the fix will land later, and other actions that show the comment was handled.
The fields to collect
On each repository-level repos-1-day row, read copilot_code_review.total_comments_evaluated and copilot_code_review.total_comments_addressed. The first is the denominator: comments checked to see whether a developer acted. The second is the numerator: comments where GitHub detected an action.
Calculate the addressed rate as total_comments_addressed divided by total_comments_evaluated. Keep the raw counts beside the percentage. A repository with 1 addressed comment out of 1 evaluated comment has a 100 percent rate, but it is not the same signal as 800 addressed comments out of 1,000.
Break the rate down before drawing conclusions
GitHub also reports evaluated and addressed counts by severity, review tier, comment type, and customization. Use review_comments_by_severity to see whether high-severity feedback is handled differently from low-severity feedback. Use review_comments_by_comment_type to separate bugs, security findings, and custom comments based on repository guidance.
The customization breakdown can show whether comments came from custom instructions, skills, MCP servers, or no customization. Compare those groups only after collecting enough activity for each group; small samples can make a repository look better or worse than its normal review flow.
Understand the merge-day rule
Comments are evaluated when their pull request merges, so the counts belong to the merge day, not the day Copilot posted the review. If you graph daily activity, expect a quiet period followed by a larger merge-day value. Do not compare the new counts directly with a same-day review-posted count.
Use the human-change-request signal separately
total_merged_no_human_change_request_after_review counts pull requests that Copilot reviewed and that merged without a later human request for changes. It is a workflow signal, not a replacement for code quality or security review. Track it next to the addressed rate to see whether feedback is acted on while human reviewers still change the direction when needed.
Do not mix this with applied-suggestion counts
pull_requests.total_copilot_applied_suggestions counts ready-to-apply suggestions that someone applied. The new addressed fields cover every evaluated Copilot code review comment and count several ways a developer can act. Keep both metrics if you want to distinguish direct suggestion acceptance from broader review follow-through.
Handle zeroes, empty arrays, and bot pull requests
The object appears on every repository row in the enterprise and organization repos-1-day reports. Repositories with no Copilot code review activity have zero counts and empty arrays. Copilot usually does not evaluate comments on bot pull requests, including Copilot cloud agent pull requests, but the no-human-change-request count still includes those merged pull requests. Preserve that difference in your report labels.
Wait for the reporting window
GitHub says Copilot usage metrics can take up to two full days after a UTC day closes to become available. Avoid flagging the newest day as a regression while data is still processing. Compare closed reporting windows and keep the data timestamp in the dashboard or export.
Access and a useful first report
Enterprise owners, enterprise billing managers, organization owners, and custom roles with the relevant View Copilot Metrics permission can access these reports when the Copilot usage metrics policy is enabled. Start with a 28-day repository report, calculate addressed rate only where the denominator is nonzero, and show the raw evaluated and addressed counts beside the percentage. Add severity and comment type breakdowns after the basic report is trusted.
The new fields let teams measure what code review feedback becomes, not only how often Copilot speaks. Use the addressed rate as one operational signal, keep its denominator visible, and pair it with human review behavior and repository context before using it to guide policy.