Why metric values differ between views
Last updated: October 27, 2026
The same metric can show different numbers in a chart, a table, a drill-down list, a report, or another tool. This article explains the most common reasons: who Span includes, how it dates records, how it aggregates them, and which comparison group it uses.
Why it matters
Most differences aren't data errors. They come from a filter, a date rule, or an aggregation working as designed. Knowing which one applies saves time when a number looks wrong and helps you explain numbers to stakeholders.
How it works
1. Who's included. Code metrics (PRs, commits, reviews, comments) count only people marked Contributor under Code Contribution in Settings > People management, plus dev agents Span tracks.
Non-contributor applies to all history. Switching someone to Non-contributor removes their past PRs and active days from every period, not just future ones.
Active days. Per-week code rates divide by active contributor-days: days a contributor wasn't out of office (OOO) and had a commit, merged PR, PR review, or PR comment that day or in the 30 days before it. Weekends count.
Start and termination dates bound the days a person can count. A person has no active days after their termination date; their earlier work stays in history.
Issue rates use a different denominator. Issues completed / week and Estimate completed / week divide by every non-OOO day for everyone in scope, contributor or not. Comparing an issue rate with a PR rate for the same team mixes two populations.
2. How records are dated. Span dates each PR by its merge time and each issue by its completion date, in your organization's time zone. A drill-down from a PR chart lists the PRs merged in that period, so a PR opened in March and merged in April shows under April. Reviews and comments are dated by when they were written, except Comments received / PR, which counts every comment on a PR in the period the PR merged.
3. How values are aggregated. Span computes each period, team, or organization value from the underlying records, never by averaging other averages.
Trimmed Average is the default for duration metrics such as PR cycle time. Span caps each record at 30 days and takes the mean of every record. Nothing is dropped. (For PR review cycles the cap is 8 cycles; for PR size, issue lifetime, and mean time to recover the option is a plain mean.)
P50, P75, and P90 return the value of a real record at that position, with no cap and no interpolation between two records.
Table versus chart. A table's period value pools all records in the range. A chart computes each week or month from that bucket's records. The period value usually isn't the average of the weekly points.
4. Which comparison group. The benchmark population is separate from your page filters. Filtering a page to one team changes the values you see, not the Organization benchmark, which still covers your whole organization until you narrow it in the Benchmark menu.
5. Different metrics with similar names. On AI Effectiveness > AI insights > Comparison, PR throughput is size-weighted PRs ÷ dev-weeks: each person's seven-day window, grouped into cohorts by how much AI-written code their PRs contain. Weighted PRs / week on Delivery divides by active contributor-days across all PRs. The two won't match, and they aren't meant to.
How to check a number that looks wrong
Confirm the date range, time bucket (week or month), and filters match between the two views.
Check the aggregation in Page settings (Trimmed Average, P50, P75, P90, or Max).
Click the chart to open the underlying records and spot-check a few.
In Settings > People management, check Code Contribution, start dates, and termination dates for the people involved.
Check Settings > Metrics for ignored repositories, branches, Git usernames, and file patterns.
If you're comparing with another tool, check whether it uses merge or creation dates, includes reverted PRs and bots, and averages per-person values.
Things to know
Worked example: Trimmed Average versus median. Four PRs take 1, 2, 3, and 60 days. A plain mean is 16.5 days. Span's Trimmed Average caps the 60 at 30: (1 + 2 + 3 + 30) ÷ 4 = 9 days. P50 returns the second PR, 2 days. Three correct answers, three different numbers.
Worked example: period versus weekly points. In week 1 a team merges 2 PRs with an average cycle time of 10 hours. In week 2 it merges 8 PRs averaging 2 hours. The chart shows 10 and 2. The two-week table shows (2 × 10 + 8 × 2) ÷ 10 = 3.6 hours, not the 6-hour average of the two points, because the busier week has more records.
Org value versus team values. The organization value isn't the average of team values. Bigger teams carry more weight, and a person on two teams counts in both teams but once in the organization.
History can change. New reverts, links added after merge, ignore patterns, and Contributor changes all update past periods. A screenshot from last month may not match today.
P90 can equal Max. With fewer than 10 records, the 90% position lands on the last record.
Company holidays count as active days unless they show as OOO in calendars or your HRIS.
Related articles
How to read Span's "/ week" metrics
How Span attributes metrics to teams
What determines contributor status in Span user profiles?
Need help?
Contact your Span account team or reach out to support@span.app.