I just spent a pleasant few days in New Orleans for the Jobg8 Job Board Summit, dodging a hurricane and eating crawfish etouffee. I also had a chance to listen to Tarquin Clark of Google and Scott Helmes of CareerBuilder talk about the Google Cloud Jobs API initiative, and implementation of said service, respectively. There were, as you might guess, many questions. Tarquin was kind enough to spend some time during the conference for one-on-ones with many folks, including myself. I walked away with a better understanding of the value – and costs – of the service for job boards and recruiting sites. (My disclaimer: I was one of the few in the room NOT taking photos of each slide – so I may have left out a few useful details below. If so, let me know!).
In a nutshell, the Google for Jobs initiative breaks out into 2 general pieces: the job search experience on Google, and the Cloud Jobs API service. The job search experience involves a specific way of marking up your jobs. You can find the schema here. Once you’ve marked up your jobs, you submit your sitemap to Google (using the Google Search console); they index your jobs and the jobs show up in search results. Pretty straightforward. So why bother? Because the marked up jobs are then eligible to be displayed in the new job search (think easier for job seekers to find). (In fact, Peter Harrison of Snagajob said that after moving to the schema, they saw a 17% increase in inbound organic traffic – plus higher conversion rates for applications). So that’s a decent sized carrot that Google is dangling.
The Cloud Jobs API side focuses on – yes, you guessed it! – search. Specifically, Google (which, after all, specializes in search) has analyzed millions of searches in an attempt to apply machine learning to solve several common problems. The most common of these is ‘mismatch’ – for example, a job seeker types in ‘server jobs Chicago’. Are they looking for jobs working in a server farm – or front-of-house jobs in a restaurant? Google takes its substantial knowledge of previous user behavior, typical searches for specific geographic locations, and so on, to deliver the most likely result back to the user. Testing with job boards such as CareerBuilder have demonstrated that their search technology is in fact delivering better results – based on time spent on results, applications, etc.
So how does a job board actually implement the Cloud Jobs search? First, you load your jobs into a private, secure location on the Google Cloud Platform. Google then segments, classifies, and maps the job according to location, employment type, education, certifications, benefits, title, and skills. Then when a job seeker types in a search at your job board, the query is directed to the Google cloud – where the query is broken apart and rewritten (again using machine learning), then submitted to your block of jobs on the Google Cloud Platform, and then results retrieved, ranked, and returned to the job seeker on your job board. This all happens so quickly, of course, that the job seeker is unaware of it – they simply get (ideally) better, more relevant search results. And of course, your employers get better matches. Another thing: the Cloud Jobs search engine is continually using your job seeker behavior to optimize – i.e., ‘machine learning’. So results should keep getting better as time goes on. Is this happening with your current job board search engine?
Those are the basics. Now let’s get into some of the messy stuff – the stuff that fueled the Q&A after the Jobg8 presentation:
- Search isn’t free. Tarquin said there would be a ‘nominal charge’ – pricing isn’t finalized, but could start at 1 cent per executed query. Even with volume discounts, this cost could add up.
- Conversely, if your users are getting better results and applying for more relevant jobs, you’ll have happier clients – and possibly more revenue.
- Is this a ‘Trojan horse’? Joel Cheesman (and others) think it is. In fact, one of the first questions focused on whether Google would gobble up job board clients, ala Indeed. I’m not so sure. The entire job board industry has rested on the back of the Google search engine since the mid-90s. Indeed gained its current spot, in large part, by gaming the search engine rules. I see the schema as a reassertion of Google’s role as a search platform focused on delivering the most relevant results to everyone – even job seekers. Same with the Cloud Job API. Could they attempt to take all employers away from all job boards? Sure. But they will (and have) make a lot more money by remaining a platform that sucks money from all players in the jobs ecosystem.
- Is there a good reason NOT to use the jobs schema? I don’t think so. In fact, I think any job board that doesn’t use the schema is simply putting themselves at a disadvantage – and most of us need all the advantages we can get.
- Is there a good reason NOT to use the Cloud Job API? I would say, it depends. I talked with several larger boards, and all were planning on doing some testing. One very large board (not CareerBuilder) is currently running A/B tests, but hasn’t made a final decision. I would say that if you have 100,000 unique visits/month or more, it’s probably worth a test. Both CareerBuilder made a strong case for the technology; they’ve been able to move their internal tech team away from search-related issues, and into higher level work in other areas – AND more importantly, they’ve seen much better results on job seeker conversions. No matter what your opinion is of Google (or its motives), you have to admit that they are the world leader in search technology. So using them as your ‘search specialist’ may make sense. (And don’t forget – this is also going to be used by employers for their career sites. Do you want your job board to return poorer results than your clients’ sites?).
It’s still early days for this initiative – but unlike Google Base, this time Google seems to be in the job space for the long haul. I’ll be curious to see where it all leads. I’m sure you are, too![Want to get Job Board Doctor posts via email? Subscribe here.]