Elke rittenregistratie moet locatiegegevens verwerken — anders weet hij niet dat je gereden hebt. Maar niet elk systeem doet dat technisch op dezelfde manier, en dat verschil bepaalt waar je mobiliteitsgegevens terechtkomen en wie er technisch bij kan.
Zo werkt rittenregistratie onder de motorkap: eerst de zes vragen waarop systemen verschillen, dan de drie manieren waarop de markt het oplost, en daarna waar MoveJack valt. Zonder verkooppraat, met de grenzen erbij.
Zes vragen waarop systemen van elkaar verschillen
“Rittenregistratie” is geen één techniek. Wie twee producten vergelijkt, vergelijkt in werkelijkheid antwoorden op deze zes vragen:
- Waar wordt de locatie gemeten? In een telefoon, of in een apparaat in het voertuig.
- Waar worden losse locatiepunten tot een rit samengevoegd? Op het toestel zelf, of op een server.
- Waar staat je volledige ritgeschiedenis? Dit is de vraag die het meest uitmaakt en het minst vaak gesteld wordt.
- Is centrale opslag bij de leverancier onderdeel van het model? Soms wel, soms alleen als je het aanzet.
- Wie kan er technisch bij? Niet wie het mag, maar wie het kan.
- Is er hardware nodig? En zo ja, van wie is die en wat stuurt hij door?
De antwoorden hangen samen, maar niet zo strak als vaak wordt aangenomen. Hardware betekent niet automatisch een cloud. Een cloud betekent niet automatisch dat iemand meekijkt. En “lokaal” betekent niet dat er nooit een technisch gegeven het toestel verlaat.
Drie manieren waarop het wordt opgelost
Local-first: de telefoon is de bron en de bewaarplaats
Bij een local-first opzet meet de telefoon de locatie, bouwt de telefoon de rit op, en staat je ritgeschiedenis in een database op dat toestel. De leverancier houdt daarvan geen centrale kopie op zijn servers.
Local-first betekent niet dat er nooit enig technisch datapunt het toestel verlaat. Voor losse functies kan een afzonderlijk gegeven wel naar buiten gaan: een coördinaat omzetten naar een straatnaam, een snelheidslimiet opzoeken, een kaart tonen. Dat zijn losse verzoeken, geen kopie van je geschiedenis. Het verschil tussen die twee is het belangrijkste onderscheid op deze pagina.
Wat local-first wél betekent: de volledige ritgeschiedenis wordt niet standaard centraal bij de leverancier opgeslagen. Wat het niet automatisch betekent: dat er geen systeemback-up van je telefoon bestaat, dat er geen cloud onder jouw eigen account in het spel is, of dat een nieuw toestel altijd leeg begint.
Of je gegevens meegaan in de back-up van iCloud of Google, en of er een eigen back-upbestand is om van te herstellen, verschilt per product. Dat is dus een vraag om te stellen vóórdat je van toestel wisselt, en geen eigenschap die uit het model volgt.
Cloud-first: de telefoon meet, de server bewaart
Ook hier registreert de smartphone, maar ritten, gps-punten of locatiehistorie worden geheel of gedeeltelijk centraal verwerkt of opgeslagen. Dat is de definitie; de rest is productafhankelijk. Of de volledige geschiedenis centraal staat, of de aanbieder die kan inzien, en of er automatische serverback-ups bestaan: dat komt bij de onderzochte producten vaak voor, maar het volgt niet uit het model. Het staat in de privacyverklaring van dat product en nergens anders.
Cloud-first is niet automatisch slecht of onveilig. Centrale opslag maakt synchroniseren tussen telefoon en laptop, een team of wagenpark in één overzicht, koppelingen met boekhoud- of urenpakketten en herstel als je toestel in het water valt eenvoudiger. Dat is een reden om het te kiezen, geen bijwerking.
Noodzakelijk is het niet. Diezelfde functies kunnen ook via een cloud onder jouw eigen account, via uitwisseling tussen je apparaten onderling, of gewoon via export en import. Centraal is de meest gebruikte route, niet de enige.
Twee voorbeelden waarvan de architectuur uit hun eigen privacyverklaring blijkt. Driversnote schrijft dat gps-posities automatisch worden verzameld door het gebruik van hun producten en dat die posities als persoonsgegevens gelden; start- en stoplocatie en coördinaten worden opgeslagen, een account is vereist, en de bewaartermijn loopt zolang je een account hebt. MileIQ schrijft dat het precieze locatiegegevens verzamelt zolang je bent ingelogd en locatievoorzieningen aan hebt staan. Of ruwe locatie het toestel verlaat, staat in die verklaring niet vermeld.
Hardware-first: het voertuig is de bron
Bij hardware-first zit de primaire locatiebron in het voertuig: een gps-unit, een kastje op de OBD-poort, een dongle of een blackbox. De registratie hangt dan niet aan een telefoon en niet aan wie er achter het stuur zit.
Twee misvattingen zijn hier hardnekkig. Hardware betekent niet automatisch dat er een cloud aan hangt, en het betekent niet automatisch dat iemand live meekijkt. Waar de ritten worden opgebouwd, waar ze worden bewaard en of er een dashboard bij hoort, verschilt per systeem — net als bij software.
Waar hardware-first logisch is: wanneer het voertuig het onderwerp is in plaats van de persoon. Bij meerdere wisselende bestuurders op één auto, bij wagenparkbeheer, bij diefstalbeveiliging, en wanneer registratie onafhankelijk van een telefoon gegarandeerd moet zijn. Dat zijn echte eisen, en een app lost ze niet op.
De vergelijking in dertig seconden
Waar het antwoord per product verschilt, staat dat er ook zo. Een tabel die overal ja of nee zegt, liegt.
| Local-first | Cloud-first | Hardware-first | |
|---|---|---|---|
| Waar wordt de locatie gemeten? | Telefoon | Telefoon | Apparaat in het voertuig |
| Waar staat je volledige ritgeschiedenis? | Op het toestel | Geheel of gedeeltelijk centraal | Afhankelijk van product |
| Is hardware nodig? | Nee | Nee | Ja |
| Is centrale opslag bij de leverancier onderdeel van het model? | Nee | Typisch wel | Afhankelijk van product |
| Is live voertuigtracking mogelijk? | Afhankelijk van product; niet aangetroffen bij de door ons onderzochte oplossingen | Afhankelijk van product | Typisch wel |
| Voor wie past dit meestal? | Wie zelf rijdt en zijn eigen administratie doet | Wie synchroniseert, samenwerkt of koppelt | Wie het voertuig beheert in plaats van de rit |
Zeven begrippen die vaak door elkaar lopen
Ze worden vaak als synoniem gebruikt, maar betekenen verschillende dingen. Dat veroorzaakt de meeste verwarring.
- Volledige ritgeschiedenis. Alles bij elkaar: elke rit, met tijd, adressen en route. Samen is dat een beeld van waar iemand komt en wanneer. Dit is het gegeven waar het om gaat.
- Losse functionele datapunten. Een positie die een functie nodig heeft, bijvoorbeeld om een adres of snelheidslimiet op te halen. Zulke verzoeken gaan zonder naam of account, maar tonen samen wel een route. Je ritgeschiedenis als geheel wordt nooit geüpload. Wat MoveJack precies verstuurt, staat verderop op deze pagina en op Privacy Proof.
- Centrale leveranciersdatabase. Een verzameling bij de aanbieder, waar zijn systemen — en dus zijn medewerkers en zijn hostingpartij — technisch bij kunnen.
- User-owned cloud. Jouw eigen iCloud of Google Drive. Ook een cloud, maar onder jouw account, niet onder dat van de aanbieder. Een systeemback-up van je telefoon valt hieronder.
- Export. Jij haalt er iets uit en stuurt het door: een PDF naar je boekhouder, een Excel naar je opdrachtgever. Een bewuste handeling met een afgebakende inhoud.
- Back-up. Een kopie om van te herstellen. Dat kan een bestand zijn dat jij bewaart, of de automatische systeemback-up van je telefoon — dat zijn twee verschillende dingen met twee verschillende gevolgen.
- Live tracking. Iemand anders ziet waar je nu bent. Dat vraagt een verbinding die continu doorgeeft, en dat is een andere functie dan achteraf een rit vastleggen.
Wie deze zeven scheidt, kan elk product zelf plaatsen — ook de producten die op deze pagina niet genoemd worden.
Waar MoveJack in dit model valt
MoveJack is een local-first smartphone-oplossing: de app legt je ritten, locaties en adressen vast op je eigen telefoon en bewaart ze daar, in een database op het toestel. Je begint zonder account, MoveJack bewaart geen centrale kopie op zijn servers, en er zit geen analytics- of crashrapportage-pakket in de app.
Voor een paar handige functies werkt de app samen met gespecialiseerde diensten. Tijdens je rit controleert MoveJack ongeveer elke 8 seconden de geldende snelheidslimiet, na de rit vult hij het adres aan en de kaart laadt zodra je hem opent; daarvoor gaan losse posities naar een kaartdienst. Bij een Nederlands kenteken vult de app merk, type en brandstof aan via de RDW, en een abonnement loopt via de winkel van Apple of Google. Dat gebeurt zonder naam of account, al tonen de positieverzoeken samen je route; je ritgeschiedenis als geheel wordt nooit geüpload. Welke gegevens precies waarheen gaan, staat op Privacy Proof.
De meeste vragen gaan over de user-owned cloud, want die missen mensen bij local-first het vaakst. Bij MoveJack zit de ritdatabase niet in de back-up van iCloud of Google. Wat er wel is: een back-upbestand dat je in de app maakt, zelf bewaart waar jij wilt en op een nieuwe telefoon terugzet, plus een export naar Excel of PDF voor je administratie. Die export zet je niet terug. Wat de app verder doet staat op alles wat de app doet.
Wanneer MoveJack niet de beste keuze is
Local-first is een keuze met grenzen, en die grenzen zijn scherp. Kies iets anders wanneer je dit nodig hebt:
- Registratie onafhankelijk van een telefoon. Als de rit ook vastgelegd moet worden wanneer er geen telefoon mee is, of wanneer die uit staat, dan hoort de bron in het voertuig.
- Meerdere wisselende bestuurders op één voertuig. Dan is het voertuig het onderwerp, niet de persoon.
- Live voertuigtracking. MoveJack doet dat niet, en dat is geen gebrek maar een ontwerpkeuze.
- Wagenparkbeheer en realtime overzicht van personeel. Daar hoort een centraal overzicht bij. Of dat via hardware of via een app loopt verschilt per product; centrale verwerking hoort er in de praktijk wel bij, maar dat volgt niet uit de architectuur zelf.
- Diefstalbeveiliging. Een app die op de telefoon van de bestuurder staat, helpt niet als de auto zonder die telefoon wegrijdt.
- Gecertificeerde hardware. Vraagt je verzekeraar, leasemaatschappij of opdrachtgever een specifiek gekeurd apparaat, dan is dat een eis waar software niet aan kan voldoen.
Herken je jezelf in dat lijstje, dan is een kastje of een cloud-first systeem gewoon de betere keuze. Herken je jezelf er niet in en doe je je eigen administratie, dan is er weinig reden om je ritgeschiedenis ergens centraal te laten staan.
Veelgestelde vragen
Wat is het verschil tussen een gps-tracker en een rittenregistratie-app?
Een gps-tracker is hardware in het voertuig en meet de auto; een rittenregistratie-app draait op je telefoon en meet jou. Daaruit volgt de rest: een tracker werkt ook zonder dat jij je telefoon bij je hebt, een app werkt in elk voertuig waarin je stapt. Wat er daarna met de gegevens gebeurt, hangt niet van het meetpunt af maar van de architectuur erachter.
Wat betekent local-first rittenregistratie?
Dat je ritgeschiedenis op je eigen toestel staat en dat de leverancier daar geen centrale kopie van bewaart. Functies kunnen daarbij wel losse verzoeken doen, bijvoorbeeld aan een kaartdienst voor een adres of snelheidslimiet.
Moet een rittenregistratie-app mijn volledige ritgeschiedenis in de cloud opslaan?
Nee, dat is een ontwerpkeuze en geen technische noodzaak. Een app kan de ritten op het toestel opbouwen en bewaren. Centrale opslag bij de leverancier maakt synchroniseren, samenwerken en herstellen wel eenvoudiger, en is daarvoor de meest gebruikte route — maar niet de enige: een cloud onder je eigen account, uitwisseling tussen je apparaten, of export en import kunnen hetzelfde doel dienen.
Is EU-cloudopslag hetzelfde als lokale opslag?
Nee, en let op wat de term precies zegt: EU-opslag gaat over wáár servers staan, niet over wie ze beheert. Beheert de aanbieder die opslag, dan blijft je ritgeschiedenis in een centrale database staan — alleen binnen de EU, wat regelt onder welk recht en welk toezicht de gegevens vallen. Gaat het om jouw eigen cloudaccount, dan is er geen centrale verzameling bij de leverancier. Vraag dus niet alleen wáár de opslag staat, maar wie hem beheert.
Wanneer is hardware beter dan een smartphone-app?
Wanneer het voertuig het onderwerp is in plaats van de bestuurder: bij wisselende bestuurders, bij wagenparkbeheer, bij diefstalbeveiliging, bij live tracking, en wanneer registratie gegarandeerd moet zijn ook zonder telefoon. Ook wanneer een verzekeraar of opdrachtgever gekeurde apparatuur eist.
Kan mijn werkgever zakelijke ritten ontvangen zonder mijn privéritten te zien?
Dat hangt van de architectuur af. Bij een systeem waarin jij een rapport samenstelt en verstuurt, bepaal jij de inhoud: je selecteert de periode en de categorie, en alleen de ritten die je bewust selecteert worden via dat rapport gedeeld. Bij een systeem met een centraal dashboard hangt het af van welke rechten daar zijn ingesteld. Vraag dus niet of het mag, maar wie er technisch bij kan.
Welke soorten rittenregistratie bestaan er?
Technisch komt het neer op drie modellen: local-first, waarbij de telefoon meet en bewaart; cloud-first, waarbij de telefoon meet en een centrale backend bewaart; en hardware-first, waarbij een apparaat in het voertuig de bron is. Daarnaast bestaat er nog handmatige registratie in een rittenboekje of een spreadsheet, die technisch niets doet maar juridisch wel mag.
Kan een rittenregistratie-app werken zonder dat mijn ritgeschiedenis naar een leveranciersserver gaat?
Ja. MoveJack werkt zo: de ritten staan in een database op je telefoon en er is geen centrale kopie op onze servers. Voor handige functies haalt de app alleen de informatie op die nodig is, zonder naam of account: tijdens je rit controleert MoveJack ongeveer elke 8 seconden de geldende snelheidslimiet, en na de rit vult hij het adres aan; je ritgeschiedenis als geheel wordt nooit geüpload. Hoe dat precies werkt, staat op Privacy Proof. Bij andere producten moet je dit per product nagaan in hun privacyverklaring.
Wil je weten waarom MoveJack deze keuze heeft gemaakt en waar het product ophoudt, dan staat dat op waarom MoveJack bestaat. Voor de dagelijkse praktijk: rittenregistratie en urenregistratie. En als je het wil proberen: download de app.