Data Filtering and Exclusions
To provide the most accurate and actionable engineering metrics, our platform automatically filters out pull requests and activities that are not representative of developer productivity. This ensures that your metrics reflect the core development work happening in your organization, free from the noise of automated or process-oriented workflows.
A pull request is automatically excluded from your metrics if it meets any of the following criteria:
- It is authored by a bot.
- It is a backmerge where the head branch is the default branch.
- It contains no unique commits (e.g., a release branch merge).
- It is a long-lived branch with more than three contributing authors.
- It is authored by a user who has been manually excluded.
Below are more detailed explanations of how these filters and exclusions work.
User-Based Exclusions
We filter out contributions from certain user types to keep metrics focused on your core team's activity.
Bot-Authored PRs
We automatically identify and exclude any pull request where the author is a known bot (e.g., dependabot).
Why we exclude bots: Productivity metrics like Lead Time and Review Cycles are designed to measure the human element of the development process. Including automated PRs, such as dependency updates, would skew these metrics and make it harder to understand the efficiency of your team's workflow. This approach ensures consistency across all productivity-focused metrics.
Open-Source Contributors
Pull requests and code reviews from open-source contributors are excluded from calculations.
A user is identified as an open-source contributor if they are not a member of your Git organization and their only contributions have been to your public repositories.
Why we exclude open-source contributors: External contributors are often highly infrequent and including their work would not accurately represent the productivity of your internal development team.
Manually-Excluded Users
You can manually exclude activity from specific users in Settings. There are two levels of exclusion:
- Exclude all pull request activity by this user: This option excludes all of a user's activity, including pull requests they've created and any reviews they've performed.
- Exclude pull requests created by this user: This option is typically used for managers, designers, or other roles that may open pull requests but are not part of the core development team. Their created PRs will not factor into developer counts. However, their code reviews and approvals on other PRs will still be counted to preserve the accuracy of metrics like Time to Review.
Workflow-Based Exclusions
We exclude certain types of pull requests that represent internal processes rather than the development of new features or bug fixes.
Dependency Updates
Pull requests that only contain dependency updates are automatically excluded if they are authored by bot.
Backmerges
A backmerge is a process PR used to sync changes between branches, such as merging the main branch back into a develop branch. These are excluded because they do not represent new work and can artificially inflate productivity metrics.
Our platform identifies backmerges by checking if a pull request's head branch is the repository's default branch.
Release Pull Requests
Pull requests associated with creating a release are excluded from productivity metrics. We use two methods to identify these:
- No Unique Commits: When a release branch is merged into main, it often contains no new code, but rather a collection of commits that already exist in other pull requests. Our platform detects this by analyzing the commit history to see if a PR introduces any unique commits. If not, it is excluded.
- Long-Lived Branches: A long-running branch that aggregates work from many different developers is often a release branch. We identify and exclude these branches, which we define as any branch with more than three unique contributing authors.