BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Eindverslag Matthijs van Dorth 1265911 Arno de Bruijn 1262467 Datum: 8-2-2013 In opdracht van: Bedrijf: Technische Universiteit Delft:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Voorwoord
Vanaf september zijn wij in het kader van het Bachelorproject van de opleiding Technische Informatica aan de TU Delft aan de slag gegaan bij Content Power te Delft om een nieuwe statistiekmodule te ontwikkelen. In deze periode hebben wij in diverse stappen toegewerkt naar een mooi en bruikbaar eindproduct. Hoe dit allemaal tot stand is gekomen is te lezen in dit rapport. Hierbij willen wij ook graag de volgende personen bedanken. Iedereen binnen Content Power en in het bijzonder Jan Niemantsverdriet, voor de dagelijkse begeleiding, de zeer gewaardeerde feedback en het feit dat wij altijd terecht konden met al onze vragen. Willem van Valkenburg, voor zijn feedback en inzichten op het gebied van SEO. Rob, Sijmen en Chris voor de diverse tips die we gekregen hebben tijdens dit project. Wij hebben een erg leuke en leerzame tijd bij Content Power met jullie gehad. En uiteraard willen we ook de klanten van Content Power bedanken voor de tijd en moeite die ze genomen hebben om ons te ontvangen en door ons geïnterviewd te worden. Verder willen wij Martha Larson bedanken voor het begeleiden van dit project en de feedback tijdens het gehele proces.
2
Inhoudsopgave Voorwoord ................................................................................................................................................ 2 Samenvatting ............................................................................................................................................ 5 1.
Inleiding............................................................................................................................................. 6
2.
Probleemstelling en -analyse ............................................................................................................ 7
2.1 Probleemstelling ........................................................................................................................... 7 2.2 Hoofdvraag.................................................................................................................................... 7 2.3 Deelvragen .................................................................................................................................... 7 2.4 Probleemanalyse........................................................................................................................... 8 2.5 Data mining ................................................................................................................................... 8 2.6 Datavisualisatie ............................................................................................................................. 8 2.7 Webstatistiekanalyse .................................................................................................................... 9 2.8 Expertsysteem............................................................................................................................... 9 2.9 Website-prestatie-indicatie ........................................................................................................ 10 3. Functionele en niet-functionele eisen ............................................................................................ 11 3.1 Basisfunctionaliteit in eerste mockups: ...................................................................................... 12 3.2 Functionele eisen ........................................................................................................................ 13 3.3 Niet-functionele eisen................................................................................................................. 14 4. Implementatie..................................................................................................................................... 15 4.1 Doelstellingenoverzicht: ............................................................................................................... 15 4.2 Expertsysteem:.............................................................................................................................. 16 5. Tests .................................................................................................................................................... 17 5.1 Implementatietesten/Unit tests ................................................................................................... 17 5.1 User Interface ............................................................................................................................... 17 5.2 SIG ................................................................................................................................................. 17 6. Requirement evaluatie........................................................................................................................ 19 6.1 Must Have ..................................................................................................................................... 19 6.2 Should Have .................................................................................................................................. 22 6.3 Could Have .................................................................................................................................... 23 6.4 Want to Have ................................................................................................................................ 23 7. Aanbevelingen uitbreiding nieuwe statistiekmodule ......................................................................... 24 7.1 Aanbevelingen uit interviews met klanten: .................................................................................. 24 7.2 Aanbevelingen uit literatuur ......................................................................................................... 24 8. Reflectie .............................................................................................................................................. 25 8.1 Matthijs van Dorth: ....................................................................................................................... 25 8.2 Arno de Bruijn: .............................................................................................................................. 26 9. Conclusie ............................................................................................................................................. 27 10. Literatuur .......................................................................................................................................... 28 3
Data visualisatie: ................................................................................................................................. 28 Data mining: ........................................................................................................................................ 29 Web usage mining............................................................................................................................... 29 Bijlagen.................................................................................................................................................... 30 A. Screenshots..................................................................................................................................... 31 B. Opdrachtomschrijving..................................................................................................................... 36 C. SIG feedback ................................................................................................................................... 37 D. Oriëntatieverslag ............................................................................................................................ 39 E. Plan van Aanpak .............................................................................................................................. 40 F. RAD .................................................................................................................................................. 41 G. TDD ................................................................................................................................................. 42 H. Testplan .......................................................................................................................................... 43
4
Samenvatting Content Power biedt hun klanten een Content Management Systeem (CMS) aan waarmee zij gemakkelijk content op hun website kunnen aanpassen of toevoegen. Voor dit Bachelor-eindproject hebben wij onderzoek gedaan naar geautomatiseerde webstatistiekanalyse en website-prestatieindicatie voor de websites van klanten van Content Power. Hiervoor hebben wij literatuuronderzoek gedaan, interviews gehouden en uiteindelijk een proof-of-concept gebouwd. Deze proof-of-concept bestaat uit een aanbevelingen-dashboard als module binnen het CMS van Content Power. Websitebeheerders krijgen met behulp van een expertsysteem gegenereerde aanbevelingen te zien met als doel meer conversies en search engine-optimalisatie. Tevens worden de beheerders in staat gesteld de prestaties van hun website te volgen door middel van door hun instelbare doelstellingen. Aan eenvoud wordt een hoge prioriteit gegeven alsmede het voorzien van de module van een "actionable interface". Vanwege de complexiteit van dit project en de gelimiteerde tijd is er gekozen voor een proof-ofconcept. Daarbij is veel aandacht besteed aan het uitbreidbaar maken van ons systeem, zodat hier later door Content Power op verder gebouwd kan worden.
5
1. Inleiding Content Power is een full service internetbureau met een intern ontwikkeld Content Management Systeem (CMS). Dit CMS stelt klanten van Content Power onder andere in staat relatief gemakkelijk content van hun website aan te passen of toe te voegen. Vaak vormen deze websites van klanten een belangrijk middel bij het vervullen van hun bedrijfsdoelen. Voor meerdere klanten is hun omzet zelfs afhankelijk van de websitebezoekers. Derhalve is het voor beheerders interessant een goed inzicht te krijgen in hoe hun website bezocht wordt. Idealiter kunnen zij zelf met deze kennis vervolgens hun websites verbeteren om zodoende meer bezoekers te trekken en een groter aantal bezoekers zich te interesseren voor hun product. Het CMS bevat reeds een statistiekmodule welke de beheerders dit inzicht moet verschaffen. Content Power heeft echter te kennen gegeven dat er nog maar weinig met deze statistieken gedaan wordt. Tevens blijkt het voor veel beheerders lastig om deze statistieken te interpreteren. Dit geeft aanleiding tot de volgende hoofdvraag: “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
In dit eindverslag beschrijven we hoe we tijdens onze stage bij Content Power antwoord proberen te geven op deze vraag. We vertellen hoe deze opdracht vorm gekregen heeft. Hoe wij door middel van onderzoek een mogelijke oplossing bedacht hebben. Hoe wij met behulp van interviews onze beoogde oplossing tot concept uitgewerkt hebben en hoe wij uiteindelijk een proof-of-concept gebouwd hebben als de nieuwe statistiekmodule voor het CMS van Content Power.
6
2. Probleemstelling en -analyse In eerste instantie zijn wij met Content Power in contact gekomen in reactie op een stageopdracht die gepost was op Blackboard. Dit betrof een opdracht voor het opzetten van een webwinkelmodule toegespitst op smartphone- en tabletbezoekers. Zodoende gingen wij voor het eerst langs bij Content Power voor een kennismaking. Echter, na enig onderzoek gedaan te hebben leek deze opdracht ons niet uitdagend genoeg. Maar de klik met Content Power was er al wel; dus hebben we in overleg besloten toch voor hun aan de slag te gaan. Tijdens het kennismakingsgesprek was naar voren gekomen dat de statistiekmodule weinig gebruikt werd. Dit probleem intrigeerde ons, en verdiende nader onderzoek.
2.1 Probleemstelling Vanuit Content Power is te kennen gegeven dat er al wel enkele gebruikersstatistieken bijgehouden worden door het CMS, maar daar nog niet genoeg mee gedaan wordt. Onze taak is dan ook om uit te zoeken hoe dat beter kan. Welke gegevens worden nu al bijgehouden en kunnen we eventueel nog meer nuttige statistieken bijhouden? Daarnaast is het zaak dat deze informatie vervolgens overzichtelijk gepresenteerd wordt voor de beheerders van websites die gebruik maken van het CMS.
2.2 Hoofdvraag Zoals in de inleiding reeds vermeld zijn wij tot de volgende onderzoeksvraag gekomen: “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
2.3 Deelvragen Om ons onderzoek behapbaar te maken splitsen we deze onderzoeksvraag op in de volgende deelvragen welke in de rest van dit document aan bod zullen komen. 1. Welke technieken zijn er om inzicht te krijgen in de acties van gebruikers? 2. Welke statistieken geven inzicht in de acties van gebruikers? 2.1. Welke statistieken worden in de huidige statistieken module bijgehouden? 2.2. Welke andere informatie kan er nog meer inzicht geven? 3. Hoe zijn deze statistieken het best (grafisch) weer te geven zodat dit ook voor niet-technische mensen begrijpelijk is? 3.1. Welke grafische weergaven zijn geschikt voor de verschillende typen data? 3.2. Hoe worden data in vergelijkbare systemen gevisualiseerd en kan dit in ons systeem beter?
7
2.4 Probleemanalyse Aangezien het ons vrij stond een oplossing te bedenken voor het geschetste probleem, zijn wij begonnen met onderzoek naar bestaande technieken die gebruikt zouden kunnen worden (deelvraag 1). Hieronder volgt een overzicht van de velden waarin we ons literatuuronderzoek gestart zijn en de technieken waar we uiteindelijk voor gekozen hebben inclusief de motivatie voor deze keuzes.
2.5 Data mining Ons onderzoek startte in de hoek van data mining. Een voor de hand liggende keuze, aangezien we voor alle websites draaiende op het CMS niet alleen beschikken over de websitecontent, maar ook over een willekeur aan metrics gemeten door het CMS waar we zelf al dan niet nog nieuwe metrics aan toe kunnen voegen. Zie voor een overzicht van alle metrics het Oriëntatieverslag in Bijlage C. In potentie valt er dus veel te meten en in de huidige statistiekmodule worden ook al de nodige statistieken geraporteerd. Daarnaast zijn er al verschillende pakketten op de markt die het mogelijk maken statistieken van een website te meten. Van de onderstaande lijst met analytics-pakketten die wij hebben bestudeerd is Google Analytics veruit de populairste. We hebben met name onderzocht hoe zij precies de voor hun beschikbare gegevens presenteren aan de gebruiker.
Google Analytics: Open Web Analytics: Piwik: OpenTracker: SiteCore:
http://www.google.com/analytics/ http://www.openwebanalytics.com/ http://piwik.org/ http://www.opentracker.net/ http://www.sitecore.net
2.6 Datavisualisatie In het nieuwe systeem is dus een hoop data beschikbaar. Deze data moet echter ook begrijpelijk en overzichtelijk gerepresenteerd worden. Datavisualisatie is de studie die zich met de visuele representatie van informatie bezighoudt. In dit gebied gingen wij opzoek naar technieken om de grote hoeveelheid data die we in dit project tot onze beschikking hebben te respresenteren. De standaard hulpmiddelen waar elk door ons bestudeerd analytics-pakket ook gebruik van maakt liggen voor de hand:
Tabellen: om simpele vergelijkingen te maken tussen verschillende waarden. Staafdiagrammen: om individuele waarden zichtbaar te maken en te kunnen vergelijken. Taartdiagrammen: voor het zichtbaar maken van verhoudingen in verzamelingen. Lijndiagrammen: om veranderingen ten opzichte van de tijd zichtbaar te maken.
8
Echter blijkt uit onderzoek [7] dat de meeste mensen beperkt in staat zijn om deze visualisaties correct te interpreteren. Tevens zouden wij binnen onze stage nooit een zo volledig uitgewerkt product kunnen ontwikkelen als de bovengenoemde reeds beschikbare analytics-pakketten.
2.7 Webstatistiekanalyse Derhalve hebben we besloten voor een andere aanpak. Toen we bij Content Power informeerden naar hun klanten en gebruikers van de statistiekmodule bleek dat een groot deel slecht in staat is de juiste conclusies te trekken uit de statistieken. Dat bracht ons op het idee om de analyse van statistieken te automatiseren. Uit literatuuronderzoek [1] en interviews hebben wij de volgende kernpunten van goede webstatistiekanalyse op kunnen stellen:
‘Goal tracking’, inzicht in conversieratio. Overzichtelijke presentatie van interessante statistieken. Eventuele filtering en aggregatie om alles helder te presenteren zodat de gebruiker gemakkelijker een beslissing kan maken aan de hand van de statistieken. Inzicht in ‘bounce ratios’ en onderscheid tussen een ‘good bounce’ (langdurig bezoek van één pagina) en ‘bad bounce’ (slechts kort bezoek van één pagina). ‘Timely tracking’. Bijhouden van de tijdsduur die een bezoeker doorbrengt op de pagina.
Metrics die inzicht in deze kernpunten verschaffen zullen dus uitgelicht moeten worden. In de requirements in hoofdstuk 3 vindt u een overzicht van de precieze metrics. Onze methode om deze metrics automatisch te analyseren is door middel van een expertsysteem [2].
2.8 Expertsysteem Een expertsysteem is een programma dat het vermogen van een menselijke expert om beslissingen te maken tracht na te bootsen [5]. Deze techniek behoort tot het vakgebied van de artificiële intelligentie (AI) en is een voorbeeld van een intelligent systeem (IS). Het expertsysteem dat wij gaan implementeren moet aanbevelingen genereren voor websitebeheerders, zodat zij in staat zijn content op hun site via het CMS aan te passen waardoor hun site beter moet gaan presteren. De aanbevelingen worden gegenereerd aan de hand van de beschikbare webstatistieken, domeinkennis van de betreffende website en expertkennis. Deze expertkennis wordt als zogenaamde regels in de vorm van 'best practices' ingevoerd. Wij hebben zelf regels opgesteld aan de hand van literatuur en tevens naar Search Engine Optimization (SEO)-experts gezocht om te interviewen. Content Power kan later nog meer regels toevoegen en beschikt zelf ook over een SEO-expert, te weten Willem van Valkenburg. Voor de verdere beschrijving van de technische werking van het expertsysteem, zie Bijlage F.
9
2.9 Website-prestatie-indicatie Het uiteindelijke doel van de webstatistiekanalyse is het bevorderen van websiteprestaties in de toekomst. Maar de websitebeheerder is uiteraard ook geïnteresseerd in de huidige prestaties van zijn website. Dit prestatieverloop willen wij representeren met behulp van het zogenaamde doelstellingenoverzicht. Daarnaast is het natuurlijk belangrijk dat de beheerders de aanbevelingen opvolgen en dus is ervoor gekozen om naast de aanbevelingen ook een spelelement toe te voegen. Als spelelement zal een sitescore gegeven worden afhankelijk van het aantal behaalde doelstellingen, zoals in figuur 1 en 2 te zien is. De beheerder zal zo gestimuleerd worden om een zo hoog mogelijke score te behalen voor zijn site door aanbevelingen op te volgen. Het gebruik van spelelementen om gebruikers te beïnvloeden wordt ook wel gamification genoemd [11].
Figuur 1: Doelstellingenoverzicht met sitescore
10
3. Functionele en niet-functionele eisen Deze sectie bevat een beknopt overzicht van alle requirements. Zie voor een volledig overzicht het Requirements Analysis Document (RAD) in bijlage E. Aan de hand van literatuuronderzoek en eisen vanuit Content Power hebben we de eerste requirements opgesteld. Op basis van deze requirements hebben we mockups gemaakt van de user interface (UI) met daarin de door ons beoogde functies. In interviews met klanten hebben we vervolgens verschillende functies gevarieerd om te kunnen concluderen wat wel en wat niet werkt. Aan de hand van deze resultaten zijn nog enkele requirements toegevoegd en aangepast. In het RAD komt aan bod welke requirements bij welke partij vandaan komen en onze motivatie daarvoor.
Figuur 2: Eerste mockup van de nieuwe statistiekmodule 11
3.1 Basisfunctionaliteit in eerste mockups: De volgende functionaliteit vormt de kern van de nieuwe module. Hiervan zijn we uitgegaan bij het ontwerpen van de eerste mockups:
Het dashboard met daarop de aanbevelingen en sitescore. Expertsyteem bestaande uit een inference engine en enkele rules, welke de aanbevelingen maakt. Uitbreidbaarheid van rules, zodat Content Power later meer toe kan voegen. Aanbevelingen zijn gerangschikt naar prioriteit. Een online enquête bij eerste gebruik, zodat domeinkennis van de specifieke site meegenomen kan worden in de aanbevelingen. Overzicht van de behaalde en te behalen doelstellingen. Gewogen doelstellingen naar prioriteit. Bij gebruik van complexe terminologie uitleg tonen.
Interview datum Interlodge ma 12-11 11:30 BestHotelOffers di 13-11 14:00 I-Matic vr 16-11 14:00 Geïnterviewde klanten, zie RAD in bijlage E voor alle bevindingen.
locatie Arnhem Huizen Leiden
Tijdens de interviews werd eerst een aantal vragen gesteld over hoe de gebruiker het CMS gebruikt en in hoeverre deze gebruiker gebruik maakt van bepaalde andere statistiekpakketten zoals Google Analytics of Google Adwords. Vervolgens werden de mockups getoond en werd er gevraagd wat de gebruiker daarvan vond. Gedurende dit gedeelte kon de gebruiker vrijuit praten over zijn ervaringen met statistieken en wat de gebruiker moeilijk vond en wat de belemmeringen waren om bepaalde dingen wel of niet te doen. We hebben van te voren wel een script uitgewerkt, maar tijdens de interviews werd hier over het algemeen van afgeweken omdat de gebruikers vaak erg enthousiast begonnen te vertellen wat zij graag aan nieuwe functionaliteit zouden zien. Op deze manier kwam wel veel informatie en nieuwe ideeën naar voren. Waar mogelijk hebben we dit uiteraard verwerkt in de requirements. Al met al was de gegeven feedback erg nuttig. Er werd in het bijzonder positief gereageerd op de sitescore-progressiebar en het doelstellingenoverzicht.
12
3.2 Functionele eisen De functionele eisen konden vervolgens worden opgesteld. Hierbij waren de interviews de belangrijkste bron, maar ook zijn er eisen gesteld afkomstig van Content Power. De verschillende functionele eisen die gesteld zijn voor dit project staan uitvoerig beschreven in het Requirements Analysis Document die te vinden is in bijlage E. Samengevat uit het RAD zijn dit de eisen geprioriteerd volgens het MoSCoWmodel.
3.2.1 Must Have 1. Expertsysteem welke aanbevelingen doet voor on-page zoekmachine-optimalisatie. 2. Actionable interface: het ontwerp nodigt uit om de aanbevelingen uit te voeren. 3. De volgende statistieken worden in ieder geval verzameld: a. aantal bezoeken op de gehele website. b. aantal bezoeken op specifieke pagina. c. aantal bounces op specifieke pagina. d. pagina-bounce rate tegenover het websitegemiddelde. e. gemiddelde tijd doorgebracht op specifieke pagina. f. gemiddelde tijd doorgebracht op de gehele website. g. exit rate per pagina. h. zoekwoord-rank. i. lengte van de meta description. j. titel ingesteld. 4. Het nieuwe systeem moet als module functioneren binnen het CMS van Content Power. 5. Vanwege de onderhoudbaarheid van de code in de toekomst door Content Power moet ontwikkeld worden in ‘de huisstijl’ in PHP en HTML. Voor databasetabellen moet de CPMyAdmin-module gebruikt worden. 6. Uitbreidbaarheid van kennis expertsysteem (medewerkers van Content Power moeten regels die gebruikt worden bij het generen van aanbevelingen kunnen toevoegen en aanpassen, alsmede de databronnen die voor deze regels gebruikt worden). 7. Overzicht met aanbevelingen, waarvan voor elke aanbeveling geldt: a. deze is in begrijpelijk Nederlands geschreven. b. lastige begrippen moeten worden uitgelegd. c. aanbevelingen hebben een prioriteit. d. aanbevelingen moeten weggeklikt kunnen worden. 8. Door beheerder instelbare doelstellingen voor hun website, op basis van de beschikbare statistieken. 9. Overzicht van de behaalde doelstellingen. 10. Overzicht van de niet-behaalde doelstellingen. 11. Sitescore, gebaseerd op de verhouding tussen behaalde en niet-behaalde doelstellingen. 12. Visualisatie van de sitescore met een progress bar. 13. Er wordt dagelijks gekeken of er nieuwe aanbevelingen gedaan kunnen worden en of aanbevelingen doorgevoerd zijn.
13
3.2.2 Should Have 1. Voorbeelden geven bij aanbevelingen van sites (intern of extern) waar dat advies wel goed geïmplementeerd is. 2. Aanbevelingen verdelen in korte- en langetermijnoplossingen. 3. Verloop in de tijd van de behaalde en nog te behalen doelstellingen. Met instelbare tijdsperiode. 4. Onderscheid naar prioriteit voor doelstellingen. 5. Integratie met het stappenobject.
3.2.3 Could Have 1. Feedback op gegeven aanbevelingen meenemen in het doen van nieuwe aanbevelingen. 2. Tonen van de meest belangrijke statistieken op het dashboard. Moet instelbaar zijn per gebruiker, wat ze zelf willen zien: a. unieke bezoekers. b. overzicht referrals. c. overzicht pagina’s met een hoge bounce rate t.o.v. sitegemiddelde. d. overzicht locatie bezoeker. 3. Hogere frequentie van het daadwerkelijk maken van aanbevelingen. 4. Disclaimer waarin vermeld wordt dat alle gegevens vertrouwelijk behandeld worden. 5. Genormaliseerde data op basis van alle websites gehost bij Content Power.
3.2.4 Want to Have 1. Voorspelling wat het effect is van het doorvoeren van een aanbeveling.
3.3 Niet-functionele eisen Daarnaast zijn er nog een aantal niet-functionele eisen gesteld aan de module. Dit zijn functionaliteiten die niet direct meetbaar zijn, maar wel van belang zijn voor een succesvol product.
Betrouwbaarheid Bruikbaarheid Efficiëntie Onderhoudbaarheid / Overdraagbaarheid
14
4. Implementatie In het Technical Design Document (TDD) in bijlage F vindt u alle implementatiedetails. Hieronder volgt een beknopt overzicht van de werking. Grofweg bestaat de nieuwe statistiekmodule uit twee delen: 1. Doelstellingenoverzicht: inzicht geven in de prestaties van een website door middel van voor de webbeheerder instelbare doelstellingen. 2. Expertsysteem: het geven van aanbevelingen hoe en welke websitecontent aangepast kan worden om de website beter te laten presteren. 4.1 Doelstellingenoverzicht: In het doelstellingenscherm is net als op het hoofdscherm de progress bar te zien. Daaronder zijn drie tabellen te zien met daarin reeds behaalde doelstellingen, niet-behaalde doelstellingen en inactieve doelstellingen. In dit scherm kunnen de beheerders zelf doelstellingen toevoegen die ze willen bijhouden. Dit onderscheid is gemaakt zodat snel kan worden bepaald wat er goed gaat en waar nog winst te behalen valt. De sitescore is zichtbaar in de progress bar boven de tabellen en wordt bepaald door de fractie van behaalde doelstellingen. Het doelstellingenoverzicht kan zeer vereenvoudigd weergeven hoeveel unieke bezoekers er bijvoorbeeld geweest zijn binnen een bepaalde periode of hoe lang bezoekers gemiddeld op de site blijven. Gebruikers kunnen zelf nieuwe doelstellingen toevoegen door middel van een formulier dat verschijnt nadat op de ‘voeg doelstelling toe’-knop wordt geklikt of kunnen oude doelstellingen wijzigen of verwijderen.
Figuur 3: Doelstelling toevoegen 15
4.2 Expertsysteem: Aan de hand van gegevens uit de volgende bronnen worden aanbevelingen gedaan aan de websitebeheerder; hoe hij of zij website-content aan kan passen om zodoende de site beter te laten presteren. - Statistieken gemeten door het Content Power CMS. - Content van de website zelf (HTML). - Domeinkennis van de beheerder, verkregen via een online enquête. - Google site rank. - Later toe te voegen externe bronnen zoals Google AdWords en social media. Aanbevelingen worden gedaan aan de hand van 'best practices' en bijvoorbeeld SEO-advies. De voorwaarde voor het kunnen doen van deze aanbevelingen is dat ze uitgedrukt kunnen worden in zogenaamde rules. Een rule bestaat uit één of meerdere condities waaraan voldaan moet worden, en één of meerdere acties die vervolgens uitgevoerd moeten worden wanneer de rule vuurt. Rule: 1...n conditions --> 1...m actions Een conditie is in dit geval een statement bestaande uit een van de metrics uit de hierboven vermelde bronnen, een operator en een doelwaarde. Van deze statement kan de waarheidswaarde bepaald worden. Als aan alle condities van een rule voldaan wordt, worden al zijn actions uitgevoerd. Voorbeelden van conditions: titleset = FALSE averageTimeOnPage < 2 sec descriptionLength <= 5 (woorden) Een action bestaat uit het creëren van nieuwe facts die kunnen voorkomen in condities van andere regels of het doen van een aanbeveling. Het expertsysteem beslist welke rules vuren aan de hand van een snapshot van de benodigde metrics, en voert al deze regels daadwerkelijk uit. Het is dus van belang dat de best practices, SEO-regels of andere regels op deze manier uitgedrukt kunnen worden. Voorbeelden van rules: descriptionLength <= 5 --> "Voer een heldere description in op de pagina" pageBounceRate >= 40, averageTimeOnPage < 2 sec --> "Veel bezoekers verlaten uw website op deze pagina. Wellicht is er geen goede call-to-action" Uiteindelijk worden de aanbevelingen zichtbaar gemaakt in de nieuwe statistiekmodule. Door hier ook een overzicht van instelbare website-doelstellingen te presenteren hopen we dat beheerders regelmatig terugkeren en de aanbevelingen daadwerkelijk uit gaan voeren om zodoende hun doelstellingen te bereiken. 16
5. Tests In het Testplan in bijlage G vindt u een uitgebreide beschrijving van de tests die wij willen uitvoeren. Hieronder vindt u een beknopt overzicht van de testresultaten.
5.1 Implementatietesten/Unit tests Voor het doen van tests tijdens de implementatie hebben we de database waarop deze module draait met verschillende testdata gevuld. Om deze tests uit te voeren zijn verschillende testmethoden gemaakt die steeds delen van de code uitvoerden, zodat gecontroleerd kon worden of de juiste data weer geretourneerd werd. Ook is veelvuldig gebruik gemaakt van het error object die beschikbaar is binnen het CMS. Zodra een bepaalde conditie geldt die niet correct is wordt de vError methode aangeroepen die aangeeft wat er fout is gegaan, zodat het debuggen een stuk makkelijker werd. 5.1 User Interface De user interface is ook getest door verschillende soorten mogelijke data in de tabellen te zetten. Zo werd gekeken of de interface er in alle gevallen nog goed uit zag ongeacht wat er in de aanbevelingen en doelstellingen staat. Daarnaast is de interface getest in verschillende browsers. In zowel IE10, Chrome en Firefox 16 bleek de interface er goed uit te zien en waren alle elementen goed zichtbaar. In IE9 was de mouseover van de progressbar niet zichtbaar, maar verder werkte ook alles in deze browser zoals het zou moeten. 5.2 SIG De kwaliteit van de code die tijdens dit project is opgeleverd, is opgestuurd aan en beoordeeld door de Software Improvement Group. Zij controleren de code op verschillende punten en geven hier bepaalde scores aan. Het volledige commentaar van de SIG is te vinden in bijlage J. 5.2.1 Feedback 1 De code is vlak na de helft van de implementatiefase naar de Software Improvement Group gestuurd. Dat onze code in eerste instantie niet hoog zou scoren op verschillende punten was wel onze verwachting. Op het moment van eerste inleveren moest er nog redelijk wat gebeuren en moesten bepaalde stukken code nog opnieuw gerefactored worden. Naar aanleiding van dit commentaar en ons eigen inzicht hebben we dan ook nog veel aangepast na dit eerste inlevermoment. Unit Size Allereerst hebben we de grootste methoden opgesplitst in kleinere methoden. Zo hebben we alle events die kunnen triggeren en worden opgevangen door vProcessActiveForm een eigen methode gegeven. De langste methode in onze code was de sGetQuery-methode die de correcte query matched met de metric type. Dit was in eerste instantie een grote switch maar uiteindelijk hebben we ook deze opgesplitst in meerdere methoden voor elke switch case. Duplication Voor de drie verschillende methoden die de doelstellingen teruggeven hebben we precies het omgekeerde gedaan. Deze methoden leken erg op elkaar dus hebben we hier één methode van 17
gemaakt welke een nieuwe methode aanroept die het onderscheid maakt tussen de drie gevallen. Hierdoor is de code korter en bevat minder duplication waardoor de code makkelijker onderhoudbaar is. Unit Interfacing Het grootste aantal parameters voor een methode is vier. Dit is een zeer acceptabel aantal. Het commentaar van de SIG om een nieuw periode-object te maken en dit mee te sturen i.p.v. een start- en einddatum is een goede suggestie. Echter, omdat voor een dergelijk object naast de checks ook formulierfuncties geprogrammeerd zouden moeten worden, zou dit te veel tijd kosten om op korte termijn te implementeren. Het maken van een periode-object zullen we wel meenemen als aanbeveling aan Content Power om in de toekomst wellicht te implementeren. Er is wel een functie gemaakt die de condities van de start- en einddatum checkt. Overig commentaar In het commentaar van de SIG over het feit dat het grootste deel van de code zich bevindt in de klasse CmsStatsModule2.php, kunnen wij ons volledig vinden. Binnen Content Power is het echter gebruikelijk om elke module in een enkele klasse te houden, zodat de code van de modules niet verspreid wordt over het gehele systeem. Uiteindelijk hebben we de methodes die ervoor zorgen dat de tabel cStatsExpertStatsData gevuld wordt in StatsExpertFillTableStats.php gezet, aangezien dit uiteindelijk als cronjob moet draaien op de server. De methoden hierin zijn daarbij ook van een objectgeörienteerde stijl omgezet naar een script. Eigenlijk had het nog beter geweest om CmsStatsModule2.php nog verder op te splitsen, door de methoden die verantwoordelijk zijn voor de enquête en de doelstellingen ook in aparte klassen te zetten. Daarnaast is er inderdaad geen aparte unit test toegevoegd, maar enkel een aantal testmethoden, omdat we gebruik hebben gemaakt van de database om de methoden te testen.
5.2.2 Feedback 2 Zoals aangegeven is in het commentaar van de tweede meting is de code aanzienlijk verbeterd. De meeste aanbevelingen hebben we doorgevoerd zoals aangegeven in het vorige deel. Zo is niet alleen de code uitgebreid, maar is het ook aanzienlijk verbeterd ten aanzien van unit size en duplication.
18
6. Requirement evaluatie In dit hoofdstuk evalueren we alle door ons opgestelde requirements en geven we aan in hoeverre aan de requirement is voldaan en of er eventueel iets is gewijzigd. Allereerst zal per requirement aangegeven worden of deze wel (V), niet (X) ofwel gedeeltelijk (V/X) is geïmplementeerd.
6.1 Must Have 1
Expertsysteem welke aanbevelingen doet voor on-page zoekmachine-optimalisatie.
V
2
Actionable interface: het ontwerp nodigt uit om de aanbevelingen uit te voeren.
V
3
Een minimum van tien verschillende statistieken die bijgehouden worden
V
4
Het nieuwe systeem moet als module functioneren binnen het CMS van Content Power.
V
5
Vanwege de onderhoudbaarheid van de code in de toekomst door Content Power moet ontwikkeld worden in ‘de huisstijl’ in PHP en HTML. Voor databasetabellen moet de CPMyAdmin-module gebruikt worden.
V
6
Uitbreidbaarheid van kennis expertsysteem (medewerkers van Content Power moeten regels die gebruikt worden bij het generen van aanbevelingen kunnen toevoegen en aanpassen, alsmede de databronnen die voor deze regels gebruikt worden).
V
7
Overzicht met aanbevelingen, waarvan voor elke aanbevelingen geldt: deze is in begrijpelijk Nederlands geschreven. lastige begrippen moeten worden uitgelegd. aanbevelingen hebben een prioriteit. aanbevelingen moeten weggeklikt kunnen worden.
V
8
Door beheerder instelbare doelstellingen voor hun website, op basis van de beschikbare statistieken.
V
9
Overzicht van de behaalde doelstellingen.
V
10 Overzicht van de niet-behaalde doelstellingen.
V
11 Sitescore, gebaseerd op de verhouding tussen behaalde en niet-behaalde doelstellingen.
V
12 Visualisatie van de sitescore met een progress bar.
V
13 Er wordt dagelijks gekeken of er nieuwe aanbevelingen gedaan kunnen worden, en of aanbevelingen doorgevoerd zijn.
V/X 19
1. Dit is volledig geïmplementeerd. Het expertsysteem kan aanbevelingen doen aan de hand van de rules. 2. Er is een progress bar toegevoegd. Hierdoor worden de gebruikers aangespoord doelen te stellen en er van alles aan te doen om deze doelen te behalen en daarmee een hogere score te halen. 3. Er worden op dit moment 19 verschillende metrics bijgehouden. Dit zijn: visits hits bouncerate pagebouncerate uniquevisitors avgtimeonsite wordcount talencount descriptionlength customurlset languageset aantalzoekwoordeningesteld titleset avgtimeonpage exitratepage pagevisits pagehits landingsratepage pagerank
4. De module verschijnt nu met eigen icoon binnen het beheergedeelte van het CMS.
5. De volledige module is opgebouwd binnen het huidige CMS. Daarbij is gebruik gemaakt van CPMyAdmin, de database beheermodule van Content Power. Daarnaast is er ook gebruik gemaakt van de building blocks in het CMS, zoals de tabellen en formulieren die gebruikt worden in de module.
6. De module is goed uitbreidbaar. Het toevoegen van nieuwe rules in de database kan met behulp van een formulier. Hierbij is dus geen programmeerkennis nodig. Het toevoegen van nieuwe metrics kan door het schrijven van een nieuwe methode die de betreffende statistiek ophaalt, waarna een nieuwe regel toegevoegd kan worden met de naam van de nieuwe metric aan de database.
20
7. Op het hoofdscherm staat standaard een overzicht met de vijf belangrijkste aanbevelingen. Dit aantal kan eventueel aangepast worden met behulp van de enquête. Voor deze aanbevelingen geldt: o Deze zijn in begrijpelijk Nederlands geschreven. o Bij lastige begrippen, zoals wat er precies bedoeld wordt met een bepaalde metric, kan de gebruiker met de muis een hover doen over het begrip. Er wordt dan een popup getoond met een uitgebreide beschrijving van het begrip. o Alle aanbevelingen hebben een prioriteit. Deze zijn afkomstig van de rules en moeten daar ingesteld worden. Van de aanbevelingen die getoond worden, worden enkel de aanbevelingen getoond met de hoogste prioriteit. o Naast elke aanbeveling staat een kruisje waarmee de gebruiker de aanbeveling kan wegklikken zodra hij/zij denkt dat deze niet van toepassing is of zodra de aanbeveling toegepast is. 8. De beheerder van de website kan zelf doelstellingen toevoegen door een formulier in te vullen. De daadwerkelijke status van de doelstelling zal pas bij de volgende iteratie van het expertsysteem berekend worden om de interface snel en responsive te houden. 9. In het doelstellingenscherm worden de behaalde doelstellingen getoond. Een doelstelling is een metric in combinatie met een operator en een doel. Doelstellingen hebben verder nog een starten einddatum, een prioriteit en een status. 10. In het doelstellingenscherm worden tevens de niet-behaalde doelstellingen getoond met hun status en de inactieve doelstellingen. De inactieve doelstellingen zijn doelstellingen met een prioriteit van 0 of waarvan de huidige datum niet in de periode van de doelstelling ligt. 11. De sitescore wordt berekend op basis van reeds behaalde en nog niet behaalde doelstellingen en wordt getoond in de progress bar. 12. In zowel het hoofdscherm als het doelstellingenscherm wordt de progress bar getoond met daarin de sitescore. 13. De opzet hiervan is iets gewijzigd. Op dit moment kan met het klikken op een knop de berekeningen worden gestart, waarbij nieuwe aanbevelingen worden gedaan. De frequency kan dus door de beheerder zelf worden bepaald. Mocht in de toekomst de beheerder of Content Power deze berekeningen wel op voorafbepaalde tijdstippen willen uitvoeren dan zal dat ook mogelijk zijn. De aanpassingen daarvoor zullen minimaal zijn.
21
6.2 Should Have 1 Voorbeelden geven bij aanbevelingen van sites (intern of extern) waar dat advies wel goed geïmplementeerd is.
V
2 Aanbevelingen verdelen in korte- en langetermijnoplossingen.
X
3 Verloop in de tijd van de behaalde en nog te behalen doelstellingen. Met instelbare tijdsperiode.
X
4 Onderscheid naar prioriteit voor doelstellingen.
V
5 Integratie met het stappenobject.
V
1. Zodra op een aanbeveling wordt geklikt wordt een stappenplan weergegeven die stapsgewijs uitlegt hoe een bepaalde aanbeveling opgevolgd kan worden. Bij elk van deze stappen wordt een visual getoond waarmee deze uitleg wordt verduidelijkt. 2. Uiteindelijk is ervoor gekozen deze functionaliteit niet te implementeren vanwege het feit dat we enerzijds de interface simpel wilden houden en anderzijds dat het vaak moeilijk is om in te schatten wat het effect is op korte en/of lange termijn. 3. Dit is uiteindelijk niet geïmplementeerd, omdat bepaalde doelstellingen wel erg kunnen fluctueren. Daarnaast zou het nog vrij veel extra tijd hebben gekost om dit te implementeren. 4. Bij elke doelstelling die wordt toegevoegd moet ook een prioriteit meegegeven worden. Deze prioriteit geeft ook aan hoe zwaar deze doelstelling meeweegt in de sitescore. 5. Deze functionaliteit is te implementeren door bij groepering een stappenobject toe te voegen. Vervolgens kunnen de metrics ook gebruikt worden om statistieken over de stappenobjecten op te vragen.
22
6.3 Could Have 1 Feedback op gegeven aanbevelingen meenemen in het doen van nieuwe aanbevelingen.
X
2 Tonen van de meest belangrijke statistieken op het dashboard. Moet instelbaar zijn per gebruiker, wat ze zelf willen zien.
X
3 Hogere frequentie van het daadwerkelijk doen van aanbevelingen.
X/V
4 Disclaimer waarin vermeld wordt dat alle gegevens vertrouwelijk behandeld worden.
X
5 Genormaliseerde data op basis van alle websites gehost bij Content Power.
X
1. Dit zou nog een goede toevoeging voor in de toekomst zijn. Wij zijn hier door tijdgebrek echter niet meer aan toegekomen. 2. Dit zou ook later nog toegevoegd kunnen worden, aangezien nu wel alle statistieken beschikbaar zijn. 3. Op dit moment kan de gebruiker zelf kiezen wanneer de aanbevelingen gemaakt worden door het expertsysteem zelf te starten. 4. Uiteindelijk zijn er geen disclaimers toegevoegd. Aangezien alles binnen het CMS draait is het logisch dat alles wat daarin gebeurt vertrouwelijk wordt behandeld. 5. Dit zou in de toekomst ook nog een goede aanvulling kunnen zijn. Echter was dit binnen dit project niet meer haalbaar.
6.4 Want to Have 1 Voorspelling wat het effect is van het doorvoeren van een aanbeveling. X
1. Dit zou eventueel later nog toegevoegd kunnen worden. Het maken van een dergelijke voorspelling is echter niet altijd accuraat, dus zal dit geen hoge prioriteit hebben.
Hieruit blijkt dat eigenlijk alle must haves zijn geïmplementeerd en we ook zijn toegekomen aan een aantal should haves. Er is hiermee voorzien in de basisfunctionaliteit, maar er is zeker nog ruimte om meer functies toe te voegen.
23
7. Aanbevelingen uitbreiding nieuwe statistiekmodule 7.1 Aanbevelingen uit interviews met klanten: Bij het geven van aanbevelingen voorbeelden tonen van sites die deze aanbeveling wel goed geïmplementeerd hebben. Waar mogelijk pagina's van de klant zelf, anders grote, voor iedereen bekende sites. Mogelijkheid tot aan- of uitschakelen van elementen op het dashboard, zodat bijvoorbeeld statistieken weergegeven kunnen worden voor gebruikers die daar behoefte aan hebben. Zoals een verloop van het aantal bezoekers op een pagina, of de bounce rate van een pagina (wij hebben deze wens van de klant opzettelijk niet geïmplementeerd omdat dit haaks staat op onze insteek van het automatisch doen van de statistiekanalyse voor de klant). Mogelijkheid van beheerder om meer doelstellingen in te stellen (het uitbreiden van het aantal metrics kan gewenst zijn). Enige voorzichtigheid is wel geboden: om de beheerders niet te overdonderen met een te grote selectie van statistieken hebben wij alleen de 'critical few' gekozen wat Kaushik ook aanraadt op zijn blog en in zijn boek [6]. Nog meer doelstellingen toevoegen gebaseerd op domeinkennis beschikbaar in het systeem.
7.2 Aanbevelingen uit literatuur Integratie van nog meer databronnen (multi-channel analytics). Bijvoorbeeld aanspreken van social media API’s als hier ook doelstellingen op gebaseerd kunnen worden. Meer domeinkennis vergaren, bijvoorbeeld door middel van vervolgenquêtes. De kwaliteit van de aanbevelingen neemt sterk toe, met meer domeinkennis. Daarbij is dit een punt waar Content Power zich kan onderscheiden van andere partijen.
24
8. Reflectie In dit hoofdstuk geven wij beiden een persoonlijke reflectie op het verloop van dit project.
8.1 Matthijs van Dorth: Dit project betekent het einde van de Bacheloropleiding Technische Informatica. Het moet een afsluiting zijn waarin allerlei aspecten uit opleiding naar voren moeten komen. Veel vakken uit de Bachelor zoals Object Georiënteerd Programmeren, Software Engineering, Software Kwaliteit en Testen en Web- en Databasetechnologie, kwamen aan bod binnen dit project. Al deze kennis samenbrengen binnen een project was erg leerzaam. Zo heb ik nu daadwerkelijk in de praktijk kunnen meemaken hoe het is om een softwareproject van begin tot einde op te zetten. Zoals is gebleken vergt dat erg veel tijd. De verschillende fasen die we in dit project hebben doorlopen, waren stuk voor stuk erg belangrijk. Zo ontstond stukje bij beetje een product waar we best trots op mogen zijn. Echter had ik, zeker in het begin van dit project, nog geen goed beeld van hoe het uiteindelijke product eruit zou komen te zien. Dit was voor mij een van de lastigste aspecten uit dit project. Ik vond het erg moeilijk om in te schatten wat precies de mogelijkheden waren en waartoe we in staat waren wat we zouden kunnen opleveren. Een ander lastig punt vond ik de rapportage. Vaak waren er wel goede ideeën, maar vond ik het lastig dat goed op papier te krijgen. Het werken bij Content Power was erg prettig. Ik vond het een groot voordeel dat het een klein team was waardoor de lijntjes kort waren en je altijd iets kon vragen. De sfeer op het kantoor was daardoor erg relaxed en informeel. Zelf werkte ik daardoor op het kantoor beter en efficiënter dan thuis of op de TU.
25
8.2 Arno de Bruijn: Bijna aan het einde gekomen van deze stage kan ik tevreden terugblikken op onze resultaten. Echter, in geen ander TU-project heb ik zo veel tijd en moeite moeten steken als in dit project. Er waren momenten waarop ik dacht "hoe moet dit in vredesnaam goed komen?". Naar mijn idee zijn we te lang in de oriëntatiefase blijven hangen. Deels is dit goed te verklaren; we zaten namelijk in een unieke situatie bij Content Power omdat we heel veel vrijheid hadden bij het zelf invullen en zoeken naar een oplossing voor een algemeen probleem. Als ik zo naar andere stageopdrachten kijk op Blackboard betreft het daar veel meer afgebakende projecten. Die vrijheid is een prachtige uitdaging maar tegelijkertijd ook een beetje beangstigend. Dit is wat dit project namelijk zo anders maakt dan alle voorgaande projecten die ik gedaan heb op de TU. Het was niet alleen technisch uitdagend, maar er werd ook een soort creativiteit verlangd bij het ontwerpen van dit systeem, en dat is wat ik misschien nog wel het moeilijkste vond aan dit project. Slechts voor algemene problemen waar we tegen aan liepen konden we terugvallen op literatuur. Andere zaken moesten we geheel zelf uitvogelen. En in die situaties besloop mij af en toe het gevoel dat ik voor veel van deze ontwerpbeslissingen op mijzelf aangewezen was. Gelukkig was Jan er om hulp te bieden in deze situaties. Hij dacht echt actief mee, en dwong ons op de juiste momenten knopen door te hakken. Zelf heb ik nogal de neiging om alles van begin tot eind uit te willen denken en mezelf te verliezen in de details. Terwijl Jan met zijn top-down aanpak een praktische inslag liet zien die mijns inziens essentieel is voor succesvolle softwareprojecten in het bedrijfsleven. Als ik één ding mag meenemen uit deze stage dan hoop ik dat ik in mijn volgende projecten het beste van beide werelden kan verenigen. Of in de woorden van Donald Knuth: “If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice."
26
9. Conclusie Voor dit Bachelor eindproject hebben wij onderzoek gedaan naar geautomatiseerde webstatistiekanalyse voor de websites van klanten van Content Power. De huidige statistiekmodule binnen het CMS van Content Power is bestudeerd evenals vergelijkbare systemen en literatuur. Op basis van dit onderzoek en interviews met de klanten van Content Power hebben wij een nieuwe statistiekmodule ontwikkeld. Het door ons opgestelde systeem bestaat uit een aanbevelingen-dashboard als module binnen het CMS van Content Power, beschikbaar voor de beheerders van websites draaiende op dit CMS. De beheerders krijgen op deze wijze aanbevelingen hoe zij content op hun eigen website aan kunnen passen met als doel conversie en search engine-optimalisatie. Deze aanbevelingen moeten helder gepresenteerd worden aan de gebruikers, met eventueel benodigde achtergrondinformatie. Om de gebruikers te motiveren dit dashboard te gebruiken en de aanbevelingen door te voeren, trachten we ze aan te sporen met een zogenaamde sitescore. Deze score is gebaseerd op doelstellingen deels ingesteld door de gebruiker zelf en deels gebaseerd op best practices. Vanwege de beperkte ontwikkeltijd is gekozen om basisfunctionaliteit van het door ons opgestelde systeem te implementeren in een proof of concept. Verdere functionaliteit wordt in dit document als aanbeveling ter uitbreiding van het systeem aan Content Power gedaan. Wat ons betreft leveren we met onze proof-of-concept een gedegen anwoord op de onderzoeksvraag die we aan het begin van dit project gesteld hebben.
“Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?” Vanwege de complexiteit van dit vraagstuk beseffen we wel dat ons proof-of-concept nog maar het begin is. Het is aan Content Power om de draad verder op te pakken. Het succes van dit systeem moet blijken na langdurig gebruik en is deels afhankelijk van de rules die in de toekomst nog toegevoegd gaan worden. Puur afgaand op de requirementsevaluatie zijn we geslaagd in het bereiken van de eisen die we aan het begin van dit project gesteld hebben. Echter is het kwantificeren van websiteprestaties geen exacte wetenschap en zijn de aanbevelingen die we doen op basis van 'best practices'. Dat maakt het voor ons op dit moment onmogelijk om te meten of een website succes heeft bij het uitvoeren van alle aanbevelingen. Wel hebben we kunnen demonstreren dat ons systeem overweg kan met allerlei rules die ook later nog aangepast kunnen worden. Dat maakt het systeem in hoge mate 'tweakbaar' en zorgt ervoor dat het systeem zich ook in de toekomst aan kan passen aan veranderde omstandigheden. We hopen dat Content Power tijdens het gebruik en uitbreiden van ons systeem net zo enthousiast is, als hun reacties op ons werk tijdens de ontwikkeling. En we wensen ze veel succes in de toekomst!
27
10. Literatuur 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Kaushik, A. (2010). Web Analytics 2.0. Indiana: Wiley Publishing Negnevitsky, M. (2005). Artificial Intelligence. 2e druk. Harlow: Person Education Limited Akerkar, R. and Sajja, P. Knowledge-based systems. London: Jones and Barlett Publishers Dunham, M. Data Mining: Introductory and Advanced Topics. New Jersey: Pearson Education, Inc. Schalkoff, R. (2011). Intelligent Systems. London: Jones and Barlett Publishers Kaushik, A. (2007). Web Analytics an hour a day. Indiana: Wiley Publishing Few, Stephen. "Show me the numbers." (2004). http://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html http://css-tricks.com/css3-progress-bars/ http://www.w3schools.com/cssref/ http://www.php.net/manual/en/funcref.php http://zbc.nu/ict/selectie-en-invoering-ict-systemen/requirements-staan-aan-de-basis-vansucces/ http://blog.silktide.com/2011/03/what-should-my-websites-bounce-rate-be/ http://www.ludicity.nl/services/
Data visualisatie: Case Study: E-Commerce Clickstream Visualization o http://courses.ischool.berkeley.edu/i247/s02/readings/brainerd.pdf o In dit wetenschappelijke artikel wordt een methode omschreven om clickstream-data grafisch weer te geven. What Did They Do? Understanding Clickstreams with theWebQuilt Visualization System o http://berkeley.academia.edu/TaraLynnMatthews/Papers/65544/What_did_they_do_U nderstanding_clickstreams_with_the_WebQuilt_Visualization_System o Dit wetenschappelijke artikel legt een systeem uit dat clickstream-data grafisch weergeeft aan de hand van server logs. Visualization and Analysis of Clickstream Data of Online Stores with a Parallel Coordinate System o http://www.springerlink.com/content/71mvrfal4dd2k5af/fulltext.pdf Clickstreams: What They Are and Why You Should Track Them o http://mashable.com/2009/08/25/clickstreams/ Flowingdata o http://flowingdata.com/ o Een blog die verschillende vormen van visualisaties toont. Data Visualisation (IN4086) - Reader 2010 o https://blackboard.tudelft.nl/webapps/blackboard/execute/content/file?cmd=view&co ntent_id=_1859925_1&course_id=_39588_1 o Paper over effectief kleurgebruik. Goede guidelines op pagina 13 en 14. Physiological principles for the effective use of color, Gerald M. Murch, Tektronix Incorporated o http://dl.acm.org/citation.cfm?id=2349
28
Data mining: Data Preparation for Mining World Wide Web Browsing Patterns (1999) o http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.3835 o In dit enigszins gedateerde artikel wordt uitgelegd hoe vanuit server logs bepaalde interessante patronen kunnen worden ontdekt. Algorithms for Association Rule Mining - A General Survey and Comparison o http://dl.acm.org/citation.cfm?id=360421 o In dit wetenschappelijke artikel worden verschillende algoritmen uitgelegd die associaties uit grote databases kan ontleden. Analyzing the footsteps of your customers o http://robotics.stanford.edu/people/ronnyk/WEBKDD2000/WEBKDD2000_ARCHIVE/ii_ 2.pdf o In dit artikel wordt een systeem omschreven dat associaties kan ontdekken uit serverlogs. cookiewetgeving o http://www.rijksoverheid.nl/onderwerpen/ict/veilig-online-en-eprivacy/internetbezoek-volgen-met-cookies o Korte omschrijving van de huidige wetgeving rond cookies.
Web usage mining Search Analytics for Your Site, Louis Rosenfeld Advanced Web Metrics with Google Analytics™, Second Edition, Brian Clifton o http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470562315,descCdauthorInfo.html o Boek over het gebruik van Google Analytics. Google Analytics, Justin Cutroni o http://www.oreillynet.com/pub/au/3170 o Auteur van 2 boeken over Google Analytics. Beginner's Guide To Web Data Analysis: Ten Steps To Love & Success o http://www.kaushik.net/avinash/beginners-guide-web-data-analysis-ten-steps-tipsbest-practices/ o Introductie over het gebruik van Google Analytics. Secure accounting and auditing on the Web o http://www.sciencedirect.com/science/article/pii/S0169755298001160 Auditable metering with lightweight security o http://dx.doi.org/10.1007%2F3-540-63594-7_75 Deflation-secure web metering o http://dx.doi.org/10.1504%2FIJICS.2007.012244
29
Bijlagen
A. B. C. D. E. F. G. H.
Screenshots Opdrachtomschrijving SIG Feedback Oriëntatieverslag Plan van Aanpak RAD TDD Testplan
30
A. Screenshots
Figuur 1: moduleoverzicht, met de nieuwe SEO aanbevelingen module
Figuur 2: Dashboard, wordt getoond na het openen van de module
31
Figuur 3: Ditzelfde dashboard als er met de muis over de progress bar wordt gehoverd
Figuur 4: Doelstellingenscherm met verschillende doelstellingen en progress bar
32
Figuur 5: Doelstellingenscherm, ook hier worden tooltips weergegeven bij de begrippen
Figuur 6: Doelstellingenscherm, met een popup voor het toevoegen van een nieuwe doelstelling.
33
Figuur 7: Aanbevelingscherm, met uitleg over de aanbeveling
Figuur 8: Enquêteformulier voor meer achtergrondinformatie, waardoor betere aanbevelingen gedaan kunnen worden.
34
Figuur 9: Het toevoegen van een nieuwe rule kan eenvoudig d.m.v. een formulier.
35
B. Opdrachtomschrijving Meer kunnen meten Op dit moment meet de Content Power statistiekmodule de volgende onderdelen: bezochte URL’s, gebruikte items op dynamische pagina's en referals. Sommige belangrijke onderdelen worden echter nog niet gemeten. Bijvoorbeeld of een formulier op een bepaalde pagina wel / of niet verzonden is (URL blijft gelijk); terwijl juist dit soort informatie een inzicht geeft in de acties van bezoekers. De eerste stap zou dus ook zijn om het mogelijk te maken dit soort acties te meten. Context Bij nieuwere websites van Content Power wordt de staat van de website bijgehouden. Denk hierbij aan wel/niet ingelogd, wel/niet items in winkelmand, wel/niet akkoord met voorwaarden. Naast te weten welke pagina een bezoeker bezocht ook te weten in welke context hij/zij dit deed kan veel meer inzicht geven. De tweede stap zou dus zijn ook deze informatie te registreren. Weergave Na het registreren van de informatie moet natuurlijk alles inzichtelijk worden gemaakt. Er is al een statistiekmodule. Deze zou kunnen worden aangevuld om ook de nieuwe informatie te tonen. De werkelijke meerwaarde zit in analyses van de data. Hierbij kan worden gedacht aan: ● Bezoekers die pagina x bezochten, bezochten ook …. (met percentages) ● Bezoekers die pagina x bezochten daarna de pagina's … (met percentages) ● Bezoeker binnen context x bezochten voornamelijk pagina's … (met percentages) ● Bezoekers kwamen voornamelijk bij context x via de pagina … (met percentages) Natuurlijk staan we altijd open voor suggesties. Hierbij kan gekeken worden in literatuur of bij bekende statistiekenprogramma's als Google Analytics. Ook kan er gekeken worden naar wat er kan worden toegevoegd aan mogelijkheden die niet in bijvoorbeeld Google Analytics zitten, aangezien hier heel dicht op de bron informatie kan worden verzameld. Flow (extra) Mocht het haalbaar zijn binnen de opdracht zou de mooiste weergave die van een flow door de website zijn. Een voorbeeld hiervan is de Google Analytics-weergave. Voor veel websites is in de configuratie al een flow gedefinieerd. Deze zou visueel kunnen worden weergegeven met daarin de volgende gegevens: ● Hoeveel bezoekers bezochten welke stap in het proces ● Hoe groot is het afhaakpercentage per stap ● Naar welke pagina's gingen de afhakers ● Welke invloed heeft elke context op de flow Soms kan de flow ook via mail verder verlopen, dus deze kan niet enkel op URL’s worden gebaseerd. A/B-testen (extra) Op sommige websites worden binnen de flow A/B-tests toegepast. Dit betekent dat er meerdere weergaven van de pagina's zijn. Aan elke bezoeker wordt een willekeurige pagina toegewezen. Achteraf kan worden gemeten welke paginaweergave het meest succesvol was. Deze informatie zou uitermate goed te combineren zijn met de flow-weergave. 36
C. SIG feedback Feedback 1 De code van het systeem scoort 3 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code gemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Unit Size, Duplication en Unit Interfacing. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de 'vProcessActiveForm'-functie binnen 'CmsModuleStats2.php', zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld '//haal data op uit formulier' en '//zet dit weg in de database' zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Daarnaast zou het verplaatsen van de code in elk 'case'-blok naar aparte functies de begrijpbaarheid van de code verhogen. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Voor Duplication wordt er gekeken naar het percentage van de code dat redundant is, oftewel de code die meerdere keren in het systeem voorkomt en in principe verwijderd zou kunnen worden. Vanuit het oogpunt van onderhoudbaarheid is het wenselijk om een laag percentage redundantie te hebben omdat aanpassingen aan deze stukken code doorgaans op meerdere plaatsen moet gebeuren. In dit systeem is er met name duplicatie te vinden binnen 'CmsModuleStats2.php'. Zo is bijvoorbeeld het grootste gedeelte van de functies 'sGetDoelstellingNietHTML' en 'sGetDoelstellingWelHTML' hetzelfde. Het is aan te raden om dit soort duplicaten op te sporen en te verwijderen. Voor Unit Interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan abstractie. Daarnaast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen van de methode en in de meeste gevallen ook tot langere en complexere methoden. In dit geval zien we bijvoorbeeld dat er enkele methoden zijn die zowel een '$a_dStartDate' als een '$a_dEndDate' meekrijgen. Voor deze parameters geldt waarschijnlijk dat ze beide een valide datum moeten zijn en dat de einddatum na de startdatum moet liggen. Dit zou afgedwongen kunnen worden door de introductie van, bijvoorbeeld, een 'Period'-object die deze checks bevat. Door dit object op te nemen als parameter zal ook de interface van de functies duidelijker worden. Het is aan te raden om kritisch te kijken naar de interface van de verschillende functies. Daarnaast nog een opmerking over de verdeling van de code. Op dit moment bevat 'CmsModuleStats2.php' ruim 67% van alle code binnen dit systeem. Daarnaast lijkt deze class ook meerdere verantwoordelijkheden te hebben. Het opsplitsen van deze class in verschillende classes met specifieke verantwoordelijkheden zal het in de toekomst makkelijker maken om de code te onderhouden.
37
Over het algemeen scoort de code gemiddeld, hopelijk lukt het om dit niveau te behouden of te verbeteren tijdens de rest van de ontwikkelfase. Als laatste nog de opmerking dat er geen (unit)testcode is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen.
Feedback 2 In de tweede upload zien we dat zowel de omvang van het systeem als de score voor onderhoudbaarheid is gestegen. Ondanks een volume-toename van 15% zien we een verbetering in de scores op meerdere punten. Zo zien we dat alle extreem lange methoden zijn verwijderd en dat de duplicatie binnen 'CmsModuleStats2.php' is aangepakt. Daarnaast zien we dat 'CmsModuleStats2.php' is opgesplitst. De aanbevelingen voor Unit Interfacing en het toevoegen van test-code blijven echter staan. Uit deze observaties kunnen we concluderen dat het grootste deel van de aanbevelingen van de vorige evaluatie zijn meegenomen in het ontwikkeltraject. Het is goed om te zien dat ondanks een stijging van het volume de onderhoudbaarheid van de code vooruit is gegaan.
38
BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Oriëntatieverslag Matthijs van Dorth 1265911 Arno de Bruijn 1262467
Bedrijf: Technische Universiteit Delft: Datum:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica 16-10-2012
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Samenvatting Content Power is een full service internetbureau met een intern ontwikkeld Content Management Systeem (CMS). Dit CMS stelt klanten van Content Power onder andere in staat relatief gemakkelijk content van hun website aan te passen of toe te voegen. Vaak vormen deze websites van klanten een belangrijk middel bij het vervullen van hun bedrijfsdoelen. Voor verscheidene klanten is hun omzet zelfs afhankelijk van de websitebezoekers.
Ons onderzoek zal zich richten op hoe de beheerders een beter inzicht kunnen krijgen in de acties van deze bezoekers. We zullen met een aantal mogelijke oplossingen komen. Dit zal betrekking hebben op zowel het loggen van de acties van de gebruikers als op hoe we deze data kunnen visualiseren zodat deze inzichtelijk worden voor de websitebeheerders.
2
Inhoudsopgave Samenvatting ............................................................................................................................................ 2 1.
Inleiding............................................................................................................................................. 4
2.
Probleemstelling en -analyse ............................................................................................................ 5
2.1 Probleemstelling ........................................................................................................................... 5 2.2 Hoofdvraag.................................................................................................................................... 5 2.3 Deelvragen .................................................................................................................................... 5 3. Content Power .................................................................................................................................. 6 3.1 Het bedrijf ..................................................................................................................................... 6 3.2 De ontwikkelomgeving ................................................................................................................. 6 3.3 Testomgeving ................................................................................................................................ 6 4. Huidige situatie ................................................................................................................................. 7 4.1 Het CMS ........................................................................................................................................ 7 4.2 De huidige statistiekmodule ......................................................................................................... 8 4.3 De huidige logging-module ........................................................................................................... 8 4.4 A/B-Testmodule ............................................................................................................................ 9 4.5 Rapportage.................................................................................................................................... 9 5. Mogelijke oplossingen .................................................................................................................... 10 5.1 Webstatistiekanalyse .................................................................................................................. 10 5.2 Datavisualisatie ........................................................................................................................... 10 5.3 Profiling & Classificatie................................................................................................................ 10 6. Statistieken en logging .................................................................................................................... 12 6.1 Logging-mogelijkheden ............................................................................................................... 12 6.2 Relevante statistieken ................................................................................................................. 12 7. Datavisualisatie ............................................................................................................................... 15 7.1 Begrijpelijk maken complexe statistieken .................................................................................. 15 7.2 Bestaande analytics-pakketten ................................................................................................... 16 8. Begrippenlijst .................................................................................................................................. 18 9.
Referenties ...................................................................................................................................... 19
Datavisualisatie: .................................................................................................................................. 19 Data mining: ........................................................................................................................................ 19 Web usage mining............................................................................................................................... 20 Appendix ................................................................................................................................................. 21 A. B. C.
Interviewvragen .......................................................................................................................... 21 Samenvatting interview werkzaamheden Willem van Valkenburg ............................................ 22 Opdrachtomschrijving ................................................................................................................. 23
3
1. Inleiding Content Power is een internetbureau met een intern ontwikkeld Content Management Systeem (CMS). Dit CMS stelt beheerders van websites onder andere in staat relatief gemakkelijk content van hun website aan te passen of toe te voegen. Voor veel eigenaren van deze websites is hun ‘online presence’ een belangrijk deel van hun bedrijfsmodel en een groot deel van hun omzet is afhankelijk van bezoekers op hun website. Derhalve kan het voor beheerders interessant zijn een beter inzicht te krijgen in hoe hun website daadwerkelijk gebruikt wordt door de bezoekers. Zo kunnen ze bijvoorbeeld inzicht krijgen in welke pagina’s veel bezoekers trekken, op welke pagina’s mensen afhaken en welke content populair is. Aan de hand van deze inzichten kunnen de beheerders eventueel aanpassingen maken die de gebruikerservaring verder kunnen verbeteren. Dit grotere inzicht moet dus leiden tot betere besluitvorming met betrekking tot de websites van klanten van Content Power, zodat zij hun uiteindelijke doel van meer omzet kunnen verwezenlijken door hogere bezoekersaantallen en een grotere klanttevredenheid. Onze rol hierin wordt het onderzoeken van de mogelijkheden waarop de beheerders deze inzichten beter kunnen verkrijgen en een prototype van een module bouwen dat deze mogelijkheden implementeert.
4
2. Probleemstelling en -analyse In dit gedeelte van het verslag zullen wij een beschrijving geven van het probleem en vervolgens aan de hand hiervan een hoofdvraag formuleren. Deze hoofdvraag zullen we opsplitsen in deelvragen die we vervolgens samen met de relevante onderwerpen analyseren. 2.1 Probleemstelling Vanuit Content Power is te kennen gegeven dat er al wel enkele gebruikersstatistieken bijgehouden wordt door het Content Management Systeem; er wordt daarmee echter nog niet genoeg gedaan. Onze taak is dan ook om uit te zoeken hoe dat beter kan. Welke gegevens worden nu al bijgehouden en kunnen we eventueel nog meer nuttige statistieken bijhouden? Daarnaast is het zaak dat deze informatie vervolgens overzichtelijk gepresenteerd wordt voor de beheerders van websites die gebruik maken van het CMS. 2.2 Hoofdvraag Bovenstaande geeft aanleiding tot de volgende onderzoeksvraag: “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?” 2.3 Deelvragen Om dit onderzoek behapbaar te maken splitsen we deze onderzoeksvraag op in de volgende deelvragen welke in de rest van het document aan bod zullen komen.
Welke technieken zijn er om inzicht te krijgen in de acties van gebruikers? Welke statistieken geven inzicht in de acties van gebruikers? o Welke statistieken worden in de huidige statistiekmodule bijgehouden? o Welke andere informatie kan nog meer inzicht geven? Hoe zijn deze statistieken het beste (grafisch) weer te geven zodat dit ook voor niet-technische mensen begrijpelijk is? o Welke grafische weergaven zijn geschikt voor de verschillende typen data? o Hoe wordt data in vergelijkbare systemen gevisualiseerd en kan dit in ons systeem beter?
5
3. Content Power In dit hoofdstuk geven wij een korte inleiding over het bedrijf en de huidige staat van het CMS. We zullen hier ook ingaan op de ontwikkelmethode en werkwijzen binnen het bedrijf. 3.1 Het bedrijf Content Power is een in 2001 opgericht full service internetbureau gevestigd te Delft. Tegenwoordig bestaat het team uit zeven professionals. De kern van Content Power is het door hun zelf ontwikkelde Content Management Systeem. Binnen dit CMS bieden zij de klanten tools en begeleiding bij de realisatie van hun online doelstellingen. Mocht de klant om functionaliteit vragen die nog niet gerealiseerd is binnen het huidige CMS dan ontwikkelt Content Power deze intern. De dagelijkse bezigheden van de werknemers van Content Power bestaan dan ook onder andere uit conceptontwikkeling, grafisch design, projectmanagement, SEO-advies en conversie-optimalisatie. 3.2 De ontwikkelomgeving Als Integrated Development Environment (IDE) wordt gebruik gemaakt van Eclipse i.c.m. de PDT package (PHP Developer Tools). Daarnaast wordt gebruik gemaakt van Subversion (SVN) voor software versioning en revisiecontrole. Binnen Content Power wordt gewerkt met bepaalde coding guidelines, zoals beschreven in hun lokale wiki https://intranet.contentpower.nl/wiki/index.php/Coding_Guidelines Dit houdt onder andere in: Hungarian style-variabelen, uniforme lay-out voor programming constructs en comments in PHPdoc-stijl met enkele intern gedefinieerde tags. https://intranet.contentpower.nl/wiki/index.php/CMSv4_phpDoc Verder is er CSS gebruikt voor de opmaak en wordt gebruik gemaakt van Javascript in combinatie met de jQuery library voor geavanceerde lay-outfunctionaliteit. 3.3 Testomgeving Binnen Content Power wordt gebruik gemaakt van de zogeheten OTAP-methode. Dit staat voor Ontwikkel, Test, Acceptatie en Productie. Tijdens de ontwikkelperiode wordt in SVN een branch gemaakt van de main trunk, waaraan nieuwe functionaliteit kan worden toegevoegd. De website is dan alleen binnen het interne netwerk te bekijken. Vervolgens kan een branch verplaatst worden naar de testomgeving waar een aantal standaard tests uitgevoerd kunnen worden. Zodra dit voldoende getest en goedgekeurd is wordt de branch verplaatst naar de acceptatie, zodat de klant ook de nieuwe versie kan bekijken en zijn goedkeuring kan geven. Zodra de klant zijn goedkeuring heeft gegeven kan de website ‘live’ gaan, zodat de nieuwe functionaliteit publiekelijk zichtbaar is.
6
4. Huidige situatie 4.1 Het CMS Het CMS is een in PHP ontwikkeld objectgeoriënteerd framework bestaande uit meerdere modules. Bij het opvragen van een webpagina wordt een template gevuld met blokken HTML gegeneerd door de verantwoordelijke building-block. Extra functionaliteit kan geleverd worden door nieuwe modules of building blocks toe te voegen of bestaande uit te breiden.
Figuur 1: CMS dashboard. Door de vele verschillende soorten klanten die Content Power heeft is niet elke module beschikbaar voor elke klant. Er zijn wel een aantal standaard modules die elke website heeft. Zo kan elke klant zelf nieuwsberichten posten of een formulier op de website plaatsen. Ook de statistiekmodule is standaard bij elke website zichtbaar. Bij het inloggen van de klant op de admin-pagina worden de modules getoond en kan de klant zelf de website aanpassen.
7
4.2 De huidige statistiekmodule Binnen het huidige CMS van Content Power bestaat er een statistiekmodule. Hierin is te zien hoeveel hits, bezoeken en bezoekers de site krijgt. Ook is te zien waar de bezoeker vandaan komt (direct, zoekmachine of link).
Figuur 2: originele statistiekmodule. In de huidige module wordt vooral gebruik gemaakt van pagehits, terwijl er veel meer data opgeslagen kan worden die nuttig is voor de beheerder van de website. De statistieken worden nu nog enkel getoond als staafdiagrammen waarbij de periode, het type statistiek en eventueel de pagina kan worden geselecteerd. Er wordt geen gebruik gemaakt van alle statistieken die worden gelogd.
4.3 De huidige logging-module Op dit moment worden er verschillende statistieken van de bezoekers gelogd. Zo wordt er van elke bezoeker een IP-adres opgeslagen (sStatsIp). Daarnaast wordt er per bezoek een sessie aangemaakt (sStatsSession) waarbij opgeslagen wordt hoe laat de eerste hit op de website was, hoe laat de laatste hit op de website was, wat de referer was en welke browser de gebruiker gebruikt. Ook wordt er bij elke sessie van een bezoeker opgeslagen welke pagina’s precies bezocht worden en om welke tijd (sStatsHit). Overigens worden bezoeken door bots, zoals de Google search bots, wel opgeslagen maar niet getoond binnen de statistieken omdat deze niet relevant zijn. Omdat deze statistieken op den duur erg groot kunnen worden, worden statistieken ouder dan een maand geaggregeerd (CBB/Scripts/agregatestats.php), zodat niet meer te achterhalen is wie welke pagina’s heeft bezocht maar nog wel het aantal pagehits, aantal bezoekers en aantal bezoeken. 8
Figuur 3: statistiektabel. Op dit moment worden de statistieken opgeslagen m.b.v. een logger (CBB/Parser/CmsStatsLogger.php). Statistieken worden opgehaald uit de database (Providers/Content/CmsDBContentProviderStats.php) en worden vervolgens getoond met Providers/View/CmsViewProviderModuleStats.php.
4.4 A/B-Testmodule Binnen het huidige systeem bestaat er een A/B-Testmodule. Deze module geeft de mogelijkheid de bezoekers verschillende versies van een website te laten zien. Ook hier worden verschillende statistieken van bijgehouden. Het doel van deze module is het inzien van het effect van veranderingen op de website. Als bijvoorbeeld blijkt dat bij een van de versies meer bezoekers doorklikken naar de webshop kan deze versie definitief gebruikt worden op de site. Deze veranderingen kunnen verschillen van de kleur van knoppen en tekstveranderingen tot compleet verschillende pagina’s. Zo kan dus op een veilige manier geëxperimenteerd worden met aanpassingen op de website.
Figuur 4: A/B-Test.
4.5 Rapportage Er bestaat een module die op een eenvoudige manier rapporten kan maken (/BB/Text/LaTeX/CPLaTeXDocument.php). Door middel van deze module kan een LaTeX-bestand worden opgebouwd waarmee vervolgens een PDF-bestand kan worden gegenereerd. Binnen deze module zijn dus ook allerlei eenvoudige tabellen en grafieken te genereren. 9
5. Mogelijke oplossingen Om een beter inzicht te krijgen in de acties van gebruikers zien willen we kijken naar de onderstaande technieken. Tevens willen we onderzoeken welke techniek of eventueel combinatie van technieken het beste aansluit(en) op de huidige situatie en wensen van Content Power. 5.1 Webstatistiekanalyse Content Power is al bezig met het loggen van statistieken. Verdere analyse van deze statistieken vindt echter nog niet plaats. Hier is dus zeker ruimte voor verbetering. Uit literatuuronderzoek, rondvraag en interviews hebben wij de volgende kernpunten van goede webstatistiekanalyse op kunnen stellen:
‘Goal tracking’, inzicht in conversieratio. Overzichtelijke presentatie van interessante statistieken. Eventuele filtering en aggregatie om alles helder te presenteren zodat de gebruiker gemakkelijker een beslissing kan maken aan de hand van de statistieken. Inzicht in ‘bounce ratios’ en het onderscheid tussen een ‘good bounce’ (langdurig bezoek op één pagina) en ‘bad bounce’ (slechts kort bezoek op één pagina). ‘Timely tracking’. Bijhouden van de tijdsduur die een bezoeker doorbrengt op de pagina.
5.2 Datavisualisatie In het nieuw te vormen systeem is er een hoop data beschikbaar. Deze data moet echter ook begrijpelijk en overzichtelijk gerepresenteerd worden. Hiervoor willen we gebruik maken van datavisualisatietechnieken. Verderop in dit document (hoofdstuk 7) vindt u een overzicht van de technieken waar we naar gekeken hebben. 5.3 Profiling & Classificatie Profiling is het analyseren van patronen in acties van bezoekers of groepen bezoekers om hier vervolgens een profiel aan te verbinden. Een profiel kan bestaan uit hoe vaak en hoe lang een bezoeker op bepaalde pagina’s is geweest, via welke zoekmachine en zoekwoorden een bezoeker binnenkomt en andere eigenschappen zoals leeftijd, locatie, browsertype en operating system (OS). Het bijhouden van individuele profielen is echter een nogal grijs gebied. In de Nederlandse wet is het verboden individuele bezoekers te volgen zonder expliciete toestemming (opt-in). Het opstellen en volgen van groepen (classificatie) is echter wel toegestaan. Vandaar dat wij gebruik willen maken van classificatie, dus het onderscheiden van verschillende groepen, om een beter inzicht te krijgen in hoe een groep de website gebruikt. Binnen het CMS van Content Power kan dit geïmplementeerd worden om zo verschillende groepen die de website bezoeken te kunnen monitoren. We denken dan bijvoorbeeld aan de verschillende zoekwoorden die bezoekers hebben gebruikt om op de site te komen. Het is zeer nuttig voor de beheerder van een website om te weten via welke zoekwoorden klanten binnenkomen en daadwerkelijk iets kopen. Verder kunnen we bijvoorbeeld kijken of er een relatie is tussen het gedrag van een groep en een classificatie volgens het MBTI-model. Dit model wordt reeds gebruikt binnen Content Power en deelt 10
bezoekers in vier categorieën in: De methodische (M), de spontane (S), de humanistische (H) en de competitieve bezoeker (C). Al deze typen bezoekers moeten bediend worden maar zij bekijken en gebruiken de website onderling anders. Wellicht valt er bijvoorbeeld een relatie te vinden in hoe gebruikers van een bepaald type tot een hogere of lagere conversieratio leiden. Aan de hand hiervan kunnen aanbevelingen opgesteld worden aan hoe de website aangepast kan worden om gebruikers van die categorie beter te bedienen.
Figuur 5: MBTI-model.
11
6. Statistieken en logging Om de acties van de gebruikers te kunnen bijhouden zal dit gelogd moeten worden door het CMS. Het doel van dit project is om uit te zoeken wat er op dit moment al gemeten wordt door het CMS, wat er nog meer gemeten moet worden en hoe we deze statistieken kunnen analyseren. Vervolgens zal deze informatie op een duidelijke manier inzichtelijk gemaakt moeten worden. In dit hoofdstuk zullen we een overzicht geven.
6.1 Logging-mogelijkheden Er zijn verschillende mogelijkheden om de acties van bezoekers te loggen. In de huidige module wordt dit gedaan door bij elke PHP-pagina een stuk code toe te voegen dat de acties toevoegt aan een tabel in een SQL-database. Data capture mechanics: cookies: worden geplaatst op de computer van de webbezoeker. Kan beperkt data en staat op slaan. Javascript tag: wordt op elke pagina geplaatst om zo gebruik te registreren. web logs: de server zelf houdt logs bij waaruit ook gebruiksdata valt te halen. web beacons / web bug: dit kan bijvoorbeeld een klein, onzichtbaar, plaatje zijn waarmee gelogd wordt wanneer het geopend wordt. server sided script: een script dat met elke pagina wordt meegezonden en uitgevoerd wordt op de server waarmee de gebruikersdata gelogd wordt. 6.2 Relevante statistieken Voor het analyseren van de acties en gebruikservaring van de bezoekers moeten een aantal begrippen geïntroduceerd worden. Deze begrippen houden nauw verband met de statistieken die we kunnen loggen en de analyse die we aan de hand van die statistieken willen maken. Voor een bedrijf dat haar doelen wil bewerkstelligen via hun website is het belangrijk dat zij zogenaamde goals stellen. Dit zijn specifieke en simpele strategieën die samen uiteindelijk moeten leiden tot het bereiken van een bedrijfsdoel.
12
6.2.1 Metrics Uiteindelijk willen wij weten of deze goals bereikt worden. Om hier achter te komen kunnen we onder andere gebruik maken van alle statistieken die gelogd worden. Deze statistieken noemen we ook wel metrics. Hieronder vindt u een overzicht van interessante metrics.
pagehit pageview time on page: tijd die een bezoeker op een bepaalde pagina blijft. time on site: tijd die een bezoeker op de gehele website doorbrengt. referral exit percentage bounce ratio conversiedoel conversieratio zoektermen locatie browser operating system schermresolutie
6.2.2 KPI KPI, oftewel key performance indicators, zijn specifieke metrics of een analyse van metrics die helpen begrijpen in hoeverre een goal bereikt is.
Bezoekersloyaliteit: aantal return visits. Bezoekersrecentheid: hoeveel tijd zit er tussen return visits. Verschil tussen Google search hits en interne search hits. Dit is bijvoorbeeld data die mensen zoeken maar niet kunnen vinden op de website, en dus interessant voor beheerders om daar content voor te genereren. Verschil tussen Google zoekwoorden en landing pages. Welke pagina’s worden bezocht bij bepaalde zoekwoorden. Welke pagina’s worden in dezelfde sessie bezocht. Bounce ratio individuele pagina tegenover sitegemiddelde.
6.2.3 Conversies Een conversie treedt op wanneer er een ingesteld doel is bereikt op de website. De fractie van daadwerkelijke conversies op het totaal aantal bezoeken maakt de uiteindelijke conversieratio. Deze gegevens zijn enorm waardevol want ze leveren zeer concrete informatie in hoeverre een website succesvol is in zijn (sub)doelen. Bestaande analytics-pakketten bieden nu ook al de functionaliteit de stappen die leiden tot een conversie te loggen door middel van een zogenaamde ‘conversion funnel’ oftewel een conversietrechter. Content Power maakt ook gebruik van deze functionaliteit in het door hun gebruikte Google Analytics-pakket. 13
6.2.4 6.2.5
Overige interessante informatie returning pages (welke pagina’s worden vaker bezocht binnen een sessie). interactie met elementen, zonder dat er naar een andere pagina wordt gegaan (polls, formulieren en dergelijke). staat van webformulier: is het reeds verzonden? context: is de gebruiker ingelogd? Overige interessante technieken Heat maps Mouse tracking Cross visit tracking (nieuwe cookiewetgeving mogelijk problematisch) Gemiddelde scroll-diepte (wordt content onder de fold wel gelezen?)
14
7. Datavisualisatie Datavisualisatie bestudeert de visuele representatie van data. In dit project hebben we veel data die we inzichtelijk willen maken; denk daarbij aan statistieken en logs die we verzamelen en de eventuele data die we zelf genereren. In dit hoofdstuk zullen we voor ons potentieel nuttige datavisualisatietechnieken opsommen waar we onderzoek naar willen doen.
7.1 Begrijpelijk maken complexe statistieken Voor ons Delftenaren is een driedimensionaal scatterplot met logaritmische schalen wellicht prima te begrijpen. Voor andere mensen, waaronder veel van de klanten van Content Power, zijn dit soort visualisaties minder goed te doorgronden. Uit onderzoek (Few, Stephen: “Show me the numbers” (2004)) blijkt zelfs dat de meeste mensen een erg beperkt aantal grafieken en visualisaties kan lezen. Daarom is het van belang dat wij voor de visualisatie van onze data gebruik maken van begrijpbare hulpmiddelen. Denk hierbij aan: 7.1.1 Tabellen Tabellen kunnen gebruikt worden om simpele vergelijkingen te maken tussen verschillende waarden. Deze worden vaak gebruikt om op een eenvoudige manier statistieken weer te geven die bijna iedereen kan begrijpen. 7.1.2 Staafdiagrammen Staafdiagrammen worden gebruikt om individuele waarden zichtbaar te maken en te kunnen vergelijken. Verschillen tussen verschillende onderdelen kunnen goed zichtbaar gemaakt worden. 7.1.3 Taartdiagrammen Taartdiagrammen worden gebruikt om percentages van verschillende onderdelen zichtbaar te maken, waarbij het totaal altijd op 100% uitkomt.
7.1.4 Lijndiagrammen Lijndiagrammen worden over het algemeen gebruikt om veranderingen ten opzichte van de tijd zichtbaar te maken. Echter valt er bij ons nog meer data te visualiseren die zich niet zo eenvoudig laat vangen in de gangbare diagrammen. Daarom gaan we onderzoek doen naar aanvullende visualisatie methoden:
Tag clouds In-page analytics Clickflow visualisation Funnel visualisation 15
7.2 Bestaande analytics-pakketten Op dit moment zijn er al verschillende pakketten op de markt die het mogelijk maken statistieken van een website te meten; van losse pakketten tot geïntegreerde modules binnen een systeem. Enkele van deze pakketten zullen wij hier bespreken, waarbij we kijken naar wat wel goed werkt en wat minder goed werkt.
7.2.1 Google Analytics Google Analytics is veruit de populairste en bekendste tool om webstatistieken te meten. Google Analytics werkt met een stukje Javascript code dat in elke pagina ingevoegd moet worden. Bij elke pageview wordt daarbij deze code uitgevoerd, waarbij deze view bij de servers van Google wordt geregistreerd. De beheerder kan vervolgens inloggen bij Google en daarbij allerlei verschillende statistieken bekijken. Daarbij zijn er verschillende tools in te stellen die geavanceerdere metingen kunnen uitvoeren die van belang kunnen zijn bij bijvoorbeeld e-commerce. http://www.google.com/analytics/ Pro’s Veel verschillende tools Veel verschillende visualisaties Op servers van Google
Con’s Moet voor elke pagina ingesteld worden Werkt enkel met Javascript tags
7.2.2 Open Web Analytics Open Web Analytics is een Open Source tool dat probeert veel van de functies van Google Analytics na te bootsen. Echter in plaats van het versturen van de data naar de servers van Google kan dit in een eigen database worden opgeslagen. Tevens kan gebruik worden gemaakt van een PHP API waardoor er geen gebruik gemaakt hoeft te worden van Javascript en er dus minder dataverkeer nodig is om de statistieken te loggen. Ook Open Web Analytics bevat veel tools die veel verschillende statistieken kan loggen al lijkt dit net iets minder te zijn dan het aantal tools die Google Analytics heeft. http://www.openwebanalytics.com/ Pro’s Veel verschillende tools In eigen database op te slaan PHP API beschikbaar Plug-ins beschikbaar voor veel gebruikte CMS-en
Con’s Minder tools dan Google Analytics
16
7.2.3 Piwik Ook Piwik is een Open Source tool dat een alternatief voor Google Analytics is. Piwik kan geïnstalleerd worden op een externe host en slaat de gegevens op in een eigen database waarbij dit geïntegreerd kan worden in vele verschillende andere pakketten. Dit pakket heeft wel iets minder mogelijkheden dan Google Analytics. http://piwik.org/ Pro’s Veel verschillende tools In eigen database op te slaan
Con’s Minder tools dan Google Analytics
7.2.4 OpenTracker OpenTracker is een pakket dat in tegenstelling tot zijn naam niet Open Source is. Het is een commercieel pakket dat realtime statistieken van bezoekers kan weergeven. Het kan visualisaties maken van individuele clickstreams. Een speciale feature is de company identification, dat aan de hand van het IPadres kan achterhalen vanaf welk bedrijf een bezoek is gedaan. http://www.opentracker.net/ Pro’s Real time tracking Company identification
Con’s Commercieel Werkt enkel met Javascript tags
7.2.5 SiteCore SiteCore is een commercieel CMS-pakket dat zeer uitgebreide statistieken kan leveren en websites op een persoonlijke manier kan aanpassen. In dit systeem wordt het CMS en de Business Intelligence tools compleet met elkaar geïntegreerd. http://www.sitecore.net/ Pro’s Zeer uitgebreide statistieken Integratie van CMS en BI
Con’s Commercieel
17
8. Begrippenlijst CMS
Content Management Systeem, stelt beheerders van een website in staat eenvoudig content aan te passen of toe te voegen.
clickstream
Volgorde van links die een gebruiker klikt op een website.
goal tracking
Het bijhouden van bepaalde doelen waarvan je wilt dat bezoekers er naar toe klikken.
conversieratio
Ratio van gewenste acties van bezoekers op het totaal aantal bezoeken.
landing page
Webpagina waarop bezoekers binnenkomen vanuit zoekmachines.
exit page
De laatste pagina die een bezoeker tijdens een sessie bezoekt.
sessie
Een bezoek aan een website waarin een of meerdere pagina’s worden bezocht.
bounces
Aantal bezoeken die starten en eindigen op dezelfde pagina.
entrances
Aantal bezoeken die starten op deze pagina.
bounce ratio
Ratio van bounces en entrances.
logs
Logbestanden, houden bij welke acties een bezoeker heeft uitgevoerd.
pagehit
Een serverrequest voor een enkel bestand.
pageview
Een serverrequest voor een enkele HTML-pagina.
KPI
Key Performance Indicator.
online presence
De online presentatie van een bedrijf.
18
9. Referenties Datavisualisatie: Case Study: E-Commerce Clickstream Visualization o http://courses.ischool.berkeley.edu/i247/s02/readings/brainerd.pdf o In dit wetenschappelijke artikel wordt een methode omschreven om clickstream data grafisch weer te geven. What Did They Do? Understanding Clickstreams with theWebQuilt Visualization System o http://berkeley.academia.edu/TaraLynnMatthews/Papers/65544/What_did_they_do_U nderstanding_clickstreams_with_the_WebQuilt_Visualization_System o Dit wetenschappelijke artikel legt een systeem uit dat clickstream data grafisch weergeeft aan de hand van server logs. Visualization and Analysis of Clickstream Data of Online Stores with a Parallel Coordinate System o http://www.springerlink.com/content/71mvrfal4dd2k5af/fulltext.pdf Clickstreams: What They Are and Why You Should Track Them o http://mashable.com/2009/08/25/clickstreams/ o Uitleg wat clickstreams zijn en verschillende tools die dit kunnen tracken. Flowingdata o http://flowingdata.com/ o Een blog die verschillende vormen van visualisaties toont. Data Visualisation (IN4086) - Reader 2010 o https://blackboard.tudelft.nl/webapps/blackboard/execute/content/file?cmd=view&co ntent_id=_1859925_1&course_id=_39588_1 o Paper over effectief kleurgebruik. Goede guidelines op pagina 13 en 14. Physiological principles for the effective use of color, Gerald M. Murch, Tektronix Incorporated o http://dl.acm.org/citation.cfm?id=2349 Data mining: Data Preparation for Mining World Wide Web Browsing Patterns (1999) o http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.3835 o In dit enigszins gedateerde artikel wordt uitgelegd hoe vanuit serverlogs bepaalde interessante patronen kunnen worden ontdekt. Algorithms for Association Rule Mining - A General Survey and Comparison o http://dl.acm.org/citation.cfm?id=360421 o In dit wetenschappelijke artikel worden verschillende algoritmen uitgelegd die associaties uit grote databases kunnen ontleden. Analyzing the footsteps of your customers o http://robotics.stanford.edu/people/ronnyk/WEBKDD2000/WEBKDD2000_ARCHIVE/ii_ 2.pdf o In dit artikel wordt een systeem omschreven dat associaties kan ontdekken uit serverlogs. cookiewetgeving o http://www.rijksoverheid.nl/onderwerpen/ict/veilig-online-en-eprivacy/internetbezoek-volgen-met-cookies o Korte omschrijving van de huidige wetgeving rond cookies.
19
Web usage mining Search Analytics for Your Site, Louis Rosenfeld Advanced Web Metrics with Google Analytics™, Second Edition, Brian Clifton o http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470562315,descCdauthorInfo.html o Boek over het gebruik van Google Analytics. Google Analytics, Justin Cutroni o http://www.oreillynet.com/pub/au/3170 o Auteur van 2 boeken over Google Analytics. Beginner's Guide To Web Data Analysis: Ten Steps To Love & Success o http://www.kaushik.net/avinash/beginners-guide-web-data-analysis-ten-steps-tipsbest-practices/ o Introductie over het gebruik van Google Analytics. Secure accounting and auditing on the Web o http://www.sciencedirect.com/science/article/pii/S0169755298001160 Auditable metering with lightweight security o http://dx.doi.org/10.1007%2F3-540-63594-7_75 Deflation-secure web metering o http://dx.doi.org/10.1504%2FIJICS.2007.012244
20
Appendix A. Interviewvragen ● Bij het opstellen van een SEO-rapport, waar haalt u uw data vandaan? ○ Welke Web Analytics pakketten gebruikt u nu, en welke heeft uw voorkeur? ○ Gebruikt u nog andere tools? ○ In hoeverre draagt de huidige statistiekmodule bij aan uw werk? ○ Van welke statistieken maakt u nu gebruik? ○ Welke data gebruikt u om inzicht te krijgen in conversies? ● Met al de voor u beschikbare data, hoe bewerkt u deze om een voor de klant begrijpelijk rapport op te stellen? ○ Is er data die u meer zou willen betrekken dan nu het geval is? ● Wat voor feedback krijgt u van klanten? ○ Waar is de klant voornamelijk in geïnteresseerd? ○ Naar welke statistieken wordt door de klanten vooral gevraagd? ○ Waar reageert de klant positief op? ○ Waar reageert de klant negatief op? ○ Welke typen visualisaties zijn voor de klanten begrijpelijk?
21
B. Samenvatting interview werkzaamheden Willem van Valkenburg
datum: tijd: geïnterviewde: interviewers:
8 Oktober 2012 13:15 - 13:30 Willem van Valkenburg, medeoprichter Content Power Arno de Bruijn, Matthijs van Dorth
Op dit moment wordt voor de werkzaamheden als SEO vooral Google Analytics en de website zelf gebruikt. De huidige statistiekmodule wordt echter nauwelijks gebruikt. Wel wordt er veel gebruik gemaakt van het script dat controleert op welke plaats de website staat bij bepaalde zoekwoorden binnen Google. Voor een aantal websites worden trechters ingesteld (een optie binnen Google Analytics) zodat gekeken kan worden wat de conversie door een bepaalde lijn van de website is. Ook maakt hij gebruik van de webmastertools van Google die aangegeven op welke zoektermen gezocht wordt. Op dit moment bevat Google Analytics steeds meer, echter moeten veel van de onderdelen steeds handmatig voor elke website worden ingevoerd terwijl dit eigenlijk steeds dezelfde stappen zijn voor dit CMS. Klanten vinden het vaak wel lastig om Google Analytics te gebruiken en kunnen niet altijd vinden wat ze zoeken. Klanten zijn niet echt geïnteresseerd in de statistieken zelf maar meer in concrete dingen als hoe verbeter ik de site zodat meer klanten producten/diensten afnemen. Statistieken zijn een hulpmiddel voor het doel om meer omzet te halen. Veel klanten reageren met hun onderbuik, wat klanten nodig hebben is data om beslissingen mee te kunnen nemen. Het is vaak lastig om je goed te verplaatsen in de klant. Zo zijn er vier soorten klanten te onderscheiden; elk type klant vindt iets anders belangrijk bij een product. Wat betreft visualisaties worden veel tabellen gebruikt, met uitleg erbij. Er zijn klanten die een losse tabel zonder uitleg niet begrijpen. Met grafieken is hij terughoudend, omdat veel klanten die niet goed kunnen lezen. SEO is niet een exacte wetenschap, er is niet een methode om ervoor te zorgen dat een pagina op #1 komt in Google. Je moet rekening houden met doelgroepen, de marketing eromheen en dat is vaak een van de lastigste dingen.
22
C. Opdrachtomschrijving Meer kunnen meten Op dit moment meet de statistiekmodule van Content Power de volgende onderdelen: bezochte URL’s, gebruikte items op dynamische pagina's en referals. Sommige belangrijke onderdelen worden echter nog niet gemeten. Bijvoorbeeld of een formulier op een bepaalde pagina wel of niet verzonden is (URL blijft gelijk). Terwijl juist dit soort informatie een inzicht geeft in de acties van bezoekers. De eerste stap zou dus ook zijn om het mogelijk te maken dit soort acties te meten. Context Bij nieuwere websites van Content Power wordt de staat van de website bijgehouden. Denk hierbij aan wel/niet ingelogd, wel/niet items in winkelmand, wel/niet akkoord met voorwaarden. Naast te weten welke pagina een bezoeker bezocht ook te weten in welke context hij/zij dit deed kan veel meer inzicht geven. De tweede stap zou dus zijn ook deze informatie te registreren. Weergave Na het registreren van de informatie moet natuurlijk alles inzichtelijk worden gemaakt. Er is al een statistiekmodule. Deze zou kunnen worden aangevuld om ook de nieuwe informatie te tonen. De werkelijke meerwaarde zit in analyses van de data. Hierbij kan worden gedacht aan: ● Bezoekers die pagina x bezochten, bezochten ook …. (met percentages) ● Bezoekers die pagina x bezochten daarna de pagina's … (met percentages) ● Bezoeker binnen context x bezochten voornamelijk pagina's … (met percentages) ● Bezoekers kwamen voornamelijk bij context x via de pagina … (met percentages) Natuurlijk staan we altijd open voor suggesties. Hierbij kan gekeken worden in literatuur of bij bekende statistiekenprogramma's als Google Analytics. Ook kan er gekeken worden naar wat er kan worden toegevoegd aan mogelijkheden die niet in bijvoorbeeld Google Analytics zitten, aangezien hier heel dicht op de bron informatie kan worden verzameld. Flow (extra) Mocht het haalbaar zijn binnen de opdracht zou de mooiste weergave die van een flow door de website zijn. Een voorbeeld hiervan is de Google Analytics-weergave. Voor veel websites is in de configuratie al een flow gedefinieerd. Deze zou visueel kunnen worden weergegeven met de volgende gegevens: ● Hoeveel bezoekers bezochten welke stap in het proces ● Hoe groot is het afhaakpercentage per stap ● Naar welke pagina's gingen de afhakers ● Welke invloed heeft elke context op de flow Soms kan de flow ook via mail verder verlopen, dus deze kan niet enkel op URL’s worden gebaseerd. A/B-testen (extra) Op sommige websites wordt binnen de flow a/b-tests toegepast. Dit betekent dat er meerdere weergaven van de pagina's zijn. Aan elke bezoeker wordt een willekeurige pagina toegewezen. Achteraf kan worden gemeten welke paginaweergave het meest succesvol was. Deze informatie zou uitermate goed te combineren zijn met de flow weergave. 23
BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Plan van Aanpak Matthijs van Dorth 1265911 Arno de Bruijn 1262467
Bedrijf: Technische Universiteit Delft: Datum:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica 7-11-2012
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Voorwoord Dit is het Plan van Aanpak van het Bachelorproject dat wordt uitgevoerd bij Content Power door studenten Technische Informatica Arno de Bruijn en Matthijs van Dorth. Dit project wordt in verschillende fasen uitgevoerd, welk in dit document verder toegelicht zullen worden. Ook zal worden beschreven wat de verantwoordelijkheden zijn van de verschillende personen die betrokken zijn bij dit project. Dit document omschrijft tevens de afbakening van het project, een tijdsplanning, de projectomgeving en een beschrijving van hoe de kwaliteit van de op te leveren producten gemeten kan worden.
2
Samenvatting In dit project zullen wij een nieuwe module gaan implementeren die beheerders kan helpen bij conversie- en zoekmachineoptimalisatie. Door het houden van interviews willen wij erachter komen hoe we de beheerders hiermee kunnen helpen en hoe zij graag het beste geadviseerd kunnen worden. Dit document omschrijft tevens de afbakening van het project, een tijdsplanning, de projectomgeving en een beschrijving van hoe de kwaliteit van de op te leveren producten gemeten kan worden.
Figuur 1: eerste mock-up van de nieuwe statistiekmodule.
3
Inhoud Voorwoord ................................................................................................................................................ 2 Samenvatting ............................................................................................................................................ 3 1. Introductie ............................................................................................................................................ 5 2. Projectopdracht .................................................................................................................................... 6 2.1. Projectomgeving ............................................................................................................................ 6 2.2. Doelstelling project ........................................................................................................................ 6 2.3. Opdrachtformulering ..................................................................................................................... 6 2.4. Op te leveren producten en diensten ............................................................................................ 7 2.5. Eisen en beperkingen ..................................................................................................................... 7 2.6. Partijen en voorwaarden ............................................................................................................... 8 3. Aanpak en tijdsplanning ........................................................................................................................ 9 3.1 Oriëntatiefase ................................................................................................................................. 9 3.2 Analysefase ..................................................................................................................................... 9 3.3 Ontwerpfase ................................................................................................................................... 9 3.4 Implementatiefase .......................................................................................................................... 9 3.5 Testfase ......................................................................................................................................... 10 3.6 Afrondingsfase .............................................................................................................................. 10 3.7 Tijdsplanning ................................................................................................................................. 10 4. Projectinrichting ................................................................................................................................. 11 4.1 Organisatie & Personeel ............................................................................................................... 11 4.2 Locatie ........................................................................................................................................... 11 4.3 Rapportering ................................................................................................................................. 11 4.4 Resources ...................................................................................................................................... 11 5. Kwaliteitsborging ............................................................................................................................... 12 Bijlage A: Planning:.................................................................................................................................. 13 Bijlage B: Interview beheerders / gebruikers: ........................................................................................ 15 Bijlage C: Uitnodiging Interview SEO ...................................................................................................... 16 Bijlage D: Uitnodiging Interview klant .................................................................................................... 17 Bijlage E: Vragenlijst SEO expert ............................................................................................................. 18 Bijlage F: Vragenlijst klanten ................................................................................................................... 19
4
1. Introductie Het bedrijf Content Power ontwikkelt websites voor haar klanten. Dit doen zij gebaseerd op een intern ontwikkeld Content Management Systeem (CMS). De verscheidenheid van klanten is groot, echter veel van hen hebben gemeen dat zij afhankelijk zijn van de prestaties van hun website. Veel van de websites bevatten een webshop, contactpagina’s of een offertepagina die direct of indirect een inkomstenbron zijn van de desbetreffende bedrijven. Meerdere factoren dragen bij aan een succesvolle webpagina. Onder andere de vindbaarheid door zoekmachines en het in staat zijn tot het maken van conversies. In hoeverre een webpagina slaagt in deze doelen is meetbaar. Aangezien wij ons in de unieke positie bevinden waarin wij beschikking hebben over zowel de webstatistieken, zoals die ook door Google Analytics weergegeven kunnen worden, evenals de inhoud van de website zoals die in het Content Management Systeem van Content Power staat, beschikken wij over veel waardevolle data. Een klein deel van deze data wordt in de huidige situatie door de statistiekmodule inzichtelijk gemaakt. Echter vind er weinig aftrek plaats van deze statistieken bij de klanten van Content Power. Aan ons dan ook de taak om een nieuw systeem op te zetten. Onze motivatie daarbij is om het de gebruiker van dit nieuwe systeem zo makkelijk mogelijk te maken zodat het syteem ook daadwerkelijk gebruikt gaat worden. Uit rondvraag en overleg is gebleken dat de rauwe statistieken voor de beheerders vaak weinig inzicht verschaffen over het presteren van hun website. Onze insteek is dan ook om een expertsysteem te ontwikkelen wat aan de hand van de statistieken en andere voor ons beschikbare data aanbevelingen kan doen naar de beheerders hoe zij hun website kunnen optimaliseren. Deze optimalisering moet onder andere leiden tot meer conversies en betere vindbaarheid door zoekmachines. In dit document zullen wij ingaan op de precieze opdracht die wij samen met Content Power beschreven hebben. Hierbij geven wij aan wat de doelstellingen zijn van ons project en in welke omgeving wij dit doen alsmede de precieze op te leveren producten met de eisen die wij daaraan stellen binnen de door ons opgestelde voorwaarden. Tevens bevat dit document een beschrijving van hoe we dit project gaan aanpakken, hoe het project wordt ingericht en een beschrijving over hoe de kwaliteit van het eindproduct zo hoog mogelijk kan worden opgeleverd. In de bijlagen vindt u tenslotte een planning van week tot week waarin staat welke onderdelen in welke weken af moeten zijn.
5
2. Projectopdracht In dit hoofdstuk zullen wij verder ingaan op de daadwerkelijk op te leveren producten, welke beperkingen en eisen we stellen aan dit project en bij wie de verantwoordelijkheden liggen. 2.1. Projectomgeving Op dit moment bestaat het CMS al uit verschillende modules. Door deze modulaire opbouw is het eenvoudig functionaliteit uit te breiden of toe te voegen. Daarnaast bestaan er binnen de omgeving van het CMS zogenaamde ‘building blocks’. Met deze building blocks kunnen bepaalde standaardelementen eenvoudig worden toegevoegd aan de modules. Het CMS draait op een webserver met ondersteuning voor PHP. Daarnaast is er een MySQL database server voor het opslaan van de data. Tijdens het ontwikkelen wordt gebruik gemaakt van OTAP (Ontwikkel, Test, Acceptatie, Productie) en ook voor elk van deze fasen is er een aparte domeinnaam en virtuele server. Tot de ontwikkelomgeving is direct toegang mogelijk met behulp Subversion. De nieuwe module gaat werken binnen de huidige modulaire opbouw.
2.2. Doelstelling project Het doel van dit project is het verwerken van de webstatistieken tot voor de beheerders bruikbare aanbevelingen. Hiermee moeten knelpunten binnen de website voor klanten op een duidelijke manier inzichtelijk gemaakt worden, zodat zij deze zelf aan de hand van de door ons geleverde aanbevelingen kunnen verbeteren.
2.3. Opdrachtformulering In dit project wordt er een nieuwe module ontwikkeld welke on-page SEO-advies en conversieoptimalisatie-advies kan geven. Dit gebeurt op basis van een expertsystee, bestaande uit een inference engine en production rules. De inference engine zal door ons ontwikkeld worden in een door Content Power beheerbare vorm. De production rules zullen wij opstellen aan de hand van literatuuronderzoek en interviews. Het moet voor Content Power mogelijk zijn om later meer production rules toe te voegen voor betere resultaten of onvoorziene ontwikkelingen. Tevens behorend tot deze opdracht is het interviewen van een aantal SEO-experts en klanten. De SEOexperts worden geïnterviewd met als doel ‘best practices’ te achterhalen en zodoende production rules op te kunnen stellen. De klanten worden geïnterviewd om er achter te komen hoe zij op dit moment statistieken gebruiken. Tevens willen wij hun mock-ups voorleggen van het door ons voorgestelde systeem, om te kijken welke elementen aan slaan bij de gebruikers en of ze dit systeem wel daadwerkelijk willen gaan gebruiken.
6
2.4. Op te leveren producten en diensten Na afronding van het project zullen wij de volgende producten opleveren:
Oriëntatieverslag Plan van Aanpak Requirements and Analyses Document Testplan Technical Design Document Implementatie (prototype aanbevelingssyteem) Documentatie voor Content Power Testresultaten Feedback SIG Eindverslag + reflectie
2.5. Eisen en beperkingen Het uiteindelijke product bevat minimaal een inference engine die vanuit de productieregels en verschillende databronnen dit kan omzetten in aanbevelingen. Tevens bevat de module een geschikte weergave van deze aanbevelingen, zodat op een duidelijke manier gecommuniceerd kan worden wat exact gedaan kan worden om de website te optimaliseren. We zullen een aantal productieregels opstellen en we zullen de mogelijkheid tot het later toevoegen en aanpassen van de regels faciliteren. Om goede aanbevelingen te kunnen doen zal meer specifieke kennis over de website nodig zijn, daarvoor zal er een vragenlijst voor de beheerder zijn waarin hij of zij extra informatie kan geven die van belang is voor de inference engine. Het daadwerkelijk invullen van deze vragenlijsten en het opvolgen van de aanbevelingen zal door de klanten zelf gedaan moeten kunnen worden.
7
2.6. Partijen en voorwaarden Binnen dit project kunnen de volgende stakeholders aangewezen worden: ●
●
● ●
Projectleden: ○ Arno de Bruijn ○ Matthijs van Dorth Opdrachtgevers ○ Content Power ○ TU Delft Klanten van Content Power Externen ○ SEO- experts
Aan de projectleden is het de taak om de eisen en beperkingen zoals die in de paragraaf hiervoor opgesteld zijn uit te werken. De opdrachtgevers zijn Content Power en de TU Delft. De contactpersoon bij Content Power is Willem van Valkenburg en bij de TU Delft is dat Martha Larson. Onder de klanten wordt verstaan alle klanten van Content Power. Echter zal in eerste instantie slechts een beperkt aantal klanten benaderd worden om in interviews mock-ups van het door ons te ontwerpen systeem voor te leggen om zodoende te kijken wat werkt en wat niet. Wij verwachten van vanuit Content Power dat zij zorgen voor de projectinrichting, dat wil zeggen toegang tot de Subversion en web- en database-servers, ondersteuning bij vragen over het huidige systeem en feedback over het geleverde werk. Van de opdrachtgevers van de TU Delft verwachten wij feedback over de door ons op te leveren documentatie. De klanten zijn belangrijke stakeholders binnen dit project, want zij zullen de uiteindelijke eindgebruikers zijn. Voor het succes van dit project is het daarom van belang genoeg feedback te krijgen van de klanten tijdens de interviews. Ook voor het inwinnen van SEO-expertise zullen wij deels afhankelijk zijn van interviews. Deze zullen door de projectleden gehouden moeten worden en hiervoor zullen zij dus opzoek moeten naar SEOexperts.
8
3. Aanpak en tijdsplanning Dit project zal in verschillende fasen worden uitgevoerd zodat aan de gestelde eisen gedefinieerd in 2.5 voldaan kan worden. De exacte weekplanning is gegeven in Bijlage A. In dit hoofdstuk zullen wij verder ingaan op de verschillende fasen van het project.
3.1 Oriëntatiefase De oriëntatiefase is reeds afgerond. In deze fase is kennis gemaakt met het bedrijf, het kantoor en de medewerkers, de tools die gebruikt worden alsmede het CMS zelf. In deze fase hebben we ook de precieze opdracht geformuleerd. Deze fase hebben we afgerond met het Oriëntatieverslag.
3.2 Analysefase In de analysefase hebben we ons verder verdiept in de kennis die wij nodig denken te hebben voor het verdere verloop van dit project. Zo behoren de literatuurverslagen tot deze fase almede het opstellen, het plannen, het houden en het uitwerken van de interviews. Deze fase wordt afgerond met dit Plan van Aanpak.
3.3 Ontwerpfase In de ontwerpfase zullen we de nieuw te maken module daadwerkelijk ontwerpen. De drie documenten die we in deze fase opleveren zijn het Testplan, het Requirement and Analysis Document (RAD) en het Technical Design Document (TDD). In het Testplan zullen wij omschrijven hoe wij de module willen testen zodat deze overeen komt met de door ons gestelde eisen. In het RAD zullen wij beschrijven, aan de hand van het MoSCoW model, welke prioriteiten we moeten stellen aan de verschillende onderdelen binnen ons systeem. Deze differentiatie stellen we op aan de hand van interviews met de klanten. In het TDD zullen we aan de hand van UML-diagrammen schetsen hoe ons gehele systeem eruit komt te zien.
3.4 Implementatiefase In de implementatiefase zullen we daadwerkelijk gaan implementeren. De RAD en TDD dienen daarbij als leidraad. Na afronding van deze fase moet de het prototype van de module af zijn.
9
3.5 Testfase In de testfase zullen we de implementatie aan de hand van het testplan gaan testen. Ook zullen we de code voor het eerst opsturen naar de Software Improvement Group (SIG). Al deze resultaten zullen we samenvoegen in het Testrapport.
3.6 Afrondingsfase In de afrondingsfase zullen we het Eindrapport opstellen met daarin al onze bevindingen uit dit project. Hierin zal ook de precieze werking van de module uitgelegd worden. Dit zal ook de laatste mogelijkheid zijn om de laatste bugs uit het programma te halen. Vervolgens zullen wij de code en het Eindverslag opleveren en onze resultaten presenteren op de eindpresentatie.
3.7 Tijdsplanning De exacte planning is terug te vinden in Bijlage A. Zoals daaruit op te maken is overlappen de ontwerpfase en analysefase elkaar wel iets, maar dat is nodig gebleken om genoeg tijd uit te trekken voor de interviews. Tijdens de kerstvakantie is een kleine buffer ingebouwd om in het geval dat we iets achterlopen dit dan in kunnen halen.
10
4. Projectinrichting Het doel van projectinrichting is het zichtbaar maken van de wijze waarop de projectmanager van plan is het project in te richten om de opdracht uit te voeren volgens de voorgestelde aanpak. De volgende punten zullen daar meestal onderdeel van zijn. Ook andere afspraken over de projectinrichting worden hier opgenomen. In dit hoofdstuk zullen wij beschrijven hoe dit project ingericht wordt. Hier zal beschreven worden door wie en waar dit project uitgevoerd zal worden en welke overige middelen nodig zijn om dit project tot een goed einde te brengen.
4.1 Organisatie & Personeel Het projectteam bestaat uit twee personen, te weten Arno de Bruijn en Matthijs van Dorth. Beiden zijn verantwoordelijk voor het succesvol afronden van dit project. De directe begeleiders zijn Willem van Valkenburg vanuit Content Power en Martha Larson vanuit de TU Delft. Zij zullen het proces nauwlettend in de gaten houden en waar nodig bijsturen. Daarnaast zal Jan Niemantsverdriet begeleiding bieden voor de dagelijkse bezigheden en technische vragen over het CMS.
4.2 Locatie Tijdens dit project zullen wij circa drie dagen in de week aanwezig zijn op het kantoor van Content Power te Delft om aan dit project te werken. Daarnaast zullen wij een dag per week thuis werken aan de op te leveren rapporten en uitwerkingen van de interviews. De interviews zullen bij de klanten en experts op locatie worden gehouden.
4.3 Rapportering Tijdens het project zullen verschillende rapporten opgesteld worden. Deze rapporten zullen in eerste instantie geschreven worden met behulp van Google Docs. Deze rapporten zullen in digitale vorm als PDF worden opgestuurd naar de opdrachtgevers. Het Eindverslag zal tevens in geprinte vorm afgeleverd worden aan de opdrachtgevers.
4.4 Resources Tijdens het project zullen we werken op onze eigen laptops. Tijdens het werken op het kantoor van Content Power kunnen wij gebruik maken van de faciliteiten die daar zijn.
11
5. Kwaliteitsborging Om de kwaliteit van het eindproduct zo hoog mogelijk te krijgen zullen we ons moeten houden aan een aantal regels. Zo zullen we ons houden aan de binnen het bedrijf gestelde coding guidelines om ook de onderhoudbaarheid te waarborgen. Om de kwaliteit van de rapporten zo hoog mogelijk te krijgen zullen de projectleden elkaars werk beoordelen. Bovendien verlangen zij van de opdrachtgevers dat er regelmatig feedback komt over het tot dan toe geleverde werk zodat dit verwerkt kan worden in volgende versies. Deze feedback zal tussentijds over de mail gegeven kunnen worden en zullen tijdens de meetings die regelmatig gehouden besproken worden.
12
Bijlage A: Planning: Week nr. 39 (24 t/m 28 sep)
fase
oriëntatie
41 (8 t/m 12 okt)
oriëntatie
42 (15 t/m 19 okt)
oriëntatie
43 (22 t/m 26 okt)
analyse
44 (29 okt t/m 2 nov)
analyse
45 (5 t/m 9 nov)
ontwerp
47 (19 t/m 23 nov)
bezigheden Kennismaking Content Power. Oriënteren op bedrijf/CMS/tools, bedenken van stage-opdracht. Probleemanalyse Literatuuronderzoek
concept: Oriëntatieverslag
Probleemanalyse Literatuuronderzoek
Oriëntatieverslag
Literatuuronderzoek interview kandidaten zoeken
concept: Plan van Aanpak
Literatuuronderzoek afspreken interview kandidaten opstellen interviews en mockups opstellen interviews/mockups PvA afronden
-
40 (1 t/m 5 okt)
46 (12 t/m 16 nov)
deliverables stage-opdracht
Plan van Aanpak
ontwerp
ontwerp
48 (26 t/m 30 nov)
implementatie
49 (3 t/m 7 dec)
implementatie
Testplan concept: TDD
TDD Interview verslagen concept: RAD RAD
TDD feedback Testplan verwerken interviews/uitwerken interviews feedback TDD verwerken TDD interviews/uitwerken interviews RAD feedback RAD verwerken implementeren implementeren
13
Week nr. 50 (10 t/m 14 dec)
fase
deliverables
implementatie
51 (17 t/m 21 dec)
test
52 (24 t/m 28 dec)
-
1 (31 dec t/m 4 jan) 2 (7 t/m 11 jan) 3 (14 t/m 25 jan)
bezigheden prototype af
prototype testen code submit SIG Vakantie
-
afronding
concept: Eindverslag
Vakantie + eventuele uitloop feedback SIG verwerken
Eindverslag
2e code submit SIG Eindverslag maken Presentatie
afronding
14
Bijlage B: Interview beheerders / gebruikers: Interview Interlodge BestHotelOffers I-Matic
datum ma 12-11 11:30 di 13-11 14:00 vr 16-11 14:00
locatie Arnhem Huizen Leiden
15
Bijlage C: Uitnodiging Interview SEO Geachte heer, mevrouw, In opdracht van de TU Delft voeren wij een stage uit bij het bedrijf Content Power te Delft. Voor deze stage doen wij onder meer onderzoek naar webstatistiekanalyse. Aan de hand van dit onderzoek willen wij een dashboard maken met een eenvoudige weergave van belangrijke statistieken en SEOaanbevelingen voor websitebeheerders. Hiervoor zijn wij erg geïnteresseerd in uw expertise en willen u graag vragen voor een kort interview (circa 30 minuten). In dit interview willen we onder andere uw werkwijze bestuderen bij het opmaken van een SEO-advies. Denk hierbij aan welke informatie u van een klant probeert te winnen, welke informatie u uit statistieken haalt, best practices en hoe u deze informatie uiteindelijk gebruikt voor aanbevelingen. Ons uiteindelijke doel is namelijk te kijken of wij een expertsysteem kunnen ontwikkelen die geautomatiseerd beheerders en tekstschrijvers SEO-aanbevelingen kan doen. Als u hieraan mee wilt werken dan komen wij graag een keer langs op een voor u uitkomend tijdstip en locatie. En uiteraard willen we u ook op de hoogte houden van onze resultaten mocht u daar behoefte aan hebben.
Met vriendelijke groet, Arno de Bruijn en Matthijs van Dorth
contact:
[email protected] 06 48 097 991
16
Bijlage D: Uitnodiging Interview klant Geachte heer, mevrouw, In verband met het uitvoeren van onze BSc-eindproject van de studie Technische Informatica in opdracht van de TU Delft voeren wij een stage uit bij het bedrijf Content Power te Delft. Voor deze stage doen wij onder meer onderzoek naar webstatistiekanalyse. Aan de hand van dit onderzoek willen wij een dashboard maken met een eenvoudige weergave van belangrijke statistieken en SEO-aanbevelingen voor websitebeheerders. Als klant van Content Power zouden wij u graag een aantal vragen willen stellen over hoe u op dit moment gebruik maakt van de statistieken die beschikbaar zijn en wat u graag zou willen zien aan de statistieken. Ook willen we een aantal vragen stellen over wat u op dit moment doet om beter gevonden te worden door Google. Als u hieraan mee wilt werken dan komen wij graag een keer langs op een voor u uitkomend tijdstip en locatie. Uiteraard willen we u ook op de hoogte houden van onze resultaten.
Met vriendelijke groet, Arno de Bruijn en Matthijs van Dorth
17
Bijlage E: Vragenlijst SEO expert 1 2
3
4
5 6 7 8 9
Waar haalt u de data vandaan die u nodig heeft als SEO? Welke metrics hebben invloed op de SEO en hoe belangrijk zijn elk van deze? a time on page b time on site (engagement) c hits/visit d referral e exit percentage f bounce ratio g zoekwoorden h returning visits Gebruikt u bepaalde standaardregels/best practices bij het analyseren van metrics? a Welke metrics zijn daarvan de belangrijkste? b Wat zeggen elk van deze metrics over de SEO? Als u begint bij een nieuwe klant, welke stappen doorloopt u dan? a Welke vragen stelt u aan de klant? b Welke analyses voert u uit? c Waar kijkt u naar op een website? d Welke tools gebruikt u? Zijn er handelingen die u bij (bijna) elke SEO-optimalisatie uitvoert? In hoeverre automatiseert u nu al bepaalde handelingen? In hoeverre betrekt u de klant bij het optimaliseren van de SEO? Wat zijn de belangrijkste elementen binnen een goede SEO? Naast de externe statistieken van belang voor Google, kijkt u ook naar interne statistieken belangrijk voor de conversie? (gevonden worden vs. op de site blijven)(SEO vs. conversion) a wat is de samenhang daartussen? b conversion ratio c time on site (engagement) d hits/visit e exit percentage f bounce ratio g returning visits 10 Welke andere best practices kunt u noemen?
11 Hoe meet u uw eigen succes?
18
Bijlage F: Vragenlijst klanten 1.
Gebruikt u op dit moment de statistiekmodule binnen het CMS? a. Hoe vaak kijkt u hier naar? b. Hoe belangrijk vindt u deze statistieken? c. Wat leidt u daaraan af? 2. Gebruikt u voor de website een analytics-pakket als Google Analytics? a. Hoe vaak kijkt u naar de statistieken hierbinnen? b. Welke statistieken vindt u dan belangrijk? c. Wat leidt u af aan de statistieken die getoond worden? d. Wat zou u graag duidelijker willen zien? e. Zijn er dingen die u lastig te begrijpen vindt? 3. Gebruikt u betaalde advertenties zoals AdWords? a. Hoe bepaalt u met welke woorden u wilt adverteren? b. Kunt u altijd afleiden of dit succesvol is? c. Waar leidt u dit uit af? 4. Heeft u wel eens een SEO-rapport laten maken voor uw website? a. Wat kwam daaruit naar voren? b. Kwamen er dingen naar voren die u niet verwacht had? c. Welke acties heeft u vervolgens ondernomen? d. Welke acties vond u lastig? e. Was dit uiteindelijk succesvol? 5. Hoeveel tijd bent u ongeveer kwijt aan uw website? a. Vindt u dat te veel/te weinig? 6. We willen u nu een aantal voorstellen voorleggen zoals onze module eruit zou kunnen komen te zien. Wat vindt u van… ?
19
BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Requirements Analysis Document Matthijs van Dorth 1265911 Arno de Bruijn 1262467
Bedrijf: Technische Universiteit Delft: Datum:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica 27-11-2012
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Samenvatting In dit Requirements & Analysis Document zullen de belangrijkste eisen worden gesteld waaraan de nieuwe module in het CMS van Content Power moet voldoen. Deze module moet een expertsysteem bevatten die aanbevelingen doet aan de beheerder van de site op gebied van betere SEO en conversies. Hoe deze module er verder uit moet zien en wat potentiële gebruikers verwachten van een dergelijke module is aan verschillende gebruikers van het huidige CMS gevraagd. Dit door middel van een vragenlijst alsmede het presenteren van verschillende mockups met verschillende mogelijkheden van hoe een dergelijk systeem er uit zou kunnen zien. In drie interviews met verschillende typen klanten is gevraagd hoe zij denken dat een dergelijk systeem er uit moet komen te zien en wat zij belangrijk of minder belangrijk zouden vinden. De uitkomsten van deze interviews vormen een belangrijke bron in de uiteindelijk requirements die volgens het MoSCoW model zijn opgesteld.
2
Inhoud Samenvatting
2
1.
Interviews
4
2.
Gebruikers
5
3.
Functionele eisen
6
4.
3.1 Must have
6
3.2 Should have
7
3.3 Could have
8
3.4 Want to have
8
Niet-functionele eisen
9
4.1 Betrouwbaarheid
9
4.2 Bruikbaarheid
9
4.3 Efficiëntie
10
4.4 Onderhoudbaarheid/Overdraagbaarheid
10
Bijlage A: Mockups
11
#1 Verwachte toename percentueel
12
#2 Verwacht totaal percentage
12
#3 Verwacht resultaat
13
#4 Verwacht resultaat + percentage
13
#21 Progress bar
14
#31 Motivatie + visual
14
#32 Motivatie + uitleg + visual
15
#33 Motivatie + uitleg in main dashboard stijl
15
#34 Enkele aanbeveling uitgelicht + alle aanbevelingen
16
#41 Doelstellingen
16
#42 Scoreverloop per doelstelling
17
Bijlage B: Individuele interviews
18
B.1 Interview Interlodge
18
B.2 Interview BestHotelOffers
20
B.3 Interview 16-11 I-Matic
22
3
1. Interviews Tijdens de analysefase zijn wij op zoek gegaan naar klanten van Content Power die bereid waren om door ons geïnterviewd te worden. Deze interviews vonden plaats tijdens de ontwerpfase. In deze interviews hebben wij met de klanten mogelijke en gewenste functionaliteit van het nieuw te ontwikkelen systeem besproken en mockups voorgelegd. In deze mockups hebben we onze bevindingen van de oriëntatie- en analysefase uitgewerkt tot een door ons voorgesteld systeem, zodoende te kijken welke aspecten goed of niet goed werken. Hieronder een overzicht van de interviews die plaatsgevonden hebben. In bijlage A vindt u alle mockups die in de interviews voorgelegd zijn. In bijlage B vindt u de kernpunten per interview.
Interview Interlodge BestHotelOffers I-Matic
datum ma 12-11 11:30 di 13-11 14:00 vr 16-11 14:00
locatie Arnhem Huizen Leiden
4
2. Gebruikers Het systeem dat wij willen implementeren komt als module beschikbaar voor de gebruikers van het CMS van Content Power. De gebruikers van het CMS, vanaf nu genaamd de beheerders, zijn dus de potentiële gebruikers van ons systeem. De medewerkers van Content Power kunnen modules aanof uitzetten zodat de beheerders deze wel of niet te zien krijgen. Zo wordt de door ons te ontwikkelen module voor de beheerders dus ook beschikbaar gesteld. Verder maken wij geen onderscheid in type gebruiker. Een beheerder heeft wel of geen toegang tot de module afhankelijk van of deze hem of haar door Content Power beschikbaar is gesteld of niet. En de gebruiker moet voor toegang natuurlijk ook ingelogd zijn in het CMS. Uiteraard krijgt elke beheerder slechts aanbevelingen te zien die specifiek voor zijn of haar site zijn.
Figuur 1: CMS dashboard.
5
3. Functionele eisen Hier ziet u een overzicht van de functionele eisen en welke acties het systeem moet kunnen uitvoeren. Deze functionele eisen zullen we indelen in categorieën met verschillende prioriteit, volgens de MoSCoW-methode. De requirements zijn tevens per categorie onderling aflopend gerangschikt in prioriteit. Per requirement wordt ook vermeld aan de hand van de eisen van welke partij deze opgesteld is. Dat gaat om de volgende partijen: ●
Content Power: zoals intern besproken en aan de hand van de originele opdrachtspecificatie.
●
Klanten van Content Power: zoals uitgezocht aan de hand van de interviews.
●
Wij zelf: aan de hand van het onderzoek dat wij gedaan hebben en aan de hand van eigenschappen van het door ons opgestelde systeem.
3.1 Must have Eisen die onmisbaar zijn. Als één van deze eisen in het eindresultaat ontbreekt kan het project beschouwd worden als mislukt. 1
Expertsysteem welke aanbevelingen doet voor on-page zoekmachine optimalisatie. [Wij zelf]
2
Actionable interface: het ontwerp nodigt uit om de aanbevelingen uit te voeren. [Interviews]
3
De volgende statistieken worden in ieder geval verzameld: [Content Power / Wij zelf] a aantal bezoeken op de gehele website. b aantal bezoeken op specifieke pagina. c aantal bounces op specifieke pagina. d pagina-bouncerate tegenover het websitegemiddelde. e gemiddelde tijd doorgebracht op specifieke pagina. f gemiddelde tijd doorgebracht op de gehele website. g exit rate per pagina. h zoekwoord-rank. i lengte van de meta description. j titel ingesteld.
4
Het nieuwe systeem moet als module functioneren binnen het CMS van Content Power. [Content Power]
5
Vanwege de onderhoudbaarheid van de code in de toekomst door Content Power moet ontwikkeld worden in ‘de huisstijl’ in PHP en HTML. Voor databasetabellen moet de CPMyAdmin-module gebruikt worden. [Content Power]
6
6
Uitbreidbaarheid van kennis expertsysteem. Medewerkers van Content Power moeten regels die gebruikt worden bij het generen van aanbevelingen kunnen toevoegen en aanpassen, alsmede de databronnen die voor deze regels gebruikt worden. [Content Power]
7
Overzicht met aanbevelingen, waarvan voor elke aanbevelingen geldt: [Interviews] a deze is in begrijpelijk Nederlands geschreven. b lastige begrippen moeten worden uitgelegd. c aanbevelingen hebben een prioriteit. d aanbevelingen moeten weggeklikt kunnen worden.
8
Door beheerder instelbare doelstellingen voor hun website, op basis van de beschikbare statistieken. [Wij zelf]
9
Overzicht van de behaalde doelstellingen. [Interviews]
10 Overzicht van de niet-behaalde doelstellingen. [Interviews] 11 Site score, gebaseerd op de verhouding tussen behaalde en niet-behaalde doelstellingen. [Wij zelf] 12 Visualisatie van de site score met een progress bar. [Interviews] 13 Er wordt dagelijks gekeken of er nieuwe aanbevelingen gedaan kunnen worden, en of aanbevelingen doorgevoerd zijn. [Content Power]
3.2 Should have Eisen met een zeer hoge prioriteit. Deze eisen moeten in het systeem komen als het ook maar enigszins mogelijk is. 1
Voorbeelden geven bij aanbevelingen van sites (intern of extern) waar dat advies wel goed geïmplementeerd is. [Interviews]
2
Aanbevelingen verdelen in korte- en langetermijnoplossingen. [Interviews]
3
Verloop in de tijd van de behaalde en nog te behalen doelstellingen. Met instelbare tijdsperiode. [Interviews]
4
Onderscheid naar prioriteit voor doelstellingen. [Interviews]
5
Integratie met het stappenobject. [Content Power]
7
3.3 Could have Eisen met een lagere prioriteit. Dit zijn eisen die gewenst zijn, maar niet kritisch voor het succes van het systeem. Indien er genoeg tijd is en het reëel haalbaar is in het systeem kunnen deze geïmplementeerd worden. 1
Feedback op gegeven aanbevelingen meenemen in het doen van nieuwe aanbevelingen. [Content Power]
2
Tonen van de meest belangrijke statistieken op het dashboard. Moet instelbaar zijn per gebruiker, wat ze zelf willen zien: [Interviews] a unieke bezoekers. b overzicht referrals. c overzicht pagina’s met een hoge bounce rate ten opzichte van sitegemiddelde. d overzicht locatie bezoeker.
3
Hogere frequentie van het daadwerkelijk maken van aanbevelingen. [Wij zelf]
4
Disclaimer waarin vermeld wordt dat alle gegevens vertrouwelijk behandeld worden. [Interviews]
5
Genormaliseerde data op basis van alle websites gehost bij Content Power. [Content Power]
3.4 Want to have Dit zijn eisen die in dit project hoogstwaarschijnlijk niet aan bod komen, maar wel in een later stadium bijvoorbeeld door Content Power geïmplementeerd kunnen worden voor extra functionaliteit. 1
Voorspelling wat het effect is van het doorvoeren van een aanbeveling. [Interviews]
8
4. Niet-functionele eisen In de niet-functionele eisen komen de kwaliteitseisen te staan die niet direct meetbaar zijn. In ISO 9126 worden deze niet functionele kwaliteitseisen van software omschreven (bron: http://zbc.nu/ict/selectie-en-invoering-ict-systemen/requirements-staan-aan-de-basis-van-succes/ ) Deze eisen bestaan uit: ● Betrouwbaarheid ● Bruikbaarheid ● Efficiëntie ● Onderhoudbaarheid / Overdraagbaarheid In de volgende stukken zullen wij elk van deze eisen bespreken en aangeven hoe belangrijk deze zijn voor onze module. 4.1 Betrouwbaarheid De betrouwbaarheid van de software kan op verschillende manieren gemeten worden. Als eerste zal de module een zo hoog mogelijke beschikbaarheid moeten hebben. Dit is echter voornamelijk afhankelijk van de beschikbaarheid van het gehele systeem en is iets waar wij niet direct invloed op hebben. Daarnaast zal de module om moeten kunnen gaan met onverwachte input. Dit gedeelte zal vooral tijdens unit-tests getest worden en staat verder beschreven in het testplan. Fouten die in de code zelf kunnen voorkomen zouden met deze unit-tests ook zoveel mogelijk naar voren moeten komen. In het testplan zal beschreven worden hoe wij ervoor zorgen dat de betrouwbaarheid zo hoog mogelijk is.
4.2 Bruikbaarheid Het doel van de module is het inzichtelijk maken van wat er precies op de website gebeurt en wat er nog verbeterd kan worden voor gebruikers met geen of weinig technische ervaring. De module zal daarom een lage leercurve moeten hebben. Om te controleren of de module daar daadwerkelijk aan voldoet zal een gebruikerstest gedaan worden. In deze gebruikerstest zal naar voren moeten komen of de gebruiker er zelf achter kan komen wat hij/zij zal moeten doen om bepaalde acties uit te voeren. Een ander aspect van bruikbaarheid is de instelbaarheid. Wij hebben ervoor gekozen zo min mogelijk in te kunnen stellen om zo de module zo eenvoudig mogelijk te houden. Voorafgaand aan de implementatie zijn al enkele mockups gemaakt, zo hebben een aantal klanten al hun feedback kunnen geven op de gebruikersinterface.
9
4.3 Efficiëntie In het huidige systeem worden : ● statistieken real-time opgeslagen ● complexe query’s zoveel mogelijk ‘s nachts uitgevoerd ● aanbevelingen met een dag vertraging gepresenteerd 4.4 Onderhoudbaarheid/Overdraagbaarheid Zodra ons BSc project afgerond is, is Content Power verder verantwoordelijk voor het onderhouden van de software. Uit de documentatie in het Eindrapport en de comments binnen de code zal duidelijk moeten worden hoe deze module werkt zodat Content Power verder kan gaan met de ontwikkeling van deze module, zoals het toevoegen van extra rules of het toevoegen van extra databronnen. Het bijhouden en regelmatig toevoegen van nieuwe rules zal belangrijk zijn om de module interessant te houden voor de gebruikers. De documentatie zal daarom als naslagwerk moeten dienen om verdere ontwikkeling te bevorderen. Omdat de module enkel binnen het CMS van Content Power werkt zal de overdraagbaarheid een minder groot issue zijn, omdat enkel de medewerkers van Content Power deze module zullen aanpassen en installeren voor haar klanten.
10
Bijlage A: Mockups
Variatie in main dashboard aanbevelingen: #1
Verwachte toename percentueel
#2
Verwacht totaal percentage
#3
Verwacht resultaat
#4
Verwacht resultaat + percentage
Variatie in mina dashboard doelstellingen visualisatie #21
Progress bar
Variantie in scherm: aanbevelingen #31
Motivatie + visual
#32
Motivatie + uitleg + visual
#33
Motivatie + uitleg in main dashboard stijl
#34
Enkele aanbeveling uitgelicht + alle aanbevelingen
Variatie in scherm: doelstellingen overzicht #41
Doelstellingen
#42
Scoreverloop per doelstelling
11
#1 Verwachte toename percentueel
#2 Verwacht totaal percentage
12
#3 Verwacht resultaat
#4 Verwacht resultaat + percentage
13
#21 Progress bar
#31 Motivatie + visual
14
#32 Motivatie + uitleg + visual
#33 Motivatie + uitleg in main dashboard stijl
15
#34 Enkele aanbeveling uitgelicht + alle aanbevelingen
#41 Doelstellingen
16
#42 Scoreverloop per doelstelling
17
Bijlage B: Individuele interviews B.1 Interview Interlodge datum maandag 12 November 2012 tijd 11:30 - 12:30 locatie Arnhem geïnterviewde Eric van Holten
Achtergrond informatie gebruiker: ●
geen ervaren gebruiker van analytics-pakket
●
gebruikt niet de oude statistiekmodule
●
maakt wel gebruik van Adwords
●
wil graag meer organische bezoeken
Gebruiker wil beschikking hebben tot de volgende informatie: ●
Aantal unieke bezoekers
●
Waar komen de bezoekers binnen?
●
Hoe komen de bezoekers binnen?
●
Wanneer is iemand een unieke bezoeker? (bij meerdere keren langs komen)
Opmerkingen mockup #1 ●
Wat zijn de doelstellingen?
●
Wat betekent dat cijfer?
●
Het opstellen van doelstellingen wel mogelijk
●
Aanbevelingen opvolgen meestal zelfde dag
●
Vindt het belangrijk dat alle gegevens vertrouwelijk worden behandeld.
●
Niet alle aanbevelingen zijn zinnig als bedrijfsinformatie ontbreekt (leeg schap/volgeboekt).
Opmerkingen mockup #3 ●
Werken met prioriteiten handiger dan percentages
18
Opmerkingen mockup #21 ●
Progress bar heeft de voorkeur
Opmerkingen mockup #31 ●
Belangrijk dat er heldere taal gebruikt wordt
●
Hecht waarde aan korte uitleg, bijvoorbeeld door middel van een tekstballon
Opmerkingen mockup #32 ●
Motivatie nuttig
●
Prioriteiten wederom handiger
Opmerkingen mockup #33 ●
Wil graag voorbeelden zien van hoe iets goed gedaan kan worden
Opmerkingen mockup #41 ●
Wil de mogelijkheid om aanbevelingen te verbergen of een lagere prioriteit te geven
Meta-informatie enquête: ●
Bereid om dat in te vullen, als het maar meer bezoekers op kan leveren.
●
Ook herhalen is prima, als dit de aanbevelingen kan verbeteren.
●
Kan antwoord geven op de enquêtevragen, mits geholpen door het systeem. Door bijvorbeeld selectieboxen met mogelijke antwoorden.
19
B.2 Interview BestHotelOffers datum dinsdag 13 November 2012 tijd 14:00 - 15:00 locatie Huizen geïnterviewde Martijn Lindeman
Achtergrond informatie gebruiker: ●
Redelijk ervaren met statistiekenpakket van Google, “Google Analytics”.
●
Zeer ervaren met Google AdWords
●
Maakt geen gebruik van de oude statistiekmodule
●
Maakt veel gebruik van conversierapporten externe partners
●
Doet weinig/niets voor meer organisch bezoeken
●
Maakt gebruik van SEO-tool woorank.com
Opmerkingen mockup #1 ●
Hogere score halen werkt aanstekelijk
Opmerkingen mockup #2 ●
Indicatie maken zitten risico’s aan vast
●
Vindt het belangrijk dat aangegeven wordt hoeveel tijd nodig is om een resultaat te behalen
●
Opdelen in lange-/kortetermijnoplossingen
Opmerkingen mockup #21 ●
Progress bar heeft de voorkeur
●
Doelstellingen invullen per tijd die ervoor nodig is
●
Waar komt een aanbeveling vandaan als er al aan voldaan wordt bijvoorbeeld een call-toaction
●
Wil prioriteiten in kunnen stellen
20
Opmerkingen mockup #31 ●
Motivatie en uitleg beide nuttig voor beginnende gebruikers
Opmerkingen mockup #41 ●
Kan doelstelling zelf opstellen
Opmerkingen mockup #42 ●
Grafiek geeft misschien niet veel weer
●
Doelstellingen zouden gewogen moeten worden (0-10)
●
Tevens gewogen aanbevelingen
●
Wil prioriteit per aanbevelingen
●
Verloop per dag wel erg kort, instelbare termijn nuttiger
Meta-informatie enquête: ●
Bereid om dat in te vullen, als het maar meer bezoekers op kan leveren.
●
Ook herhalen is prima, als dit de aanbevelingen kan verbeteren.
●
Kan antwoord geven op de enquêtevragen, mits geholpen door het systeem, door bijvoorbeeld keuzevelden.
●
Onderscheid maken in termijn voor enquête
21
B.3 Interview 16-11 I-Matic datum vrijdag 16 November 2012 tijd 14:00 - 15:00 locatie Leiden geïnterviewde Martijn de Kruyf
Achtergrond informatie gebruiker: ●
Enige ervaring met Google Analytics/vooral vorige versie
●
Geen ervaring Google AdWords
●
Maakt geen gebruik van de huidige statistiekmodule
●
Heeft zelf wel eens wat SEO gedaan, voor eigen website
Opmerkingen mockup #1 ●
Het spelelement werkt wel aanstekelijk
●
Groot gedeelte SEO kunnen gebruikers zelf uitvoeren
Opmerkingen mockup #21 ●
Vindt een pie chart meer aanspreken
●
Duidelijk doelstellingen te zien
●
Wederom spelelement om streven te halen
Opmerkingen mockup #42 ●
Wil wanneer een belangrijke doelstelling bereikt is dat zien, eventueel door kleur toe te voegen
●
Vraagt zich af welke doelstellingen je zou kunnen hebben
●
Hulpomgeving met meer informatie zeer nuttig
Meta-informatie enquête: ●
Is bereid om tijd te investeren in eenmalige enquête
●
Kan antwoord geven op vooraf bepaalde vragen
●
Merkt op dat veel afhangt van de website content 22
BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Technical Design Document Matthijs van Dorth 1265911 Arno de Bruijn 1262467
Bedrijf: Technische Universiteit Delft: Datum:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica 11-12-2012
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Voorwoord Na een uitgebreide oriëntatie en het opstellen van de requirements kunnen nu de technische details uitgewerkt worden. Dit rapport zal het technische ontwerp omschrijven aan de hand van de requirements. Dit rapport bevat alle diagrammen die nodig zijn bij de implementatie en dienen daarbij als handvat voor het verdere verloop van dit project.
Samenvatting De module die gebouwd gaat worden leent zich in theorie goed voor een Model-View-Controllerontwerppatroon. Ook al wijkt de praktijk hier deels vanaf is deze simplificatie een handige afspiegeling van de implementatie. In het Model wordt de structuur van de database vastgelegd. In dit model worden de databasetabellen en onderlinge verbanden vastgelegd. In de View wordt vastgesteld wat de user interface zal bevatten. De View is echter al gedeeltelijk vastgesteld door middel van de mockups die voor de interviews zijn gemaakt, de View is dan ook hierop gebaseerd. In de Controller wordt het expertsysteem geïmplementeerd met daarin de inference engine en de knowledge base.
2
Inhoud Voorwoord .......................................................................................................................................... 2 Samenvatting....................................................................................................................................... 2 1. Introductie ....................................................................................................................................... 4 2. Architecture ..................................................................................................................................... 5 2.1 CMS-structuur: .......................................................................................................................... 5 2.2 Model View Controller: ............................................................................................................. 6 2.3 Overview:................................................................................................................................... 6 3. Model .............................................................................................................................................. 7 3.1. Databasetabellen...................................................................................................................... 7 3.2. Externe Data ............................................................................................................................. 9 4. View ............................................................................................................................................... 10 4.1. Dashboard .............................................................................................................................. 10 4.2. Enquête .................................................................................................................................. 10 4.3. Doelstellingen ......................................................................................................................... 10 4.4. Aanbeveling ............................................................................................................................ 10 5. Controller....................................................................................................................................... 11 5.1 Rules: ....................................................................................................................................... 11 5.2 Working Memory: ................................................................................................................... 12 5.3 Inference Engine ...................................................................................................................... 12 Bijlage A: Overzicht metrics............................................................................................................... 13 Bijlage B: Definitie metrics ................................................................................................................ 14 Bijlage C: Klassendiagram .................................................................................................................. 16
3
1. Introductie In de komende hoofdstukken zullen we de verschillende onderdelen die de nieuwe module gaat bevatten verder specificeren. In hoofdstuk 2 zullen we een overzicht geven van de huidige structuur van het CMS en een overzicht hoe de nieuwe module eruit gaat zien en hoe dit in het CMS past. In hoofdstuk 3 zal in worden gegaan op het Model onderliggend aan de module. De database zal een belangrijke rol spelen binnen deze module. In hoofdstuk 4 zal in worden gegaan op de verschillende elementen die in de user interface terug te vinden zullen zijn. In hoofdstuk 5 zal het ontwerp van het expertsysteem zelf worden gegeven.
4
2. Architecture 2.1 CMS structuur: Globaal bestaat het CMS van Content Power uit drie packages: BB, CBB en MBB (zie het overzicht hieronder). De door ons ontwikkelde module zal zich voornamelijk binnen de CBB package bevinden. In bijlage A vind u het package diagram met de klassen die zich binnen deze package bevinden. Building blocks (BB) Deze package bevat klassen van veelgebruikte functionaliteiten. De building blocks kunnen los van het CMS gebruikt worden op websites. Door een instantie van de klasse aan te maken, een aantal methodes in te stellen en vervolgens via een methode de HTML op te vragen, wordt hiervan gebruik gemaakt. Deze package bevat bijvoorbeeld klassen voor het versturen van mailtjes, opbouwen van formulieren op websites, maken van menu’s, maken van stappenwizards, pop-ups, et cetera. CMS Building blocks (CBB) Deze package bevat alle klassen die nodig zijn voor een correcte werking van het CMS, zoals bijvoorbeeld het opvragen van informatie uit de database, weergave voor modules in het CMS. Verder bevat CBB de klassen die de volledige CMS-functionaliteit mogelijk maken. De CBB-klassen maken soms gebruik van de algemene klassen uit BB. Maatwerk Building blocks (MBB) Deze package is voor elke website verschillend opgebouwd. Aan deze package kunnen klassen worden toegevoegd die de werking van klassen in BB en CBB automatisch overerven. Op deze manier is het mogelijk om elke website volledig naar de wensen van de klant in te richten, door methodes uit de objecten van BB en CBB te overerven.
5
2.2 Model View Controller:
De module leent zich bij uitstek om gebruik te maken van een Model View Controllerontwerppatroon. Door gebruik te maken van dit ontwerppatroon is de software eenvoudiger uit te breiden en bevordert het de leesbaarheid van de code. Tevens is het tijdens de implementatie mogelijk om beiden aan verschillende onderdelen te werken zonder elkaar echt in de weg te zitten. Op papier zou dit ontwerppatroon dan ook goed moeten werken. Vanuit Content Power werd aangegeven dat het CMS zelf ook opgebouwd is met MVC in gedachten. Echter bleek in de praktijk dat de exacte scheiding niet altijd gehandhaafd kon worden. Ons werd aangeraden om het MVContwerppatroon alleen als leidraad te nemen. 2.3 Overview: De gehele module zal er globaal uit komen te zien als op onderstaand plaatje. In hoofdstuk 5 vindt u een gedetailleerd overzicht van het functioneren van het expertsysteem.
Figuur 1: opbouw module.
6
3. Model 3.1. Databasetabellen
Figuur 2: databasemodel. StatsExpertTargets In deze tabel worden de doelstellingen die de gebruiker heeft ingevoerd aan de hand van een formulier opgeslagen. De MetricType en Operator worden uit andere tabellen gehaald. Verder moet nog een prioriteit, een start- en einddatum en een doelstelling worden meegegeven. De huidige iCurrent en bAccomplished variabelen worden door het systeem opgezocht en opgeslagen. StatsExpertRecommendation In deze tabel worden de recommendations geplaatst die door het expertsysteem zijn gedaan. De tabel bestaat uit een link van de tabel StatsExpertAction van waar uit de recommendations zijn gemaakt, een prioriteit en een pagina waarop de aanbeveling betrekking op heeft. Daarnaast bevat de tabel een kolom met booleans die aangeeft of de aanbeveling zichtbaar is op het dashboard of dat deze onzichtbaar is gemaakt door de gebruiker. StatsExpertRecommendationUitleg In deze tabel wordt per voorgedefinieerde recommendation een uitleg geplaatst over hoe een aanbeveling uitgevoerd kan worden. Deze tabel bestaat uit de link naar de recommendation, een stapnummer, een uitleg over wat er in deze stap uitgevoerd moet worden en eventueel een plaatje met daarin een visual waarin deze stap uitgelegd wordt.
7
StatsExpertRule In deze tabel worden de rules opgeslagen voor het expertsysteem. Een rule bestaat uit een conditie en een actie. Deze combinatie is uniek in de tabel. Hieraan behoort verder nog een prioriteit en een vertrouwen dat aan de rule gegeven wordt en een boolean dat aangeeft of de rule geactiveerd is. StatsExpertEnquete In de tabel StatsExpertEquete komen de resultaten van de enquête terecht. Deze tabel bevat een variabelenaam, een operator, een waarde en de groepering waarop de variabele betrekking op heeft. StatsExpertStatsData In deze tabel worden de statistieken opgeslagen die voortkomen uit de verschillende statistiektabellen. Op deze manier hebben alle statistieken een uniforme weergave en kan het vanuit een tabel gebruikt worden in het expertsysteem. De tabel heeft een MetricType afkomstig uit een andere tabel, eventueel een start- en einddatum, wanneer deze nodig is een paginaId die aangeeft of het over een individuele pagina gaat of over de site in zijn geheel en de huidige waarde die hierbij hoort. Hulptabellen Er zullen een aantal hulptabellen gemaakt worden die de tabellen aan elkaar linken en ervoor zorgen dat in bepaalde kolommen slechts een aantal waarden mogen voorkomen. ● ● ● ● ● ● ● ●
StatsExpertMetricTypes ○ Hierin staan de typen metrics die gebruikt mogen worden StatsExpertOperator ○ Hierin staan alle verschillende operators die gebruikt kunnen worden StatsExpertAction ○ Dit zijn alle mogelijke acties die kunnen voortkomen uit de rules StatsExpertCondition ○ Dit zijn alle condities die mogelijk zijn in de rules StatsExpertPaginaGroepering ○ Het type pagina behorend bij een Metric StatsExpertVariable ○ De mogelijke variabelen die in een conditie kunnen voorkomen StatsExpertFact ○ De mogelijke facts die in een conditie kunnen voorkomen StatsExpertTypeWebsite ○ Het type website instelbaar in de enquête
8
3.2. Externe Data In de module zullen we gebruik maken van de huidige statistieken die reeds opgeslagen worden. Omdat daar op dit moment nog niet heel veel mee gedaan wordt zullen we zelf nieuwe queries moeten maken die aan de hand van deze statistieken metrics berekenen. Deze data zullen opgeslagen worden in StatsExpertStatsData. De data die daarin worden opgeslagen is afkomstig van de volgende reeds bestaande tabellen: ● ● ● ● ● ●
sStatsHit sStatsIp sStatsItem sStatsReferer sStatsSession sStatsUrl
9
4. View 4.1. Dashboard Zodra de module wordt geopend vanuit het beheergedeelte in het CMS wordt de dashboard getoond. Dit dashboard is gebaseerd op de layout van mockup #21. De progressiebalk die getoond wordt laat een percentage, een score zien van de verhouding van reeds behaalde doelstellingen en het totaal aantal doelstellingen gewogen naar prioriteit. Daaronder wordt een lijst getoond met de vijf belangrijkste aanbevelingen. Deze aanbevelingen worden gegenereerd door het expertsysteem en zijn gesorteerd naar prioriteit. Zoals gedefinieerd is in de requirements moeten deze aanbevelingen ook weggeklikt kunnen worden zodra de beheerder vindt dat deze niet van toepassing is op de site. Zodra de gebruiker op het kruisje klikt wordt de aanbeveling verborgen. 4.2. Enquête Wanneer de gebruiker de enquête opent, wordt er een pop-up getoond met daarin vragen over de inhoud van de website. De antwoorden op deze vragen worden in de tabel cStatsExpertEnquete opgeslagen zodat deze als feiten kunnen worden gebruikt in het expertsysteem. 4.3. Doelstellingen Zodra geklikt wordt op de progressiebalk zoals getoond is in mockup #21, wordt een nieuw scherm getoond zoals in mockup #41. Op dit scherm worden de doelstellingen getoond in drie categorieën. Deze categorieën zijn: behaalde doelstellingen, niet-behaalde doelstellingen en inactieve doelstellingen. De inactieve doelstellingen zijn doelstellingen met een prioriteit van 0 of waarvan de perioden niet binnen het huidige tijdstip liggen. Binnen dit scherm worden nog een paar functionaliteiten toegevoegd. Zo zal het mogelijk zijn om nieuwe doelstellingen toe te voegen, doelstellingen te wijzigen en doelstellingen te verwijderen. 4.4. Aanbeveling Zodra op een aanbeveling is geklikt wordt het scherm getoond dat ongeveer overeenkomt met mockup #31. Bovenin het scherm wordt de aanbeveling nog een keer getoond. Daaronder zal een uitleg worden weergegeven samen met een visual die bij deze uitleg hoort. Zodra op een van de verschillende stappen wordt geklikt wordt een andere visual getoond die bij deze stap hoort.
10
5. Controller Het expertsysteem functioneert in de module als Controller. Deze kan onderling verdeeld worden in de volgende onderdelen:
Figuur 3: onderdelen expertsysteem.
Overzicht expertsyteem: ●
●
Knowledge base ○ Rules ○ Working memory Inference engine ○ Pattern matching ○ Select rules ○ Execute rules
Er vindt dus een strikte scheiding plaats tussen de “kennis” in de knowledge base en de logica in de inference engine. Ook de kennis in de knowledge base kan onderverdeeld worden in enerzijds de productiekennis van de rules en anderzijds de domeinkennis in de working memory. Onderstaand zullen we uitleggen wat elk onderdeel doet.
5.1 Rules: De regels bevatten de ‘expert’-kennis in de vorm van zogenoemde if-then statements. Met in het antecedent één of meerdere condities en in het consequent één of meerdere acties. 1...n
condition
->
1...k
action
De condities moeten allen als ‘waar’ evalueren voordat de rule kan vuren. Als een rule daadwerkelijk uitgekozen wordt om te vuren dan worden alles acties behorende bij deze rule uitgevoerd. Een actie kan nieuwe feiten genereren in de working memory, of een aanbeveling doen.
11
Nieuwe aanbevelingen worden in de tabel cStatsExpertRecommendation geplaatst, zodat deze in de interface makkelijk uitgelezen kunnen worden. De rules zelf worden in de tabel cStatsEpertRule opgeslagen, met daarin per rule afzonderlijke links naar de bijbehorende condities in de tabel cStatsExpertCondition en de bijbehorende acties in de tabel cStatsExpertAction. De regels zijn op deze wijze opgeslagen omdat het de gebruikelijke manier van opslag is binnen Content Power en er toch geen staat van de regels onthouden hoeft te worden na executie van het aanbevelingensysteem.
5.2 Working Memory: De working memory dient om de staat van feiten tijdens executie van het expertsysteem bij te houden. De working memory bevat tijdens initialisatie: ● ●
de gemeten metrics. alle feiten verkregen uit de domeinenquête.
Wanneer het expertsysteem gaat draaien kunnen er nieuwe feiten gegenereerd worden aan de hand van de acties van regels waarvan aan alle condities voldaan wordt. De condities van deze regels worden precies getoetst aan alle feiten beschikbaar in de working memory. Tijdens executie kunnen er dus nieuwe feiten toegevoegd worden en oorspronkelijke feiten van waarde veranderen.
5.3 Inference Engine Het is vervolgens aan de inference engine om juist die regels te kiezen die moeten vuren. Zoals eerder gezegd kan een regel pas in aanmerking komen om te vuren dan en slechts dan aan al zijn condities voldaan wordt. De inference engine bevat dan ook een methode die voor een gegeven regel kan kijken of deze actief kan zijn aan de hand van de huidige staat van de working memory. Alle actieve regels worden in de agenda geplaatst. Vervolgens moet gekeken worden welke van de regels in de agenda daadwerkelijk gaat vuren. Dit gebeurt aan de hand van de onderlinge prioriteiten toegekend aan de regels. De regel met de hoogste prioriteit vuurt als eerst. Indien er meerdere regels zijn met dezelfde prioriteit vuurt de regel die het eerst in de agenda geplaatst is. Er zijn meerdere van deze conflict resolution-methoden beschikbaar. Wij hebben voor deze eenvoudige opzet gekozen zodat het aan de expert is om te bepalen welke regels een hogere prioriteit moeten hebben ten opzichte van andere. Vervolgens moet de regel daadwerkelijk vuren. Wanneer een regel vuurt wordt naar al zijn acties gekeken. Al deze acties worden één voor één uitgevoerd. Een actie kan feiten toevoegen of veranderen in de working memory of een aanbeveling voor de website wegschrijven. Nadat er een regel gevuurd heeft start de select-execute loop weer opnieuw. Deze loop stopt wanneer er geen nieuwe regels meer kunnen vuren. Er zijn dan immers geen nieuwe feiten meer te ontdekken, waardoor het systeem in evenwicht is.
12
Bijlage A: Overzicht metrics type
pagina
visits pagevisits
tijdgebonden
X
X
X
hits pagehits
site
niettijdgebonden
X X
X
X X
bouncerate
X
X
uniquevisitors
X
X
avgtimeonsite
X
X
pagebouncerate
X
X
exitratepage
X
X
avgtimeonpage
X
X
talencount
X
X
aantalzoekwoordeningesteld
X
X
wordcount
X
X
descriptionlength
X
X
languageset //1 waar; 0 niet waar
X
X
customurlset //1 waar; 0 niet waar
X
X
titleset
X
X
13
Bijlage B: Definitie metrics Visits Met visits wordt het aantal verschillende bezoekers op de website of pagina bedoeld. Een visit op de site is een doorlopend bezoek van een gebruiker binnen één sessie. Een sessie is een opeenvolgend bezoek van één of meer pagina's door dezelfde bezoeker. Hits Het aantal hits is hier gedefinieerd als het aantal keren dat een pagina of een ander item op de site wordt weergegeven door een bezoeker. Als een bezoeker een bepaalde pagina meerdere keren bezoekt zullen al die keren als hits meetellen. Bouncerate Het percentage bezoekers dat een pagina bezoekt en de site gelijk weer verlaat. Binnen een sessie wordt dus een enkele pagina bekeken. Hierbij wordt de bounce rate van alle pagina’s van de site samengenomen. Uniquevisitors Het aantal unieke bezoekers is niet exact te berekenen. Dit komt omdat het niet is toegestaan om individuele bezoekers te tracken. Wij doen een schatting door te tellen hoeveel verschillende IPadressen met een bepaalde browser de site hebben bezocht. Avgtimeonsite Ook de gemiddelde tijd die een bezoeker op de site doorbrengt is niet exact te berekenen. Dit is omdat alleen kan worden opgeslagen wanneer een pagina wordt opgevraagd door een bezoeker. Daardoor is niet te meten hoe lang een bezoeker de allerlaatste pagina heeft bekeken. Wij doen een schatting naar de gemiddelde tijd door de gemiddelde tijd te nemen van alle sessies van het opvragen van de eerste pagina tot de allerlaatste. De meting is daardoor een onderschatting. Pagebouncerate Dit is hetzelfde gedefinieerd als de bounce rate echter is dit nu per pagina gemeten. Daarmee kunnen verschillen in bounce rate van de pagina’s gemeten worden en is te zien of bepaalde pagina’s er uitschieten. Exitratepage Met de exit rate van een pagina wordt bedoeld het percentage dat na het bekijken van deze pagina geen andere pagina meer bekijkt op de site. Dit is dus het percentage dat afhaakt van de site na het zien van deze pagina. Avgtimeonpage Wanneer een gebruiker op een site meerdere pagina’s bekijkt wordt van elke pagina afzonderlijk opgeslagen op welke tijdstip dat gebeurt. De tijd dat een bezoeker op een pagina doorbrengt wordt gemeten door het verschil te nemen tussen de tijdstippen wanneer de bezoeker twee opeenvolgende pagina’s opvraagt. Hierbij wordt het verschil genomen waarbij de exits die vanaf de pagina voorkomen niet worden meegerekend. Talencount Binnen het CMS kunnen verschillende talen worden ingesteld waardoor bezoekers de site in verschillende talen kunnen lezen. Deze metric geeft het aantal talen weer van de site. 14
Aantalzoekwoordeningesteld Deze metric maakt gebruik van de Google indexer module. Dit is het aantal zoekwoorden die zijn ingesteld in de Google indexer module. Wordcount Deze metric telt het aantal woorden op een pagina. Hiervoor wordt gekeken in de teksten ingesteld door de websitebeheerder. Descriptionlength De description length telt het aantal karakters van de description tag in de meta tags van een HTMLpagina. De description tag wordt onder andere gebruikt door Google om een korte samenvatting te geven van een pagina. Languageset Deze metric geeft aan of binnen de HTML van een pagina is aangegeven in welke taal de teksten geschreven zijn. Dit helpt onder andere Google om te zien in welke taal de pagina geschreven is. Deze metric geeft FALSE ofwel 0 terug als dit niet zo is, anders true. Customurlset Een custom URL is een leesbare naam van een URL. Dus in plaats van “site.com/page8757/” is de URL bijvoorbeeld in de vorm van “site.com/news/”. Zo is het duidelijker wat voor informatie op de pagina staat. Deze metric geeft FALSE ofwel 0 terug wanneer URLs niet op deze manier zijn beschreven, anders wordt er TRUE geretourneerd.
15
Bijlage C: Klassendiagram
Figuur 4: klassendiagram.
16
BSc-project: Geautomatiseerde webstatistiekanalyse & websiteprestatie-indicatie “Hoe kunnen beheerders die gebruik maken van het Content Management Systeem van Content Power een beter inzicht krijgen in de acties van bezoekers?”
IN3405 Bachelorproject - Testplan Matthijs van Dorth 1265911 Arno de Bruijn 1262467
Bedrijf: Technische Universiteit Delft: Datum:
Content Power Faculteit Elektrotechniek, Wiskunde en Informatica 22-10-2012
Commissie: Begeleider Content Power: Begeleider TU Delft: Coördinator BSc:
Jan Niemantsverdriet M.A. Larson H.G. Gross
1
Samenvatting Om een zo goed mogelijk product af te leveren zullen wij de nieuwe module goed moeten testen. Verschillende soorten tests moeten worden uitgevoerd. Tijdens het implementeren zullen we unittests uitvoeren om de code te controleren op fouten. Na afloop van de implementatiefase zullen we een gebruikerstest uitvoeren met enkele toekomstige gebruikers waarin we de gebruiksvriendelijkheid willen testen. Ondanks zorgvuldig te werk gaan en uitvoerig te testen bestaan er zoals bij elk softwareproject bepaalde risico’s. Deze risico's zullen in dit document ook beschreven worden.
2
Inhoud Samenvatting ...................................................................................................................................... 2 1. Introductie ...................................................................................................................................... 4 2. Implementatietest .......................................................................................................................... 5 2.3 Testen van Expertsysteem ........................................................................................................ 5 2.4 Testen van User Interface ......................................................................................................... 6 2.5 SIG ............................................................................................................................................. 6 3. Gebruikerstest................................................................................................................................. 7 4. Performance Testing ....................................................................................................................... 8 5. Risico’s............................................................................................................................................. 9 5.1 Usability..................................................................................................................................... 9 5.2 Technisch .................................................................................................................................. 9 5.3 Juridisch..................................................................................................................................... 9 5.4 Expertkennis.............................................................................................................................. 9 6. Afronding ...................................................................................................................................... 10
3
1. Introductie Om het eindproduct zo goed mogelijk te kunnen laten functioneren zal deze goed getest moeten worden. Dit is nodig om de software te laten functioneren zoals wij dit gespecificeerd hebben in eerdere documentatie. Door goed te testen willen we de kans dat er iets fout gaat bij het gebruik van deze software minimaliseren. In dit rapport zullen wij uiteenzetten hoe wij dit gaan aanpakken. Het testen zal bestaan uit twee delen. In het eerste deel zullen wij beschrijven hoe wij de code gaan testen. Dit zal ervoor moeten zorgen dat de kans op fouten of onverwachte output tijdens het uitvoeren van de software zo laag mogelijk is. Het tweede deel van het testen bestaat uit de gebruikerstest. In deze test zullen wij enkele toekomstige gebruikers vragen de software te gebruiken en vragen wat ze ervan vinden en of alles duidelijk is. Dit zal vooral de gebruiksvriendelijkheid van de software testen.
4
2. Implementatietest De implementatietest zal voornamelijk tijdens het implementeren gedaan worden. Deze tests zullen vooral bestaan uit unit-tests. In de unit-tests zullen steeds kleine stukken code getest worden, zoals een enkele methode of een klein deel daarvan. Het is de bedoeling dat zo goed als elk stukje code gecoverd wordt door een unit-test. Er zal geen gebruik worden gemaakt van een bepaald framework voor het doen van deze unit-test maar we zullen dit doen op de manier zoals dat bij Content Power het gebruik is. Er zal veel gebruik worden gemaakt van het error object dat aanwezig is binnen het huidige CMS. Dit kan helpen fouten op te sporen bij het doen van asserts.
2.1 Statistieken Zoals aangegeven is in het TDD wordt veel gebruik gemaakt van databases. Eén van de bronnen van data die wij gebruiken zijn de statistiektabellen die al in het huidige systeem zitten. Veel van de queries en methoden die wij ontwikkelen maken gebruik van deze data. Vervolgens wordt deze data bewerkt en opnieuw in een tabel gezet. Deze aanpak van het gebruik van tabellen als in-en uitvoer heeft voor ons als groot voordeel dat wij de unit-test in de database kunnen zetten. In de tabel waar wij de data vandaan halen kunnen wij zelf een aantal testdata zetten en deze na uitvoer van de methodes controleren in de uitvoertabel. Er zullen een aantal testmethoden gemaakt worden die deze testdata in de verschillende invoertabellen zullen zetten.
2.2 Enquête Een andere bron van data die gebruikt wordt komt uit een vragenlijst die door de gebruiker is ingevuld. Deze zogenoemde domeinkennis is nodig om de gebruiker aanbevelingen te doen die daadwerkelijk nuttig kunnen zijn. Ook deze data komt in een tabel te staan. Ook hierbij zullen wij gebruik maken van een aantal verschillende testdatasets om de verschillende mogelijkheden die bestaan binnen de vragenlijst te testen.
2.3 Testen van Expertsysteem Het expertsysteem zal getest worden met een aantal testregels. Deze testregels zullen bepaalde condities hebben die wel of niet gelden. Deze testregels zullen één of meer condities bevatten met daarbij één of meer acties. De condities worden zo gekozen dat deze voor verschillende sites en pagina’s een ander resultaat geven. Zo ontstaat een set van diverse regels waarbij alle verschillende combinaties getest worden. De uitkomsten hiervan zullen in de recommendations-tabel terechtkomen. Gezien er met een klein aantal pagina’s gewerkt wordt in de testset kan eenvoudig worden gezien of de juiste acties zijn uitgevoerd.
5
2.4 Testen van User Interface De visualisaties zullen gebaseerd worden op de inhoud van de aanbevelingen van het expertsysteem, de behaalde en niet behaalde doelstellingen en eventueel de statistieken. Elk van deze onderdelen is al individueel getest en zal enkel nog in combinatie getest moeten worden. Het testen van de gebruikersinterface zal dan vooral bestaan uit het nagaan of de juiste items geplaatst worden en daarbij de juiste visualisaties komen te staan. Dit zal ook gedaan worden aan de hand van een aantal eigen ingevoerde testdata. Ook zullen we testen of de interface goed werkt op verschillende browsers. Omdat we wel een aantal nieuwe technieken gebruiken zullen we hierbij echter alleen recente browsers testen, te weten Firefox 16, Chrome en IE9.
2.5 SIG De code zal tweemaal gecontroleerd worden door de Software Improvement Group. De eerste keer zal zijn nadat het eerste prototype van de module af is en de tweede keer aan het eind van het hele traject. De SIG zal de code controleren aan de hand van een checklist waarbij gekeken wordt naar bepaalde algemene coding guidelines, opbouw van de klassen en methoden en leesbaarheid.
6
3. Gebruikerstest Een belangrijk onderdeel van de testfase, gezien onze requirements gesteld met betrekking tot de usability, zal de gebruikerstest zijn. In de gebruikerstest willen we enkele toekomstige gebruikers het systeem laten testen. Als kandidaten daarvoor zouden we graag de klanten van Content Power willen vragen waarmee we al een eerder interview hebben gehad. Deze klanten hebben daardoor al wel een idee van het doel van deze module en kunnen daardoor wellicht net iets betere feedback geven. Echter kan deze gebruikerstest pas gedaan worden als de module zo goed als af is en dus zal er na deze tests niet al te veel tijd meer zijn om hele grote aanpassingen te doen. Deze test is echter wel erg belangrijk voor ons want hieruit zal blijken of de klanten deze nieuwe module daadwerkelijk nuttig vinden en vaker zullen willen gaan gebruiken. De gebruikerstest zal bestaan uit twee delen. In het eerste deel zetten wij de gebruiker de module voor en vragen wij de gebruiker een aantal acties uit te voeren. Deze acties kunnen bestaan uit onder andere het invullen van een vragenlijst, het bekijken van behaalde en niet behaalde doelstellingen en het bekijken van een aantal aanbevelingen. In het tweede deel zullen wij nog een zeer kort interview afleggen waarin we terugkomen op de stappen die de gebruiker heeft gemaakt en vragen wat hij/zij ervan vond en wat er eventueel nog verbeterd kan worden. De gebruikerstest zal plaatsvinden na afloop van de implementatiefase. Op deze manier kan de gebruiker een zo compleet mogelijk beeld krijgen van de module.
7
4. Performance Testing Tijdens het implementeren gebruiken we steeds kleine sets aan data. Dit heeft als voordeel dat we snel kunnen controleren of de methoden binnen het systeem werken. Hoe het uiteindelijk in de praktijk zal werken waarin echte data wordt gebruikt met statistieken uit de database zal moeten blijken uit de performance test. In de performance test zal echte data van een website gebruikt moeten worden om te kijken hoe zwaar bepaalde queries zijn. Dit zal ook bepalen hoe vaak bepaalde scripts uitgevoerd mogen worden. Aangezien tijdens de implementatie met een kleine set zal worden gewerkt zal ook nog getest moeten worden hoe de module presteert op websites met meer pagina’s en een groter volume aan bezoekers. De module zal daarom worden uitgerold op minimaal twee websites en zal er opnieuw getest worden. Deze keer zal er ook met een grotere set van echte regels worden getest, zodat dit een goed beeld geeft van hoe de module in een ‘live’ omgeving presteert.
8
5. Risico’s Zoals bij elk software project het geval is brengt ook dit project bepaalde risico’s met zich mee. In dit hoofdstuk zullen wij de grootste en belangrijkste risico’s aangeven.
5.1 Usability Het grootste risico ligt wat ons betreft bij de gebruiker. De software zal gebruiksvriendelijk moeten zijn anders zal de gebruiker snel afhaken. Daarnaast zal de gebruiker het idee moeten hebben dat de aanbevelingen daadwerkelijk iets toe zullen voegen aan zijn website, want ook dan zal de gebruiker snel stoppen met het gebruik van de module. 5.2 Technisch Een belangrijk aspect is hoe de berekeningen voor het systeem gedaan worden. Alhoewel wij verwachten dat dit goed zal gaan bestaat er een kleine kans dat, zeker bij grote sites met heel veel bezoekers, bepaalde berekeningen niet haalbaar zijn binnen een redelijke tijd. 5.3 Juridisch Onlangs is in Nederland nieuwe wetgeving van kracht gegaan dat verbiedt individuele bezoekers te tracken. Alhoewel op dit moment binnen de module geen individuele gebruikers worden getoond, worden er wel statistieken bijgehouden van gebruikers in het algemeen. Indien bepaalde regelgevingen nog strenger worden, zullen bepaalde onderdelen van het systeem in strijd zijn met de wetgeving. 5.4 Expertkennis Het expertsysteem staat of valt natuurlijk met de rules die zijn opgesteld door een expert. Deze rules zullen moeten kloppen, maar ook van tijd tot tijd moeten worden bijgewerkt. Als de rules niet kloppen of niet volledig zijn zal het expertsysteem nooit goede aanbevelingen kunnen doen.
9
6. Afronding De uitkomsten van alle verschillende tests zullen worden gerapporteerd in het Testrapport. Met betrekking tot de implementatietests zullen we voorbeelden geven over hoe we hebben getest, eventueel met wat voorbeeldcode. Van de gebruikerstesten zullen we een rapportage geven van wat er tijdens deze testen is gebeurd en welke feedback we van de gebruikers kregen. Dit rapport bevat tevens de feedback van de Software Improvement Group. Het bepalen van de behaalde eisen die gesteld zijn in het Requirements & Analysis Document zal gedaan worden in het Eindverslag.
10
