Friday, April 3, 2009

GA: 12 suggesties voor verbetering

Ik heb van een aantal mensen gehoord dat ze vinden dat ik op deze blog aangenaam neutraal ben in mijn teksten over GA. Dat probeer ik natuurlijk ook te zijn - als je blogt hoef je geen dingen te verkondigen die niet kloppen of al te duidelijk commercieel gemotiveerd zijn. Daar word je meestal snel op afgerekend. Bovendien, goeie wijn behoeft geen krans. GA is de facto de marktleider wat betreft marktaandeel in de webanalyticswereld en verdient het daarom om kritisch gevolgd te worden. Vooral door de meest trouwe fans.

Vandaar dat ik een lijstje heb opgesteld van suggesties waarvan ik denk dat ze zouden bijdragen aan het kwaliteitsimago van Google Analytics. Ik hoor graag of jullie hier aanvullingen op hebben. Totdat deze issues worden aangepakt is het in ieder geval goed dat zoveel mogelijk mensen zich ervan bewust zijn als ze naar de data kijken. Ik heb ze onderverdeeld in verschillende groepen:

1. Dingen die niet doen wat ze beloven
2. Admin
3. Gebrekkige functionaliteit
4. Onduidelijke terminologie en definities
5. Feature requests

1. Dingen die niet doen wat ze beloven

Site Overlay
De Site Overlay functie geeft de indruk dat-ie het aantal kliks laat zien die zijn gedaan op verschillende links op pagina's. Dit is niet correct. Wat de Site Overlay toont is voor de verschillende links op die pagina hoeveel pageviews er zijn geweest op de achterliggende URL's met als referrer de huidige pagina.
Er worden dus geen kliks gemeten, maar pageviews. Dat betekent dat je geen informatie gaat zien als je gebruikmaakt van redirects in die links, Flash of javascript. Als er bovendien problemen zijn met je implementatie van GA kan het zijn dat de gebruikerssessie wordt onderbroken en dat leidt opnieuw tot geen data in de Site Overlay.

Suggestie: Haal de functie uit GA, of zorg dat ze voor alle typen links werkt. En als je zegt dat je kliks meet, dan moet je dat ook doen.

Lookup Tables
Lookup tables worden gebruikt om websites die ingewikkelde en lastig te interpreteren urls hebben een vertaalslag te laten maken naar de rapporten. Dat vereenvoudigt de interpretatie van de data en betekent dat je niet iedere pagina apart hoeft te benoemen in de trackPageview. 
Je laadt een spreadsheet in met alle urls in je website die je wilt hernoemen en daarbij de nieuwe naam en in je rapporten zie je alleen nog de laatste.
Helaas is er wel een link naar Lookup tables in de filter interface, maar werkt die niet en heeft die ook nooit gewerkt. 

Suggestie: Haal de link eruit, of zorg dat Lookup tables wel worden ondersteund - het is wel een heel coole functie!

2. Admin

Linken meerdere Adwords accounts aan Analytics
Als je meer dan één Adwords account hebt en je wilt de resultaten daarvan zien in je Analytics rapporten, dan moet je Google bellen om dat voor je te regelen. Dit is iets wat niet alleen nergens terug te vinden is en dus niet heel gebruiksvriendelijk, maar met name voor Google ook niet schaalbaar. 

Suggestie: Account eigenaren moeten zelf in staat gesteld worden om hun accounts te linken en unlinken, hoe ze dit willen, wanneer ze dit willen. 

Geen adwords cost data is geen adwords visits.
De nieuwe regeling dat de cost data moeten zijn geimporteerd in een bepaald account om de adwords visits te kunnen zien werkt verwarrend. Bijvoorbeeld als een bedrijf een specifiek profiel heeft ingericht voor een bepaalde medewerker waarvan het niet wil dat die adwords costgegevens te zien krijgt loopt de totale meting scheef. De adwords visits die er in dat profiel natuurlijk ook zijn worden daar geregistreerd als direct verkeer. Zie hier het nieuwe help center artikel over deze issue.

Suggestie: Als accounts zijn gelinkt, autotagging staat aan, cost sources zijn toegevoegd, maar er zijn profielen waar de cost sources niet worden getoond, moet er een vette disclaimer worden getoond bij de data in die rapporten omdat verkeer vals wordt benoemd.

3. Gebrekkige functionaliteit

Filters werken niet op e-commerce data 
Ik heb daar hier al eens over bericht. 

Suggestie: Neem de e-commerce data mee als wordt gefilterd. Mocht dit niet mogelijk zijn, maak er dan melding van dat er iets niet goed gaat en filter wel ook de visits uit die transacties hebben gerealiseerd.

Filters werken op pageview niveau - niet op sessieniveau
Dit heeft tot gevolg dat het infilteren van bepaalde pagina's in een profiel niet correct werkt. Ook het standaard filter 'verkeer naar een subdirectory' geeft daarom problemen. Je moet dan via een omweg zorgen dat het verkeer wel correct wordt gemeten. Deze omweg bestaat uit een extra advanced filter waarbij je iedere sessie die een bepaalde pagina gezien heeft een vlag meegeeft in een custom field. Vervolgens filter je die sessies in. 
Advanced segmentation werkt wel op sessieniveau. In veel gevallen kun je dus ook een verschil zien tussen beide rapporten.

Suggestie: Ik heb begrepen dat dit moeilijk op te lossen is, maar als dat zo is, maak dit probleem in ieder geval wereldkundig, met de workaround. 


Datasampling ondermijnt enterprise class features.
Met de gigantische hoeveelheden data die GA moet verwerken is het verbazingwekkend hoe goed de performance is. Voor enkele features moet daarvoor wel een offer worden gebracht: bij meer dan 50.000 datapunten wordt datasampling toegepast. En hoe groter het aantal entries, hoe breder de sampling wordt. Met name het veelgeprezen Advanced Segmentation lijdt hieronder. Hoewel sampling niet ongebruikelijk is in webanalytics maakt het wel dat GA duidelijk aan enterprise readiness inboet. Als je kijkt naar data moet je er wel op kunnen vertrouwen en datasampling werkt dat vertouwen niet in de hand. 

Suggestie: Bied grote klanten de mogelijkheid om (tegen betaling?) zonder datasampling te kunnen werken.


4. Onduidelijke terminologie en definities

Analytics is in meer dan 20 talen beschikbaar. Het is een enorme klus om voor alle definities goede vertalingen te vinden en er gaat dan ook nog wel eens wat verloren in de vertaling. Met name tussen het helpcenter en de tool treden nog wel eens verschillen op in terminologie. Ik gebruik daarom het liefste het US-Engelse origineel om de verwarring zoveel mogelijk te beperken.

Verschillende cijfers voor revenue, welke wordt gebruikt voor ROI berekening?
Als je een adwords account hebt kun je de ROI, of eigenlijk ROAS (return on ad spend) daarvan door GA laten berekenen. De omzet die daarvoor wordt gebruikt wordt volgens het helpvenster berekend als e-commerce revenue + total goal value. Maar e-commerce revenue bestaat uit die revenue puur, en die inclusief belasting en verzendkosten. Welke wordt gebruikt? Dat staat niet gedocumenteerd. Het lijkt mij voor de hand liggen om in ieder geval verzendkosten niet mee te rekenen, maar GA gebruikt de revenue inclusief deze kosten en BTW.

Suggestie:  Duidelijkheid creëren over welke cijfers worden gebruikt en (op termijn) keuzevrijheid geven. 

Revenue per click compared to site?
In het Adwordsrapport heb je wanneer je Adwords en Analytics goed hebt gelinkt en e-commerce hebt geinstalleerd en/of doelwaarden ingesteld een metric die RPC heet, ofwel Revenue per Click. Er wordt per campagne/advertentiegroep/keyword berekend hoeveel deze kliks je gemiddeld hebben opgeleverd.  Dan staat er bij die metrics een percentage 'compared to site', waarbij je een idee krijgt hoe die verkeersbron het doet vergeleken bij het totaalgemiddelde van de site.
Van RPC heeft het echter geen zin om Compared to site te laten zien, aangezien Adwords het enige marketingprogramma is waarvan we kliks (itt bezoeken) registreren. Wat hier wordt getoond is de totale revenue gedeeld door het aantal kliks uit deze bron. Dus de vergelijking valt altijd negatief uit en is daarom zinloos.

Suggestie: Verwijder Compared to site bij deze metric.


5. Feature Requests

Calendar functie
Als je op accountniveau een calendarfunctie zou hebben, dan zou automatisch bijgehouden kunnen worden wie wat op welk moment heeft gedaan. Dit maakt interpretatie van data een stuk helderder. Op profielniveau zou je bijvoorbeeld offline campagnes in de kalender kunnen zetten om het effect daarvan op de website duidelijk te kunnen tonen. 

Alerts
Een grote wens van veel gebruikers van GA is toevoeging van alerts, waardoor je bericht krijgt als metrics onder een door jezelf aangegeven benchmark duiken. De voordelen hiervan zijn duidelijk.

Match type en gehele advertentie
Wat betreft de link met Adwords is er wel het nodige veranderd de laatste tijd. In plaats van de wijziging die heeft plaatsgevonden had ik zelf liever gezien dat de rapportage was uitgebreid met match type (broad, exact, phrase) informatie bij de keywords en in het Ad versions rapport de gehele advertentie in plaats van alleen de eerste regel.


Heb je ook suggesties voor nieuwe features in GA, of ben je storende problemen tegengekomen in de rapportage? Reageer hier!

1 Comments:

Anonymous John Muijen said...

Het zou wel aardig zijn als je onder de e-commerce sectie je marge op de producten kan invoeren zodat je echt ziet of je AdWords campagnes rendement opleveren.

April 8, 2009 at 8:49 AM  

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home