As you may know, recruiting data can be complex. For example, you may find that you have applications whose application dates fall before, or after, when their respective job (aka requisition) was open. This can happen for various reasons, such as:

While leaders and users believe their data may align, we often find that it doesn't and will require logic to create an Applications per Job metric that follows the relationship between the applications and the job they applied for and not general activity.

Let's start with some simple aggregated data to help explain things:

Note, for explanation purposes, this example has the Job Open and Close in the same month. As you know this rarely, if ever happens.

There are two important points to understand before we proceed:

Now, let's apply these two points in a visual (click to expand). Below, you can see the three months: August, September, and October. For each of these months, there's the distinct job that opened on the first day of the month and closed on the last day of the month. Above each month, you can see check boxes that represent the applications. The applications appear over the month in which they were submitted and are color coded by the requisition # to which they belong.

As you can see, there are applications with application dates set in August and October that actually belong to Requisition #2 (which was open in September). While, in our minds, we would understand to attribute these two applications to Requisition #2 (as we did in the table earlier), the data doesn't align to the same periods without intervention. If we apply the Applications per Job calculation from Point #1 to the data found in each month, the results in the site will be as follows:

The results above differ from the averages under Point #1. This view presents activity that is occurring in each month and can sometimes cause confusion to end users. End users often expect a clear association between job and application that doesn't always align to the recruiting process.

To allow those two applications to be tied to their respective job, we have to make adjustments to the logic here. Specifically, we have to change how application data responds to time, thereby allowing the applications to not be boxed-in by the months in which they were submitted. When we make this logical change, however, we see the following:

In the visual above, you can see how data is getting rolled up and still counting applications where and when they don't belong. While this view may be helpful in different metrics, it won't help us, as is, in our current task. We now have to tell the application data to do the following:

For the two bullet points above, our solution is to have the applications counted on the date when their job closes, or the job close date. This date works well as it will be the same for all of the applications of a job, whereas dates like interview date are unique to each application and can still be problematic. When we apply this solution to the date, you can imagine it looking like this:

In the visual above, you can see how, by using the requisition close date, the two applications for Requisition #2 are now tied to their respective job in September and counted once. Now, when we apply the Applications per Job calculation from Point #1 to the data found in each month, the results in the site will be as follows:

These results match the intended results as shown under Point #1.

One Model is committed to helping you best utilize your data, and recruiting data is no exception. If you're interested in creating an Applications per Job metric or other complex metrics, please connect with your Customer Success Lead and Data Engineer.