This analytics page presents Campaign Coverage KPIs and trends, generating a bigger picture of vulnerability instances covered by campaigns and the campaign coverage workload in your organization.
This is a pre-filtered report that only shows data on vulnerabilities running campaigns.

Use the Campaign Tracking report to vie stats on tickets created in Jira/ServiceNow through the Vulcan Platform.

First, ensure you cover the Analytics Filters and Data Drilling to learn about the expected behavior of the trends and presented data.
For your reference, you can read all about Vulcan Campaign here.

The Campaign Tracking KPIs are the first and main widgets you encounter when entering the Campaign Tracking Analytics report.

Keep in mind that by default, the data in this report is pre-filtered to show info only on vulnerabilities that have running campaigns.

What each KPI represents?

Let's assume you have 100,000 vulnerability instances in the whole environment. Out of which, you've covered 10,000 vulnerabilities instances in one campaign targeting remediation in production environments. The campaign you opened contains 50 different Jira tickets. In this case, the data would show:

In this double graph, you can choose to view cumulative or daily numeric trends of running campaigns or vulnerability instances covered in campaigns. In other words, this double graph offers you a perspective on:

Let's take a look at the following data point and learn how the Remediation / Introduced delta can be quickly calculated.

In a Cumulative view on Campaigns on May 9, you had 3 open/running campaigns (un-remediated) and 2 remediated ones.
This means that the delta is -1 (2 remediated - 3 introduced = -1).

The delta here represents your workload capacity. In this case, on May 9, you had one un-remediated campaign.

Your security team workload capacity was less than the 100%+ goal. Keep in mind that you should always be remediating more campaigns than introduced.

This is the same graph you have in the Remediation Performance Report.

Read about this graph here.

A bar chart of your business groups and how many open tickets (open actions) for each Business Group, including ticket status.

Note: The statuses are retrieved from the integrated "Take Action" connector (Jira, ServiceNow, etc.,). Each connector has a different set of statuses.

This trend shows the number of tickets opened for each type, depending on your configured integrations (Jira, Service Now, Email, etc.), and the ticket statuses.

Note: The statuses are retrieved from the integrated "Take Action" connector. Each connector has a different set of statuses.

List of Business Groups sorted by the due-date compliance in a closed ticket.

Look at your Campaigns by Business Groups with the highest MTTR (Mean Time to Remediation) and how their rank shifts (Current vs. Previous Rank).

Let's take a look at the example below, assuming we've set the Period filter to compare the "Last 30 Days" with the 30 days before it:

This trend shows the MTTR of campaign-covered vulnerability instances by status.

For example:

27 days is the MTTR of Medium risk-level vulnerability instances. In other words, It takes around 27 days to remediate Medium risk level vulnerabilities counted from when a campaign is opened. On the other hand, it takes more time (MTTR 44) to remediate High and Critical vulnerabilities. This indicates that you need to focus on lowering the MTTR for vulnerabilities in higher risk levels.

This trend indicates the MTTR of campaign-covered assets by type (Host, Image, Cloud, Website, etc.).

For example:

The MTTR of Image assets covered in campaigns is 96 days, while the MTTR of Host assets is 43 days.

Read our Analytics FAQ and Data Validation article here.