Google I/O 2011: Connecting People and Places

Mitchell: Well, good morning, everybody.
Welcome to the Geo track at Google I/O 2011.
Um, I trust you all enjoyed this morning's keynote.
We have a great lineup
of content for you over the next two days.
We hope you'll stick with us, and I'm gonna kick it off today
by talking about connecting people and places.
Uh, my name is Thor Mitchell.
I'm the product manager for the Google Maps APIs
based in, uh, Sydney, Australia.
So what I'm gonna talk about this morning is, firstly,
a little bit about what we mean when we talk about places
and why they're important,
a little about how Google connects people with places,
and then move on to focusing on how you can do the same
in your applications.
So we start at the beginning.
This is Google Maps circa 2005.
Back then, there was no Street View.
There was no maps, uh, My Maps.
There was no Western Europe, for that matter.
Um, so...
So it was, uh, it was a nice, simple world back then.
Um, if you look at the very top,
just, uh, just in the search box there,
you'll see that there are only three options--
You've got maps, a local search, and directions.
Now what's interesting about this,
compared to, um, what we're used to now,
is that Maps allows you to search for addresses,
for geographical entities.
Local search was business listings and points of interest,
and you had to make that decision.
You had to choose for yourself.
Um, what am I looking for here?
What type of thing do I want to find?
Now the thing about that is
it doesn't really map to the way we just think about
the world around us on a day-to-day basis.
If I were to say to you,
or if someone was to ask you right now, where are you?
There are all manner of different reasonable answers
you could give, and the answer you chose
would probably be based on who was asking.
So if it was someone you knew was already at I/O,
they'd--you would probably just say, "Oh, I'm in Room 8."
If it was someone you knew
was in San Francisco, then "Moscone Center."
If it was someone you knew was abroad,
then "in San Francisco" would suffice,
and all of these are places,
uh, in their own way,
and all of them are reasonable answers to this question.
The one thing you're unlikely to say is the answer
your phone would give you if asked this question,
or, at least, I would hope you're unlikely to say that,
'cause I wouldn't be none the--the wiser if you did.
So what we need to do, if you want to bring
location-based applications to mobile devices like these,
that relate to users in the way they relate to the world--
we need to bridge this divide
between this sort of fuzzy notion of a place
and the sort of more geometric model
that, uh, mobile devices use.
Of course, we're sort of fast and loose
with what we consider to be a place.
It can be one of many things.
It can be an address. It can be a city.
It can be a landmark. It can be a natural feature.
It can be a point of interest. It can be a business.
It just goes on and on and on,
and you have to kind of accommodate all that
if you want to make people feel at home with these applications.
So we recognized this at Google, uh, some time ago,
and back in September 2009, we launched Place Pages.
So now every place had a page
where we could aggregate
all the information that we could find about it,
um, including information that we sourced from business owners,
information that we sourced from data providers,
information that we'd crawled from, uh, sites online.
The next logical step to this was actually to--to offer Places
as a first-class citizen within Web Search.
So now you can search for places directly from Web Search,
and this was something that was launched last year,
and this is a reflection of the gradual evolution
of Places as a concept within Google's product
to being a first-class citizen, to being an independent entity
coming out from under the wings, if you like,
of Google Maps.
And that reached its logical conclusion
with the launch of the Google Places mobile app.
Now you can just start from Places.
Um, and Places and Maps are now peers of each other.
You can move interchangeably between them.
Of course, in the developer team,
we realized that places were important there, too.
And we've built a,
um, a, uh, a popular Maps developer platform.
We didn't really have a strong Places story.
So at Google I/O last year,
we introduced the Google Places API,
and the goal of the Google Places API
was really to try and capitalize a--
the development of a-an ecosystem around--
a developer ecosystem around Places
in much the same way that we had done for Maps.
However, we didn't rush into it.
We took it, uh, we took it easy,
uh, and we started just by talking to developers
to get a better understanding of what they needed.
We launched a developer preview back in July,
and we spoke to many, many developers
about what their requirements were,
about what the challenges are in building location-based apps,
and what we needed to do to meet their needs.
Now it was a hugely valuable exercise.
We learned an enormous amount in the process,
um, and we were also very pleasantly surprised
by the overwhelming response from developers.
The downside to this was that there were many developers
who we just couldn't accommodate in the preview,
so if you were in that bucket, um, I apologize,
but if you, um, if you did participate,
we're really grateful for all the great feedback you provided.
And for the last six months or so,
the team has been working hard
to try and take all that feedback,
factor it into the product,
um, and deliver something that will suit the needs
of as many developers as possible.
And really, it's the result of that effort
that I want to present to you today.
So...
first things first.
No more waiting.
As of the end of today,
the Google Places API will be available to every developer.
[applause]
And if you were with us last year,
you'll notice a lot of things have improved,
a lot of things have changed,
um, and I'm gonna go over some of that with you right now.
But if you're not familiar with the Places API,
let's just start with the basics.
What is the Google Places API?
Well, at its heart, it's extremely simple.
You give us a location,
you give us an area around that location,
a-a radius around that location to search in,
we will give you back up to 20 places that match,
and these can be addresses.
They could be points of interest.
They can be businesses.
So to give you an idea for why this is valuable,
and to illustrate the value
of some of the other features we're launching,
I'm gonna use an example.
Now I totally made this example up
for the purposes of this presentation.
However, I don't doubt
that there are applications out there that are similar to this,
so if your application's a bit like this,
I'm sorry.
Um, consider it, a, uh, consider it flattery.
So let's suppose I like sport.
I love sport.
Not actually participating in sport.
That's--that's too hard. No.
I like watching sport.
Um, and I prefer to watch sport with friends
in a bar.
I'd just like to point out--
Comic Sans, always the answer.
Right.
So sports good, friends good, bar good.
What I'm really looking for here is to find that awesomeness
that is the combination of all three.
I'm looking for an app that will help me,
um, help me find places that are showing games,
help me meet friends there,
um, generally, uh, find me that awesomeness,
and so consequently, we'll call this the AwesomeFinder.
Now there's something--
there's something not right about this.
It's like a Web 2.0 application, this.
Ah, that's better. Okay.
So as any good product manager will tell you,
you start out with a product requirements document.
What do we need?
Well, we need to find bars nearby
that are showing games I want to see,
we need a way of sharing my plans with my friends,
and I want help choosing, if I've got many options,
which bar will be the best one for a given game.
Oh, yeah, and then maybe I have to make some money as well.
So what do I need to do this?
Well, I need the name and location of bars.
Okay, no problem.
Google Places API at your service. Sorted.
I'm also gonna need the dates and times of games,
and I'm gonna need to match up those games
with the bars that are showing them.
Now I could go out there and try and source this
from TV companies or from business owners,
but I'm just gonna take the easy option.
I'm gonna crowdsource it.
So this is a photo I took, uh, just over the weekend,
of a bar literally opposite
the hotel I'm staying at for Google I/O,
so this happens all the time, everywhere.
Um, bars advertise what games they're showing.
I'm not sure if you can see that.
There's a list of games at the top.
On the bottom, it says, "Neighborhood Appreciation Day,
$1 off draft drinks."
So you can get all your friends together,
you can get drunk, and there goes the neighborhood.
So...
We want to crowdsource the collection of games--
of these--these, uh, information about these sort of listings
and what--what bars are showing what,
um, so how do you do that?
Well, let's say I'm walking down the street and I see that sign,
I should be able to go, Hey, I'm a great lover of this app.
I'm gonna contribute,
and I'm gonna correlate these, uh, these games with this place.
So the first thing I need to do is identify the bar I'm at,
and that's where we come to the check-in.
Now check-in has kind of become this, uh,
this very common notion over the last year or so,
um, but it's really a very simple concept.
It's just a way of telling an app
the place you're currently located at,
in order to--for it to then offer you
you know, opportunities around that--
sharing it with your friends, perhaps loyalty offers,
various other things, but it's cool.
The check-in is very simple, and you're here--
people talk about, uh, you know, check-in is over and so forth.
Well, check-in is just a feature.
Saying that--saying that the check-in over--
check-in is over is saying like the log-in is over, right?
So colors are probably not helping us a great deal here,
but what we have here is, um, a map,
uh, very nearby, actually,
um, and then in the middle here, we have our location,
and then there's a-a circle around it
that is the ambiguity, if you like,
in my location signal-- the margin of error
that I'm getting from my location-based device.
So what my phone is saying
is that I am somewhere within this circle,
which you can barely see, but it is there.
So what we need to do
to initiate the process of a check-in
is perform a Places API search
for this point with this radius,
because, essentially, whatever I need to check into
should be in that area.
In fact, just as a tip,
I would say, if you're building such an application,
pad a little,
because one of the, uh, one of the things you might notice
is that this circle sort of dissects Del Taco just here,
um, but the actual point feature of a Del Taco
is actually outside the circle,
so, eh, add a little bit of a margin there.
So what would the flow look like for this application?
Well, I would get a list of places.
Um, I'd choose one, I'd check in,
and then I would be able to fill in,
uh, the games that are, uh, that are being shown at that place.
Now the more eagle-eyed of you will notice
that this looks like a real application,
and this looks like a real application,
and this looks something like I knocked up in a text editor,
and you're not wrong.
In fact, what I've got here,
and what you'll see in a number of screenshots
over the course of the next few slides,
is a reference client that we've built for the Places API--
we've built one for both Android and iPhone--
um, that just shows you the--the core features
and gives you somewhere to start,
and we'll be publishing the source code for those
as a code sample, um, in the--
in the not-too-distant future.
Okay.
However, if you look at--if you look at the--the list of places
on this screenshot in detail, there are some of them
which are clearly not gonna be showing sport,
for example, Britex Fabrics.
Clearly, when you're looking at the Google Places application,
the one that we had-- I mentioned earlier,
that you have on your phone, we have no sense
of what your intent is in looking for Places,
but in this particular application,
we know exactly what kind of things you're looking for.
We know you're gonna be looking for bars,
so why show anything else?
Well, we can help you there,
because the Places API now has a catalog
of over 100 different types,
and you can choose one or more of these types,
and say, I just want to receive Places of that type.
Now I'm gonna show you the impact of this.
This is a-a search, uh, nearby
with no type filtering at all,
and you can see plenty of Places.
No bars, as it happens, Switch to bars--just bars.
So it's not that type filtering actually just removes non-bars.
It actually gives you more space in your results for more bars,
um, and greatly increases the chances
that the place you need is gonna be in there.
Okay.
So sometimes, though, even that won't cut it.
If you happen to be somewhere
where there are just a lot of bars,
like Austin, for example,
um, you may still find that it's not--
the Place you need is not in that set of 20 results,
so you're gonna have to search.
But searching on mobile phones is a pain,
especially if you're going from bar to bar
when you're doing it.
So we're gonna try and make that easy for you, so today,
we're introducing a new feature for the Places API,
which we call Autocomplete.
Autocomplete is based on the same technology
that drives the, um, feature
on the Google Maps search-- search, um, field,
which, um, offers predictions
as to the places you're looking for as you type.
You can now integrate that same technology
into your mobile applications.
You can choose to say, I just want you to offer me addresses,
I just want you to offer me businesses, or--or both,
and you can also give a hint as to the location of the user,
um, in order to-- to bias the results.
So let's see how well this works.
This is exactly where we were a minute ago.
We were somewhere--ooh, sorry. Back, back.
We were somewhere not far from here,
um, about here somewhere,
and this is a list of bars,
but let's say I want to check into Jillian's.
Jillian's is a bar just opposite the Moscone Center,
if you're not familiar with it.
It's right over the road,
and it's conspicuous by its absence from these results.
So what I did is I took
the Places API Autocomplete service,
I gave it, um, this location, this same location,
based on this map, and I started typing.
Well, let's see how far I need to type.
[humming]
One,
two.
Problem solved.
So...
if you still can't find the Place you need
after you've done that, the chances are,
we don't have it, and that does happen sometimes,
because Places data is continuously changing.
About 20% of Places we see,
um, in our index, change every year,
and keeping up with changes in businesses--
businesses opening, closing, moving, renaming--
is one of the biggest challenges
of managing this kind of a service,
but your users are out there, out and about every day,
and they will see new Places very quickly,
and they will want to check into them.
In fact, particularly when it comes to things like bars,
there's a certain, um, there's a certain cachet
in knowing about the hot new bars
and being one of the first people to go there,
so people will start wanting
to check into places really quickly.
Now it's already possible
for a user to submit new Places to Google for Google Maps.
They go into a moderation pipeline, we check they're okay,
um, and assuming they are, then they'll get published
and everybody will benefit, and that's great.
The problem with check-in apps
is people want instant gratification.
They want to be able to check into a place
as soon as they've added it,
and if they are unable to do that,
it's more likely that they will generate more Places,
and then we'll build this, um, virtual cycle
of adding Places and checking into Places,
so we need to be able to support that, too.
So for that reason, we have a Report service,
and this allows you to add new places immediately.
So you can submit a new Place to us,
and that new Place will be reflected in subsequent searches
made by your application instantaneously.
Now at the same time,
we will take that Place and we will moderate it,
and assuming it moderates well, it will become available
to all applications using the Places API.
So you don't have to worry about other apps
spamming your app with Places that you don't want
or that aren't good,
um, but at the same time, all those apps
that are generating good data, good content,
you will benefit from that use as well.
We also have a Delete service,
obviously, so that you can crowdsource, if you like,
your, uh, your maintenance of your--of these Places.
You can, uh, allow your users to indicate
whether newly added Places are good or bad,
and you can choose to delete the ones that,
uh, that it seems your users don't agree with.
So here's just a quick visual overview of how this works.
Every Places API application
has its own little private set of Places
that have been added by its users.
They get blended in with your search results
that come from Google Places,
um, and then all those changes also get passed into moderation
and then ultimately end up in Google Places,
where they'll appear not just in the Places API,
but also on Google Maps, across all the other properties
that Google has that exposes Places.
Okay, so we're in good shape.
We have, um, we can implement the check-in.
We can collect that information about the bars that we need
from users, and the--the games they're showing.
Um, we can, uh, we can find bars
if they're not showing up in our initial search.
We can add bars if they're missing.
So now we can move on to the next step,
which is, okay, I'm out and about.
I want to decide where to go.
So just showing you what games are around
is relatively straightforward.
You have a list of all the Places
that people have checked into and associated,
um, associated upcoming games with,
so you can show those on a map.
You can also encourage people to check into bars
when they arrive to watch a game,
not just in order to add new information
or new games to that bar.
So you can share that with friends.
You can see where your friends are watching games.
You can plan ahead.
But it would be good to know,
you know, if I've got a few choices,
where shall I go? What would be the most fun?
So what makes a bar fun
when it comes to watching a big game?
And to a large extent,
it's simply the number of people there.
You want atmosphere.
You want lots of like-minded people enjoying the game.
So as a general rule, for the most part,
the fun of a bar during a game
is a function of the number of people watching it
that increases until it gets to a critical point,
where the bar is so full
that you can't actually reach the bar,
and then it begins to kind of fall off
until you get to the point where you can't actually
reach the bathroom, and then it's no fun at all.
So as long as we can keep on the left-hand side here,
we'll be in good shape.
For the most part, in most cases, um, I think
popularity of the bar would be a good indicator
of how much fun it is to be there during that game.
So how do you assess that?
Well, you have the check-ins, and the check-ins are
a reflection of the popularity of that bar.
You--it's a signal as to how many people are there,
and check-ins, generally speaking,
are a great proxy for that,
um, both over short periods of time and longer ones.
So on the left here, we have a-a couple of mocks
of the kind of check-in activity you might expect to see
over the course of a day at two different venues.
At a coffee shop, you would see,
you know, a morning spike as everybody gets their hit,
and then, uh, another spike at lunchtime
that's a little lower, and then it would
sort of tail off towards the end of the day.
At the ballpark, you'd expect to see nothing for days on end,
and then suddenly, there'll be a massive rush of check-ins
when the game starts, and then it will die away.
So similarly, we've got on the right there,
we've actually got a-a heat map
that we generated based on Hotpot ratings
that were collected in Austin over the course of a week,
and that also indicates
the--the Places that are most popular.
This bright sort of patch here is, uh, 6th Street,
which, if you've ever been to Austin,
is kind of the--the heart of the downtown,
um, nightlife area.
Okay, now...
let's take this ballpark example,
um, just because it's such an extreme case.
If I am stood outside the ballpark, at--
let's take the ballpark here, in San Francisco, AT&T Park.
I'm stood outside the ballpark
at about, you know, 10:00 in the morning.
Am I more likely to check in there
or the coffee shop next door? Well, probably the coffee shop.
But if I'm checking in in the vicinity of the ballpark
right at the beginning of a big game, it's far more likely
that's actually where I want to check in,
so we should use those signals.
We should use those signals, um, not just to measure popularity
but to then influence the ranking
of the search results we give you.
So we're also enabling you to do that.
If you indicate to us
the Places where your users are checking in,
we will give you app-specific personalized reranking
of your search results in real time,
based on the activity that you're seeing.
Now I want to stress that the Places API,
like all of our Maps API Web services,
is developer-authenticated,
so we have no knowledge of the end user here.
We don't--nor do we ask for it.
Um, this is app-specific ranking
based on anonymous check-in signals
that you provide us for this purpose.
Okay, so that's an overview,
and I want to just give you a-a brief recap,
and if there are, um, two slides
that I want you to take away with you from this whole talk,
it's this one and the next one.
So four key services--
Search, Reporting, Check-ins, and Autocomplete.
You'll see there, 100,000 requests per day,
completely free, to the Search service.
Um, you can filter by name,
and you can also-- so you can filter by type,
but you can also filter by name in the Search service,
but it doesn't have the Autocomplete functionality.
That's--that's separate,
and designed deliberately to be more lightweight,
and real-time, check-in-based reranking
and delete Places instantly, and also get the benefit
of all those Places that are being generated
that get positively moderated.
Second slide--"Key benefits."
So what are--what do we feel are the strengths of this API?
Well, effectively, the strengths of this API
are the strengths of Google.
It's comprehensive.
We have, um, detailed good coverage.
Um, it's accurate. It's curated. It's moderated.
It's clean.
You won't see lots of park benches
and "my mate's house" and...
Um, I was, uh, I was at South by Southwest in Austin,
um, a couple of months ago,
and I was stood in a queue that ran five blocks
from a party that was sort of the opening night kickoff
and as I was stood there, there was a guy
who was using a location-based check-in app
stood about 10 meters in front of me.
He was in the process of adding a Place
for the queue for the party.
I turned to the person I was with and said,
"This is my data quality problem, right there."
It's--so it's clean. It's also fast.
We sort of take that for granted at Google,
um, that everything has to be fast.
Um, the Maps APIs are known for their reliability,
and, crucially, it's global.
This is a-a heat map
of, um, Place locations that we've served up,
um, and you can see--
if you--when the day inevitably comes
that you want to expand your application
outside these borders, we are ready and waiting.
And there's one more thing--
We have this Web-based Maps API.
You may have heard of it,
and we wouldn't want to leave it out in the cold,
so we're also launching today
a set of classes in the Maps API
to bring the same services into the Maps API.
In fact, these services-- the Place Search service
and the Autocomplete service-- were the very services I used
to build the demos that I showed a moment ago.
Um, so all these features will be also available
to Web-based applications.
Right, and that's-- that's the overview from me,
and now I'd like to, uh, invite,
uh, a good friend of ours up to the stage.
Um, so I'll let you introduce yourself.
This is Seth, and he's gonna talk a little bit
about how, um, SCVNGR, um, his company,
has benefited from their use of the Places API.
Priebatsch: Cool, cool. Thank you.
[applause]
Priebatsch: And hit number 3.
All right, thank you. Uh, hi, everyone.
My name's Seth Priebatsch.
I am the Chief Ninja of SCVNGR
and, uh, and I'm on my last slide already,
so I have to go backwards. Uh, hold on a sec.
Voilà.
Uh, so I'm just gonna talk for a couple minutes quickly
about sort of a real-world use case.
We integrated with the Google Places API
about five or six months ago
and have had a phenomenal experience with it,
and so I'm up here to sort of sing the praises of it
and very realistically tell you about how we took SCVNGR
from being something very, very small--
uh, we actually launched at Google I/O here last year--
uh, to something very, very big,
in large part on the back of the Google Places API,
letting them do a lot of heavy lifting for us,
and it's been--it's been an awesome experience.
So first, very quick background--
Some of you may have heard of SCVNGR.
A lot of you probably haven't,
so 30 seconds on, what is SCVNGR?
SCVNGR is a location-based game, and it's a very simple game.
You go places, you do these things called challenges,
quick, fun things to do at Places,
and you can unlock rewards.
So you can go to a place. You can check in.
You can snap a photo. You can leave a comment.
You can also create your own challenges,
and anyone can build these challenges,
so sort of our goal is to create what we call a game layer
on top of the world, where everyone is both building
and playing this game at the same time.
And some quick history-- like I mentioned,
we actually launched this product last year at Google I/O,
um, with 0 users.
You know, you sort of always have to start with 0.
Six months later, we had half a million users.
Three months after that, we had a million users,
and somewhere in that period,
at around the 5- or 6-month mark,
we switched to the Google Places API,
um, in large part to get better data
and to be able to handle a lot of the load
that we were coming under, uh, to make SCVNGR perform
fast and seamlessly for our growing user base.
The Google Places API is also incredibly reliable,
and one of the things I want to talk about
is that you can use it to build a great consumer experience.
We're nearing a million and a half users
and growth is accelerating like mad,
but you can also build a really big business,
a meaningful enterprise business on top of that.
Uh, we've got over 3,000 enterprises
building on SCVNGR, from Coca-Cola to the Smithsonian
to Sony to GameStop, all the way to the U.S. Navy,
and all of that is relying on a core Places database,
uh, which is provided through the Places API
and through Google Places, and it is reliable,
and it's something that you can get,
you know, a really big business and large enterprises
building off of and supporting.
One of the recent examples of load that we came under
and--and sort of a beautiful use case
of being able to get the right data from the Google Places API
was a campaign we ran with Buffalo Wild Wings,
where, over 6 weeks at their 700 locations,
180,000 unique people played SCVNGR, checked in,
did something like 1.2 million challenges,
unlocked rewards, and we didn't have to add
a single Place to the database.
There were 0 user places added for that entire campaign.
They were all already there from the Google Places API.
Huge campaign, very successful, and something that we,
you know, were able to kind of provide turnkey,
just adding our, you know, our unique secret sauce,
the SCVNGR game mechanics, and building off of
the infrastructure from Google Places.
So enough background on, uh, on--on SCVNGR.
Uh, you know, the interesting thing that we want to talk about
is what Google Places let us do, and where I really want
to take this is from sort of the core of what SCVNGR is,
which is our mission.
Our mission was to build the game layer
on top of the world, and to do that, we needed
a couple pre-requisites, right? We needed game mechanics.
Cool, uh, we could figure that out on our own.
We needed a game platform, we needed players and builders,
and we needed to be able to connect them to places.
We needed to be able to connect them to the world,
and so we went on this big quest for the world,
and that's the quest that eventually led us
to Google Places and to the Places API,
and if you're looking to connect people to the world,
and, of course here, by "the world,"
I mean something a little bit more specific
than just everything that's around us.
I mean having the knowledge to connect people
to the places that matter. You have a couple options.
We thought about building it ourselves.
We thought about, you know, asking our users
to create these Places for us, to crowdsource them,
to scrape it from the Web, to do whatever we could
to try and get a good Place database.
We looked at SimpleGeo, and we spent a lot of time
working with those guys, and they actually have
some really interesting things that we're working on,
uh, that they're working on.
We ended up working initially with GeoAPI when we launched.
We did not launch with the Google Places API,
and later did a transition to that.
GeoAPI later became part of Twitter.
Um, it has now been shut down, and we actually--
we did the transition several months before they--
they deprecated the API,
but one of the interesting parts of doing this transition
is we were sort of in a unique position
to do some real comparison
between two relatively full-featured Places databases,
and I'll give some data on what that looked like afterwards.
Um, and then there's also the Facebook Places API, which,
if you guys are interested in location-based services,
you've probably spent some time looking at.
And the reason why we ended up transitioning
to the Google Places API over the Facebook Places API
is that, um, you know, aside from quality of data
and some other reasons I'll go through in a second,
one of the big restrictions on the Facebook Places API
is that to make any requests, it is all user-authenticated.
Um, and as Thor was mentioning earlier,
uh, Google Places is developer-authenticated,
so you can have, a, you know, an app and you can get the Places
and you can bring them into your app
and do whatever you want, and protect user privacy
and enable your users to have a clean and safe experience.
With the Facebook Places API,
all queries have to be authenticated by the user,
and that was something that we just weren't able to implement,
and so we made the decision about five or six months ago
to transition to the Google Places API
for, sort of, these five big reasons.
One is, you know, breadth of data.
There's a huge amount of data on the Google Places API.
It's all over--I mean, it's all over the States.
It's all over the world.
You know, Places that you-- that you want your users
to be able to use your app, it's there.
There's a tremendous amount of depth of data.
Most of our activity happens in big cities,
so we don't just want lots of data everywhere.
We want the right data. We want to be able to dig in deep.
We found that with the Places API.
Quality of data is phenomenal.
If you've got the Place, you also want to be able
to get the phone number. You want to be able to get the URL.
You want to have the right address.
You want to be able to link to places that might have reviews.
All of that comes standard with the Places API,
and it's been really valuable for us.
Speed & reliability is--is super key.
We've got a lot of people
hitting our servers all the time.
The Google Places API returns quickly.
It returns reliably.
We haven't had a single issue, and we work with lots of APIs,
which are, you know, some are more reliable than others.
and so we're very happy with both the speed and reliability
and consistency of all of that, and also the road map
that Thor and his team are taking this thing down.
They've started adding great categorization,
some of the things they talked about today--
just really interesting features, which make our jobs,
as location-based app developers, much, much easier,
enable us to focus on what we're good at,
the unique component that we provide.
In our case, game mechanics. In your case, it might be
enabling you to help, you know, find your friends at bars,
but focus on what you're good at
and outsource a lot of the hard work to the Places API,
and so the future improvements are a key part of it.
And the last slide I want to sort of go through
is some of the results we saw for this.
After we did the transition,
we had a 41% decrease in "frustrated" location queries,
and this concept of a "frustrated" location query
is one that we developed to try and figure out how to judge
how our users are interacting with the Places we've got.
When you load up SCVNGR,
it's gonna show you Places around you,
and if you find the place that you want,
you're gonna click on it immediately.
If you don't, you're gonna have to either load more
or do a search, or do something to try and find that Place,
and we define that as a "frustrated" user,
someone who opened up the app
and did not get what they want immediately.
And the number of people who opened up the app
and did get what they want immediately increased hugely,
and the number of people
who had to actually do those searches dropped by 41%.
Um, and this is kind of an abstract term
to keep track of, a "frustrated" query,
but it's really important
if you're building a location-based service
that when they open your app, that the Place they want,
that the Place they're at is there immediately,
and dropping that frustration by 41% was huge for us.
Second is that the Places added per thousand queries
dropped by almost threefold,
and this is how we keep track of the quality of our database.
You know, over a thousand queries,
a thousand people opening up their phone and saying,
"Hey, show me the places around me."
How many of them have to actually add a place?
And it dropped from 60 to 22
after we transitioned to the Places API.
Again, a huge increase
in just basically quality of interaction for our consumers.
There was a 62% drop in reports of incorrect Place info.
You know, this Place is here, but the address is wrong,
the phone is wrong, the Web site is wrong,
you know, something about this place is wrong.
It's just a much higher quality data set,
and something that we've been able to now help in improving
through some of the things that Thor mentioned as well.
And, of course, international expansion comes standard.
We are only U.S.-focused at the moment,
but when we're ready to go international,
when you guys are building apps
and are ready to go international,
obviously, the Google Places API has huge support for that,
and that's one of the things that we found
in other location databases-- it's just hard to come by,
so a really, really great asset.
And the final one, which has just been wonderful for us,
in working with lots and lots of different APIs--
it's been up all the time.
It's been fast. It's been reliable.
We haven't had any issues, and if you're building,
you know, a key part of your infrastructure,
and if you're building a location-based app,
you know locations are as key as it gets.
Having it be up all the time is really, really critical.
So that's sort of my quick use case story
on the Google Places API, and I'll pass it
back to Thor now, but thank you for your time,
and have fun building with the API.
[applause]
Mitchell: Thank you, Seth.
Okay.
So that's all well and good.
How do you get started?
So we have a bunch of documentation
that, uh, that's been posted.
You can go to, uh, code.google.com,
obviously, is where Google keeps all its API documentation,
and the Places API is no exception.
There's separate documentation for the Places features
I mentioned that are also coming to the JavaScript API.
If you're not a big fan of long URLs,
I'm sure your search engine of choice can help.
If you need to--if you want to sign up to use the Places API,
you'll need to get a Google APIs console key.
Now if you've used any of the existing
Maps API Web services, um, this will be new to you.
The Google APIs Console
was a service that launched a couple of months ago,
um, that is a sort of a dashboard for API use,
all in the manner of APIs that Google offers.
It's a really nice, tidy way to look at, uh,
to manage your use of the service,
to manage your keys, to check your usage, and so forth.
Um, and then I encourage you to go to our follow-up session.
As you can tell, this is more of a broad overview of the service,
and I'm sure many of you
want to get stuck into the nitty-gritty details.
So the tech lead, the lead engineer for the Places API,
will be presenting a session tomorrow at 3:00 P.M.
It's entitled
"Location Based App Development Using Google APIs,"
and it's essentially just going right into the,
uh, the thick of using the Places API.
Okay, so, uh, you'll start to see these
as you go through I/O sessions.
We have a, uh, feedback pages set up for every session,
and we'd love to-- to get your thoughts
on how you feel, uh, whether you feel this was useful.
We also have hash tags for each of the tracks at I/O this year,
um, so feel free to use those.
And with that, um, we'll start with Q&A,
and, Seth, you want to join us?
[applause]
Mitchell: [laughs)]
Priebatsch: [speaking indistinctly]
Mitchell: Yes.
man: So, um, we do a lot with location-based,
and what we're noticing is that the young kids--
they're constantly really excited
about sharing their location,
and I'm seeing, like, the younger generation,
they're not worried about privacy as much,
and they're really out there.
Like, me, I want people to know where I am at all times
so they can always get in contact with me,
and I'm wondering--
do you see, like, the younger generations coming up--
they're not worried about privacy,
they're really out there,
they really want to have the connectivity,
and just, you know, just really engaging?
Mitchell: Do you want to-- Priebatsch: Sure.
So I-I think that what we're starting to see
is--is that, you know, across all ages
and all demographics and everything,
people do want to be connected to places.
You know, when people, um, spent a lot of time at places,
there are places that they love, and every different group
has important places they want to connect--be connected to.
Some people love museums. Some people like bars.
Some people want to hang out at malls,
and so we're seeing a general trend
that more and more people want to use these types of services,
and I would agree with you in sort of a broad overview,
that, um, you know, the younger generations are more bold
about sharing information into a digital world.
But even then, you still want to be careful
to, you know, protect privacy,
and I think that in many ways,
some of the things we talked about earlier,
about being able to proxy that through a developer key
and then give users control over--Hey, I do want
to share this data, and I know who I'm sharing it with,
um, and people will get more and more comfortable with that
as they get more and more educated,
but still a valid concern for lots of people out there.
Mitchell: I also think it's beholden on us
who work in this industry,
and who are aware of the consequences
of, you know, privacy leaks or, um, and the sort of--
just the longevity of information online,
to protect people not only from concerns now,
but concerns they may have later.
So their--their feelings about privacy may change over time,
so it's important that we sort of optimize
for, you know, the worst case, if you like.
man: Loved the talk. Mitchell: Thank you.
man: Can you talk a little bit more in detail
about the moderation process
and how Places will eventually get selected into it or not?
Mitchell: Yeah, um...
yeah, if you could, that'd be great. [chuckles]
Mitchell: This is Jen Fitzpatrick,
who's a V.P. at Google on local.
Fitzpatrick: Hi, everybody. So, yeah, the moderation process.
Um, so we put a lot of effort
into trying to make sure that the Places that we,
uh, the Places that we surface
are actually, uh, legitimate businesses--
are places in the real world, uh, right?
Um, and so we have a variety of means
that we use to do that verification,
um, everything from, sort of using, you know, using humans
to actually, you know, sort of verify that the business exists
to, um, sort of corroborating,
you know, sort of other data from across the Web,
um, and basically looking at all the signals that we can
to try to essentially verify that--
that both the existence of a place, um, is, in fact, real,
um, and that the data that we have about it is correct.
man: Is there any SLA, in terms of, like,
you know, if you add a place in and it is valid,
that within 30 days, you'd probably see it come in,
or a week, or...
Fitzpatrick: We don't currently have an official SLA.
We're obviously looking to make that turnaround
as fast as possible, but there's not a--
there's not an official SLA at this point.
man: Thank you.
man: So Places or location-based services
work great when I'm in my home country.
But when I am traveling, the data charges are exorbitant,
like, $20 a megabyte, and I can't really use
the Places and these apps when I'm traveling,
and many people do that for vacations and business.
So we're trying to solve the problem with an app,
um, and the only way we had--
uh, to have the top Places made available offline,
that they can synchronize and take it with them,
uh, for cities,
and the only way we had so far was to build it ourselves,
and pretty much like what you had on your list on the top.
So how can this new API help us automate some of that
and take some of the subset of--
like a Most Popular Places offline with me
for specific cities that I'm traveling to?
Mitchell: So the API as it's currently designed
is certainly very focused on,
um, finding places near a user at that moment in time.
Um, we don't really have a model for saying,
um, can I precache all the Places information
in a certain area, um, and there are, you know,
some sort of licensing complexities
around doing that.
We do allow sort of a limited amount of caching
for performance reasons,
um, and, you know, you can refresh cache data,
um, but it needs to be--
it needs to be data that was originally requested
relating to a real user query,
rather than sort of an offline operation.
So, you know, in truth, I would say it's not a use case
that we are able to cater to right now.
man: Okay. Mitchell: But this is
the kind of feedback that's very valuable,
so, um, one thing I should have mentioned
is we do have a, uh, an issue tracker,
where you can go and report any concerns you have for the API
but also request features.
man: But in the meantime, uh, caching that locally
in our own database and building our own app--
that may not be allowed by licensing,
and so the only option is to build our own
popular Places database for taking it with you?
Mitchell: [chuckles) Brian sat up there.
Do you have something to say?
man: The answer is basically yes.
man: All right, thanks. Thank you.
man: Hi. Um, one of the problems I run across as a user
is when I go to check into a Place,
and there's a bunch of user-created events,
like for when I have Movies in the Park,
you'll go and you might see a Movies in the Park.
You might see this park name.
Is there any plans in the future
to separate events from Places
or allow you to check into an event at a Place,
or, um, without creating ten different things,
like today, when I checked into Google I/O,
but it's also the Moscone Center.
And--and how do you deal with events at a location?
Mitchell: So the short answer is yes.
Um, we thought about this at great length, actually.
I mean, one of the benefits of the developer preview we've had,
um, and also looking at, you know,
a lot of the popular sort of location-based apps out there,
is we can get a very clear sense
of the way people are likely to use these types of apps
and how that will impact the service,
and clearly, events, you know, are a-a big part of that.
One of the--the things we, um, we toyed with
was, well, is an event just a type of place?
You know, is it just a type of place
that has an expiring date on it?
And we decided, ultimately, that no, it's not.
An event is actually a property of a place,
and consequently, we needed, in order to do this right,
we needed sort of an extra layer of features
on top of the existing Places API,
where you can attach events to places,
you can check into events, and so forth.
So that's something that we actively planned to do,
but we, um, it's not something we were able to get done
um, right now, in time.
man: Thank you.
man: So at--you started your presentation
speaking about the granularity
of search return, uh, results,
talking about Moscone Theater in San Francisco.
Um, taking that example further,
uh, we're here in Room 8.
If I was to do a search on Room 8,
you know, it needs to be in the context
that I'm here at this event, um, but further to that,
the returned result would be in this area on Google Maps,
but is there any plans to take that further,
to perhaps step inside the building
and demonstrate where we are or where--where the--
where we should go for Room 8 within this conference?
Mitchell: Do you mean from a mapping perspective
or from a check-in perspective?
man: Yeah, from--so-- from the mapping perspective,
to visually demonstrate to the user,
um, or do we--should we build custom layers
when--when that occurs,
or what's the best practice for that?
Fitzpatrick: We don't currently have plans along those lines,
but it's a great idea. [chuckles]
man: Thank you.
man: I just want to thank you
for releasing the Places API for us all to use.
It's really great, and I'm really excited
to see the focus on Autocomplete.
Um, for--for Web users, sometimes the easiest way
to bias a search result for Autocomplete
is to use their I.P. address.
Is that going to be an option that we--that we can use
to bias, uh, Autocompletes?
Mitchell: Um-- man: And location searches?
Mitchell: Right now,
the service doesn't automatically support that.
Um, I'm trying to think whether there is--
I know that we previously had a, um,
uh, I think Gears--
Google Gears had an I.P.-based geolocation service,
but I'm not sure whether we still have that.
Um, no. I'm being told
by more learned minds than my own that we do not.
I think, in truth, that, uh, that is the right abstraction.
I'm not sure I would want to put that specifically into this API.
I think it's more useful to be able to say,
for a given I.P., have the location,
and then you can use that in many different Places.
So, you know, that's something that we can look into.
man: Okay, thank you.
man: Is there a "Natural Features" category?
I'm thinking of a use in a botanical garden
or arboretum. Mitchell: Yes, there is.
Yeah. I would--in the interests of full disclosure,
I would say that it's mostly large-scale features right now.
Um, you know, uh, parks-- sort of national parks
and volcanoes and things like that.
but, um, you know, the nature of the category theme
is that you can add Places and you can--
any Place that you add, you can tag with one
of our existing categories, and you can send--
man: And how would moderation fit in that category?
Mitchell: You know, I doubt we had to face that... [laughs]
um, until now, so I'm not sure, in all honesty.
Um, but, yeah, I-I will-- I'll be interested to see.
[chuckles]
man: Hi, thanks for doin' this. It was informative.
Um, simple question-- Support for GAPE?
Mitchell: For--
man: Google Apps for the enterprise.
Mitchell: So this is integrated into App Engine, or...
man: No, integrated with signing in
from your enterprise account, as opposed to GMAIL.
Mitchell: Oh, I see.
So, um, the authentication scheme we use
is tied into the Google APIs Console,
so, uh, essentially, the way the Google APIs Console works,
if you're not familiar with it,
is that when you log in for the first time,
you can create projects,
um, and each project has a key associated with it.
And any given project can have multiple owners,
so you can associate multiple Google accounts
with a given project, so that projects don't get orphaned
if one person's, um, not available.
I'm not actually sure,
um, what the, uh, Google Apps account integration
into Google APIs Console is,
but it's something I'll be happy to look into for you.
man: Well, I think my--so-- I'm pretty sure
you can't check in from an enterprise account today,
so forward-- Mitchell: Sorry, you mean a--
man: Using a latitude, let's say.
Mitchell: Right.
man: So where's that on the road map for people
that primarily use Google from an enterprise perspective?
Mitchell: It's worth--it's worth me stressing, actually,
that the check-in service as part of the Places API
is just this anonymous, um, reranking model.
man: Okay.
Mitchell: It's totally unrelated to the check-in feature
that's now part of Latitude and Google Maps.
man: Oh, it's totally separate. Okay.
Mitchell: Yeah. So, um, but I know that there--
that there has been, you know, interest expressed
in, um, enterprise features for Latitude.
It's not something that I am, you know, am fully aware of,
but I know there's-- there's interest in it.
So if it would help, I can probably connect you
with the right people to ask. man: Okay, thanks. Okay.
man: Uh, related to the earlier point
that 20% of the Places in the database,
uh, change every year--
Is there any thought been put to making the API queriable
from a historical perspective,
so where you would provide a date as a parameter
and sort of get what was around at that time?
Fitzpatrick: As far as I know, it's not something we've, uh,
it's not something we've looked at.
Mitchell: Yeah, but I like the idea. [laughs]
So I would say log it as a feature request.
It's certainly interesting.
man: Okay, I've seen the premier version of the API.
What are the advantages of this premier version,
and are there any limitations to the free version?
Mitchell: So the Google Maps API in general,
the overall family of products, has a premier version,
which is an enterprise version,
and Maps API Premier has a number of advantages,
including broader licensing rights, for example,
using use on the Internet or in for-fee applications,
also higher quotas on geocoding and directions,
and, uh, and elevation.
Um, and right now, however,
the Google Places API is,
uh, although we're now making it available to everybody,
it's still considered to be in Google Code Labs,
um, which is sort of the initial stage
that an API goes through,
where it's still being developed and evolving,
and we need some flexibility just to adapt to feedback.
Um, as a general rule,
Labs APIs are not included in Premier
because enterprise customers have much stronger
backward compatibility expectations on an API,
so, um, what we anticipate happening
is that the Places API will graduate from Labs
um, you know, in the not-too-distant future,
once we've, you know, we're comfortable with it,
it fits everybody's needs,
and then it will be integrated into Maps API Premier.
Um, and until we get to that point,
I couldn't say what the specific benefits will be.
Um, I would imagine that, at a minimum,
you know, the same licensing, technical support,
service level agreements, and so forth, would be,
um, you know, would be the most likely possibility,
rather than necessarily specific feature differentiation.
man: But no limitation on the usage so far?
Mitchell: So currently, the API, um, allows you to perform
up to 100,000 queries per day for free.
man: Thinking from a perspective of emergency response
and/or marketing,
uh, if you can plot a polygon
or put a point with a radius
and get a summary report
about how many people are connected--
how many--how many bars do you have,
how many hospitals,
but instead of having them brought in
as points with a lat long, individuals,
to summarize the reports,
is it possible, currently,
if, let's say, we bring it into the Fusion Tables
and then summarize them there and spit them out?
Mitchell: Um, so just so I understand,
this was getting an assessment
of a number of businesses of a given type in a given area?
man: Yeah. Mitchell: Okay.
man: So either you trace a polygon, or you put a point
and you put a buffer around that point,
and you want summaries, not just a bunch of points.
You want summaries--how many bars, how many hospitals...
Mitchell: Right.
man: for emergency response or for marketing purposes.
Mitchell: Sort of density, essentially.
man: Yeah. Mitchell: Yeah, so, no,
that's not something that we have right now,
but, again, it's something that it sounds like,
you know, we could-- we could consider.
So if you just do a search for Maps API issue tracker,
you'll see there's actually a link there
for logging Places API feature requests specifically,
and, you know, I'm working to collect those.
And also, I should mention that,
um, you can star feature requests
to indicate your interest in them, and then
that ends up ranking them for us in terms of popularity,
which is something that we take very seriously.
So I recommend everybody, in fact,
even if you don't have an idea in mind,
keep a regular eye on that
and just flag the things that you find interesting,
and that will help us prioritize.
Okay, it looks like that's all the questions we have,
so thanks very much, everybody, for coming,
and, uh, enjoy the rest of your I/O.
[applause]