What Location Data Is Actually For
Four operational questions that genuinely need location, and the ones that get answered with it because the data happens to be there.
Location tracking is sold as a single capability and used for four different purposes with very different justifications.
The four purposes
Dispatch. Which vehicle is nearest to the next job. Needs current position, needs nothing historical.
Proof of attendance. Confirming someone arrived at a customer site. Needs a point in time and place, not a continuous record.
Safety. Knowing where a lone worker is if something goes wrong. Needs current position and a way to raise an alarm.
Cost and compliance. Mileage, fuel, driver hours, vehicle utilisation. Needs aggregate distance and duration, mostly not a route.
None of the four requires a continuous record of every movement, which is what most deployments collect.
The purposes that are not on the list
Checking whether someone is where they said.
Measuring how long a person spent at each stop as a performance figure.
Knowing what a driver does at lunchtime.
Reconstructing someone's day after the fact because a manager is curious.
Each of these gets answered from the data once the data exists, which is why the collection decision matters more than the access policy.
Vehicle or person
The distinction that determines almost everything.
A tracker in a company van follows an asset. Where the van is used only for work and never taken home, the location data is about a vehicle.
A tracker in a van taken home follows a person, including to their house, their doctor, their children's school.
An app on a phone follows a person always, because the phone goes everywhere.
Products do not make this distinction; deployments must. It changes the legal basis, the retention, and whether a pause control is essential rather than optional.
The proportionality question
Regulators across Europe have repeatedly examined the same question: was the amount of location data collected necessary for the stated purpose.
The answers have been consistent. Continuous tracking for fleet management has been found excessive where less detailed data would serve. Tracking during breaks has been found excessive. Long retention of route history has been found excessive.
Which means the design question is not whether you may track, but how little tracking answers your question.
Where to start
Write down which of the four purposes you have.
Then write down the least location data that answers it: a current position, a point at arrival, a daily distance total.
Most operational questions are answered by far less than a continuous breadcrumb trail, and starting from the question rather than the product is the difference between a defensible deployment and an expensive one.
Who this is for
Three audiences with different reasons to be here.
Whoever has been asked to deploy something and needs to know which questions decide the outcome.
Whoever has to assess it — legal, HR, a works council — and needs the technical picture in terms that connect to the obligations.
And, indirectly, the drivers, whose cooperation is what keeps the data usable and whose interests are treated here as a design input rather than an obstacle.
Written for the first, with the second's questions answered where they arise.
Turn the principle into a test
For an example that can make this requirement testable, consult time tracking software. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, failures and permissions.