The problem with tracking

You can track your Uber until it gets to you. Once you get in the Uber, your friends can track your ride until you get to them. The simple ability to track a ride seems useful. Sounds like something I should be able to do for everyone coming to me or I am going to. Sounds like something everyone should be able to do for things in their lives that are out and about. After all, when things are on the move, they are trying to get somewhere, usually to someone, usually with some purpose. The simple ability to track people and things on the move seems useful.

Then why is Uber the only thing I can track? We wondered if the tracking need is restricted to app-based transport services. Hollywood movies and TV shows that animate a moving dot on a screen suggest otherwise. In the world of Google Maps, Find My iPhone, Nearby Friends on Facebook, Share Location on Whatsapp, and the never ending list of apps that seem to want access to my location, there is plenty of room for moving dots. Yet, why is it that tracking is static and restricted to getting current location? How hard is it for Google or some biggie to open up tracking for developers so we can watch things move on a map with an ETA just like we track our Uber?

We got more curious as developers and started looking for APIs to do just that. We quickly learned that the publicly available tools and primitives for location-based services are point-in-time in nature and using that to build continuous tracking is a hard problem. With the user’s permission, the smartphone OS allows apps to get current position. Maps let you plot the position. Cloud services powered by the maps companies let you lookup the address (reverse geocoding), distance from another address (path), traffic conditions on the way (ETA), etc. But there is simply no API to say “track until it gets there” that just works.

We looked up how things used to be tracked before smartphones. So there were days when you had to make capital investments to install RFID and GPS chips on assets that needed tracking. The chips would send data streams to a server and then a piece of software would process it, visualize it, put it in context and help make sense of it. These chips are still out there for traditional track-and-trace but get pretty clunky to manage.

Then along came smartphones. Most smartphones come with a powerful GPS chip and a powerful connected computer on top (we inadvertently discovered the power of a smartphone GPS when we recently learnt that GPS was active in airplane mode while in flight!). As discussed earlier, the smartphone OS lets apps fetch current location from the GPS. This data can be processed on the phone or in the cloud – to provide better local search, maps, ETAs, navigation, distance, traffic conditions, etc. The way it works is that developers can call the location-based services on the phone or in the cloud every time they need it. Third party APIs for location-based services charge based on number of API calls.

The smartphone companies and maps apps have invested hundreds of millions of dollars to build tracking but access to that technology is restricted for their internal use. Ride-sharing apps have separately invested in powering a great tracking experience for users but restricted usage to their own products. If developers outside of these companies want to build tracking for their own use and make it available to users of their products, they have to do it themselves. Considering how often people and things are moving around in our lives with a smartphone besides them, and how often the people who care about this movement have access to a computer or smartphone, we imagine that a large number of people in the world need tracking.

When developers start implementing tracking, they encounter a number of problems to start.

1. They must decide the accuracy and frequency of the GPS location stream. Heavy streams cost battery life and data usage while lighter ones miss out key data and impact tracking experience. Balancing the two is a hard problem.
2. The raw location stream received on the servers is noisy because of patchy cell networks and variance in GPS data. Data needs to be filtered to get the signal out of the noise. Picking and implementing the right filters is a hard problem.
3. Clean data needs to first be put in context of a trip, and then in context of the overall business. Users, customers, operations teams and other stakeholders need to view it in a meaningful way in real-time as well as for future analysis.
4. Real-time data needs to translate to a great tracking experience. The vehicle needs to animate on a map with an accurate ETA, the user needs to be able to identify and contact the driver, the experience needs to integrate into the current product experience.
5. It is hard to manage integrity of the data and reliability of the service across smartphone OS versions, cellphone network idiosyncrasies, local map datasets, multiple vehicle-types, etc. As soon as developers are done solving yesterday’s problems, new ones show up daily.

Developers will find that there is open source code for each problem but the problem is not with finding the code, it is about running it. “It is easier than ever to build software, but harder than ever to operate it” (Jeff Lawson – Twilio). Even if developers were to bite the bullet and find the right software or service for each component, operating all this is probably not best use of their time. It can surely be made less painful.

We realized that things are the way they are because (a) it is hard to build continuous tracking out of point-in-time location-based services and (b) more products and businesses need continuous tracking than just ride-sharing apps (don’t hold your breath for them to open up a tracking service to developers anytime soon). That leaves all these engineering teams across the world with the same cruel home work assignment. This is an inefficient use of developer time and a structural flaw that HyperTrack intends to fix.

We have built a tracker SDK that easily integrates into your smartphone app (Android or iOS). You tell our API where you are going and we track the app until it gets there. This most primitive version is called HyperTrack Lite. The more you tell us about the asset, the trip, the tasks, the customer, and so on, the more you and your customers stand to get out of the service. The richer version is available today as HyperTrack API v2. Location-awareness of apps does not need to be point-in-time anymore. HyperTrack wants to take it to the next level with continuous tracking. We want to make tracking easier for developers, as easy as we imagine (as developers) it should be. Request access if you want to try.

Find the original post here