Echte geolocatie: cases en geleerde lessen

Geolocatie is al lang geen exotische functie meer. Tegenwoordig is het geïntegreerd in last-milebezorging, vlootbeheer, lokale marketing en zelfs in de manier waarop een website besluit welke valuta je te zien krijgt. Maar tussen de theorie uit de handleidingen en de praktijk zit een kloof die je pas merkt wanneer de gps faalt in een steegje, wanneer de browser om toestemming vraagt en de gebruiker nee zegt, of wanneer de API een positie teruggeeft met 800 meter afwijking.

Dit artikel legt niet uit wat geolocatie is. Het verzamelt concrete implementatie-ervaringen, fouten die zich herhalen en grenzen die je beter kent voordat je een klant of een baas precisie tot op de millimeter belooft.

Waar het echt wordt gebruikt: vier scenario’s met details die ertoe doen

1. Stadsbezorging: de geofence die niet overeenkomt met de werkelijkheid

Een veelvoorkomend geval bij koeriersbedrijven: er wordt een servicegebied met coördinaten gedefinieerd en een geofence ingesteld om alleen bestellingen binnen dat gebied te accepteren. Het probleem ontstaat wanneer het gebied op een verouderde satellietkaart wordt getekend en een straat doormidden snijdt die in werkelijkheid bij de buurgemeente hoort. Het resultaat zijn geweigerde bestellingen aan de grens en boze klanten.

De praktische les: geofences moeten worden gevalideerd met echte postadresgegevens, niet alleen met lijnen op de kaart. Volgens documentatie van kaartaanbieders veranderen administratieve grenzen en hebben basislagen update-achterstanden die in peri-urbane gebieden meer dan een jaar kunnen bedragen.

2. Lokale marketing: de actieradius die niemand meet

Advertentiecampagnes met geografische targeting laten je een straal rond een winkel kiezen. Een veelgemaakte fout is aannemen dat een straal van 5 km gelijkstaat aan “mensen die te voet kunnen komen”. In een stad met een snelweg of een rivier ertussen omvat die straal wijken met een beroerde bereikbaarheid. In de praktijk is het verstandig de straal te combineren met verkeersgegevens en met de werkelijke locatie van actieve gebruikers, die advertentieplatforms wel bieden.

Dit werkt niet hetzelfde voor dienstverleners aan huis als voor retail: in het eerste geval betaalt het bedrijf de verplaatsing en moet de straal rij tijden weerspiegelen, geen hemelsbrede afstanden.

3. Vlootbeheer en hulpverlening: het rapport dat te laat aankomt

Volgsystemen versturen periodiek posities. In gebieden met onregelmatige mobiele dekking slaat het apparaat de posities op en verstuurt ze in één keer zodra het weer signaal heeft. Wie die gegevens gebruikt, moet erop voorbereid zijn een reeks punten met oude tijdstempels te ontvangen. Als het dashboard die punten toont alsof ze actueel zijn, neemt de vlootbeheerder beslissingen op basis van verouderde informatie.

Een detail dat je alleen met echt gebruik leert: de batterij van het apparaat bepaalt de verzendfrequentie. Apparaten die zijn ingesteld om elke 30 seconden te rapporteren, putten de accu van het voertuig of de terminal uit tijdens lange werkdagen. Gebruikelijk is om modi af te wisselen: hoge frequentie tijdens beweging, lage frequentie bij langere stops.

4. Web en apps: geolocatie via IP versus de gps van de browser

Wanneer een website om de locatie vraagt, zijn er twee heel verschillende routes. De geolocatie-API van de browser gebruikt gps, wifi en zendmasten en vereist expliciete toestemming van de gebruiker. Geolocatie via IP vraagt geen toestemming en is veel minder nauwkeurig: het kan de bezoeker plaatsen in de stad van de internetprovider, tientallen of honderden kilometers van zijn werkelijke positie.

In ecommerceprojecten werkt het gebruik van IP om “je dichtstbijzijnde winkel” te tonen als benadering, maar het faalt bij gebruikers van bedrijfsnetwerken of VPN’s. De gebruikelijke aanbeveling is een handmatige selector als terugvaloptie te bieden en de toegang tot de aankoop nooit te blokkeren door een foutieve geografische detectie.

Fouten die zich herhalen en hoe je ze voorkomt

• Precisie verwarren met nauwkeurigheid. De gps kan een straal van 10 meter aangeven en toch 40 meter verschoven zijn door signaalreflecties tussen gebouwen. In smalle straten springt de positie van de ene stoep naar de andere zonder dat de gebruiker beweegt.
• Weigering van toestemming niet afhandelen. Veel ontwikkelingen gaan ervan uit dat de gebruiker accepteert. Als hij weigert, moet de applicatie blijven werken met een standaardlocatie of met handmatige invoer.
• Coördinaten opslaan zonder referentiesysteem. Het mengen van WGS84 met andere coördinatensystemen veroorzaakt afwijkingen van honderden meters. Je moet documenteren welk systeem elke datalaag gebruikt.
• Privacy negeren. Het opslaan van de positiegeschiedenis van gebruikers of werknemers vereist een juridische grondslag en transparantie. Volgens de regelgeving inzake gegevensbescherming die in de Europese Unie van toepassing is, vereist continue tracking van werknemers rechtvaardiging en proportionaliteit.
• Niet binnenshuis testen. In industriële hallen, winkelcentra of ondergrondse parkeergarages werkt de gps simpelweg niet. Als het gebruiksscenario afhankelijk is van posities binnenshuis, moet je je toevlucht nemen tot bakens of wifi, met andere infrastructuur en andere kosten.

Wat geolocatie niet oplost

Het is belangrijk eerlijk te zijn: geolocatie vervangt geen goed onderhouden adressensysteem. Een bestelling met een onvolledig adres blijft een probleem, zelfs als de klant zijn exacte positie heeft gedeeld. De coördinaat van het bezorgpunt geeft niet de portiek of de verdieping aan.

Het lost ook de attributie in advertenties niet op: weten dat een gebruiker in de buurt van een winkel was, bewijst niet dat hij die heeft bezocht. Betrouwbare meting van fysieke bezoeken vereist andere technieken, zoals enquêtes of panels, en zelfs dan zijn de gegevens schattingen.

En het is op zichzelf geen beveiligingsoplossing. Apparaten kunnen signaal verliezen, worden uitgeschakeld of gemanipuleerd. Elk localisatiesysteem met een beschermend doel moet worden gecombineerd met andere signalen en met menselijke responsprotocollen.

Hoe je begint zonder te struikelen: een praktische volgorde

1. Definieer het gebruiksscenario en de fouttolerantie. Een wandelapp heeft precisie van meters nodig; een lokale marketingcampagne kan met kilometers werken.
2. Kies de juiste positiebron. Gps van het apparaat voor hoge precisie, IP voor een benadering zonder frictie, mobiele netwerkgegevens als terugvaloptie.
3. Ontwerp de toestemmingsflow. Leg de gebruiker uit waarvoor je de locatie nodig hebt voordat je de dialoog van de browser of het besturingssysteem opent.
4. Test onder echte omstandigheden. Loop door smalle straten, ga een winkelcentrum binnen, simuleer slechte dekking. Emulators reproduceren deze fouten niet.
5. Registreer de datakwaliteit. Sla de gerapporteerde precisie op bij elke positie. Dat veld maakt het achteraf mogelijk twijfelachtige punten te filteren.
6. Herzie de privacy vanaf dag één. Bepaal wat wordt opgeslagen, hoe lang en met welk doel.

Een opmerking over kosten en afhankelijkheid van leveranciers

Kaart- en geocoderings-API’s hebben gebruiksvoorwaarden en prijzen die veranderen. Een project dat vandaag met een gratis quotum werkt, kan duur worden naarmate het aantal verzoeken groeit. Het is verstandig de officiële documentatie van de leverancier te raadplegen en een plan B te voorzien, zoals het cachen van geocoderingen van terugkerende adressen om identieke queries niet te herhalen.

Samengevat: geolocatie is een krachtig hulpmiddel met concrete grenzen. De projecten die het beste werken, zijn die welke die grenzen vanaf het ontwerp accepteren, handmatige alternatieven bieden en de positie behandelen als elk ander gegeven, met zijn foutmarge en zijn privacybeleid.