Google Local Search Trends IV: Federation
Google Local Search Trends IV: FederationIn the previous installments of my series on local search trends, I focused on the common themes behind some very public new features and interface changes Google has deployed in recent months, looking to identify what these trends mean for businesses trying to promote themselves effectively in local search. I discussed personalization, the trend toward search results tailored to the specifics of queries; verticalization, the development of separate interfaces and differentiating features in traditional and non-traditional verticals; and socialization, the explosion of user-generated content in Google profiles.
In this final installment, I’ll turn my attention to a subject that is more technical in nature and that, to my knowledge, has barely been written about in the local search press but stands a chance of influencing the trends already discussed and making it easier for agencies and local search platforms to support local businesses effectively. I’m referring to recent changes in the Google My Business API, the programmatic interface that Google partners (like my company, SOCi) use to maintain, update, and optimize profiles for multi-location businesses and SMBs.
The initial launch of the GMB API in late 2015 allowed partners to maintain listings in near-real-time and at a much greater scale than was possible before. Now we’re in the midst of another sea change. Since the beginning of 2021, the API has been undergoing a complete overhaul from the ground up, a change that, once completed, will leave us with a totally different architecture that is more flexible and capable of much quicker iteration. This means, in all likelihood, that Google My Business as it is used by partners and the businesses who work with them will be able to move faster to fix issues and release new features.
The Evolution of the Google My Business API
First, a little history. Prior to 2015, companies that wanted to help businesses manage their listings on Google had a hard row to hoe. Google’s local tools were built primarily for small business owners to manage things themselves and were not friendly to large-scale operations. There was some bulk upload functionality that would allow you to update several listings at once, but that was about it. Google tolerated the presence of listing management companies but did nothing to actively encourage them.
Why did this change? My view is that Google eventually realized it would never achieve a critical mass of participation from businesses in the U.S. (let alone across the globe) if it did not support partners who were, after all, trying to help evangelize for the importance of listing management and take on the bulk of the effort. No one really knows for sure what proportion of all Google listings are actively managed, but my guess is that before the API, things had plateaued (in the U.S.) somewhere around the halfway mark. Google took a look around and realized that, if they were ever to become an independent rather than a derivative source of local business data and remove their dependence on licensed and crawled secondary sources, they would have to change their thinking.
The GMB API came, frankly, as a surprise to us in the space, but a welcome one. Along with the launch of the API, Google opened up various types of GMB partnership that allowed us to get direct access to support resources who could expedite the resolution of issues (Google calls this “3P” or third-party support). Google also created a new type of master GMB account, called an Organization or Org account for short, that allowed us to aggregate all listings under management into a single dashboard, with location groups to keep each brand separate. The API itself was the biggest boon, letting us create a programmatic connection with the Google platform in order to push timely, transactional updates. We benefited, our clients benefited, and consumers benefited as well, since the accuracy of store data could be much more easily maintained.
Google released two to three API updates per year for the next several years, trying to keep up with the fast pace of new feature development in Google My Business as well as Search and Maps. (We think of these things as unified, but in fact they are all different platforms whose feature sets are never entirely equivalent to each other.) By the time of the v4.8 release last year (we are now up to v4.9), the API had become a massive repository of features for managing client accounts, users, verification, locations, location groups, profile data, reviews, Q&A, media, and many other details. Every time the GMB team wanted to add something new, they had to release an update of the entire API. The situation was becoming unwieldy, and the API, useful as it was, never quite managed to reach full feature parity with the GMB dashboard.
The Move To Federation
The answer to this problem devised by the GMB API team, as noted in the current version of the GMB API online documentation, is federation: “Going forward, the API will undergo a new federated model. There will be separate endpoints for different functionality such as Posts, Reviews, etc. Each endpoint will have a different base URL. This allows for much greater flexibility when it comes to consuming the API as well as launching new features.” With notable optimism, the doc continues: “This change will be greatly beneficial and allow Google to release new features, updates, and fixes sooner.”
The notion of a federated model for APIs is not new. Netflix, for example, provides developers with a single, unified API that represents the aggregate of hundreds of microservices operating independently. Federation, in essence, involves subdividing your services into “bounded contexts,” each with its own coherent grouping of functions. In simple terms, federation means breaking up a complex system into component parts and letting each part operate independently within an overall architecture that knits the components together into a coherent whole.
Image courtesy of MuleSoft
Unlike Netflix, the Google My Business team elected to go with a federated model that would be released one component at a time as a series of separate APIs, leaving it to GMB partners to knit them together into a unified platform. These APIs share a common syntax, and in many cases during this initial deployment phase, their functionality has not been significantly different from the component in the legacy API that they are replacing. Still, they represent a totally different architecture from what GMB partners have grown used to.
As things stand today, we are roughly at a midpoint in the transformation of the GMB API from the legacy unified model to the new federated model, with the following new APIs released so far in 2021:
- Account Management: Replaces all functions in the legacy API related to creating and updating GMB accounts; creating and updating users at primary owner, owner, and manager levels; and associating accounts with locations.
- Lodgings: A special API for managing hotel amenities. This is entirely new functionality not previously available in the legacy API, and fixes a longstanding issue whereby expanded hotel amenities (released in 2019) were not supported by the API.
- Place Actions: An API for management of secondary URLs that relate to consumer actions such as booking an appointment (physical or online), making a restaurant reservation, or ordering food for pickup or delivery.
- Notifications: Replaces legacy real-time notifications for the following:
- Listing information has been updated (by Google or a secondary source)
- Listing status has changed (suspensions, duplicates, etc.)
- Listing has a new or updated review
- Listing has a new or updated question or answer
- A new media item (photo or video) has been added to the listing (by a Google user)
- Verifications: Replaces legacy features, allowing partners to showcase verification options to a merchant (phone, postcard, email, text, or auto-verify) and to complete the verification process.
- Business Information: The biggest chunk of functionality so far, this API replaces most of the features that allow partners to update business profile information like name, address, primary and secondary phone numbers, primary and secondary hours, primary website, primary and secondary categories, attributes (aside from hotel amenities), parent/child and chain affiliations, and more.
Google has published a deprecation schedule that notates when new APIs are released and when legacy functionality will be sunsetted. GMB partners will have to keep on their toes when it comes to this schedule, which is aggressive and has already begun rolling off the first set of legacy features, those related to account management, which were officially sunsetted on September 30. April 30, 2022 will be the next important drop-dead date, when the new and relatively complex Business Information API will become the only programmatic method for updating GMB profile information.
What This Means and Where It Leaves Us
There are several functional areas in the legacy API that Google hasn’t yet gotten to with its new versions, including:
- Questions and answers
- Photos and videos
- Food menus
- Insurance networks (for healthcare)
In addition, there are several features in the GMB dashboard that never made their way to the API at all:
- Updating map pin placement
- Product menus
- Call history (new feature in beta)
- Various Insights and Performance metrics including:
- Directions requests by distance
- Phone call volume by day of week and time of day
- Popular times
- Photo quantity compared to similar businesses
- Messages and bookings counts
- Average time to respond to messages
- Mobile and desktop views
- Search keywords by volume
In addition to these items, there are some long-standing wish list items from partners that, for various reasons, have never been prioritized, such as the ability to initiate merge requests in order to clean up duplicate listings more efficiently.
If the new federated model lives up to its stated purpose, items like these will be dealt with more easily in the near future. It’s reasonable to expect that after a few more months of development — certainly less than a year from now — Google will have completed the initial rollout of the new architecture, replacing all functionality in the legacy API with new, smaller, and more dedicated components. At that point, we’ll want to start looking for faster development cycles across a broader range of features.
Certainly, if the trends I’ve been outlining in this series continue, the increased flexibility of the Google My Business API(s) of the future will aid in their evolution. Already, we’ve seen the Lodgings API support the differentiation of the hotel vertical (per my theme of verticalization), and it’s worth noting that the Place Actions API was released in parallel with the launch in the dashboard of the Food Ordering tab back in April — another move toward vertical differentiation.
Regardless of the trajectory, it’s clear that GMB development will continue its ramped-up pace for the foreseeable future, hopefully in a direction that makes Google’s local offerings more useful for businesses and consumers alike.