60% Reduced Cost by Optimizing Google Maps API Calls
Would you like to save a chunk on your Google Maps API cost and have your maps API consumption volume drop like a rock? Then read on.
Anyone working with Google Maps API knows that it can get expensive quickly, especially if it is a core part of your product. Depending what your implementation requirements are and how your site or app relies on maps, you may not only be paying for the visual maps, but geocoding, routing, places, and more, and all of a sudden your maps CPM costs can start skyrocketing – especially if you add in street view panoramas and other more expensive features.
Product managers, project managers, and developers alike can benefit for understanding how Google Maps billing works to create the most efficient implementation possible that still meet business goals. Google provides some guidance on this, but it still confuses many and their pricing sheet isn’t as easy to find as one might hope.
How Google bills for Maps, in a nutshell
The easiest way to explain it is that there is a different cost per 1000 calls to their APIs based on the specific maps product you need to use. For the arguably most common map implementations out there, this is now $7 per 1000 API calls (in the first paid tier, less at higher volume). Google calls these “credits” that you are using, perhaps to make you feel better? There’s no credit about them, besides that charge on your credit card.
If you load a dynamic map on every page view of your site, you will be charged $7 CPM for that mapping feature. Online media publishers know that this can be a big negative line item counting against your net eCPM/RPM.
Let’s say your site’s RPM is $14 – Google Maps would be eating up half of your revenue. That’s not counting any other requirements you may have, such as geocoding or routing.
I won’t go into the details on each different maps API cost, but wanted to quickly summarize it. You can get more details from Google here.
How I cut cost by 60% for a client
One of my consulting clients in the travel space mentioned in passing the increasing cost of maps so I did some digging to help find out what might be causing it.
Finding out what had high utilization wasn’t as easy as you would think. There was only 1 API key in use for everything – routing, geocoding, dynamic JS maps, etc. So let me suggest this now – it will be a lot easier to track down usage to specific functionality if you use a different API key for various features. If you haven’t implemented it this way, I highly suggest you change it.
Once I figured out what was causing it (a cron job doing geocoding inefficiently which was implemented by a 3rd party developer) we now have the ability to make business decisions and improve the implementation.
But, while I was doing that I came up with a simple idea which is what this post is all about.
I came up with this little hack
This is actually really simple. Not every visit to your site is a visitor, and not every visitor will use the map, so why show it to them right away?
Here’s my simple solution and It isn’t limited to only Google Maps API – I think you could use it with just about any maps provider.
I can’t claim this to be 100% original because I have seen other sites that have a button to show a map, but most are just a little button somewhere. I suggested they should try disabling the map and only consuming the API onClick when a visitor was interested in it.
Immediate results: 60% maps API savings
I think the graph speaks for itself so I don’t have much more to say about it other than including it again for ease of reference.
The best part is this took very few man hours to deploy, so the cost saving accounting for dev time can be immediate, depending on you API usage volume.
Other Google Maps cost optimization ideas
Google provides some generic ideas but they’re not terribly exciting. Quotas? Yawn. Budget Alerts? Yay fun, now you can see in the middle of the month that your end of the month bill is going to be huge! That’s helpful…
I’m not an expert into all things Google Maps, this I know. But I definitely have a knack for looking at ways to optimize and reduce expenses, so down the maps rabbit hole I go.
Our next steps will be to evaluate whether some of these additional ideas are viable.
- Using the static maps API for the page-load map displays. I like this quite a bit for a few reasons:- You can still display a map with custom points on it
– Cost is 2 CPM in the first tier
– In some implementations, this is all that is needed vs dynamic maps. For example, on the page it can serve as a reference to where points are in relation to the map bounds, and when clicked on it can take the visitor to a larger interactive map. It may be enough to give most visitors what they need, and further eliminate cost by users engaging with dynamic maps. A/B testing (remember use a separate API key for the interactive map load when a visitor is coming from the static map, as well as the on-page maps) would show whether it is viable. - Lazy load may be an option for some, but with the maps on this site being very prominent above the fold, that wouldn’t save anything. It may for someone else though, and if that’s you then you might look into it.
- Optimize your geocoding. Caching is allowed for up to 30 days, so don’t re-run what you don’t need to. Don’t geocode everything before you attempt filtering. If you are a site that focuses on a 1 country (USA Hotels for example) make sure you filter out any data feed items which are irrelevant before running the geocode, such as hotels in any other country besides the US. Sounds like common sense, but things like this often slip through the cracks.
- Cache anything else you are allowed to. A number of maps APIs allow for caching per the TOS, so if you are utilizing one that does, look into caching.
Hopefully this helps you save some money on your maps implementations.
