It’s funny that when I talk to people in the travel industry about mashups and APIs, most of them get glazed looks in their eyes. Throw in terms like location based services or geospatial awareness and I’ve lost them. What most of them don’t realize is that the majority of the travel apps that are starting to come out, both online and for mobile are mashups that are relying on location awareness and geospatial data. Many of them, like Pocketvillage are a consumer interface on top of a variety of APIs all normalized for a single homogenous user experience. That’s right, it’s essentially a metasearch tool that pulls in content from a variety of sources including Viator, GetYourGuide, TourCMS, Rezgo, AirBnB, and many others. What differentiates a metasearch like Pocketvillage from other metasearch applications however, is the fact that with location based services enabled, Pocketvillage can return content based on your current location. The issue right now however is that not all geo data is equal. Not all APIs provide geolocation information and some return it based on different criteria.
Let’s take the hotel, air, and car out of the travel equation for a minute and focus on the local experiences. According to the PhoCusWright research study titled “When They Get There (and Why They Go)“, 77% of active travelers are likely to use a mobile device while traveling. Although the majority of them use their mobile devices for taking photos and sharing on social networks, almost two thirds of travelers use their devices to find and book local attractions, tours, and activities. So, if I were to travel to Rome for example, what would I use an app for? Trying to book my hotel? Maybe. Renting a car? Maybe. Trying to find the local landmarks, heritage sites, museums, things to do? Most definitely. Yet, this is the content that is hardest to source and to aggregate because the data is held in so many different places and most of it is not accessible through APIs. According to the same report only about 14% of tour and activity operators use a reservation platform. I would think that many of those are probably not even storing geolocation data, which means that a very large number of destination based products are not even accessible to location aware devices.
At the two most recent Tnooz THack events in Las Vegas and Boston, the majority of the apps developed used APIs for local tours, activities, and events that included location data. Not surprisingly the reason for this is because the apps were being developed for mobile devices. This is where, I believe, the greatest opportunities exist in the travel space. The question is whether we can get businesses to add geolocation data to their product offerings and do it in a standardized way.
Certainly that is not an easy request to satisfy. The largest hurdle is not necessarily the technology but educating businesses and making them aware that there are services available (many of them free) that can be used to store their location data. Why, even a clever web developer could help their small business customers include geolocation data directly into their websites by using Schema.org to format the underlying HTML. The tools are there and the technology exists, the issue is that not enough small businesses understand how to use the tools or have the wherewithal to do it themselves.
This is where developers can step in and make a difference. Using structures like Schema.org or even more complex structures like the OpenTravel Alliance message schemas, application & API developers could be integrating standard methods for capturing geo-location data and sharing that data with third parties. If we want and expect small businesses to add location based data, then we have to make it easy for them to do so. Education can only go so far, making the geolocation process part of the user experience means ensuring that businesses don’t have to think about adding location data, they will just do it.