Case study · Machine learning advisory
A vice president asked for a written view on two open questions: what could be learned about the candidate journey, and whether machine learning would materially improve resume-to-job matching. Fifty-six pages, delivered while the company was mid-rebuild.
A vice president at Monster.com asked for a written analysis. The company had been through a long decline and was being rebuilt, and two questions were open: what could actually be learned about the candidate journey, and whether machine learning would materially improve the matching of resumes to job listings.
The work was unsolicited in origin — a conversation that turned into a request — and it was delivered as a fifty-six page analysis.
What was actually being asked
The two problems were treated separately because they have different data requirements, different success measures and different build costs. Merging them would have produced one confident answer to neither.
The analysis opened with a page of questions back to the client — what are you tracking now, how well is it working, which parts of the journey matter to you, what does “better” mean here. Not rhetorical questions. Real ones, because the answers changed which methods were appropriate. A proposal that arrives certain about a business it has not yet examined is a proposal that has stopped listening.
Three implementations, examined
Each was documented for what it does, how it appears to work and what it implies about cost and effort - rather than named as a competitor and left there.
One of the three was a cloud service selling job-matching as an API. That meant a meaningful part of what was being considered as an internal build was available to buy. Saying so reduces the size of the project being proposed, which is exactly why most proposals do not say it.
| Recommendation | What it involved |
|---|---|
| Understand the journey properly first | Evaluate the available journey-analysis platforms against the specific need, then work out where custom analysis has to fill the gap. Not a tool purchase — a fit test |
| Test matching where the data already exists | Recommendations from referral keyword traffic, from partial search behavior on the site, and delivered by periodic email — three places where signal was already being generated and discarded |
A further section listed opportunities beyond the brief: predictive analytics on the journey, keyword and search-structure analysis from server logs, and other applications of the same techniques.
Visualizing individual paths through a site is a Sankey problem, and the analysis included working code for it rather than a description. Showing the actual method is a different kind of claim from naming it, and it lets a technical reader judge whether the person writing has done this before.
| The usual proposal | What was done here |
|---|---|
| Arrives certain | Opens with questions whose answers change the recommendation |
| Proposes to build | Documents what can be bought first, even when that shrinks the work |
| Names the technology | Shows the method, in code, so a technical reader can judge it |
| One big recommendation | Two, separated because they need different data and prove different things |
Every other case study on this site withholds the client. This one does not, because the work was a written analysis prepared at an executive’s request rather than an assessment of a company that did not ask to be assessed. The distinction matters and it is the whole reason the others stay anonymous.
Marketing Analytics Consultants
We look at what already exists, tell you what can be bought rather than built, and give you the arithmetic — including when the answer is that it is not worth doing.