Een eenvoudig concept dat misleidende analyses voorkomt.

Ik draai al heel wat jaren mee in de datawereld en zie een fundamenteel concept dat keer op keer onderbelicht blijft in opleidingen en trainingen. In de meeste gevallen gaat het intuïtief wel goed, maar vroeg of laat komt iedereen weleens een verwarrende of misleidende analyse tegen waarvan de aanleiding tot die verwarring, of nog erger: fout, terug te voeren is op precies dit concept.

Het gaat om het onderscheid tussen standen en mutaties.

Je hebt er ongetwijfeld al eens mee gewerkt.

Ben je, net als het grootste gedeelte van je collega’s, ook al eens in de valkuil getrapt dat je het onderscheid niet scherp had?

Laten we, voordat we verder gaan, eens kijken wat dit onderscheid in de praktijk precies inhoudt.

Wat maakt het onderscheid tussen standen en mutaties?

Een stand is een fotomoment: de toestand (hoedanigheid) van je onderwerp of een groep van je onderwerpen op één specifiek tijdstip. Een stand is meestal een aggregatie, vaak een telling (aantal abonnees), maar soms kan het ook om een andere vorm van aggregatie gaan, zoals een som (banksaldo).

Een mutatie is een verandering die gebeurt binnen een bepaald tijdvak. Om te bepalen in welk tijdvak de mutatie plaatsvindt, heb je natuurlijk een tijdstip nodig van die mutatie. Soms is dat één tijdstip (het moment dat je een transactie deed, of dat je een e-mail opende), maar soms heb je een start en eind (de start en finish van een hardloopwedstrijd, het moment dat je de betaalfunnel in ging totdat je de transactie volbracht). Om te bepalen in welk tijdvak de mutatie hoort, maak je een keuze voor één specifiek tijdstip.

Een stand hoort dus bij één moment; een mutatie hoort thuis in een tijdvak.

Denk er eens aan alsof je naar een balans en een winst-en-verliesrekening kijkt. De stand is als de balans: een momentopname van waar het bedrijf op een bepaald moment staat, bijvoorbeeld op de laatste dag van het jaar. De mutaties zijn als de winst-en-verliesrekening: ze laten zien hoe je van de ene stand naar de andere bent gekomen over een bepaalde periode. Zo kun je goed voor ogen houden dat een stand je vertelt ‘hoe het nu is’ en een mutatie je laat zien ‘wat er is veranderd’.

Met andere woorden: de stand op tijdstip t is gelijk aan de stand op het beginmoment (laten we zeggen t = 0) plus alle mutaties die in die periode hebben plaatsgevonden.

Dus de formule is:

stand op t=0 plus de som van alle mutaties in dat tijdvak = de stand op t+1

Je ziet dat de concepten niet op zichzelf staan, maar met elkaar te maken hebben.

Heel eenvoudig: als je ze door elkaar haalt, kun je in de problemen komen. Dat kan leiden tot fouten, verkeerde conclusies of op z’n minst flink wat verwarring. Het is dus belangrijk om helder te hebben wat wat is.

Waar gaat het mis met de tijdsdimensie?

Tijd is sowieso vaak een van de lastigste factoren in data-analyse.

Er zijn in deze context twee veelvoorkomende problemen.

1. Optellen over de tijd.

Je kunt in het algemeen prima standen en mutaties optellen over dimensies, bijvoorbeeld regio’s, maar de dimensie tijd werkt anders.

Hoewel er bij de dimensie tijd een natuurlijke hiërarchie is (7 dagen in een week, iets meer dan 4 weken in een maand, 12 maanden in het jaar), mag je alleen bij mutaties sommeren.

Bij standen kan dat echt niet. Dat komt doordat standen geen cumulatieve betekenis hebben: elke stand vervangt de vorige.

Voorbeeld: Als je op maandag 100 leden hebt, dinsdag 102 en woensdag 103, dan heb je natuurlijk niet ineens 305 leden bij elkaar opgeteld.

Bij mutaties kan dat wel, maar bij standen niet.

Je kunt bij standen wel op andere manieren aggregeren over de dimensie tijd, maar niet sommeren.In de praktijk worden vaak ultimo (last) of primo (first) genomen. Maar ook minimum, maximum of gemiddeld kan soms passen.

2. Filters over tijdvakken.

Het is vrij normaal om bij dashboards filters toe te passen.Soms kun je datumranges zelf kiezen met een begin en eind, soms kun je de laatste x weken of y maanden kiezen. Dit filter is meestal alleen zinnig bij mutaties, niet bij standen. Immers, de stand is een momentopname.

Nu hoor ik je denken, ‘kan toch best, ik wil het verloop zien in de laatste x periode’.

En dat kan inderdaad kloppen.Maar is dit heel logisch?

Soms wel, maar heel vaak ook niet.

Vaak weten mensen nu niet meer waar ze naar kijken.

De stand van de actieve klanten vorige week? Nieuwe klanten? Klanten die hun abonnement deze maand hebben verlengd? (zitten de mensen met een jaarabonnement die niets hebben gewijzigd nu wel of niet in deze selectie?)

Kortom: vaak veel verwarring.

Advies: houd standen en mutaties helder gescheiden, dan voorkom je verwarring en fouten.

Hoe je dit in de praktijk toepast

Als je dit in de praktijk brengt, zijn er een paar concrete dingen om in gedachten te houden.

1. Zorg dat dashboards, grafieken en assen duidelijk gelabeld zijn, zodat gebruikers meteen kunnen zien waar ze naar kijken. Dat is echt een no-brainer, maar het voorkomt veel verwarring.

2. Ten tweede, let extra op als je tijdfilters gebruikt in dashboards waar zowel standen als mutaties in zitten. Als je een tijdfilter toevoegt, zorg er dan voor dat duidelijk is welke visualisaties daarop reageren. Een stand zal je soms niet willen laten veranderen op basis van dat tijdfilter. Het moet in elk geval door je ontwerp duidelijk zijn welke grafieken en tabellen wel en welke niet moeten reageren. Als er filters nodig zijn, probeer dan verschillende dashboardtabs te maken om de verschillende cijfers goed uit elkaar te halen.

Dus een apart dashboardtab voor de stand op een peildatum (een fotomoment, vaak ‘nu’, maar het kan ook een ander moment zijn), en een aparte voor de mutaties (over de tijd, doorgaans x-assen met tijdsdimensies).
Dat lukt niet altijd, maar het belangrijkste is dat je er goed over nadenkt.

3. Ten derde, als je werkt met tools waarin de gebruiker veel ruimte voor interactie met de data heeft, zoals Looker, moet je extra opletten. Als gebruikers vrij zijn om zelf te aggregeren, dan is het zomaar mogelijk dat ze een combinatie bij elkaar klikken die niet kan. Het vervelende is dat je dit niet altijd zelf ziet. Waarschijnlijk had je zelf wel gesignaleerd dat opgetelde ledenstanden niet zinnig zijn, maar dan moet je dat wel net zelf ook hebben getest.

Zorg dan in de configuratie, bijvoorbeeld in LookML, dat je aangeeft dat standen niet over tijd mogen worden opgeteld, terwijl dat voor mutaties wel kan. Zo voorkom je dat gebruikers per ongeluk standen gaan stapelen over de tijd en de mist ingaan.

En test het ook altijd zelf!

Het lijkt een detail, maar het onderscheid tussen standen en mutaties bepaalt of je analyses hout snijden. Maak het expliciet in je modellen, leg het uit aan je collega’s en check het in elk dashboard.

Het scheelt je later een hoop misverstanden.