Want a Google map? Well, Google has blocked the road – so you’ll need new directions.
This article was to begin as more of a technical insight into the repercussions of what, at first, seemed like a fairly minor change to the Google API terms of service. After talking to colleagues about it and seeing their eyes glaze over after about a minute I remembered that generally only technical people find technical stuff interesting. When it comes to the internet, for the majority of people it boils down to two states. Working or not working, on or off. Binary.
That segues nicely into the initial reason for writing this. Something wasn’t working. We had been developing a couple of websites for a client over the past two or three months and, as is usual for one of these projects, we’d been using our development web server so that the client could keep an eye on what we were doing.
The two websites have, as the majority do these days, a customised Google Map on the contact page and they were working fine right up until the point we wanted to make the sites live. Luckily we have procedures in place that allow us to view the “live” experience before things become available to the wider world and it was at this point that we noticed that there were now unhelpful error messages where once there had been helpful maps.
Not to get too bogged-down with the technical, Google has changed its terms of service with regard to the Maps API and not bothered to shout about it too loudly. Since June 22nd 2016 all new Google Maps used on a website/app (other than directly embedded maps) require an API key before they will display on the webpage. As these maps were now on different domains as opposed to our development server, in Google’s eyes they were “new” and as such required an API key. We’re experts at this so it was a simple job to change the code to abide by the new rules.
It’s easy to get an API key if you know what you are doing. It’s free and all you need is a Google account. But here’s the rub – there are limitations and these limitations gave me pause for thought and a secondary angle for this article.
To pay or not to pay – that is more binary
The API will only allow 25,000 calls (in our case map-loads) per day before you have to pay and judging by the development community’s response to this there are a lot of annoyed people out there and I can, at least in one respect, understand why. Something that people previously had unlimited access to for free is now being metered.
Is this limit not generous though? Certainly the majority of the websites we develop would not exceed this so for our clients the issue ends there. But if your website map uses the API and is visited more than 25,000 per day you could have problems but would you be willing to pay for it?
It’s probably fair to say that if your website map gets more than that amount of traffic per day then it’s a popular site and likely has some commercial purpose for being there so why shouldn’t you pay if the service you are using adds to the success of the website?
My personal view is yes, if you are using the service to that extent then payment should be expected. If you use Gmail (or one of the other large email service providers) the service is usually free until you hit certain limits or want extended functionality for business use, then there are additional fees but nobody seems to have a problem with this.
I think this latest change (apart from the fact that they didn’t really tell anyone about it) is a good move and seems to make the system a little fairer for all. For all its perceived faults Google seems to have the right approach to monetisation – they give many great services for free and charge for advanced features. OK, it can be argued that in return for ‘free’ services you are giving them an awful lot of useful data but I’m afraid that’s one of the prices for the digital world we live in.
Paul – Senior Web Developer