Live map tracking: what it looks like in a service app

Live tracking comes down to three connected pieces: the crew's phone sends its position as it moves, the server passes it on right away, and the customer sees a dot on the map getting closer. For the customer, it answers the only question that matters after ordering: "how much longer?" For the business, it means fewer "where are you?" calls.

The three pieces

1. The crew's phone. In the browser, the position comes from the Geolocation API. The watchPosition() method notifies the app every time the device's position changes. The API only works on secure pages (HTTPS), and the user has to grant permission explicitly when first asked. The browser uses the best method the phone has available, GPS for example.

2. The server. It receives the positions and pushes them on immediately. This is usually done over WebSocket connections: an open, two-way session between the browser and the server, so the customer gets updates without constantly asking "has anything changed?"

3. The customer's screen. The map, the moving dot, the estimated arrival time and the order status.

An example: a towing app

In a towing and roadside assistance app, people say what happened, see the price before ordering and follow the crew on the map until it reaches them. Behind it there are usually three apps connected in real time: one for customers, one for partner companies and one for drivers. All of them can run in the phone's browser, with nothing to install.

In an app like this, the map is the part people see, but the hard work is in the statuses: who received the order, who accepted it, who's on the way, what happens if nobody is available.

What the customer sees

• Clear statuses, in words: order received, crew assigned, on the way, arrived. The map only shows up once a crew is actually on the way.
• An estimated arrival time, updated as the crew gets closer. An honest window beats an exact minute that keeps changing.
• Who's coming: the company name and a "Call" button, for when the crew can't find the address.
• Nothing extra. The customer doesn't need the full route, just the current position and the estimate.

Permissions and battery

On the web, the location permission is requested when it's needed, with one sentence explaining why: "So the customer can see when you'll arrive."

If the business wants the driver's phone to keep sending its position with the screen off, the conversation changes. On Android, background location is a separate permission, and from Android 11 on the user has to turn it on in settings ("Allow all the time"). Google asks you to explain why you need it and to keep the app working if the user says no. We covered the differences between a browser app and an installed one in our PWA article.

Battery matters too: send the position less often when the crew is far away and more often as it gets close.

Location data is personal data

The GDPR lists location data among the identifiers that can make a person identifiable. For drivers, that means clear rules:

1. Track the position only while an order is active, not all day.
2. Collect only what the purpose requires (the data minimization principle).
3. Don't keep routes longer than necessary.
4. Drivers know when they're being tracked, for example from a visible indicator in the app.

If you need an app with dispatch and a live map, see how we work.