Gebruiksstatistieken... weet wat je meet!

Ik heb deze week een flink deel van de dag met mijn hoofd in Excel gezeten. Niet dat ik plotseling een management functie ambieer, maar omdat ik een goed (beter) beeld wilde hebben van het gebruik van een bepaalde SharePoint omgeving. Dit om een goede inschatting te krijgen van de hoeveelheid verkeer die ik kan verwachten op een applicatie die vanuit een SharePoint webpagina wordt aangesproken.

Ook een mooie gelegenheid om eens wat gedachten over web statistieken op een rijtje te zetten.

Allereerst antwoord op de vragen:
- Wat meten we?
- Waarom meten we?

Wat meten we?
Als een gebruiker (bezoeker) een web adres in zijn browser intypt dan legt de browser contact met de webserver waar de betreffende website is ondergebracht. Tijdens dit contact (request) worden gegevens over het verzoek door webserver vastgelegd in een logbestand. Dit is onder anderen wie het verzoek doet, welke bestanden hij opvraagt en wanneer de aanvraag is binnengekomen, maar ook zaken als het gebruikte besturingssysteem, de browserversie, etc.). Omdat een web pagina vaak bestaat uit een tekstbestand (HTML) waarin ook zaken als plaatjes voorkomen, zal de browser meerdere verzoeken doen aan de webserver: voor ieder bestand 1 request. Een webpagina waarin 3 plaatjes zijn opgenomen zal bijvoorbeeld 4 requests vergen: 1 voor de web pagina en 3 voor de plaatjes. Interactieve web pagina's, bijvoorbeeld waarin de eindgebruiker formulieren kan invullen en waarin ingevulde veldwaarden worden gecontroleerd, of web pagina's waarin illustraties elkaar afwisselen, zullen na het laden van de web pagina nog steeds requests aan de web server versturen voor additionele bestanden (plaatjes, controle resultaten, etc.).

Hier ontstaat een mogelijke verwarring: het verschil tussen hits en bezoekers.
Lang geleden, toen webpagina's, JavaScript en Perl-scripts nog met teksteditors werden geschreven, had ik een discussie met een business manager van een internet bedrijf over bezoek statistieken van een bepaalde web site. De sponsor van de web site werd maandelijks een rapport voorgeschoteld met daarin een uitspraak over de populariteit van deze web site en de de directeur was erop gebrand de getallen zo hoog mogelijk te laten uitvallen. In de logbestanden die ik moest analyseren maakte ik duidelijk verschil tussen het aantal hits (webpagina's, plaatjes, ander bestanden die door de browser werden opgevraagd) en bezoekers (toendertijd het aantal web pagina's dat werd opgevraagd). Het aantal bezoekers was natuurlijk aanmerkelijk lager en had niet de voorkeur van de betreffende directeur. Na uitleg van mij over wat precies werd gemeten werd de voorkeur enigszins aangepast door te sturen op het voorzien van de web pagina's van zoveel mogelijk plaatjes. Rest mij te zeggen dat ik hier niet aan heb meegewerkt :).

Ik wil met het bovenstaande voorbeeld overigens niet zeggen dat het meten van hits geen doel dient, want dat is geenszins het geval. Je moet alleen weten waarvoor je het kunt gebruiken, wat me brengt op het doel van het meten.

Web site of web applicatie?
Maar allereerst het volgende. In de onderstaande tekst heb ik het over web applicaties. Hieronder versta ik de verzamelnaam voor web sites (html, rss, etc.) en applicaties (b.v. apps) die gebruik maken van een web server.

Waarom meten we?
Grofweg kunnen de volgende doelen met meten worden nagestreefd:
- Meten van de populariteit van een produkt of dienst
- Meten van het gebruiksgemak van een web applicatie
- Meten van beschikbaarheid, prestaties en werklast van een web applicatie

Meten van de populariteit van een produkt of dienst
Dit is een breed doel, maar komt is essentie neer op het bepalen in hoeverre het produkt of de dienst die door de betreffende web applicatie ondersteunt interesse geniet van de internet gebruiker. Van belang hierbij zijn bijvoorbeeld hoeveel echte bezoekers de web applicaties krijgt, of deze bezoekers regelmatig terugkomen en welke handelingen de bezoekers uitvoeren. Dit laatste is natuurlijk het allerbelangrijkst: een bezoeker kan slechts de begin pagina bekijken, maar ook geinteresseerd rondkijken, en in het beste geval een of meerdere transacties afsluiten (lees: iets via de web applicatie aanschaffen).

Indirect is de populariteit trouwens het meten van de doeltreffendheid van de verwijzingen naar de betreffende web applicaties, bijvoorbeeld vanuit zoekresultaten en banners/advertenties. In het algemeen: wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat iets zeggen over de populariteit van de web applicatie en/of het ondersteunde produkt of de ondersteunde dienst. Wellicht is het gelinkte onderdeel zoveel gebruikt dat het een gemakkelijker te bereiken plaats in het menu verdient?

Aanvullende, belangrijke metingen kunnen natuurlijk gedaan worden door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).

Meten van het gebruiksgemak van een web applicatie
Hierbij gaat het om meetgegevens waaruit kan worden afgeleid hoe gebruiksvriendelijk de bezoeker de betreffende web applicatie vindt, ofwel: antwoord vinden op de vraag of de bezoeker zijn doel op een voor hem voldoende gemakkelijke manier kan bereiken. Wat hierbij belangrijk is te meten welke weg (klik- of zoekpad) de bezoeker aflegt voordat hij zijn doel bereikt, en dit te vergelijken met de optimale navigatie zoals die in het ontwerp van de web applicatie is bedacht.
Interessant hierin is ook het gebruik van de zoek faciliteiten de betreffende web applicatie. Ingevulde zoektermen, zoekresultaten verfijnen (b.v. door faceted search) en navigatie vanuit de zoekresultaten zeggen veel over de onderwerpen waarnaar de bezoeker naar op zoek is en de doelmatigheid van zijn zoektocht. Wellicht betekent veelvuldig gebruik van de zoekmachine naar een bepaalde term dat het onderwerp in kwestie slecht vindbaar is?

Ook wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat ook iets over het gebruiksgemak van de web applicatie. Wellicht is het gelinkte onderdeel dan ook lastig te vinden?

Gerelateerd aan het meten van het gebruiksgemak van een web applicatie is het meten van het gebruiksgemak van de wijze waarop de web applicatie wordt gevonden, bijvoorbeeld vanuit zoekresultaten en banners/advertenties.

Ook hierbij kunnen aanvullende, belangrijke, metingen natuurlijk worden gedaan door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).

Tenslotte zeggen foutmeldingen veel over het gebruiksgemak dat een bezoeker ervaart. Fouten als een "404" of "Not Found" (zie ook: HTTP 404) worden wel vastgelegd maar regelmatig niet meegenomen in bezoekstatistieken.

Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Deze categorie doelen heeft een duidelijk technische achtergrond.
Meten van beschikbaarheid van web applicaties (en de onderliggende diensten als servers, besturingssystemen, platforms etc.) is essentieel binnen web dienstverlening. Hierbij gaat het in essentie om het halen van gemaakte afspraken (SLA's) die over de web dienstverlening zijn gemaakt tussen de klant (business) en de IT-leverancier waarbij het meten van beschikbaarheid als onderbouwing kan worden gebruikt. Hierbij gaat het trouwens dus om hits in plaats van bezoekers, omdat de beschikbaarheid gemeten wordt van alle (technische) bronnen; HTML webpagina's, plaatjes, scripts, etc..
Een speciaal doel van het meten (zowel hits als bezoekers) is het bepalen van de werklast die een bepaalde web applicatie zal moeten kunnen verwerken of de werklast die een daaraan gerelateerde (gelinkte of geintegreerde) (web) applicatie zal moeten kunnen verwerken. Zie hiervoor ook mijn artikel over integratie: Platform integratie: functionaliteit onder handbereik.

Een paar voorbeelden ter illustratie...

Een web applicatie zal worden gemigreerd naar een nieuw platform
Hierbij zal bepaald moeten worden in hoeverre het nieuwe platform (en onderliggende soft- en hardware) voldoende geschaald is of schaalbaar is om de verwachtte werklast te kunnen verwerken. Een goede inschatting van het bezoek en het gebruik van bronnen (hits op bestanden) is hiervoor essentieel.

In een bestaande nieuws webpagina worden RSS feeds vanuit een andere bron weergegeven
In het algemeen: een web applicatie zal gebruik maken van een andere web applicatie, en hier dus web verkeer op genereren en daarmee de werklast van de andere web applicatie verhogen. Het is hierbij dus van belang om te weten om welke extra werklast het hier gaat. Bezoekersaantallen van de web applicatie (b.v. de nieuwspagina in het voorbeeld) zijn hierbij daarom van belang. Voor iedere bezoek wordt minimaal een request gedaan aan de andere web applicatie. Mocht de andere web applicatie de extra werklast niet kunnen verwerken, kan dat negatieve gevolgen hebben voor de web applicatie(s) die ervan gebruik ma(a)k(t)(en). Een web applicatie kan dan bijvoorbeeld trager functioneren of deels of geheel niet beschikbaar lijken te zijn.

Van belang bij het meten hiervan is onderscheid te maken tussen gemiddelde werklast en piekbelasting.

Valkuilen en praktische tips, een overzicht
Op basis van de bovenstaande doelen en praktische ervaringen, onderstaand een aantal belangrijke valkuilen en praktische tips.

- Houd het doel van de analyse goed in de gaten en gebruik de juiste metingen daarbij
Gaat het om populariteit, ga dan niet uit van hits. Gaat het om werklastbepaling, ga niet alleen uit van bezoekers, maar neem alle web verkeer mee in de analyse.

- In vakantieperioden is het aanmerkelijk rustiger dan in "normale" werkweken.
Daarnaast vieren we niet tegelijk onze vakanties; ons land is ingedeeld in regio's, dus als het in de ene regio een normale werkweek lijkt, kan een regio waar vakantie gevierd wordt, de hoeveelheid web verkeer omlaag brengen. Tenslotte zijn (dat is voornamelijk bij intranetten van belang) werkweken niet bij iedere organisatie dezelfde: soms wordt er bijvoorbeeld ook in het weekend gewoon doorgewerkt. Ga daarom uit van "normale" werk weken zoals die in de betreffende organisatie gelden.

- Bij het berekenen van gemiddelde - en piekbelasting moet je rekening houden met werkdagen, werktijden, pauzetijden, en andere bijzondere tijdsperioden.
In het algemeen zou rekening gehouden kunnen worden met een 8 urige werkdag waarin medewerkers eerder kunnen beginnen of later kunnen stoppen. Ik ga meestal uit van een 10 urige tijdsspanne. Gedurende pauzes en aan het begin en einde van de werkdag ontstaan vaak pieken of dalen in het webverkeer.

Pieken in web verkeer, vooral aan het begin van de dag, ontstaan doordat...

- ... bij het opstarten van de browser vaak meteen een standaard webpagina (b.v. de homepage van het intranet) wordt geladen.
Dit geeft een vertekend beeld van de populariteit van de homepage (en een piek in het webverkeer aan het begin van de dag). Dit webverkeer zal daarom buiten de populariteitsmetingen gehouden moeten worden, maar zal wel meegenomen moeten worden bij belastingmetingen. Let op: in de praktijk veelvuldig crashen van pc's en browsers zorgt eveneens voor een toename in webverkeer op de standaard ingestelde browser homepage.

- Spiders en monitors genereren ook webverkeer; filter dit verstandig uit. Een web server registreert alle requests vanuit alle bronnen. Naast browsers (die verzoeken namens gebruikers doen), worden requests ook automatisch gedaan door programmatuur. Voorbeelden hiervan zijn: monitors, spiders (bijvoorbeeld voor zoekmachines), maar ook: RSS newsreaders. Deze requests zijn herkenbaar aan de informatie die bij die requests aan de web server worden meegegeven zoals gebruikersnaam (zoals bijvoorbeeld service accounts in het geval van spiders op intranetten) en type client (b.v. browser / reader versie). Dergelijke requests zullen ook met de regelmaat van een klok plaatsvinden; op vaste dagen / tijdstippen.

Wat betreft web verkeer vanuit RSS readres: het opvragen van een (RSS) web pagina hoeft niet noodzakelijkerwijs te betekenen dat een nieuwsbron populair is. Een klik vanuit een RSS feed naar het achterliggende artikel zegt meer.

Wanneer een inschatting van belasting gemaakt moet worden, moet web verkeer van spiders, monitors, etc. meegenomen worden. Wordt de populariteit gemeten, dan kan dit verkeer er wellicht beter uit gefilterd worden of kan het web verkeer opgesplitst worden naar kanaal / device / type applicatie waarvan het afkomstig is.

- Meten van webverkeer op individuele pagina's zegt relatief weinig over de populariteit van een site of web pagina.
Wat meer zegt is het gedrag van de bezoeker; klikpaden, zoektermen, afsluiten van transacties, etc..

- Vergeet niet te meten wat er fout gaat.
Een bezoeker die regelmatig geconfronteerd wordt met fouten, haakt af. En dat kan nooit de bedoeling zijn.

Conclusie
Aanleiding voor het schrijven van dit artikel was dat ik deze week een flink deel van de dag met mijn hoofd in Excel heb gezeten. Waarom ik dat deed is dat ik twijfelde aan de bezoekstatistieken die ik in mooie diagrammen en overzichtjes vanuit een web statistiek software pakket kreeg voorgeschoteld en die normaliter voor waarheid werd aangenomen.

Mijn twijfel bleek terecht: een groot deel van de gemeten "populariteit" bleek veroorzaakt te worden door automatische bezoekjes van spiders en monitors.

Meten is weten, maar weet eerst wat je meet.