Over the past year we have interacted with thousands of developers from over 30 countries and as many industries. These conversations have helped us understand the use cases that compel developers to build location tracking features into their products. Turns out they are forced to build and operate complex location tracking infrastructure to make the features work.

HyperTrack APIs have been built to enable these use cases such that developers can focus on features that are core to their business and not have to worry about the infrastructure. In this post we draw a distinction between location tracking features and infrastructure and propose a better primitive to solve the problem. In the next post we walk through the HyperTrack API framework and how the building blocks work for your use case.

Life before HyperTrack – a truckload of science projects

Let’s take a quick look at the infrastructure that developers are forced to build or use in order to enable location tracking features.

The device OS provides current location through the GPS module Wifi and cellular network triangulation. Developers are on their own to figure out how often to get current location to create a location stream. Developers usually beam the stream up to the server at the same frequency although the battery cost of doing so is 5-10x. The trade-off between battery drain location accuracy and realtime-ness of consumption is often unmanaged. Location streams are then passed along to maps APIs to snap them to road and visualize on the map. Other maps APIs are used to locate the destination and get transit ETAs from the current location to destination based on current traffic conditions and fastest routes. The location streams are dumped into logs for future querying.

As teams roll out the basic solution to track dozens of drivers or hundreds of daily trips they discover operating issues that they had usually not factored at the start. They discover the need to manage real-time communication between the device and the server and journal events on both systems depending on which one is the source of truth for what event. This may require inventing new data formats and new techniques to sync true time. They discover that location streams are noisy and need filtering before they are submitted to maps APIs. They discover the need to get activity data on the device to get a better idea of what happened on the way. We observed that such infrastructure is required to meaningfully track thousands of daily trips and service the features they enable.

As usage scales further they discover the pain of managing flaky data networks and offline patches. Errors that add latency to or block the app usage and were earlier minor irritants now become unacceptable. Supporting a wide range of smartphone devices becomes painful and standardizing device models and systems gets hard to manage. Business users and end customers tracking the trips experience fatigue about watching the points hop abruptly on the map and expect smoother animation granular statuses and higher predictability. We observed that this infrastructure becomes critical when tracking tens of thousands of daily trips.

Location data is unique and can be powerful when used in conjunction with the transaction and user data related to the trip being tracked. It becomes imperative to apply machine learning and data science to this data set. The improvements in address geocoding ETAs location accuracy granular status of trips snap to road and fault tolerance create significant business impact. Due to the cost and expertise of building this out only the companies that are leaders in a market space or a geographical region can afford such investments.

Here is a summary of these infrastructure components with the respective technologies available today the impact of each component and the cost to make it happen.

In the pre-HyperTrack world location awareness of apps is based on current location; maps platforms are built for addresses and navigation; and a variety of generic infrastructure software developed for different purposes is available as open source or micro-services. A combination of all of these is being force-fitted to solve the location tracking problem thus leading to development overheads direct costs and operating inefficiencies.

The reimagined primitive- one API that just works

In a world where hundreds of thousands (if not millions) of developers are going to take location awareness of their apps to the next level with tracking it would be an awfully inefficient use of the world’s collective intelligence if they had to build similar yet sub-optimal infrastructure along the lines as listed above instead of building tech that uniquely contributes to the world.

HyperTrack has re-imagined the location tracking infrastructure to one simple API that just works. It looks like this.

Plug a lightweight SDK into the app of the user you want to track and call the HyperTrack API to start and end tracking. That’s pretty much all there is to it.

Now that we have abstracted out the infrastructure problem for developers to build features on top of let us take a closer look at the building blocks and how they work across use cases.