Continuous Intelligence

Haal meer uit je data

Een introductie tot Data Mining met CRISP-DM

Het belang van data

Data is altijd al een belangrijke factor geweest in de zakenwereld, maar nog nooit was het zo makkelijk om data te verzamelen als tegenwoordig. Giganten zoals Google en Facebook hebben ons geleerd, dat hoe meer data je tot je beschikking hebt, des te beter kan je groeien als bedrijf. Hierbij wordt snel vergeten dat je alleen met pure data niet veel kan zeggen. Het is een heel proces en ook een bepaalde manier van kunst om van je data inzichten te genereren en dat is waar de echte waarde pas tot stand komt. Om je hierbij te helpen werd CRISP-DM bedacht. In het vervolg van dit artikel worden voorbeelden gebruikt binnen het domein van websites en webapplicaties om het proces van CRISP-DM beter te verduidelijken.

 

CRISP-DM

CRISPDM-Extended.png

CRISP-DM staat voor Cross Industry Process for Data Mining en is het standaard proces met betrekking tot het genereren van inzichten uit ruwe data. De complete CRISP-DM methodology bestaat uit meerdere levels van abstractie, maar in dit artikel wordt hoofdzakelijk op de 6 fasen ingegaan. Daarnaast worden de desbetreffende generieke taken besproken om een beter beeld van de fasen te kunnen krijgen. Deze zes fasen zijn als volgt:

 

  1. Business Understanding

  2. Data Understanding

  3. Data Preparation

  4. Modeling

  5. Evaluation

  6. Deployment

 

CRISP-DM gaat uit van een flexibele aanpak, het moet dus altijd mogelijk zijn om van een fase naar een vorige fase te kunnen gaan.

Business Understanding

De eerste fase is een belangrijke fase, die vaak over het hoofd wordt gezien. De focus ligt bij een goed begrip krijgen van de projectdoelstellingen en -vereisten vanuit een zakelijk perspectief. Binnen deze fase hoor je de probleemdefinitie en het voorbereidend plan op te stellen voor je doelstellingen. Zorg er dus voor dat je weet waar je naar op zoek bent en met welke middelen je aan de slag wil gaan om deze doelstelling te bereiken.

Een website met doel te informeren zal een metric, die beschrijft hoe lang een gebruiker op een pagina blijft, interessanter vinden, dan een webwinkel, die meer wil weten over het gedrag voordat een conversie plaatsvindt.

Data Understanding

ai-artificial-intelligence-blur-546819.jpg

In deze fase ga je dieper in op je data, die je van plan bent om te gebruiken. Bekijk goed welke bronnen je ter beschikking hebt en in hoeverre deze bij dragen aan het behalen van je doelstellingen. Het identificeren van kolommen die missende of onbetrouwbare informatie bevatten is cruciaal. Je zult vast moeten leggen in hoeverre deze data nog bruikbaar is of beter genegeerd kan worden. Hier komt nog bij dat bepaalde metrics verschillende definities kunnen hebben afhankelijk van de persoon die deze vraagt.

Zorg er dus voor dat elke metrics een duidelijke definitie heeft en dat deze definitie ook gedeeld wordt met de personen die de data moeten interpreteren of gebruiken.

Een voorbeeld zou de metric sessieduur zijn. Om deze metric goed te kunnen interpreteren is het van belang om te weten wanneer een sessie start en stopt. Definitie één kan zijn: “De sessieduur is gelijk aan de tijd dat men ingelogd is”. Een andere definitie kan als volgt zijn: “Een sessie start bij de eerste interactie van een gebruiker en nadat de gebruiker 15 minuten inactief is geweest zal deze sessie stoppen; De sessieduur is de tijd tussen de eerste en laatste interactie”. Dan stelt zich wel weer de vraag, wat is een interactie? Alleen clicken, of ook scrollen?

Data Preparation

            Als het goed is heb je een goed begrip daarvan hoe je data uit ziet aan de hand van de vorige fase. Iets dat je opgemerkt zou kunnen hebben, is dat de een kolom data bevat die dezelfde elementen soms anders weergeeft. Een andere opmerking zou kunnen zijn, dat de data die je hebt gemeten verschillende eenheden bevat binnen dezelfde kolom of de verkeerde data types. Het is de bedoeling van deze fase om deze kolommen op te schonen, zodat er geen misverstanden zijn en alle daten aan dezelfde eisen voldoen.

            Stel je voor jou website bevat een formulier waar gebruikers in kunnen vullen hoe groot ze zijn. Nu heeft jouw website internationale gebruikers en vullen deze soms in cm, m of feet in. Aan de hand van je gedefinieerde metrics in de vorige fase, zul je deze kolom kloppend moeten maken, zodat elk getal of cm, m of feet is.

Modeling

            In deze fase is het de bedoeling de data zo te transformeren en te modelleren, dat deze klaar is om gevisualiseerd te worden. Afhankelijk van de complexiteit van je vraagstuk zal deze fase voor uitdaging kunnen zorgen. In vele gevallen wil men een trend waar kunnen nemen binnen bepaalde classificaties of groeperingen, waardoor vaak aggregaties toegepast worden.

            Voor dit voorbeeld hebben wij een webshop en het vraagstuk is wat voor invloed de sessieduur heeft op het koopgedrag. Bij deze aanpak groeperen wij de gebruikers per 3 minuten die ze doorbrengen op de website, omdat de gemiddelde sessieduur 8 minuten is. Hierdoor krijgen wij 5 groeperingen met een voldoende aantal gebruikers om er een mening over te vormen. De overigen gebruikers filteren wij weg, gezien deze voor ruis zorgen. Voor elk van deze groep berekenen wij de som van het aantal conversies die ze hebben gepleegd elke dag. Nu kunnen wij deze tabel makkelijk visualiseren om er uiteindelijk een conclusie uit te kunnen halen.

Evaluation

            Dit is de fase, die beslist of de ontdekkingen voldoen aan de criteria. Hierbij wordt terug gekeken naar het gehele process hoe men tot deze statistieken is gekomen. Je vraagt je af of de data die gebruikt werd, compleet en toepasselijk is, men controleert of er geen fouten zijn ontstaan tijdens de data preparation en modeling en als alles klopt kan men doorgaan naar Deployment. Is dit niet het geval, gaat men terug naar de desbetreffende stap gaat vanuit daar weer verder. Een fenomeen dat regelmatig voorkomt, is dat er inzichten waargenomen worden, die voor het desbetreffende partij al eerder heeft waargenomen, dit kan afhankelijk van de situatie handig zijn of betekenen dat je met een nieuw vraagstuk aan de slag moet.

Deployment

Dit is de laatste fase waar men alleen terecht komt als de evaluatie geslaagd is. Activiteiten binnen deze fase is een deployment plan schrijven, kijken hoe men deze inzichten voortdurend kan monitoren & onderhouden en het maken van het Final Report en/of Presentation. Met andere woorden er wordt ervoor gezorgd, dat de inzichten duidelijk weergegeven, goed beschikbaar gesteld en bijgehouden worden, zodat er bedrijfsdoelen of keuzes gevormd kunnen worden.

A/B testing

Door Ewan Klomp

directionalsign_83858.png

Veel mensen denken dat A/B testing enkel iets is voor grote bedrijven, met heel veel gebruikers zoals Facebook of Amazon. Maar niets is minder waar. Met de komst van tooling zoals Google Optimize is het mogelijk om ook bij kleine bedrijven A/B tests effectief uit te voeren. A/B testing met weinig moeite en zeer beperkte kosten. Op deze manier ontstaat een nog betere en completere teststraat. Ook kan de Product Owner nog beter inzicht krijgen in het softwaregebruik.

Wat is A/B Testing ook al weer?

Om nog even het geheugen op te frissen: bij een A/B test krijgen gebruikers applicatieversie A of applicatieversie B. Op basis van tevoren bepaalde metrics wordt uiteindelijk één van de versies als definitieve versie gekozen voor alle gebruikers.

Door A/B tests kan een softwareproducent betere beslissingen nemen op het gebied van User Interfaces, door bijvoorbeeld te kijken naar welke versie correleert met de grootste conversie.

Google Optimize als A/B test tool, biedt een goede integratie met Google Analytics.

Google Optimize

In dit artikel gaan we dieper in op Google Optimize. Optimize biedt een goede integratie met Google Analytics. Daarnaast heeft het een gratis versie waardoor je snel alle opties kunt onderzoeken. Uiteraard zijn er meer tools waarmee A/B tests uitgevoerd kunnen worden, zoals the A/B testplatform van VWO of het experimentenplatform van Optimizely. Welke het best bij jouw organisatie past is afhankelijk van je teststrategie.

google-optimize-logo-480x480-1-140x140@2x.png

Implementatie A/B Testing

Een A/B test opstellen is in feite een experiment uitvoeren. Je begint met een hypothese, verandert een element en bekijkt de statistieken (lees resultaten) van de vooraf bepaalde metrics.

Google Optimize heeft een editor waarmee je webelementen gemakkelijk kunt bewerken. Je meet met deze webelementen de metrics vanuit je Google Analytics doelen. Een andere nuttige functionaliteit van Google Optimize is dat je je direct op op bepaalde gebruikers kunt richten, op basis van bijvoorbeeld gedrag of locatie.

A/B Testing en Continuous Delivery 3.0

Met A/B testing leg je ook een directe link met het Continuous Intelligence en Continuous Planning gedeelte van Continuous Delivery 3.0. Op deze wijze krijg je nog meer informatie van gebruikers, op basis van de verzamelde metrics. Hier kan de Product Owner de backlog prioritering op aanpassen

AB_testing.png

Het figuur toont hoe de resultaten van A/B testing het Continuous Intelligence proces en Continuous Planning proces voeden

Bijvoorbeeld: als de conversie met de nieuwe versie niet is verhoogd, kan je een work item aanmaken waarin je onderzoekt hoe je de conversie wel kunt verhogen.

Via de bovenstaande aanpak kun je laagdrempelig kennismaken met de mogelijkheden om je product en je ontwikkelprocessen te verbeteren met A/B Testing, Continuous Intelligence en Continuous Planning. Ik hoop je geïnspireerd te hebben om A/B testen te implementeren in jouw teststraat! Download nu de whitepaper over A/B-testing.

Cross-platform UI testing met Xamarin

Door: Ewan Klomp

Nadat Microsoft begin 2016 Xamarin overnam, heeft Microsoft grote stappen gezet om cross-platform applicaties met goede performance in C# te bouwen. De snelheid is nog niet helemaal als Native code. Maar door de mogelijke code sharing tussen de twee platformen (iOS en Android) is het een degelijke optie. Zeker wanneer er geen zware computationele berekeningen nodig zijn. Dit artikel gaat dieper in op hoe je User Interface tests uit één project, op beide platformen draait.

Simpele werkwijze

De user interface test van Xamarin werken met een interface. De user interface test library heet Xamarin.UITest en de interface de IApp interface. Xamarin kan met dezelfde interface beide platformen bedienen. Door de IApp interface is het klikken van een object op iOS en Android heel simpel, met dezelfde app.Tap(string) method call.

Creëren van test cases

De methoden die de IApp interface heeft zorgen dat er diverse, geavanceerde test cases gecreëerd kunnen worden. De mogelijkheden zijn vergelijkbaar met die van grotere test platformen zoals Selenium. Ook kan je met Xamarin objecten makkelijk vinden door middel van naam of XPath. Vervolgens kun je ze klikken of er tekst bij invoeren. Natuurlijk bevat Xamarin specifieke methoden voor gestures zoals drag/drop, pinching, en swiping om een gebruiker zo goed mogelijk na te bootsen.

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

Hoe het werkt

Als je dus binnen je test een object aan wil klikken genaamd ´buttonHome´, voer je de functie app.Tap(buttonHome) uit. Dit zoekt dan het object met id ´buttonHome´ op in de huidige views die open staan. Om er voor te zorgen dat de juiste view de juiste ID heeft moet de ID op de juiste plek in de layout files toevoegen: .xib voor iOS en .xaml voor Android.

  • Op iOS geef je een id op deze manier mee aan een element in de .xib file:
    <accessibility key="accessibilityConfiguration" identifier="buttonHome"/>

  • Bij Android in de .xaml op deze manier:
    android:id="@+id/buttonHome"

Let hier op

In principe is het mogelijk om een test te schrijven die draait op Android en IOS. Het probleem zit soms in het verschil van gedrag tussen de platformen op het gebied van views. Hier moet dan binnen 1 testcase een verschillende implementatie voor geschreven worden. Verder is het van belang dat elk element van een testcase waarmee je werkt zijn eigen unieke ID heeft en hetzelfde zijn op beide platformen. Bij een juiste implementatie is het enige verschil de initialisatie van de applicaties voor het testen. Let er op dat je de ID’s van de objecten gelijk houdt op beide platformen. Hierdoor kunnen juiste objecten op de juiste plek gevonden worden.

En nu jij

Hopelijk heb ik je enthousiast gemaakt en ga je zelf met Xamarin aan de slag. Als je hier meer over wilt weten kun je me bereiken via ons contactformulier: