Analytics - Candidates Report

Purpose

The purpose of this report is to display activity with candidates according to various criteria and filters.

Principle of Value Display

The report displays activity with candidates that occurred in the monitored period and which we measure through movement within the recruitment flow. Thus, each "1" in the report means that 1 candidate was moved to a given state in the recruitment flow.

In other words, the report does not show only the current state where the candidate is, but their history of movement through recruitment process states. If a candidate was moved 3 times to the next state in the given filtered period, they will be recorded 3 times, once in each state they were moved to.

I can therefore track, for example:

• Quantitative indicators of the recruitment process such as:
  • How many new candidates we had
  • How many interviews we conducted
  • How many offers we made
  • How many candidates we hired

• Performance of candidate sources such as:
• • What were the sources of candidates for back office positions who got at least to an interview in the current quarter?

• Analysis of rejection reasons
• • How quickly were we able to find out that a candidate has higher salary expectations for IT positions at headquarters over the past year?
  • What are the rejection reasons and their frequency in individual recruitment phases for IT positions at headquarters over the past year?

The report's explanatory power and conclusions we can draw from it are closely related to the recruitment flow setup and also to the care and systematic approach to state changes. Thus, if you move every candidate who receives an offer to a "Selected" state, you can then easily draw conclusions about the number of offers.

Filtering

Candidates whose actions appear in the report can be filtered according to the following values and their combinations:

• Date
  • filters candidate actions (i.e., movements in flow) that occurred in the filtered period
    • This is also important for other tabs of this report - filtering is always done by movements in flow and not e.g., by rejection action or candidate tagging
  • so it is not about candidate creation, but about all movements in flow in the given time range
  • the default date setting is displayed from today going back one month, clicking shows a calendar element for further selection

• Recruitment flow
  • filters only actions with candidates processed according to selected recruitment flows
  • multiple values can be selected
  • depending on how your flows are defined, it can be, for example, a flow for a certain type of positions, department, etc.

• State
  • filters by specific states in the recruitment process, i.e., counts only actions in the given states
  • you can therefore display only new or hired candidates, candidates at interview, etc.

• Action author
  • filters by the name of the user who performed the action
  • for the action, neither the ownership of the position nor the candidate matters, but who physically moved the candidate

• Position
  • filters actions with candidates applied to selected positions by position name or its part
  • this filter, unlike others, has the option to select multiple values at once if filtering by a certain string in the position name and you want to then select all positions with this string - see image below
  • you can therefore filter e.g., all positions that have "part-time" or "java" in the name

• Filter items
  • this filter selects a group of positions grouped under the given filter item or multiple items
  • depending on the setup of your specific filter items, you can then easily filter by groups of positions, e.g., by branch, employment type, technology, manager, customer, etc.

• Candidate
  • filters by specific candidates
  • to reduce GDPR-related risks, the report contains only candidate IDs, not their names
  • you can find out the candidate ID from the card URL in the browser: e.g., address app.recruitis.io/zadavatel/uchazec/detail/1235157 means candidate ID 1235157

• Sources
  • filters candidates by the source from which they applied
  • you can therefore track source quality in general (how far did candidates from selected sources get in the process?), compare two sources not only at entry but e.g., at the interview, offer phase, etc.

• Rejection reason
  • filters only actions with candidates who are already rejected based on selected reasons
  • you can thus compare or analyze in which phases you reject candidates for what reasons and change e.g., the content of advertising, information for candidates, or interviews to avoid unwanted scenarios later in the process

• Tags
  • filters only actions with candidates who have selected tags
  • multiple items can be selected

Below the filters are several checkboxes that affect data display:

• Ignore duplicate repeated actions
  
  • if a candidate was moved to the same state repeatedly, it is counted only once - the last (most recent) change

• Show empty recruitment flows
  
  • If filtering (e.g., position) excludes recruitment flows where there was no activity, you can turn them on

When switching between tabs of one report, filtering does not change and is therefore applied to the newly selected data view in the second tab.

Each filtered data set has a sum as the last row in the table and you can thus see at a glance how many actions in total were done for the given data slice (e.g., for IT positions at our headquarters from external recruitment this year)

Tabs

The candidates report can be consumed from several basic views represented by separate tabs:

• By positions
• By source
• By action author
• By rejection reason
• By tags
• By rejection method
• By candidates

The principle of data display, filtering, etc. is the same in all cases, only the dimension for rows in the detail table changes. So, in the tab by positions we see data divided into rows by positions, in the tab by source the data in the table is divided into rows by source, etc.

Candidates report by positions

This view offers a breakdown of recruitment activities by positions, i.e., rows are individual positions and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings. I can thus see how individual positions are doing overall, or compare them with each other.

In the image below we can see, for example:

• In the filtered period, we had new candidates for 3 positions, a total of 26, most of them were for the HR manager position - 11
• In the given period, we conducted 12 interviews, made 5 offers, and hired 4 candidates

Candidates report by source

This view offers a breakdown of recruitment activities by candidate application sources for specific positions, i.e., rows are individual sources and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings. I can thus see how individual sources are doing in terms of "quality", i.e., how far candidates from specific sources get on a given type of position according to the selected filtering.

In the image below we can see, for example:

• Most candidates come from career pages, this source is also the highest quality - all hired are from it and at the offer stage it is 2/3 of candidates
• Referral candidates are also relatively high quality, but they fail to progress to the offer stage
• Candidates "recycled" from the database do not get past the first stage at all - are we doing talent database searches correctly?

Candidates report by action author

This view offers a breakdown of recruitment activities by action authors, i.e., typically recruiters. Rows are individual recruiters and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings. I can thus see how individual recruiters are doing from an activity perspective.

In the image below we can see, for example:

• Who performed the most actions with candidates overall
• Who conducted the most interviews
• Who made the most offers
• Who hired the most candidates

Candidates report by rejection reason

This view offers a breakdown of recruitment activities by rejection reasons, i.e., shows for what reasons candidates who went through given recruitment phases were rejected. Rows are individual rejection reasons and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings.

In the image below we can see, for example:

• The most common rejection reason is that the candidate has too little experience
• It happened that higher candidate salary expectations were revealed only after the second interview round, which ideally should have been discovered earlier

This tab also offers the option to switch the time filter to a mode where the rejection date is evaluated instead of the flow movement date, as is the case on other tabs.

Candidates report by tags

This view offers a breakdown of recruitment activities by tags assigned to candidates. Rows are individual tags and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings. I can thus see the movement of candidates with certain tags in the system. Since the definition of tags and their categories is entirely up to Recruitis ATS users, the explanatory power and types of KPIs derived from their use with candidates in various recruitment phases can vary significantly.

Tag filtering behavior:

a) I have no tag in the filter

• The report lists all tags that candidates matching the selected filtering have
• One candidate can have, and typically has, multiple tags, so if I do not filter any specific tags, the number in the "New" column does not equal the number of candidates. In other words, one candidate is counted in the given column as many times as they have tags - the reported quantity is tags, not candidates.

b) I have one tag in the filter

• This view selects only 1 specific tag and therefore the numbers in individual table columns correspond to the number of candidates (this follows from the fact that one candidate cannot have the same tag multiple times)

c) I have multiple tags in the filter

• If, for example, I search for candidates by two or three tags, the search result will be exactly these tags
• In this case, you also have the option to choose whether to use the AND or OR operator between tags
  • OR operator means that candidates who have tag A or tag B are shown - the result in the table then shows different numbers of candidates for specific tags (e.g., I search for candidates with Prague or Brno tag)
  • AND operator means that only candidates who have all filtered tags at once are shown - the result in the table then shows the same numbers of candidates for all tags (e.g., I search for candidates with Brno, Java, and Full remote tags)

Candidates report by rejection method

This view offers a breakdown of recruitment activities by rejection method, i.e., shows how filtered candidates were rejected and in which phase. Rows are individual rejection methods and columns remain the values of individual states in the selected recruitment processes corresponding to all filter settings.

I can thus see what the frequencies of candidate rejection methods are in given states. The first column "Total" shows the sum for the entire row.

This tab also offers the option to switch the time filter to a mode where the rejection date is evaluated instead of the flow movement date, as is the case on other tabs.

Candidates report by candidates

Here, individual candidates matching the filter settings are displayed as rows. However, this view differs from other tabs in this report, mainly in these respects:

• Filtered period
  • Unlike other tabs, the filtered period is controlled by the candidate creation date (i.e., not by the flow movement date)
  • This means that it does not time-limit the display of candidate actions (i.e., I see even flow movements after the end of the filtered period, if there were any), because the candidate was created in the filtered period
  • The default filter behavior can be changed with the switch "Filter by flow change date (not by candidate creation date)" and then listed candidates will be filtered by flow movement timestamps (i.e., not by candidate creation date) and I will only see candidates who were moved in the filtered period
  • Example:
    • Candidate was created on Jan 1 and was moved to the second state on Jan 3
    • In the default filtering with date from Jan 2 - Jan 31, the candidate will not appear (creation already on Jan 1, thus outside the filtered range)
    • But if I turn on the option under the date filter "Filter by flow change date (not by candidate creation date)", they will appear, because the movement action took place on Jan 3, i.e., after Jan 2, which is the start of the filtered period.

• Columns in report
  • There are not only states in selected flows, but a number of values related to candidates (see description below)

Description of columns in the candidates tab:

• ANSWER_ID
  • candidate identifier with link to the respective candidate's card
• LAST STATE
  • current state in which the candidate is
  • the candidate could have reached this state even after the end of the filtered period)
• POSITION
  • name of the position the candidate applied for
• REJECTION DATE
  • if it is a rejected candidate, the rejection date is displayed
• OWNERS
  • direct owners of the candidate (i.e., position author or candidate author if entered manually)
• SHARED WITH
  • who the candidate was shared with
• BRANCH
  • branch assigned to the given position as the place of work
• FILTER ITEMS
  • filter items of the given position
• GENDER
  • candidate's gender
• SALARY
  • candidate's salary requirement (taken from the relevant field on the candidate card)
• MEETINGS
  • Overview of scheduled meetings (interviews)
• STATE LIST
  • equivalent of "new" state (i.e., first state in flow) is essential for date filtering - in this tab, filtering is by candidate creation
  • other states in flow - timestamps of when the candidate was moved to individual states are listed (even after the end of the filtered period)

Good to Know

• Data is updated once a day - you can see the update date in the report on the right side at the top
• Changing the filter is not done immediately, but you need to press the "Display" button (both when adding and removing filtering)
• You can always save filtered data to a CSV file (button below the table) and open it in Microsoft Excel for further processing. Charts can be saved as images using the icon in the upper right corner.
• Each filtering after selecting the "Display" button changes the report URL in the browser window and you can thus save the given report filtering setting to bookmarks and recall it anytime later
• You can learn general information about the BI module in this article: Analytics - Introduction to BI Module
• The analytics feature is available by default in the Enterprise license and higher.