Q&a for Getting Started with The Google Places Api

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.