[Opgelost] Het grootste nadeel van een webanalyticspakket

vraagtekenDe meeste sites worden op dit moment gemeten met een webanalyticspakket. Maar wat gebeurt er daadwerkelijk met het webanalyticspakket? Wie logt er in? Waarom? Hoevaak? (trouwens, wie meet dat?) Bij veel bedrijven wordt het webanalyticspakket slecht gebruikt. Maar waarom? Wat is de reden dat webanalyticspakketten zo slecht gebruikt worden? Er zijn meerdere redenen voor (traagheid, veel klikken, altijd inloggen, etc), maar de belangrijkste is omdat de data in een webanalyticspakket niet te begrijpen is.

Oké, misschien chargeer ik, maar dit is wel waar het vaak mis gaat. Gebruikers van de pakketten (lees: analisten), weten nog net wat er gemeten wordt, maar collega’s, leidinggevenden en andere geïnteresseerden snappen er gewoon weinig van. Hoe komt dit? Pakketten zijn niet ingericht op de behoefte van de gebruiker, maar ingericht op de meetwaardes die gemeten worden. Dat is de reden dat je haast nooit direct antwoord krijgt op je vragen, maar eerst een tijdje moet rond klikken, wanneer je inlogt in een pakket. Zonde van je tijd.

Stel jezelf de ‘waarom’ vraag

Waarom is een pakket niet opgebouwd naar aanleiding van de behoefte van een gebruiker? Een pakket is qua meetwaardes vaak wel ingericht op de behoefte van een gebruiker (ik wil deze pagina’s, deze conversies, deze metrics meten), maar de pakketten geven geen antwoord op de ‘waarom’ vragen die ten grondslag liggen aan deze meetwaardes. Antwoorden op de vragen als: ‘Waarom wil je conversies meten?’ of ‘Waarom wil je bezoekers meten?’. Vaak hebben de antwoorden op deze vragen direct te maken met de doelstellingen die je met je site, of vaak zelfs: afdeling of bedrijf, hebt.

Welke doelstellingen heb je met je als bedrijf en/of met je site?

De doelstellingen die jij, jouw afdeling of je bedrijf heeft kunnen vaak niet allen gemeten worden door het webanalyticspakket. Vaak zijn er doelstellingen die betrekking hebben op andere data dan de data die gemeten wordt in analyticspakketten. Denk bijvoorbeeld aan gebruikerstevredenheid, financiën (inkomsten / uitgaven), concurrentiedata en data uit het CRM of HR pakket. De behoefte is vaak om al deze doelstellingen in één overzicht met elkaar inzichtelijk te maken. Dat geeft immers het volledige antwoord op de ‘waarom’ vraag. Het feit dat het analyticspakket maar één databron is, maakt het geen handig pakket om al je afdelingsdoelstellingen mee te visualiseren.

doelstellingenResumé: De antwoorden op de ‘waarom’ vragen geven vaak inzicht in de doelstellingen die jij jezelf hebt gesteld met betrekking tot de website. Helaas zijn deze antwoorden door de slechte inrichting van een pakket en de onvolledigheid van de data maar moeilijk te vinden, waardoor het belangrijke inzicht in de doelstellingen uitblijft.

Gebruik het pakket enkel als databron

De twee behandelde punten: 1. de behoefte om inzicht te krijgen in de overkoepelende doelstellingen en 2. het probleem om deze antwoorden uit het webanalyticspakket te krijgen, maken het webanalyticspakket een onhandig pakket om de belangrijkste vragen voor jouw bedrijf of afdeling te beantwoorden. Dit brengt mij direct bij een simpele oplossing: gebruik het analyticspakket hier niet voor, maar gebruik het analyticspakket enkel als databron. Dit heeft als voordeel dat je niet meer te maken hebt met de slechte indeling van het pakket en dit geeft je de mogelijkheid om je belangrijkste vragen op een andere manier te beantwoorden, waarbij de analyticsdata slechts één bron is.

Visualisatie: het sausje

Nu we het analyticspakket enkel nog als bron gebruiken hebben we wel een nieuw ‘frontje’ nodig om de antwoorden op de vragen (de doelstellingen) te geven. Door goed te kijken naar je doelstellingen en de vertaling daarvan kan je een goed dashboard maken dat direct antwoord geeft op de voor jouw bedrijf/afdeling belangrijke vragen. Voor ieder bedrijf zal dit zeer waarschijnlijk een eigen sausje betekenen, een eigen vormgeving gebaseerd op eigen doelstellingen. Het resultaat is een goed gevisualiseerd overzicht, op maat gemaakt, met gecombineerde databronnen, dat je altijd antwoord geeft op de belangrijkste vragen.

eigen sausje

Tijdens het Webanalytics Congres (17 maart) zal ik samen met Saskia Dikmans vertellen hoe SNS Bank dit proces heeft aangepakt en het resultaat hiervan tonen.

Reacties (10)

  1. Je moet alleen opletten dat je niet in de hele grote valkuil stapt om alleen maar in bedrijfsdoelen te denken bij het maken van je KPI dashboard (of doelstellingen data visualisatie). Denk vooral ook aan klantdoelen. Kan de bezoeker wel doen wat hij wilde doen, is hij of zij tevreden? Daar wil je doelen over instellen (en informatie over terugzien).

    Als het dashboard dan ook nog goede inzichten geeft (of eigenlijk signalen) waar actie gewenst is, heb je echt een mooi stuurmiddel. Cijfers samenbrengen is niet genoeg. De inzichten moeten ook leiden tot actie!

    Hoe wij dit gebruiken binnen het conversie optimalisatie proces bij MoneYou.nl kun je van MoneYou en mijzelf horen op hetzelfde congres, zelfde datum, zelfde plaats, alleen een andere tijdstip 🙂

  2. @Ton: dat hangt helemaal af van de behoefte die je hebt als bedrijf / afdeling. Wil jij inzicht geven in de doelstellingen waar de medewerkers op afgerekend worden of wil jij de site verbeteren? Logischerwijs wil je het beide, wat er in resulteert dat je enerzijds de status van de doelstellingen toont en anderzijds klantinzichten geeft waardoor je je site kunt verbeteren (waardoor je weer sneller je doelstellingen zult halen).

    Dus, ‘ja, goed punt’, maar als er geen behoefte is om klantdoelen inzichtelijk te maken (om welke reden dan ook) dan zeg ik: niet doen.

  3. Dan zeg ik: zorgen dat tevreden bezoekers als doelstelling wordt opgenomen bij de beoordeling van de medewerkers 🙂

    In de huidige open communicatie tijd is het niet handig om geen aanpassing door te voeren daar waar de klanten massaal niet goed worden geholpen omdat je target daar al gehaald is en op een ander onderdeel nog niet. Vandaar dat je een tevreden bezoekers doelstelling nodig hebt om balans te krijgen en bedrijfsomzet en klantgeluk!

  4. Het mooie is dat dit bij ons ook zo is, alleen zit daar volgens mij de vraag niet (iedereen wil tevreden klanten en meer verkoop). De vraag zit hem er meer in van: wat is je doel het met dashboard (welke vraag moet het beantwoorden). Als je de analyse / inzichten niet in een dashboard wilt (bijvoorbeeld omdat je deze informatie te gedetailleerd vindt voor een dashboard) dan is dat een keuze en zal je dit niet snel op een dashboard tonen. Overzicht houdt je dan met een dashboard (op hoog niveau – met signaleringsfunctie op dat niveau) en inzichten/analyses worden uitgevoerd / aangevraagd bij analisten (detail niveau).

    Keuzes, keuzes 😀

  5. Klopt, je dashboard bevat alleen inzichten die kunnen aanzetten tot actie (bij afwijking). Bij voorkeur moet in 1 oogopslag helder zijn op welke deelgebieden nu aandacht vereist is en klanttevredenheid is daarbinnen dan 1 van de belangrijkste (website onbereikbaar ligt daar boven, slecht lopende funnel daaronder). Maar ik begrijp dat dat een subjectieve mening is en niet elk bedrijf deze balans heeft 🙂

    Overigens benieuwd naar je presentatie natuurlijk de 17e!

  6. True, maar wat bij een dashboard ook meespeelt is de verversrate van de data. Als, bijvoorbeeld, je gebruikerstevredenheid één keer per maand gemeten wordt en je aanvragen één keer per uur, dan is het interessanter om continue aanvragen te tonen ipv continue een gebruikerstevredenheid die een maand niet wijzigt (niet actionable). Het is daardoor vaak (merk ik) een combinatie van factoren die de visualisatie maken tot wat hij is (verversrate, belang van waardes, actionable, etc).

  7. Bezoekerstevredenheid kun je herleiden door bezoekersgedrag te analyseren van mensen die niet direct voor het einddoel (kopen) komen. Die data heb je near real-time, afhankelijk van je web analyse pakket en inrichting. Je formule kun je elke paar maanden opnieuw eiken. Op deze data kun je weer doelstellingen op loslaten, waarbij je dashboard dan vooral de trend goed moet kunnen doorvertalen. Je wilt een signaal immers niet pas op het moment dat het leed al is geleden. Als de trend toont dat er in de toekomst iets niet goed gaat wil je (bij een bepaalde zekerheid) ingrijpen.

    Dat laatste stuk, daarvan moet ik wel aangeven dat ik nu in de experimenteer fase zit (predictive analytics) t.a.v. dashboards. Het vertalen van trends naar conclusies is nu nog een taak van de analist bij onze dashboards. Het inzicht krijg je wel, het signaal ook, maar de keuze voor actie ligt nog bij je zelf.

    Je kunt je afvragen of je je systeem wilt laten sturen (de discussie hadden we hier eerder), maar als ik zie hoeveel fouten er momenteel in de praktijk worden gemaakt bij het interpreteren van data en hoe groot het te kort aan ervaren webanalisten is, dan zeg ik op dit moment: laat het systeem maar kiezen. Dit geldt uiteraard niet voor kleine bedrijven met 1 ondernemer aan het stuur. Daar is het onderbuik vaak een prima raadgever (vaak ook door gebrek aan significante aantallen bezoekers)

  8. Mooi verhaal!

    Nog een toevoeging hierop:
    Wat ook al blijkt uit de discussie hierboven; bij het creëren van een overzicht (op welke wijze ook) kan dit zorgen voor behoorlijk wat discussie zorgen binnen je organisatie / afdeling: wat moet er in? wat niet?. Dusdanig veel inzicht kan daarnaast ook zorgen voor schrik reacties, vaak van andere afdelingen. Zorg daarom dat je erg duidelijk hebt wat je (daadwerkelijke) ‘Waarom?’ vraag inhield en wat je doelstellingen en uitgangspunt waren.

    Ander punt:
    De moeilijkheid van het creëren van een dashboard is dat je veel inzicht wilt geven wat vaak betekend; veel data tonen. Maar, tegelijkertijd wel overzichtelijk wilt houden/bieden. Meer data betekend in dit geval niet direct voor meer inzicht. Dit kan voor een behoorlijk interactie en visueel ontwerp puzzel zorgen. Neem daarvoor voldoende tijd.

    Ik ben benieuwd naar de presentatie van jou en Saskia van hetgeen wij de afgelopen maanden gezamenlijk hebben gecreëerd!

  9. Het is volgens mij het meest belangrijk dat iemand in de organisatie een brandende vraag heeft: een zogenaamd burning platform. Als dat ontbreekt, dan is de meeste analyse futiel omdat interesse in de verklaring ontbreekt.

    Analisten moeten zoeken naar hetgeen relevant is. Relevant is belangrijk én actueel. In de bovenstaande voorbeelden zie ik allemaal belangrijke issues. Maar niet alles kan tegelijkertijd even belangrijk zijn.

    Verder ben ik het met Reinout eens dat mensen niet teveel verwachtingen moeten hebben van WA pakketten. Het is inderdaad één van de databronnen. Als zodanig is het vrijwel nooit zelfstandig geschikt om belangrijke business vragen te beantwoorden. Het zal altijd maar een deel van de data opleveren.

    Overigens geldt Reinouts bevinding volgens mij voor iedere meetmethodiek. Neem nou boekhoudingen en jaarrekeningen. Veel organisaties gebruiken deze systemen en vrijwel niemand begrijpt ze. Boekhouders kunnen er vrij goed mee omgaan, maar collega’s en leidinggevenden snappen er maar weinig van. Volgens mij is het met financiele verslaggeving best goed gekomen als bedrijfsdiscipline

  10. Misschien is het onderstaande een totaal verkeerde insteek maar ik geef het een poging.

    Volgens mij wordt het tijd dat wij Webanalisten (ik generaliseer hier maar even alle verschillende titels bij elkaar) de informatie die we verkrijgen vanuit onze waanzinnige tool set (Google, Webtrends, Omniture, Twitter, Facebook etc) domweg als EEN onderdeel van het totale informatie domein van de klant zijn organisatie gaan zien (de fancy term die hier door de grote jongens wordt gebruikt is Enterprise domein). Wij zien nog te vaak in de praktijk dat deze informatie als een geheel eigen entiteit wordt gezien. Gevolg is dat mensen hier hun eigen vorm en structuur aan gaan geven middels Dashboards (ik kom zo nog even terug op definitie van een Dashboard, veelal wordt dit namelijk gebruikt als een verkapte vorm voor een ubercoole MS Excel exercitie – voor de redactie: ja, ook wij (lees: ik) maken ons hier ook nog wel eens schuldig aan).

    Ik ben het met Reinout eens als het gaat om de manier waarop je het doel van een Dashboard moet zien. Voordeel is alleen wel als je aanhaakt bij het eerder genoemde organisatie breede informatie beleid je kunt stellen dat er drie niveaus zouden moeten zijn: Strategisch, Tactisch en Operationeel . Voor deze laatste: ik hoop altijd dat een Dashboard in bepaalde mate wel een schrik effect terweeg brengt en dat mensen vervolgens aan de slag gaan met de juiste onderdelen uit hun totale toolset. Dit gezegd hebbende: volgens mij moet een Dashboard sturen, in de context van het niveau dat je nastreeft, en als het er op aan komt, ga je als analist aan de slag met de tools die het dashboard gevoed hebben.

    Tot slot zou ik nog terug komende op het begrip Dashboard. Ik zie, ook mijn eigen collega’s, de meest bizare dingen doen met MS Excel. Maar laten we Dashboard wel gelijk even goed doen. Ik zou willen stellen dat een beetje serieus dashboard niet de zoveelste MS Excel is maar dat het een solide realtime applicatie is die je bij de klant oplevert in de vorm van een 40inch Flatscreen die, als je handig bent, zelf ook nog even ophangt aan de muur daar waar de managers (strategisch en tactisch) meerdere keren per dag langs lopen. Worden ze gelijk geconfronteerd met het werk van ons Webanalisten.

Reacties zijn gesloten.