Applications per job

Understanding how to create the metric can be complicated - we're here to help.


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:

  1. An application was transferred to a different job; even though the job just opened

  2. A job's open date was shifted due to activity

  3. Standard talent acquisitions processes weren't followed

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.



Why do we need to adjust the logic?

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


Job Open Date

Job Close Date

Total # of Applications

Requisition #1

August 1st

August 31st

7 applications

Requisition #2

September 1st

September 30th

9 applications

Requisition #3

October 1st

October 31st

4 applications

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:

  1. To calculate the Applications per Job, we would intuitively assume the following general calculation:


    Total # of Applications / Total # of Jobs


    While we could calculate an average using all of the data, we could also calculate the averages for the job in each month. In this example, the calculation would be simple:


    • August Average

      • 7 applications / 1 job = 7

    • September Average

      • 9 applications / 1 job = 9

    • October Average

      • 4 applications / 1 job = 4


  2. In the One Model site, data is always pivoted by time. So, when we create a metric, it will always generate a number based on the time period selected.

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:

  • August Average

    • 8 applications / 1 job = 8

  • September Average

    • 7 applications / 1 Job = 7

  • October Average

    • 5 applications / 1 job = 5

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.



How do we fix this issue?

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:

  • Be counted once for the job to which it belongs

  • Be counted on an appropriate date when its job appears in the data


Final Solution

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:

  • August Average

    • 7 applications / 1 requisition = 7

  • September Average

    • 9 applications / 1 requisition = 9

  • October Average

    • 4 applications / 1 requisition = 4

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.

Was this article helpful?

0 out of 0 found this helpful



Please sign in to leave a comment.