Top-5 veelvoorkomende ontwerpfouten bij Klipfolio dashboards

19 augustus 2020 | 9 minuten leestijd

Sinds 2014 zijn we Certified Partner van Klipfolio. In de afgelopen jaren hebben we met deze prachtige tool ontzettend veel dashboards mogen bouwen. Dit deden we voor veel verschillende klanten met ook heel verschillende doelen. Ook helpen we veel marketingbureaus of klanten met de doorontwikkeling van hun dashboards die initieel door anderen zijn opgezet.

Veel ervaring dus! Door die ervaring weten we wat er speelt bij het bouwen van een Klipfolio dashboard. Een aantal zaken komen we daarbij vaak tegen, waar we zelf tegenaan gelopen zijn of die we juist bij dashboards van anderen hebben gezien. Ontwerpfouten, bijvoorbeeld.

Veel van deze ontwerpfouten zijn vaak heel verklaarbaar omdat je enerzijds snel een wijziging wilt implementeren. Anderzijds heeft Klipfolio zelf een behoorlijke ontwikkeling doorgemaakt, waardoor er nu functionaliteiten zijn die het ontwerpproces nu eenvoudiger maken.

Hierbij onze top-5 van ontwerpfouten in Klipfolio. En de oplossingen om ze te vermijden.

#1 – De “gatenkaas”

Ontwerpfout: Geen rekening houden met ontbrekende data
Resultaat: fouten in de grafieken met alle risico’s vandien
Oplossing: Lookup-functie gebruiken

Wat bedoelen we hiermee? Stel, je verwacht dat een bestand voor elk voorkomende maand, week, dag wel data heeft. Dus je verwacht bijvoorbeeld:

2020-01 100
2020-02 300
2020-03 200
2020-04 100
2020-05 200
2020-06 300
2020-07 400
2020-08 200
2020-09 100
2020-10 200
2020-11 100
2020-12 200

Maar stel, de werkelijkheid is dit

2020-01 100
2020-02 300
2020-04 100
2020-05 200
2020-06 300
2020-07 400
2020-09 100
2020-10 200
2020-11 100
2020-12 200

Hier kun je vrij snel zien dat er in maart en augustus geen data is. Echter, wanneer je een grotere dataset hebt kan het lastig zijn om deze gaten te op te merken.

De volgende grafiek laat de lijn zien die je had verwacht te zien. Hier is alle data te zien; de lijn loopt netjes van de eerste tot aan de laatste maand.

Maar in plaats daarvan krijg je de volgende grafiek:

Op het eerste gezicht valt hier weinig op. Bijna identiek aan wat je verwacht had zelfs, en dat is precies het gemene aan deze ontwerpfout. Wanneer je voor de X-as de kolom ‘datum’ pakt en voor de serie de kolom met data, dan doet Klipfolio precies wat je vertelt en plot deze data voor je. Echter als je goed kijkt zie je dat de X-as maart en augustus overslaat en deze helemaal niet meeneemt. Hierdoor lijkt de grafiek op eerste gezicht correct, maar is hij dat eigenlijk niet.

Wat kun je hieraan doen om dit op te lossen?
In dit geval is het handig om te werken met een DATERANGE-functie op de X-as.

DATERANGE(start, end, [format])

En aangezien we in dit geval de data per maand willen zien, moeten we de daterange functie combineren met een GROUP. Stel dat je een dynamische bron gebruikt en je ook nieuwe data wilt weergeven, dan kun je de parameter end ook nog vervangen door een functie als TODAY().

GROUP(DATERANGE("2020-01","2020-12","yyyy-MM"))
GROUP(DATERANGE("2020-01",DATEVALUE(TODAY(),"yyyy-MM"),"yyyy-MM"))

Door een van de twee bovenstaande functies te gebruiken weet je zeker dat de X-as alle mogelijke datums weer zal geven, en hij niet alleen zal aflezen wat hij binnenkrijgt.

Belangrijk is om deze functie te combineren met de LOOKUP-functie in je serie. Eerder heeft Tamara hier een uitgebreide uitleg over geschreven. Door het gebruiken van de lookup functie voor de serie zal Klipfolio altijd de juiste waardes koppelen aan de juiste datums. Doe je dit niet, dan zul je in dit scenario een grafiek krijgen met verschoven data, waar april wordt gerapporteerd als maart, enzovoort.

Door het gebruiken van de LOOKUP-functie registreert Klipfolio dat er geen matchende waarde is voor de maanden maart en augustus en zal het deze vervolgens rapporteren als 0. Op deze manier schets je geen vertekend beeld en kan je snel fouten in de data achterhalen.

LOOKUP(X-as, Kolom A(datum), Kolom B(data))

Als alternatief kun je ook de instelling ‘Leave gaps for blank values’ aan zetten.

De grafiek wordt dan als volgt geplot, met ‘gaten’ waar de data ontbreekt voor maart en augustus

#2 – Slicing

Ontwerpfout: De SLICE-functie inconsistent gebruiken
Resultaat: fouten in de grafieken met alle risico’s vandien
Oplossing: slice vermijden waar het kan + borgen in je data quality proces

Dit is puur slordigheid en het overkomt ons allemaal wel eens. SLICE is een erg handige functie in Klipfolio, waarbij je een aantal rijen aan het begin of het eind van een kolom kunt weghalen. Meestal gaat het om de eerste regel waarin een kolomtitel staat.

Een veel voorkomend probleem bij het gebruiken van de slice is dat deze op een inconsistente wordt gebruikt. Ben je niet consistent, dan kun je tegen onverwachte resultaten aanlopen. Dit komt doordat er een mismatch ontstaat tussen de hoeveelheid data per component in de formule.

Voorbeeld data

conditie uitkomst

foo 100
bar 200
foo 300
bar 400

De select functie bijvoorbeeld selecteert iets wanneer aan een voorwaarde wordt voldaan, en anders niet.

SELECT(B:B, A:A="foo")

Zal leiden tot

100
300

Stel dat we alles willen behalve foo, dus

SELECT(B:B, A:A!="foo")

Nu krijgen we uitkomst

200
400

Die kopregel willen we hier niet, dus die halen we eerst weg

SELECT(SLICE(B:B), SLICE(A:A)!="foo")

Het resultaat is nu

200
400

Maar wat als we dit vergeten in 1 van de 2?

SELECT(SLICE(B:B),A:A!="foo")

Nu krijgen we

100
300

Wanneer je dan de SLICE gebruikt, is het zaak om altijd heel goed de formules bij langs te lopen. Staat de slice bij alle componenten in de formule? Geven alle evaluaties (bliksemschicht rechts van de formulebalk) exact dezelfde hoeveelheid data weer? Als dat het geval is dan zit je goed.

Tip: heb je een SLICE gebruikt maar krijg je niet de resultaten die je verwacht? Controleer eerst goed of je deze wel echt overal gebruikt hebt voordat je het probleem ergens anders gaat zoeken.

#3 – De factor tijd

Ontwerpfout: In je klips geen rekening houden met de factor tijd, dus rapporteren over de hele base zonder rekening te houden met tijd.
Resultaat: beperkte bruikbaarheid tot zelfs foute conclusies
Oplossing: dimensie tijd toevoegen.

Stel: je hebt verschillende categorieën die je graag wilt weergeven in een staafgrafiek. Dan is het soms heel verleidelijk om alle data te gebruiken en te selecteren, deze categorieën op de ene as te zetten, en de waardes op de andere as. Op deze manier kun je de categorieën mooi met elkaar vergelijken.
Echter, wat wij aanraden is om toch een tijdsdimensie mee te nemen omdat dit veel meer informatie biedt.
Sterker nog: door de factor tijd niet mee te nemen, loop je het risico dat je appels met peren vergelijkt.

Stel, dit gaat om verschillende producten. Dan kun je met een grafiek zonder tijd bepalen welk product het best verkocht is. Met een grafiek over tijd kun je verschillende trends ontdekken:

Is de verhouding tussen twee producten altijd gelijk?
Of verschilt dit per maand/seizoen?
Wanneer het ene product minder verkocht wordt, wordt het andere dan meer verkocht (concurrerende producten)?
Of is product A het afgelopen jaar het meeste verkocht maar in de jaren ervoor weinig?

Dan zou een grafiek zonder tijdsdimensie misschien weergeven dat dit product minder verkocht is dan product B, dat het vroeger goed deed maar het afgelopen jaar minder.
Als dat niet haalbaar of handig is, zorg dan in elk geval dat je niet alle data selecteert, maar alle data van de afgelopen x periode; het is dan in elk geval afgebakend.

De factor tijd en het begrip daarvan, is binnen de data analyse cruciaal. De langste discussies en grootste misverstanden hebben vaak iets te maken met de tijd. Het onderwerp is te groot en te divers om in dit blogartikel uitgebreid te beschrijven. Voor nu is het wat ons betreft belangrijk dat je er in elk geval over nadenkt en het niet vergeet.

#4 – Redundantie

Ontwerpfout: Redundantie, dezelfde stukken formule vaker uitschrijven (herhalen)
Resultaat: complexe formules die moeilijk te onderhouden zijn.
Oplossing: hidden data elementen toevoegen en daarnaar refereren in je formules. Als je met multi component Klips werkt, kun je ook hergebruiken

Komt dit je bekend voor: je hebt een tijd zitten puzzelen met “or”, “and”, en “if” statements, maar je hebt nu precies de functie geschreven die precies die data selecteert die je nodig hebt. Deze ga je vol enthousiasme in meerdere series stoppen en je bent tevreden met het resultaat. Maar na een tijd moet deze functie toch veranderd worden, en moet je hem op ál die plekken weer aanpassen. Niet erg leuk werk.

Gelukkig is hiervoor een oplossing die je werk overzichtelijker maakt, en wat het onderhoud ook nog eens makkelijker maakt. Dit is het “Hidden data field”.
In dit veld kun je de berekening maken die je wilt. Vervolgens kun je dit veld gebruiken in andere functies door ernaar te refereren via “&Data:” gevolgd door de naam die je hieraan gegeven hebt.

Een mooi voorbeeld komt van een opdrachtgever voor wie wij een dashboard gebouwd hebben. Deze opdrachtgever heeft data van verschillende websites, en wil deze graag van elkaar kunnen onderscheiden. Hieronder staat de functie, als je niet met hidden data fields werkt:

Maar als we dit wel doen, ziet de functie er uit zoals hieronder. Het grote middelste gedeelte is nu gestopt in de hidden data fields “channel” en “sessions” (die op hun beurt ook weer verwijzen naar andere hidden data fields) en wordt op verscheidene plekken in de klip gebruikt. Wat kun je doen als er iets verandert aan een van de website URLS? Dan kun je dit makkelijk op 1 plek aanpassen en ben je snel klaar. Daarnaast is het tijdens het schrijven van de functie veel makkelijker om het overzicht te bewaren.

#5 – Spaghetti Graphs

Ontwerpfout: Te veel waardes van een dimensie in een chart.
Resultaat: Onoverzichtelijke grafieken
Oplossing: Beperken van aantal series en samenvoegen van data

Iets anders dat we veel tegenkomen zijn onoverzichtelijke grafieken. Ook wel “Spaghetti Graphs” genoemd. Deze grafieken zijn zo druk dat ze eigenlijk hun waarde verliezen: je kunt de trends niet meer duidelijk aflezen.

Wij hanteren als vuistregel: toon maximaal 7 series. De rest van de waardes gaan in de categorie ‘overig’. Het is wel belangrijk om goed met de klanten of je team te overleggen welke data er terecht komt in overig. Wat ook erg handig is, is om aan de Klip een kleine notitie toe te voegen die weergeeft welke waardes er precies in zitten, zodat iemand die de klip voor het eerst bekijkt dit ook weet.

Tot slot nog  2 bonus ontwerpfouten specifiek voor Google Analytics

Bonus #1 – Berekeningen met users

Ontwerpfout: Users afkomstig uit de API mag je, in tegenstelling tot sessies en pageviews en andere metrics, vaak niet zonder meer optellen.
Resultaat: foute data, met alle risico’s vandien.
Oplossing: 2 bronnen en toggle met user input control

Stel dat je een bron hebt uit Google Analytics met datum en daarachter aantal sessies en aantal users.
Vervolgens wil je aantal users per maand. Je mag dan niet het aantal users optellen! Althans niet als je het aantal users wilt berekenen conform de methode van Google Analytics zelf.

Dit is het beste aan te duiden met een voorbeeld.
Stel dat je de hele maand 1 user hebt op je website. Die komt elke dag 1 keer op je website.
Google Analytics zal zeggen dat je in die maand 1 user hebt met 30 sessies, geaggregeerd.
Wanneer je deze uitsplitst op dagbasis, dan geeft de Google Analytics API per dag steeds 1 sessie en 1 user. Als je vervolgens het aantal users weer optelt, dan zou je 30 users krijgen. Dat klopt gewoon niet.

Als oplossing kun je een bron aanmaken die alleen de users ophaalt en waarbij je de datum uit de dimensies haalt. In plaats daarvan maak je gebruik van een begin en einddatum in de filters (welke je dynamisch uitleest uit variabelen), of je gebruikt een andere aggregatie, bijvoorbeeld maand, als dimensie.

Bonus #2 – Data uit een steekproef

Ontwerpfout: Geen rekening houden met de sampling van Google Analytics.
Resultaat: Scheve verhoudingen
Oplossing: Precisie van de sampling verhogen of dynamische dimensies toepassen

Wanneer je in Google Analytics een grote bak data opvraagt kan Google Analytics sampling toepassen. Dit gebeurt ook wanneer je via Klipfolio een API call maakt naar Google Analytics. Echter, er komt geen waarschuwing zodat je kunt zien dat het gaat om gesampelde data, dus het valt vaak niet meteen op. Om deze reden is het belangrijk om van te voren te controleren of er wel of niet sampling toegepast wordt in Google Analytics. Is dit het geval? Dan zijn er alsnog opties om aan de niet gesamplede data te komen.

De eerste optie is een optie die ook beschikbaar is in GA zelf, en dat is de “report higher precision” optie. Deze kan je bij een API call ook gebruiken in je query door het volgende toe te voegen aan de query:

&samplingLevel=HIGHER_PRECISION

Dit helpt soms, maar lang niet altijd.

Een tweede optie is het gebruiken van dynamische parameters in de API call. Variabelen die je aanmaakt in de klip kunnen weer gebruikt worden in de query naar de API. Dit doe je met {props.[variabele]} waar [variabele] de naam is van de door jou aangemaakte variabele. Een voorbeeld van hoe dit eruit ziet is:

https://www.googleapis.com/analytics/v3/data/ga?ids=start-date={props.firstmonth}&end-date={props.lastmonth}&metrics=ga%3Asessions&dimensions=ga%3AyearMonth%2Cga%3AlandingPage&samplingLevel=HIGHER_PRECISION

Wat wij sowieso altijd aanraden is om gebruik te maken van de Google Analytics Query Explorer. In deze tool gemaakt door Google zelf kun je inloggen met je GA account en kan je alle mogelijke metrics en dimensies aanklikken. Klik op run en de pagina zal je de onderaan de pagina volledige query weergeven, evenals de resultaten en hierboven een indicator die weergeeft of sampling heeft plaatsgevonden.

Dit was onze opsomming van veel voorkomende en vermijdbare fouten in Klipfolio.
Ongetwijfeld kun je zelf nog meer missers of lastige voorbeelden uit jouw praktijk noemen, heb je vragen of wil je meer weten over foutloos of eenvoudiger klips bouwen in Klipfolio. Laat het ons dan weten:

neem contact op

Heb je een specifiek probleem waar je een goeie oplossing voor zoekt, neem dan ook contact met ons op.