Het is een nogal vervelende ervaring om in een zoet ogende appel te bijten en die hap direct weer uit te spugen, omdat je er dan pas achter komt dat hij van binnen verrot is. Je verwachting van een overheerlijke appel gaat in rook op. Bij de volgende appel die je eet, denk je waarschijnlijk twee keer na voor je er al te gretig je eerste hap uit neemt. Deze blog gaat echter niet over appels of voedsel. We hebben het hier over andere dingen die na verloop van tijd ook kunnen gaan rotten, zonder dat je het in de gaten hebt. Deze blog gaat over rottende data.
Als de naar bovenstaande afbeelding kijkt, zou je dat soort gegevens gebruiken? Het antwoord ligt niet zo voor de hand als met een appel. Maar de vraag die je jezelf stelt is in essentie hetzelfde als die bij de appel: hoe oud is het al? Als we die vraag niet kunnen beantwoorden, dan zouden de gegevens niet gebruikt moeten worden. Want net als een appel, kan ook data gaan rotten.
Wat houdt rotten (van data) in?
Als je er vanuit een natuurlijk perspectief naar kijkt, dan betekent het dat een object, bijvoorbeeld een appel, aan het vergaan is, waardoor het niet meer geschikt is voor consumptie. De reden dat de appel vergaat ligt in het feit dat hij bestaat uit organisch materiaal. Het ontbinden van organische materialen wordt beïnvloed door luchtcirculatie, temperatuur, vochtigheid en de chemische samenstelling. Behalve ontbinding door bacteriën, vergaan andere materialen door oxidatie. Denk bijvoorbeeld aan ijzeren platen. IJzer reageert met het zuurstof in de lucht en verroest daardoor. Het materiaal wordt zwakker en uiteindelijk valt het volledig uit elkaar. Vanuit dat perspectief is rotten van data wellicht een ietwat misplaatste naam. Maar ik gebruik het toch om een punt duidelijk te maken: gegevens kunnen verouderen en daardoor onbruikbaar worden.
Wat zijn voorbeelden van verouderde (verrotte) gegevens?
Je zou kunnen denken dat gegevens niet kunnen verrotten wanneer ze in een systeem ingevoerd zijn. Ja, er vindt fysieke ontbinding plaats, omdat de gegevens hetzelfde blijven en in sommige gevallen niet aan relevantie verliezen. Sommige gegevens blijven altijd valide, bijvoorbeeld geboortedatums en -plaatsen. Een ander voorbeeld is een database met ronde eettafels waarvan de diameter, radius en oppervlakte (Opp. = π × r2) per tafel altijd hetzelfde is. Maar niet alle gegevens zijn stabiel en er zijn gegevens die kunnen rotten. Om aan te sluiten bij het voorbeeld van de tafels, dan zijn het aantal tafels op voorraad of de prijs van een specifieke tafel gegevens die hun validiteit kunnen verliezen en daardoor kunnen rotten.
Ik gebruik nog steeds het woord rotten, omdat niemand die bij zijn gezonde verstand in een verrotte appel zou bijten. Daarom geloof ik dat je ook geen verrotte data zou moeten gebruiken.
Variabele klantgegevens
Als je gegevens van klanten verzamelt, zoals namen en adressen, dan kunnen deze gegevens onderhevig zijn aan veranderingen. Mensen verhuizen. Klanten vertrekken. Mensen komen te overlijden. De lijst met duizendenden klanten wordt potentieel minder betrouwbaar.
Tijdsgebonden gegevens kunnen vanaf het moment dat ze opgeslagen worden vervallen
Dus, het rotten van gegevens heeft te maken met bepaald soort gegevens die om verschillende redenen kunnen verouderd. Maar de manier waarop data verrot is anders dan bij een appel, want vooral tijd is één van de belangrijkste factoren. Gegevens kunnen al beginnen te rotten op het moment dat ze opgeslagen worden.
Werken met verouderde gegevens
Laten we zeggen dat je 1.000 klanten in je database hebt staan. Voor een marketingprogramma exporteert jouw marketingmanager de klantendatabase om klanten persoonlijke mails te sturen over nieuwe producten, inzichten enzovoort. Omdat het flink wat werk is om persoonlijke gegevens te importeren en exporteren van en naar het CRM-systeem, doet de marketingmanager dat niet zo regelmatig. Het oorspronkelijk geëxporteerde bestand had 1.000 klanten, maar in hoeverre is die dataset nog valide na zes maanden? Zou je over zes maanden nog dezelfde 1.000 klanten hebben, of zijn het er meer of minder? Als je er meer hebt. Dan worden er kansen gemist. Als je er minder hebt, dan ben je mensen aan het benaderen die niet langer klant zijn. In het geval dat je andere klanten hebt gekregen, maar nog steeds 1.000 namen waarvan er nu 20% nieuw is, dan zit je er ook flink naast.
Hoe kun je voorkomen dat gegevens verouderd raken?
Er zijn veel meer voorbeelden te noemen van gegevens die mogelijk verrotten. Ik raad daarom aan dat je naar je eigen gegevens kijkt om te zien waar er potentieel rot kan optreden. Des te meer een organisch product blootgesteld wordt aan lucht en hoe warmer het is, des te sneller het rottingsproces gaat. Wat zijn de criteria waardoor jouw data rot? Wat zorgt ervoor dat jouw gegevens sneller rotten dan je dacht? En wat kun je er tegen doen?
De juiste wijze van gebruik en opslag
Een makkelijke manier om verse melk langer goed te houden is door het in de koelkast te zetten. Data is natuurlijk geen organisch product. Je zult gegevens bij moet houden zodat ze betrouwbaar blijven. Maar je zult ze ook op de juiste manier moeten bewaren! Ik bedoel hiermee dat je moet kijken naar welke gegevens er nog steeds accuraat zijn, maar ook welke gegevens (nog steeds) geschikt zijn voor het doel waar jij ze voor gebruikt. Iemands leeftijd als 42 opslaan heeft niet veel zin en raakt zeker weten verouderd, tenzij je ook de datum waarop je die observering gedaan hebt erbij vermeldt. Hoe dan ook, als je in plaats daarvan de geboortedatum van iemand weet, dan kun je de leeftijd achterhalen en zo kun je de gegevens vers houden en verrotting voorkomen.
Een uniform model?
Dingen worden ingewikkelder als er gegevens op verschillende plekken en in verschillende vormen opgeslagen worden. Er bestaat niet één groot datamodel dat al jouw gegevens vers houdt voor alle verbonden digitale omgevingen. En het is maar goed ook dat zoiets niet bestaat, want de complexiteit van een uniform model dat alle mogelijke gegevens met elkaar verbindt is, als je mij vraagt, deels een heilige graal en deels een Fata Morgana. In andere woorden: het zou fantastische zijn als het zou kunnen, maar het is echt niet haalbaar gezien de complexiteit en de kosten die het met zich mee zou brengen. Maar als we kijken naar uniformiteit van gegevens en hoe die door verschillende personen geïnterpreteerd wordt, dan zien we interessante verschillen. Neem bijvoorbeeld een bankrekening. Het is mogelijk om rood te staan op een betaalrekening (een manier voor banken om geld te verdienen), maar niet op een spaarrekening.
De waarde van historische data
Oude data hoeft niet per se verrot te zijn. Historische data kan geanalyseerd worden en daar kunnen patronen in gevonden worden. Een voorbeeld hiervan zijn seizoensinvloeden op de verkoop. Hoewel de gegevens van gister niet altijd heel veel over vandaag te zeggen hebben, bevatten ze wellicht toch lessen over dezelfde dag in volgende week. Oude data is niet noodzakelijkerwijs waardeloos, maar ook niet zijn gewicht in goud waard. Per situatie zul je moeten bepalen wat de potentiële zeggingskracht van de gegevens is en of dat te staven is met nieuwe gegevens.
Onvolledige data betekent gemiste kansen
Een klant kan zichzelf als single registreren wanneer hij of zij iets bestelt op jouw webshop, maar hoe weet je of deze persoon nog steeds vrijgezel is? Misschien kun je dit ‘ontdekken’ aan de bestellingen die hij of zij plaats, maar is dat een betrouwbare manier om gegevens te valideren? Dit zou uit kunnen lopen op missende gegevens en zodoende gemiste kansen.
Beheer je gegevens
Het vers houden van je data begint bij de juiste manier van opslaan. Een goed doordacht datamodel zal zorgen dat er geen overbodige gegevens opgeslagen worden, dat er een vastgesteld Entiteit-Relatie-Diagram of Domeinmodel is en dat de tabellen en velden die gebruikt worden daadwerkelijk de gegevens correct kunnen bevatten. Het klinkt allemaal logisch, maar er zijn tal van situaties waarin dezelfde data verschillende vormen aan kan nemen. Denk maar aan het verschil in datumnotaties in de VS en Europa. Maar ook adressen van klanten en postcodes kunnen verschillen van land tot land.
Wie beheert de gegevens?
Ben jij zelf de belangrijkste bron van de opgeslagen gegevens of zijn ze afkomstig van een andere organisatie? Als de gegevens van een ander organisatie komen, zouden zij je dan van een periodieke update kunnen voorzien? Het is belangrijk dat je duidelijk hebt dat de gegevens die je gebruikt up-to-date zijn. Is er een API die je zou kunnen gebruiken om de data bij te werken?
Eén van de mogelijke manieren om dit te doen is door je klanten zelf hun gegevens te laten bijwerken. Je zou dit zo gemakkelijk mogelijk voor ze moeten maken door alle hulp in te bouwen die je maar kunt bedenken, drop-down lijstjes met steden enz.
Validering van gegevens met de PostNL API helpt bij de controle van adressen, wat zeker een steun in de rug is bij het vers en correct houden van gegevens.
De onzekerheid groeit als de gegevens ouder worden
Tot slot: Hou het vers. Werk niet te lang met dezelfde uitdraaien, maar gebruik liever een nieuwe uitdraai als je opnieuw met de gegevens aan de slag gaat of maak een interface voor de database. Zulke interfaces kunnen API’s zijn, maar ook heel goed Graph QL schemas enz. Je kunt zelfs met algoritmes werken om gegevens te analyseren, maar wees voorzichtig met de privacy wetgeving. Toestemming vragen is tegenwoordig in iedere situatie een goed idee. Kijk ook eens naar de wenselijkheid van professionele ondersteuning.
Het belangrijkste van alles ligt misschien wel in de clou van het voorbeeld: Als ik een appel eet, kijk ik ernaar voor ik een hap neem. Pas dezelfde regels toe op je gegevens en bekijk ze goed voordat je ze gebruikt.
Met dank aan Prof. Dr. Martin Kersten (CWI) voor het oorspronkelijke idee van data schimmel.
