Verregaande data analyses maken in slechts 6 stappen

Je wilt aan de slag met verregaande data analyses. Logisch! Want de tijd dat we tevreden waren met simpele informatie over onze bezoekers zijn allang voorbij. We willen steeds meer weten over bezoekers, zodat we bijvoorbeeld deze, daar waar mogelijk, kunnen indelen in verschillende segmenten. Misschien zelfs in meerdere segmenten. We zijn op zoek naar meer informatie over de bezoekers (verrijken van data), zodat we ze beter kunnen bedienen, met meer conversies van dien. Vaak wordt dit als rocket science ervaren, waardoor het wordt verschoven naar een “next summer”, terwijl dit helemaal niet hoeft. Je kunt namelijk heel snel en simpel beginnen.

In dit artikel probeer ik uit te leggen hoe we met een paar simpele stappen al een goed fundament kunnen neerzetten voor een verregaande data analyse. Als voorbeeld gebruik ik een verzonnen elektronicawinkel die fysieke én online winkels heeft, waarvoor we graag de verhouding tussen loyale klanten en hun Net Promoter Score in kaart willen brengen.

Opzet verregaande data analyse

Om dit allemaal in gang te zetten hebben we een platform nodig. Dit kan variëren van je lokale datawarehouse tot een complex cloudplatform. Tegenwoordig zijn er heel wat betaalbare platformen op de markt. Denk aan Microsoft Azure, Google Cloud Platform, Amazon AWS, etc. De meerderheid van deze platformen hebben hun eigen ETL (een afkorting voor “Extraction, Transformation and Load” oftewel: het klaarstomen van je data) en data analyse laag. Welke van de Big Data platformen het handigst is, hangt af van je doel, de grootte van de data en je kennis. Je kunt ook besluiten om een platform gedeeltelijk te gebruiken, bijvoorbeeld alleen voor opslag van data.

Stap 0: Strategie uitdenken

Wat wil ik bereiken? Welke data analyses moet ik hiervoor doen en welke data heb ik hiervoor nodig?
In dit geval willen we de verhouding tussen loyale klanten en hun NPS in kaart brengen. Hiervoor moeten we eerst bepalen wat de definitie is van een loyale klant. Om het nu simpel te houden gaan we uit van een model waarbij een klant loyaal is, wanneer deze meer dan één keer per jaar een aankoop doet op onze website. We hebben dus een overzicht nodig van online aankopen.

We hadden overigens ook de winkelaankopen kunnen meenemen (misschien op basis van het rekeningnummer) maar voor de overzichtelijkheid van dit artikel doen we dat niet.

We hebben natuurlijk ook een overzicht nodig van alle NPS (Net Promoter Score) die is toegekend door de klant. Het belangrijkste is dat alle beschikbare data gekoppeld kunnen worden. Als dit niet mogelijk is kunnen we niet verder. Vandaar ook dat dit stap 0 is: het is een basisvoorwaarde.

In dit voorbeeld slaan we de user ID van Google Analytics op in onze eigen systemen. Het is dus belangrijk dat deze variabelen gekoppeld worden aan onze lokale gegevensbron (CMS) via het TMS (Tag Management System) of direct in de source van de website. De ga:userID zal dus onze gemeenschappelijke sleutel worden. Hiermee koppelen we de gebruiker tussen Google Analytics en onze systemen.

We moeten dus ook in de NPS formulieren de user ID meesturen. Mocht dat niet lukken dan zou je ook een proces kunnen opzetten waarbij je dit matcht op bijvoorbeeld het e-mailadres of een hash hier van (aangezien je geen mailadressen mag opslaan in Google Analytics).

Stap 1: Datavergaring

Hoe kom ik aan alle data? Denk bijvoorbeeld aan een klantenbestand, aan margecijfers en online gedrag. Welke afdelingen moet ik hiervoor benaderen en hoe kunnen zij data delen met mij?

Als we de data gekoppeld hebben kunnen we de IT-afdeling vragen ons toegang te geven tot de transactiedata. Deze zetten ze elke dag als CSV klaar (CSV is vaak het gemakkelijkst voor de IT afdeling en wordt ook breed ondersteund). Zo ook het klantenbestand. De NPS data halen we op vanuit de servers van een 3^e partij in JSON formaat.

Belangrijk is om altijd een check te bouwen die je waarschuwt indien de data niet langer goed worden verwerkt. Hoe later je hier achterkomt des te langer je analyse-mogelijkheden stil kunnen komen te liggen. Doe dit in het begin desnoods handmatig (elke dag kijken of de feeds klaarliggen en zijn verwerkt).

Stap 2: Datatransformatie

Op het moment dat we de data hebben, beseffen we vaak dat het niet altijd conform onze wensen is ingedeeld. Zelfs als we dit van te voren hadden geweten is er soms niets aan te doen. Je kunt bijvoorbeeld Google Analytics data niet veranderen van opzet/structuur, dus dat zul je achteraf moeten doen. Er zijn veel tools op de markt die ons kunnen helpen bij het transformeren van de data. Denk bijvoorbeeld aan Excel, R en andere gevestigde namen binnen het ETL-proces. Er zijn ook tools die zich richten op het transformeren van specifieke data (zoals bijv. Google analytics data).  Voor beginners zijn er ook visuele tools (Analytics Canvas, Talend, Pentaho), waarbij je met drag & drop je transformaties kunt inrichten.

In dit geval moeten we de transactiegegevens koppelen aan het klantenbestand. Dit moeten we namelijk gebruiken om de NPS data te koppelen aan de transactie feed. De datasets zijn niet zo complex, dus in dit geval gebruiken we R om de JSON response van de NPS API uit te lezen en te combineren met het transactie- en klantenbestand.  We krijgen dus uiteindelijk één CSV feed met alle transacties, aanvullende klantinformatie en (indien aanwezig) de NPS.

R heeft veel gratis libraries die het werken met verschillende dataformaten en cloudplatformen gemakkelijker maken. In dit geval hebben we de libraries: RCurl (om connectie te maken naar de API van de NPS), jsonlite (om de json reponses van de API plat te maken) en bigrquery (om data door te sturen naar BigQuery) gebruikt. Stap 3 gaat hier verder op in.

Stap 3: Data opslag

Nadat we deze stappen hebben gezet, is het noodzakelijk om opslag te hebben waarnaar we de data kunnen schrijven om zodoende koppelingen en extracties makkelijker te bewerkstelligen. Het is eventueel mogelijk om Microsoft Access dan wel Excel (offline) te gebruiken als opslag. Mijn advies is om dit in een cloud omgeving te doen. Denk aan een BigQuery, Google SQL Cloud, Azure of AWS Redshift etc. Je hoeft je dan namelijk veel minder druk te maken over de beveiliging van de data. Ook is het verbinden naar je databron veel makkelijker, omdat er veel libraries zijn die het werk al voor jou doen en je wilt namelijk een future proof (datawarehouse) database creëren, die je makkelijk kunt verrijken, waar je makkelijk analyses op kunt uitvoeren en die overal te bereiken is.

Omdat onze elektronicazaak al een BigQuery omgeving heeft, slaan wij nu alle data op in BigQuery. De samengestelde feed slaan we op als een aparte tabel.

Stap 4: Dataverrijking

Nu we onze database hebben opgebouwd, is het veel makkelijker om nieuwe data toe te voegen.
Dit kan door bijvoorbeeld scripts (R, NodeJS) of applicaties via een Task Scheduler* te draaien. Denk aan data uit je social media, display en andere kanalen. Het belangrijkste is hier dat we al deze data kunnen koppelen. Voor gebruikers is dit vaak een user ID, voor producten een product SKU of product ID.

* Een Task Scheduler is een programma dat meestal op een server draait en vaak ook gratis wordt meegeleverd (in Windows bijv.) die het mogelijk maakt om op gezette tijden iets uit te voeren.

Stap 5: Data extractie

Belangrijk is dat we uit de opgeslagen data de juiste informatie ophalen. Het is aan te raden om tijdens deze stap nogmaals te kijken naar de aggregatie. Is het nodig om tijdens elke analyse weer gigabytes aan data te doorzoeken of kunnen we ook geaggregeerde statistieken per dag opslaan? Dit kan namelijk veel schelen in de kosten van de cloudomgeving daar men hier doorgaans betaalt voor de tijd dat men de service gebruikt of de hoeveelheid data die men opslaat. Zwaardere queries die langer duren, kosten dus ook meer.
Voor de dashboards is het zelfs nog belangrijker om geaggregeerde data te hebben, omdat deze veel sneller werken wanneer statistieken al zijn voorgecalculeerd.

Stap 6: Data analyse

Er zijn momenteel enorm veel Dashboarding en Data Analyse tools op de markt. Denk aan Google Data Studio, Qlik, Power BI, Tableau etc. Voor welke tool je kiest, hangt wederom geheel af van jouw specifieke situatie. Soms wordt er al een tool gebruikt binnen de organisatie. Sowieso spelen in een keuze voor een tool naast mogelijkheden ook de kosten en gebruiksvriendelijkheid mee. In dit geval houden we het simpel en verbinden we Excel aan BigQuery zodat we snel data kunnen ophalen met simpele SQL-achtige opdrachten.

Het komt er nu op neer dat we een query doen waarbij we alle klanten ophalen die meer dan één keer voorkomen in de transactietabel in de afgelopen 365 dagen, want dat zijn onze loyale klanten. Aan de hand van deze klanten kunnen  we vervolgens in kaart brengen wat de NPS doet met de frequentie van aankopen.

Conclusie

Ik heb in dit artikel met hele simpele voorbeelden geprobeerd duidelijk te maken dat het echt niet zo lastig hoeft te zijn om diepere analyses te doen op data die we al hebben of makkelijk kunnen vergaren.

Uiteraard kun je je data en je analyses veel groter of ingewikkelder maken, maar de kunst is juist om klein te beginnen. Hiermee kun je namelijk veel makkelijker het gewenste “fingerspitzengefühl” ontwikkelen, zowel bij jezelf als in je organisatie. Uiteindelijk is het verstandig om bij complexere trajecten specialisten als database engineers en econometristen te betrekken.  Zij zijn natuurlijk getraind in de juiste methodes en technieken. Maar door eerst je basiskennis te ontwikkelen leer je waar de mogelijkheden liggen en weet wat er nodig is om deze kansen te benutten. Zo kun je betrokken specialisten beter aansturen terwijl zij zich buigen over ingewikkelde datakoppelingen en formules.