CHRIS BROADFOOT: Hi everyone.
I'm Chris Broadfoot.
I'm an engineer on the Google Maps Developer Relations team.
MARCELO CAMELO: Hi, I'm Marcelo.
I'm the Lead Engineer on the Places API.
CHRIS BROADFOOT: Now, as part of developer relations, I talk
to a lot of developers, and I meet many that use the Google
Places API.
Some of them have a few questions, and it's great to
have you today.
So the first question is, when do I need to provide my
developer key?
MARCELO CAMELO: So you always have to provide a developer
key when using the Web Services API.
You don't have to use the key when you're using the JSAPI,
but you can use it if you're on the [INAUDIBLE] usage on
the developer console.
CHRIS BROADFOOT: OK, cool.
So you mentioned the JavaScript API.
What's the difference between the JavaScript
API and the Web Service?
MARCELO CAMELO: So the main difference is that the
JavaScript API can be used directly within the browser.
And the Web Service on the other hand, can be accessed
from any platform using the programming
language of your choice.
Some services like Place Reports, Check-Ins and Events
are only accessible via the Web Service API though.
CHRIS BROADFOOT: OK, so another one I get frequently
is, can I call the Places API endpoints directly from my
mobile app?
MARCELO CAMELO: Well, technically you can.
Most mobile development platforms allow you create the
Web Service directly.
But doing this may risk leaking your developer key.
And you don't want that to happen because it may lead to
someone else using your key, and using up your quota or
spamming your service.
CHRIS BROADFOOT: So speaking of quota, how do I get more
than the courtesy limit of 1,000 requests per day?
MARCELO CAMELO: Well, you have to go to the developer
consoles and then enable billing on
your Place API project.
Doing so will lift your quota to 100,000 requests per day.
The developer console will ask for your credit card details,
but we only use that for identification purposes.
CHRIS BROADFOOT: OK, so will my credit
card ever be charged?
MARCELO CAMELO: So no, we do not charge for the access to
the Places API.
If at any point in the future, we start offering an option to
pay for extra quota, that'll be done on top of the existing
free quotas, and you have to explicitly sign up for it.
CHRIS BROADFOOT: OK, so since I can't buy more quota today,
what if my app's really popular, and I need more than
100,000 requests per day?
MARCELO CAMELO: Well, if that's the case, you can
request additional quota.
And to do that, you search for the quota uplift form.
And we receive those requests, we look
through each one of them.
We love getting them because it means people are using the
Places API and liking it.
And we try to reply to everything single one.
CHRIS BROADFOOT: OK, so say I have a lot of Places.
Can I add them in bulk through the API?
MARCELO CAMELO: So that's not exactly the use case of the
Places API.
We don't have a functionality for bulk upload of Places.
And the main purpose of the API is to get input
from the end user.
CHRIS BROADFOOT: Another one I get really often
is from store managers.
They have really good data about all the stores.
So how can they make sure they get them into Google+ Local?
MARCELO CAMELO: Again, this is not the main use case of
Places API.
If you have good data about your stores, you have to
upload them through the Google Places Manager's Tool on
place.google.com/manage.
CHRIS BROADFOOT: Another one people get about usage is, how
do I use the sensor parameter?
MARCELO CAMELO: All right.
So the idea with the sensor parameter is to tell us where
you get your location data from.
So if you're doing a search, and the location came from,
say, the phone GPS or Wi-Fi location service, you would
set the sensor to True.
On the other hand, if the search location is not coming
from a sensor-- for instance, if the user is pointing a
location on a map--
you should be setting the sensor to False.
We only use that value for information purposes only, and
it will not influence your results in any way.
CHRIS BROADFOOT: A lot of queries to the Places API
returns references and IDs, and they both
appear to be unique.
What's the difference?
MARCELO CAMELO: So that's a question we get a lot.
On the Places API, we split the Place ID into two separate
attributes--
the Place Reference, and the Place ID.
The place reference you use to fetch details of a place or to
reference a place when you're doing a Check-In or adding an
Event to it.
The Place ID you use to tell whether two places are the
same and also for indexing content to a place.
CHRIS BROADFOOT: So I noticed the reference changes on each
request I do to the API.
So I'll probably use the ID as a foreign key, and use the
reference to retrieve more details.
Should I storing other Place data as well?
MARCELO CAMELO: You could cache Place data
for up to 30 days.
But you don't really want to keep the data for much longer
than that because it goes out of date really quickly.
And you can use the reference to refresh your data.
CHRIS BROADFOOT: OK.
So another thing I notice is, I get attributions from where
the data came from.
Do I need to display these?
MARCELO CAMELO: Only if you want to be compliant to your
terms of service, and I recommend that you do.
That's the first thing we're going to look, if you apply
for a quota uplift.
CHRIS BROADFOOT: OK.
So another great feature of the API are Check-Ins.
So developers ask me, what are they for, what
can I use them for?
MARCELO CAMELO: So the Check-Ins give the Places API
extra signals about the relevance of a place.
And we can use those signals to improve search results and
make them more relevant to users.
So developers should send a Check-In whenever the users
has executed an action that tells us that a Places result
is usable for them.
CHRIS BROADFOOT: So I might get more relevant search
results if I used Check-Ins.
How are search results ranked usually?
MARCELO CAMELO: So by default we use a ranking algorithm
called [INAUDIBLE].
And it uses a number different signals.
For instance, how popular a place is, the number of
reviews it has, its ratings, number of Check-Ins, and other
stuff as well.
CHRIS BROADFOOT:OK, so there's a bit of magic going on there.
MARCELO CAMELO: Absolutely.
CHRIS BROADFOOT: So some developers don't want magic,
and they just want to find the closest place.
How can they do that?
MARCELO CAMELO: That actually also requires magic.
But there is a switch that we call the rank-by switch, and
you can use it to toggle between getting results ranked
by [INAUDIBLE]
or getting results ranked by distance.
CHRIS BROADFOOT: Magic seems to be what Google's good at.
MARCELO CAMELO: We try.
CHRIS BROADFOOT: So one of my favorite features is
autocomplete.
Developers ask me how can I customize the look and feel of
autocomplete?
MARCELO CAMELO: So we use CSS to do all our styling.
So developers can overwrite a [INAUDIBLE] container and
[INAUDIBLE]
item classes in their CSS to change the look and feel of
autocomplete.
CHRIS BROADFOOT: OK, so that's it for developer questions.
I just have one of my own, while I've got you here.
So that is, what are the kind of apps that you'd like to see
developers build?
MARCELO CAMELO: OK, so we do have the expectations that the
Places API will enable an entire ecosystem of
location-based apps.
I'd love to see developers going beyond just offering
suggestions for restaurants and dealing with places like
art galleries, maybe about urban graffiti, apps for
families, apps for kids, maybe apps about sports.
I also want to see apps that help users accomplish very
specific tasks.
And especially, I'm looking for apps where developers have
put their local expertise and knowledge
into the Place results.
CHRIS BROADFOOT: Great.
I'm really looking forward to developers create these kind
of applications.
I think the Google Places API is a really great way to add a
dimension of local data to applications.
Thanks so much for answering these developer questions.
I'm really looking forward in the future to see what you add
to the Google Places API.
MARCELO CAMELO: Thanks, Chris.