Well, obviously, it's the first vertical pre-trained machine learning model from Google. That's clear. Right? But what does this really mean? To answer that, let's take a step back– story time. Here at Google, we started with a simple question. How could we create a tenfold increase in the number of people that we hire? We began by taking a deep look at all of Google's hiring channels. And we found, to our surprise, that the Google career site, which you see here, was one of the most scalable channels in that it was severely under-utilized. So after analyzing user behaviors and interactions on the career site, we realized if we were able to make even a small change to the career site conversion rate, we'd be making a material difference to the bottom line, to the number of people that we hired every year. And so we looked for opportunities where we could optimize. We ran countless experiments, and we focused hard on improving the career site visitor experience, looking for every way we could drive an increase to conversion and ultimately generate high-quality hires.
The resulting solutions, which are still in use on the Google career site today– feel free to take a look as we are hiring– became the first version of the Google Cloud Jobs API. So I'd like to take this opportunity to introduce Christian Posse, our chief data scientist, who is here to talk about the problems we've seen along the way and what we've done to solve them. Please join me in welcoming Christian to the stage. CHRISTIAN POSSE: Hi, everyone. Can you hear me? So yes, let's take a second just to talk about one of the main problems that the Jobs API is trying to tackle. So as you know, there's no external writing job postings. So very often, what we're seeing are companies which are struggling and using some kind of internal language for describing job titles that may not be of use to job seekers. So you can see a few of them up there. They are real. We have seen them through the Jobs API. They are not the worst ones, and I'm sure that if you are in the industry, you can come up with weirder ones.
On the other hand, job seekers do not have a PhD in terminology, and so they cannot anticipate all the possible ways that a title can be expressed. So even if you are a recovery and asset protection specialist, you may never find these rec and asset prot level one jobs. Because how on earth do you know it's spelled this way? So the Google Cloud Jobs API is like a translation engine– a Rosetta Stone, we like to call it– that helps match the employer's interest with a job seeker's interest. So now if you are trying to fill this rec and asset prot level one position, the API is going to help you surface a job to the job seekers which are best suited for it. By the way, the Rosetta Stone, if you remember, is a stone that was rediscovered by the French in Egypt in 1799. It contains three translations of the same decree. At the bottom, it's in Ancient Greek. It was known at the time. The top one was Ancient Egyptian hieroglyphs that were unknown. And thanks to the stone, 20 years later, a French scholar was able to translate or decipher the hieroglyphs.
So I like to think about the job seeker queries like the Ancient Greek, who kind of know what's going on. You have the job posting titles, who have no idea. These are the hieroglyphs. Essentially, the API is the Rosetta Stone. But the best way to fill a problem is to see it in action. So let's look at the search behavior on the previous version of the Johnson & Johnson career website. And we're going to take a very simple query, like searching for an admin assistant role in New York. What could go wrong? Well, if you look at the results, it's a bit surprising. They are all mismatches, and there are a couple of reasons for that. The first one is the realization that very often job titles are the combinations of two or three very generic terms. Independently, each term is very vague. But when you put them together, they create a very specific meaning. And this makes any keyword-based search very challenging. OK. You saw that problem. There are more issues. One is that an admin assistant is a supporting role for senior positions.
So it will tend to be mentioned in the job descriptions of the more senior role. And now you have an increased risk of returning the senior role in the search results for the admin assistant query, just because you had the hit on the secondary role in the job descriptions for the senior role. And it's what happens here, essentially. If you look here, all of these drugs are for the seniors. And by doing so, you're missing the intent of the job seeker. So the API is attacking this issue and many others, and we will see a bit more in the future. But how does it work? So at the core of the Google Cloud Jobs APIs are data models that encode our knowledge about occupations, skills, educations, locations, companies, employment type, and more. What you're seeing here is a visual representation of one of our data models, which is the title or occupation data model. So once again, just imagine that you are at night and looking in the sky. Try to do that tonight, but good luck in San Francisco.
There is a fog. So go back home and look at the sky. Imagine that every star you're looking at is a title. Related titles are close stars in the sky. And like stars concentrated in galaxies, titles that belong to the same job categories will tend to concentrate in clusters. So if you look at our skies, we have some exciting galaxies here, like the accounting and finance, or the business operations, or the art of fashions and design. Each galaxy is made of thousands of titles, and we understand around 250,000 titles. Yes. But much more interesting is if you look at the structure within the galaxies. There's a fine structure that encodes the type of similarities between those titles. OK. So we are in the age of space travel, right? So maybe we can go visit some of these stars. You want to do that? I don't even know why I'm asking you, because in a way, you don't have a choice. Doors are closed. So put your seat belts on and enjoy the ride. So let's look at the video.
So our journey is going to start by visiting the business development manager star. So what we want to see with this video is a couple of things. I will tell you what you would have visited. So if you're in the business development manager stars, you're going to see that in the neighborhood space there are very small nuances of that title. Oh, thank you. Finally, we're kicking off. Excellent. There we go. We are in the advertising and marketing galaxy. So the first thing you can see here in the close by space– we are capturing very small nuances, like a business development manager or it can be a business development director. So we have these nuances between a manager and a director. You have a business development marketing manager. We also capture a lot of vertical video manager role, like a government business development manager, IT development manager, or retail business development manager. So those are small nuances we capture. But a business development manager can be also expressed in many different ways, like for example, a brand development manager.
So we just visited a nearby space. We went a bit further. And you can see here, we exemplify a few more alternatives of how a business development manager is being expressed. It can be mentioned as a director of brand strategy, or a strategic planner, partner relationship manager, even a chief marketing officer or an account marketing executive. OK. So now we're going to switch, and we're going to go to a far, far away galaxy, which happens to be the transportation and logistic galaxy. And we're going to visit a star which is the truck driver star. So it takes a little while, because really we're going to go across the universe. There we go. And look and see. Again, we have tons of nuances around the truck driver. So in the nearby space, you capture things like a delivery driver, or a class-A CDL driver, a 7.5-ton driver, or things like car transporter, or tow truck coordinator. But the most important thing to realize is that there are strong differences between those roles.
For example, heavyweight and lightweight truck driving have very different driving requirements, in terms of driver license. So you never want to return heavyweight truck driver roles to a lightweight truck driver query, because there's a mismatch. Finally, we're going to go into the admin assistant role that we saw a bit earlier, which happens to be in the administrative and office galaxy, which is a good one. Same pattern here. You can see that we have all the possible nuances. So for example, an admin assistant can be a personal assistant, an office assistant, a secretary, administration coordinator, and so on. We again capture a vertical admin assistant, like faculty admin assistant or store admin assistant. We capture also different seniority levels, like senior admin assistant, or admin assistant one, two, or three. OK. So we're done with our space. I hope you're not too dizzy. But as you can see, it was fast travel– some hold-up at the very beginning, but we did this travel, and we never spent quality time at one of these stars.
So what we're going to do now is take a break, take a vacation, and revisit one of these stars– the exciting business development manager one– and try to explore it in more depth. So what we said earlier is we understand a lot about this title. The first thing is we understand all the possible synonyms that can be expressed, especially also slang ones. So if you are in the biz dev world, you may spell something like bizdev in one single word, where we capture business development in that case. You can use abbreviations. There, too, those are captured. You just saw earlier, we understand a lot of the related roles. We also have relationships and strength of relationships between those roles. Those are captured. Earlier you saw that this role belongs to the advertising and marketing galaxy, but actually it belongs to more galaxies than that. It also belongs to the sales galaxy and the management galaxy. You want to capture all of these facets of the diamond that a business development manager role is.
And all of these relationships, we have them with confidence scores, so you know the strength of their relationships. Finally, we also understand what are the skills related to that role. And since we're talking about the skills, why don't we do a small, deep dive into our skills ontology? And we're going to use the business development manager role to exemplify what we're trying to build. So what you're seeing here is a simplified snippet of our skills data model related to the business development manager case. So the first thing is if you are a business development manager, you must have business development skills. That's kind of a duh moment, right? But actually, it's a critical one, because at this point in time we can start reasoning about what it means. Business development skills– it's a collection of different skills, such as brand building, finding business opportunities, relationship building, sales skills, strategy management skills. But if you have this set of skills, you'd better have good communication and interpersonal skills.
So what you're seeing here is essentially we have a graph of skills with different types of relationships, which are encoded by the different types of arrows here. So some skills are part of larger skills, some skills are collections of skills, some skills are prerequisites of skills, and some skills are related to other skills. For example, the business development skills are related to strategy partnership development. And more importantly, also we understand the relationship between occupations skills and education. So we did earlier the hop from business development manager to the business development skills. Business development belongs to the larger business skills, which is commonly associated with an MBA degree, which is included here. OK. So we talked about the mismatch between job seekers and employers. We talked about all these beautiful data models. Well, how do we bridge the two? And this is where machine learning comes into play. So essentially, machine learning helps us extract content on both sides from the employer and the job seeker and map the content to the data model with great accuracy.
Once we have done the mapping, essentially we can leverage Google search technology for retrieving and ranking search results. So here on the left, you see the employer. Whenever a job posting is inserted in the private tenant on the Google Cloud platform, we parse the job posting, and we structure it. So we're going to use now natural language processing and machine learning for essentially building structure. For example, the first thing we do is we automatically segment the job description into its main constituents, which are responsibilities, company descriptions, requirements, and other subsections. We also extract two dozens of what we call Nuggets, like, for example, all the leaves– parental leaves, sick leaves, vacation. We extract all the benefits if they are present on the job posting. We extract things like shift flexibility, life insurance, 401k, tuition reimbursement. So we extract these data, and we normalize them, and we surface them. We also extract and normalize the skills from the Requirements section.
Also something you saw earlier– we automatically categorize the job posting into one of these broad job categories, our galaxies from a bit earlier. So we created a very large set of metadata that we're going to leverage in the search. On the right side, you see the job seeker. So when the Jobs API gets the job seeker query, we do the same work. We try to identify if there is a title, employment type, company, skills, education, statement. Pretty much anything that moves, we try to detect it and normalize it, so that we can now match to the rich metadata of the job posting we just talked about. So maybe we can take a minute to go visit one of these data processes that we have built. And the one example maybe we can use is our title standardizer. As you know, job posting titles are very, very noisy. I think I will just give you an example. I think in the millions and millions of job postings that we have analyzed, we find that actually the number of unique strings that you can extract in terms of titles on job postings, it's pretty much just reduced your set by 75%.
So essentially, if you have 10 million job postings, you end up with 2.5 million job titles which are unique strings. It's very noisy. Why? Because there are ads. And so often you find content that does not describe the occupation. You find things like location, company name, employment type, but you find things also like advertising jargon– needed, wanted, grand opening. And sometimes you find extremely useful information like administrative jargon, like a reference ID on the job posting. So the first thing that a Jobs API does is clean up the mess. And then we standardize the remaining content. So if you have acronyms, abbreviations, we also do contextual disambiguation. And finally, also, we extract the skills and specialties from the job postings and add that to the title. At this point in time, we built high-dimensional vector representations of those titles. The dimension of the vector is essentially the terms and expressions that we have gathered from the titles and the skills extracted from millions of job postings across hundreds of thousands of career websites.
So now we can use machine learning. At this point in time, we built a classifier. It's an ensemble classifier that is a collection of natural-language-based processing classifiers and the neural nets. And the classifier will attempt at mapping the statement that you are feeding it– so this title string– into zero, one, or more occupations in our title data model. Why zero, you ask? I'm glad you asked. Well, Princess of Darkness– it's a title we have seen. And I use that all the time, so not literal. No, Princess of Darkness. So unless you have some extra information that you have extracted from a job posting, like skills, we must be able to say, I have no clue what to do with that. On the other hand, very often, especially on the query side, especially also with the blue collars and those skills, you don't find very specific titles. Titles tend to be pretty vague. So you must be able– like retail sales or team members or I want to work in warehousing. You must be able to map the query or the titles to not a single node into the ontology but to a multitude of them.
And we do that with a confidence score, which means that whenever we do the mapping, we have a sense that the mapping was done without ambiguity– or maybe with some ambiguity, and we take care of that also in the search results. So that concludes our little, deep dive into the title standardizer. We have similar standardizers for education, skills, and others. But I think at this point in time you're much more excited to see how these surface into the product. So I'm going to hand back to Matt to see how our customers are using the API today. Thank you. MATTHEW MOORE: All right. Thank you, Christian. So our goal is to bring this next wave of computing to the entire talent industry. Fundamentally changing how employers are able to attract, connect with, and retain talent, job search, if you think about it, is just the first step in this API's journey. I mean, almost every business starts their hiring processes with job search. And as we found, once optimized, it's a very powerful tool in your hiring arsenal.
So by working with existing independent software vendors and job platforms, we aspire to create turnkey access to the API. We want to provide a better job search experience for all employers and candidates. Because let's face it– hiring the right people is one of the most important things your company needs to do. To date we've announced two core use cases, both of which are running in a closed alpha program in North America. The first one is powering job boards. For the job board case, we are pleased to share that CareerBuilder is nearing a production release, and ongoing testing and improvements continue to date with Dice.com. Our second and extremely important use case is powering talent networks and company career sites. We're also pleased to announce for CareerBuilder that they've brought over 20 companies online with the API in their talent network, including CIOX Health, GameStop, and Lucas Group, helping thousands of job seekers find their next job going forward.
Additionally, the Cloud Jobs API continues to power job search on the Google and FedEx career sites. And later this month, Jibe will be onboarding HealthSouth, the largest owner and operator of inpatient rehab hospitals in the United States, and Eaton, a multinational power management company. Specifically for Google and our online hiring efforts, our career site handles several million queries each month. And we've seen a 28% increase in candidate success rate from apply to hire since our journey with the API began. And last but definitely not least, we're pleased to be joined here today by one of our newly onboarded customers, Johnson & Johnson. So please join me in welcoming up to the stage Sjoerd Gehring, Global Vice President of Talent Acquisition at Johnson & Johnson, and Joe Essenfeld, CEO and founder of Jibe. Welcome up. [APPLAUSE] Come on. There we go. All right. Thanks for joining us here today, guys, and it's great to have both of you here to talk about the Jobs API.
So, Sjoerd, I was wondering to kind of start us off, could you talk a little bit about Johnson & Johnson's hiring processes and some of the challenges you face? SJOERD GEHRING: Absolutely, Matt, and it's a pleasure to be here today. At Johnson & Johnson, we fill about 25,000 positions a year. And as a company, we have a goal in the next decades to find a cure for cancer. So we're heavily investing in our oncology and hematology businesses. Currently, we have approximately 350 roles open today in the oncology and hematology space, primarily in the research and development, and various commercial roles. Given the fact that these roles are so niche and so hard to fill, we're having a real issue filling these positions simply because we're tapping into a very small talent pool. And our current approach is really not getting us to the hiring goals that we need fast enough, so we're always looking for innovations related to job search and hiring practices. MATTHEW MOORE: Wow.
So you know, when you first started chatting with Joe about the machine learning and the API, what was it that caught your attention as a possible way you could use this to solve some of those challenges? SJOERD GEHRING: Yeah. We've been interested in machine learning for a few years now, really because we believe that it can enable us to much better identify and hire talent faster. And one of the things that we need to do a much better job of is to proactively identify and match people with the skills and interest in the oncology space to our various open positions. And we feel that the Jobs API can actually make a real difference here. MATTHEW MOORE: And I understand– I may have had a previous look– that you and Joe have brought some examples to share with us today. SJOERD GEHRING: We have. So we prepared three different examples for the audience today. The first one is a search query around oncological research and in the location the United States. And what you see on the left side of this slide is our previous keyword-based search technology.
And on the right side you see an example using Google search. And as you can imagine, on the left side, a job seeker would actually be quite discouraged having searched for oncological research and not seeing any oncology-specific positions in the top search results that the search yielded. On the right-hand side, where you see our Google search results, is that Google search is actually using the understanding of language to return much more relevant jobs, even when it doesn't use the exact keyword in these jobs. The other thing that you see in this result is that the Google search yields fewer and much more quality and relevant search results over the before picture, which really saves job seekers quite a bit of time. The second example is around a search query around microbiologists. And what you see here is that although the first two examples are pretty similar, further down in the list you start again to see Google search returning much more relevant job search results for job seekers.
And last but not least, the third example here is around internships in New York City. We get an enormous amount of job search queries around internships with J&J. And I actually thought this was a particularly interesting example, because in the before picture you see four results in the search, three of which aren't really relevant. And the after picture there, 11 relevant internship results in the New York City area– much more relevant for job seekers, again, using Google search. MATTHEW MOORE: Yes. First of all, thank you so much for being here and sharing these examples with us. We're really excited to continue to work with you as you move forward with hiring. So, Joe, just having heard from Sjoerd, could you maybe tell us a little bit about the API onboarding process with Johnson & Johnson? JOE ESSENFELD: J&J was the second company to be onboarded on the API, and Jibe powers career sites. So when we're going into production with jobs for a global company like J&J, one of our concerns are, how do you deal with that with a closed alpha program?
You're putting jobs in production. You're handling this big responsibility of hiring. And with collaboration with Google, we were able to successfully put in place some measures to make sure that even though it was an alpha program, we had a successful launch. One of the things that we found very helpful was actually having a customer success function installed in this early-adoption program. So as we launched these jobs, and J&J being the second one, we were able to do it about three times faster. So we got J&J live, from the time we got the thumbs up, in about a week. And going forward, we now have a turnkey interface that any existing Jibe client can be live on this API in under a day and can begin testing. So it really gives us the space to do that. But beyond that quick turnaround time, we were able to actually interface and make sure that the job families, the job descriptions, the job application process, were all maintained, and we could maximize that value of that machine learning process and not have to worry about production issues with such a young API.
So it went very smoothly, and we're two for two so far. MATTHEW MOORE: We hope that trend continues. JOE ESSENFELD: Absolutely. MATTHEW MOORE: As you brought Johnson & Johnson and more companies going forward online, has there been anything that surprised you about hiring or the API in general? JOE ESSENFELD: Yeah. I think there were two things, really, with J&J that were surprising. The first one was how important location search is. We were very focused on understanding this story and the benefit behind machine learning, talking about the translation, and looking at the relevance of search results like Sjoerd shared about oncological research and microbiology. But when we started really analyzing the query data, we noticed how often job seekers searched for location. They searched for location in the keyword field. They searched for location in the location field. And the lift that we saw– at Jibe, we pride ourselves on having good products all around, but our location search didn't match Google's at all.
It was more based on radius. And being from Manhattan and working there, you know, when you do a radius search for a job in Manhattan, you end up with suggestions in Hoboken, and Jersey City, and Queens. And no offense to those places, but people typically don't want to work there when they're searching for a job in Manhattan. So we saw some great lift with location alone and also the ability of the API to parse out the results in the keyword field. So job seekers don't like following directions. And when we looked at the data, we saw the keyword field was just polluted with all this information. And the machine learning API was able to parse that out, return intelligent results back, and improve conversion when we had that. So that was the first surprise there. And then the second, which was really funny, was this emotional connection that people had understanding that machine learning was powering the search. At first, it was trying to debunk it. Oh, I'm going to find the query that's going to show this thing doesn't work.
And then they're pounding the API. They're looking for results. And then what they find is how well it works, and they start to understand that it's not about keyword search, but it really goes back to Christian's example about translation. And a good example was a query that someone put in for SQL. So they were looking for jobs related to that. And the first result that came back– and this wasn't for J&J, it was for another client on the API– was an HR admin position. And they're like, oh, I got it. We found that this didn't work. And as they clicked into the job, it wasn't in a database category, wasn't in an IT category, but at the bottom of the job description it mentioned how important it was about pulling reports from SQL. So this was a great example of how that keyword actually surfaced the skills required for that job. And that person switched, at that point, from trying to debunk it to then trying to find more examples of how this machine learning really worked.
So those are two great surprises as we implemented this and went live. MATTHEW MOORE: Awesome. We always love creating more believers in it, so thanks for sharing. In the last few minutes we have here on the stage, is there anything else you might want to share with folks in the audience who would be interested in improving their hiring process and talent search? JOE ESSENFELD: Sure. I think one thing that's really important to think about is job seekers as consumers. When they're on a company's career site, that is when they're the most engaged. And it really has to be like any other transaction on an e-commerce site or any other consumer-facing site. And when you think about machine learning, it's important to think about it in that consumer frame. So we want to find the positions that are most strategic to fill and understand how that translation of what those job titles and job descriptions are are really relevant to those job seekers. So I'd say take a step back.
Don't think about quantity and just filling your pipeline, but what's meaningful to your company and how does that translation through your machine learning really help improve your conversion. And when you start thinking about it in that context, you get a lot more support and understanding inside the organization about how to consumerize that experience for job seekers and really improve candidate experience. MATTHEW MOORE: Awesome. Well, again, thank you very much for both joining us today and for being an excellent partner through this alpha program and hopefully beyond. In short, thank you so much for taking the time to share your vision both for Johnson & Johnson and the API today. It's been great working with both of you, and we hope to continue it going forward. Thank you very much. SJOERD GEHRING: Thanks, Matt. JOE ESSENFELD: Thank you. Great. [APPLAUSE] MATTHEW MOORE: All right. So I'm sure you're all excited to see what's next for the API. And today, we're pleased to announce several updates to the alpha and share with you some of our future plans for the API.
We've been hard at work these past few months evolving the Jobs API to address additional customer needs and prepare the API for broader adoption, which I'm sure you're all interested in. So first of all, we've added featured jobs, which enables a hiring company to promote jobs that it has a business-critical need to fill as soon as possible and be seen by as many job seekers as they can get it in front of. Secondly, we've added histogramming, which is the ability to include and render dynamic search counts alongside your filters, which is going to greatly improve the understandability of your search results and experience. Next, we've added support for bulk operations. Bulk operations allows you to send multiple creates, updates, or deletes in the same call, which is a much requested and extremely useful feature when you're managing a lot of job data like many of our customers do. And finally, we've added significant relevance-thresholding improvements further ensuring our objective to return great matches for all job seeker queries and showcase the search quality of the API.
But now let's take a look at what's coming next. So in the first quarter of this year, we'll be rolling out some important changes and enhancements to the API. To start, we're going to be making improvements to how we handle locations in your job data, improving our support for both jobs without locations, which happens, and jobs with many locations. This quarter, we're also going to be introducing integrations for behavioral data, improvements to our existing data models, which will further improve your search results. Looking forward, this half of the year, we're aiming to graduate our API into beta, expanding and making the API prepared for greater public availability. With the beta launch, we're also aiming to release a couple of cool new features, such as commute search, which we're going to talk about more in a moment, and job-to-job recommendations, improving on our models, which will build smarter associations between jobs in the system. And finally, as we look to the future, we've got an ambitious set of goals for the API to bring and expand the API to customers worldwide, translating and localizing in new countries and languages.
And while we started with job search, our goal is to take this machine learning-powered API to the next level and enable job-to-person recommendations, helping generate smart job recommendations based on resumes and profiles, so your job seekers never even have to search. Because search– it's not always the right tool for the job. It's limited to being initiated by the job seeker. And this next step will move the API forward, leveraging machine learning to intelligently match job seekers with your company's open opportunities. But let's take a moment and dive into one of the features that I'm extremely excited today to reveal for the first time, which is the ability to search jobs by how long it takes to commute to work. So as a little background, it's been shown that an employee's commute has one of the strongest ties to job satisfaction. And when you're trying to attract and retain the best talent, employees need to be satisfied with all aspects of their job, including how long it takes to get to work.
There are many job seekers that depend on the availability of timely public transportation to get to work. A job that's 20 miles away may take over two hours to get to by bus, which is time that could be spent at home with your family. An employee that has to spend two hours commuting every day is probably going to be an attrition risk. And even for drivers, job search until now has been entirely straight line distance-based. And that's useful if you can afford to fly to work every day. Most job seekers don't have that luxury or a straight-line route to work. And when you're commuting during normal business hours, there's something that slows you down even further, which is traffic. I'm sure you're all familiar with it. With commute time search we're aiming to help job seekers make informed decisions around where their next job is located and be happier, more effective employees. Let's take a look at the demo and pray the internet works. All right. So we've loaded up this quick demo running on the API to demonstrate how you might use the API to allow job seekers to search by commute time.
On the right, you'll see the browser developer console, which is showing the real-time API output. And we've loaded this instance up with some test data for software engineering positions, where you can specify a street address, which is Sunnyvale in this case, a method of transportation, which is either public transit, walking, or driving– and we'll pick driving here– and the amount of time you're willing to commute, which we'll leave at 30 minutes in this case. When we search, we can see the API returns jobs that have street addresses specifically reachable within 30 minutes, as indicated by the blue area on the map. And as you can see, for this job in particular we were able to identify the company's street address and determine that this job is 28 minutes away in traffic. To take a look at another quick example, let's search from an address in the city of San Francisco– say, the downtown area, where we all are right now. And because I'm commuting from the city, I'm more interested in public transit options.
And I live in San Francisco. I have a high tolerance for commute– say, 60 minutes or so. When I search, I can see the extremely non-polygonal set of locations, where we return jobs which are influenced by local public transport options– BART, which takes you up through Walnut Creek, and Caltrain, which takes you down into the peninsula. And we can get an accurate and specific understanding of where I can reach in an hour from the city, which is very important if I don't have a car, for example. You know, this is a brand new way of representing location-based job search, one that's more reflective of the actual experience of traveling between home and work. Sorry, just jumping back to the slides here. We're excited to share this with you today, and that's your sneak peek at the future of the Jobs API, which you can look forward to seeing more about in the next couple of months. We hope you enjoyed this first look at this brand new feature, and we're excited to be making this available to our customers going forward in the near future.
And we really can't wait to see what awesome stuff they bring to the table with them. [APPLAUSE] Thank you. You're probably all wondering at this point how to get started with the Jobs API. If you manage a company's career site– and we already have a number of approved reseller integrations in place at this time– we recommend you contact your applicant tracking system or career site provider to ask about leveraging the Jobs API. And if they're not already a reseller, encourage them to sign up with Google at the website you see here, cloud.google.com/jobs-API. For anyone here that runs an applicant tracking system, or is a career site provider, or a job board, or any other business interested in leveraging the API, please also visit cloud.google.com/jobs-API to register your interest in the service, and we'll get back to you shortly. Our API is still in alpha. And once we've granted you access, getting started with the API is as simple as setting up a new project in the Cloud developer console and registering your account with our service.[MUSIC PLAYING]
Google Cloud Jobs API uses machine learning to help companies build a compelling career site search experience that helps candidates easily find the jobs most relevant to them. The API has been powering the Google career site for months and is also deployed at large companies such as Johnson and Johnson. In this video, you’ll learn how you can deploy the Jobs API on your career site to power your efforts to hire the best people. You’ll also learn how the API uses machine learning to understand the nuances of job titles, job descriptions, skills and preferences, and how it matches job seeker preferences with relevant job listings based on sophisticated classifications and relational models.
Missed the conference? Watch all the talks here: https://goo.gl/c1Vs3h
Watch more talks about Connected Business Platform here: https://goo.gl/CtHNJm