Scoring
Match Scoring🔗
Match is a term-based matching engine. Scoring for Match queries is not fundamentally different from manually entered searches. The difference is that Match generates a pre-constructed query from a job or candidate that is optimized to bring the most relevant matches to the top of your search results.
Weights🔗
Match uses different weights on different criteria to optimize the quality of the matches. For example, skills can get a higher weight than the education level. We use optimized default weights in most cases, but they are configurable per setup.
The requiredness setting of the term (nice-to-have / should-have / must-have) influences the weight. Moving from nice-to-have to should-have increases the weight for that particular term. Changing it to must-have turns it into a hard filter.
Depending on the weight configuration, each criteria gets assigned a fixed part of the score, illustrated in the pie chart below. Note that the values in this chart are arbitrary and only serve as an example.
In this example we see that the job title criteria contributes 30% to the score. That means, if you get a perfect job title match, it will contribute 0.3 to the score of the result. The combined criteria add up to a score between 0 and 1 (where 0 is an unrelated result and 1 is a perfect match that matches all criteria).
Dynamic Match🔗
Some weights are modified depending on characteristics of the input job or candidate. For example: - If a job is remote, we don't include location in the query - If a job is in the IT domain, we value IT skills more
There is a number of rules that apply here. These two only serve as examples.
Boosting🔗
On top of that there are some general boosting mechanisms: - Recency boosting: job titles that are more recent are more important and get a higher score - Cross field boosting: e.g. skills occurring in a recent job title tend to be important
Semantic signals🔗
In the score compostion other semantic signals than the query terms can play a role. This means that the terms in the query and the scoring explained above might not cover all edge cases. Sometimes the difference between a user's expected score and the actual score might differ due to these semantic signals. These signals may include information that is not covered by the structured (parsed) contents of the query, and are not always visible in the UI.