André Scholten

Google Website Optimizer Calculator

André — Thu, 17 Jun 2010 19:34:28 +0000

Ik vond vanmiddag toevallig een tooltje die ik ooit gemaakt had op basis van Google's eigen Website Optimizer Duurcalculator. Waarom had ik die tool gemaakt? Omdat de tool van Google zelf in mijn ogen niet voldoet. Wat kun je dan met die tool? Berekenen hoe lang een A/B of multivariate test ongeveer gaat duren voor er statistisch significante resultaten zijn.

Google's Tool

De tool van google ziet er als volgt uit:

De eerste 4 velden zijn prima in te vullen. Je kiest een aantal combinaties, je zoekt het aantal pageviews op die je normaal op de te testen pagina haalt. Je wil 100% van het bezoek in het experiment en je succespercentage zoek je op in je Analytics pakket, dit percentage is afhankelijk van het doel van je test.

Maar dan het laatste vakje: de verwachte verbetering. Tja, weetikveel? De klant wil 50%, ik denk dat 5% al mooi is, en de waarheid zal er tussen liggen. Maar op basis van het aantal dagen dat een test zal duren kies je vaak ook het aantal varianten dat je wil testen. Hoe meer varianten je in een korte tijd kunt testen hoe meer je uit de test haalt. Extra leesvoer: hoe lang moet een test duren. Maar zonder een goede inschatting van de te verwachten verbetering weet je niet hoe lang een test duurt.

André's testduur calculator

En daarom heb ik onderstaande tool gemaakt. Je vult de bekende velden in, en in de tabel wordt dan het aantal dagen getoond dat nodig is voor een significant resultaat. Door nu te spelen met de waardes zie je ook direct het effect op de periode. Je kunt beter zien in welke periode een bepaalde verbetering te halen is: hoe meer groen, hoe beter het is. Je kunt beter inschatten welk aantal varianten haalbaar is: bij veel verbetering snel resultaat en bij minder verbetering toch nog altijd binnen een paar weken.

Vul de velden in:

Gerelateerde artikelen:

Meet de snelheid van je site in Google Analytics

André — Mon, 12 Apr 2010 11:36:42 +0000

Toegegeven, het is niet een nieuw idee om de snelheid van je pagina's te meten met javascript. Maar dit vervolgens doorgeven aan Google Analytics middels event tracking is dat wel. Nu Site Speed een officiële SEO ranking factor is het belangrijk om inzage te hebben in je snelheid.

De Google Webmaster Tools levert al een mooie grafiek over de tijd die Google over het renderen van je site doet. Zie voor meer uitleg mijn blog over het sneller maken van mijn eigen blog. Maar nog meer cijfers van alle laadtijden bij diverse gebruikers is altijd handig.

De laadtijden in cijfers

Op dit moment kan ik per pagina zien wat de totale laadtijd is geweest, maar ook het gemiddelde. Dat rapport ziet er als volgt uit:

Ik heb nog niet heel veel data, ik had geen zin om te wachten met bloggen Het leuke is dat je nu ook laadtijden kunt gaan bekijken per regio of type verbinding:

Nadeel van dit "custom report" is dat je zelf de kolom met de gemiddelde tijden moet uitrekenen (Excel) omdat hier alleen de totalen getoond worden. Voor DSL zou dat dan 20.126 / 19 = 1059 millisecondes per pagina worden. Op dezelfde manier kun je ook voor browsers of besturingssystemen kijken wat de laadtijden zijn.

Als kers op de taart kun je de laadtijden ook in een grafiek weergeven om zo het resultaat van je werk over verloop van tijd te zien. Kies daarvoor deze optie boven je grafiek in de gebeurtenissen rapportage:

Het script

Het script is eigenlijk heel eenvoudig. Het bestaat uit 2 delen waarvan de eerste helemaal bovenin de pagina vlak na de geplaatst moet worden:

Het 2de gedeelte is iets geavanceerder en ziet er als volgt uit:

Of in de oudere versie van het meetscript:

Let op dat je een nieuw profielnummer gebruikt en niet het UA nummer van je hoofdmeting. Dit script zorgt er namelijk voor dat anders je bouncerate op nagenoeg 0% komt te staan. Daarnaast moet er vanwege een bug eerst een trackPageview gedaan worden omdat andere het meten van het event niet goed gaat. Deze trackPageview wil je ook niet in je hoofdmeting hebben.

Gerelateerde artikelen:

Wat nou privacy, ik meet waar jij geweest bent

André — Wed, 17 Mar 2010 09:06:42 +0000

Het klinkt gek maar toch kan het: ik lees de historie van je browser uit en plaats deze gegevens in Google Analytics. Zo weet ik precies welke sites je allemaal bezocht hebt, scary he? Zo kan ik heel mooi een profiel maken van het type bezoeker wat hier op de site komt aangezien ik weet welke sites ze in het verleden (tot zo ver de Browser historie reikt) allemaal bezocht hebben.

Zo ziet mijn bezoekersprofiel er op dit moment uit:

En let op: die sites linken niet naar mij, het is echt Browser History data. Ik heb nog niet heel veel meetdata, maar zo te zien zijn mijn bezoekers ook trouwe Bol en Tweakers.net bezoekers.

Techniek

Hoe is dit technische mogelijk zul je je afvragen? Nou, middels een hack lees ik de back-knop én de historie van je browser uit. Dit is technisch mogelijk in Firefox, Internet Explorer en ook Chrome.

Vervolgens kun je de lijst met bezochte sites op slaan. Ik heb gekozen dit tijdelijk met Google Analytics te doen zodat ik vanuit daar een mooi rapport kan maken. Ik ga verder niet in op de technische details aangezien de impact op iemands privacy groot kan zijn.

Kansen

Met deze meetgegevens kun je hele interessant dingen doen. Je kunt bijvoorbeeld zien of bepaalde groepen sites missen in in de profielen van je bezoekers. Begin dan met een sitegerichte bannercampagne om zo nieuwe bezoekers die dus nog relatief onbekend zijn met jouw site te targetten.
Tegelijk levert het informatie op over de concurrenten die bezocht worden. Welke worden er nou veel en welke weinig bezocht door jouw bezoekers.

Privacy

Tja, wat denken jullie? Kan dit? In theorie is het mogelijk dat ik een scan doe op de aanwezigheid van adult sites in je Browser historie. Die sites sla ik dan op bij je naam of IP en heb direct een vervelend dossier over jou. De technologie is best interessant gezien de informatie die je krijgt, maar ik denk dat een heleboel mensen er toch problemen mee hebben dat iemand kan zien wat ze bezocht hebben.

Wat denken jullie? Hoeveel van jullie hebben ondertussen even de Browser historie verwijderd?

Gerelateerde artikelen:

Je referrals zijn echte parels, laat ze niet verloren gaan

André — Thu, 25 Feb 2010 22:01:19 +0000

Het zou eigenlijk een basisonderdeel van je Google Analytics implementatie moeten zijn: het instellen van een gaaf filter dat er voor zorgt dat je referrals niet verloren gaan. Hier zit zo veel informatie in, nog meer dan je in een gewone Google Analytics implementatie kan verwachten. Even een opsomming van de voordelen:

Leg campagnes naast referrals (verwijzende sites)
Bekijk de gebruikte sites (en zoekwoorden) van affiliates
Analyseer welke resultaten in de zoekmachines aangeklikt worden
Ga na welke URL het populairst is i.p.v. alleen toplijsten per domein

Ik zal ze stuk voor stuk behandelen, en natuurlijk hoe eenvoudig het is om het op je eigen account in te stellen. Dit zijn wellicht niet eens de enige voordelen, er zullen er meer zijn die jullie hopelijk nu te binnen schieten, laat ze horen in de comments.

Leg campagnes naast referrals (verwijzende sites)

Een neveneffect van het taggen van campagnes is dat Google Analytics deze waardes gaat gebruiken in alle rapportages. De oorspronkelijke referral wordt hierbij genegeerd en gaat voor altijd verloren. Een simpel voorbeeld is bijvoorbeeld een ingekochte tekstlink die je via een netwerk weg zet. Je tagt hem als tekstlink en zo wordt hij op tientallen sites geplaatst. In je rapporten zul je vervolgens dit zien:

Maar je weet nu niet op welke sites de link gestaan heeft. Enerzijds wil je een totaalrapport kunnen maken over die ene link en daarom had je hem getagd. Maar anderzijds wil je ook de sites terug kunnen halen, maar dat kan niet meer door het taggen.

Door het instellen van het filter wat ik onderaan dit artikel laat zien kan dit wel. Je ziet dan totaalcijfers van de campagnes, en je kunt ook eenvoudig de bijbehorende verwijzende sites opvragen.

Bekijk de gebruikte sites (en zoekwoorden) van affiliates

Niet echt helemaal een nieuw punt als je het vorige stukje gelezen hebt maar voor affiliates geldt precies hetzelfde. Je tagged alle links die je beschikbaar stelt voor affiliates zodat je kunt zien hoeveel bezoek en conversies ze opleveren. Tevens wil je naast die tagging zien welke sites de diverse affiliates hiervoor gebruiken.

Tip: zie je dat er geen verwijzende site bekend is bij een affiliate? Dan is hij verdacht. Hier loont het vaak om even uit te zoeken waarom dat zo is.

Een extraatje is dat je nu ook kunt zien welke URL's in de zoekmachines gebruikt zijn om bij je site te komen. Affiliates die adverteren in de zoekmachines kunnen zo bekeken en geanalyseerd worden. Je haalt makkelijk de zoekwoorden terug. Ook is dit direct een controlemiddel mocht je een beleid hebben dat er helemaal niet geadverteerd mag worden in de zoekmachines.

Analyseer welke resultaten in de zoekmachines aangeklikt worden

Ik had het al even genoemd, maar met het opslaan van alle referrals worden niet alleen de websites opgeslagen, maar ook de URL's van de zoekmachines. Hier kun je hele leuk dingen mee doen door ze te doorzoeken op de aanwezigheid van bepaalde parameters. Met behulp van de geavanceerde filters onderaan de lijst kun je zien hoe vaak men op een sitelink geklikt heeft:

Voor een hele uitgebreide lijst verwijs ik je naar dit blog. Je kunt nu zien hoe vaak mensen via een spellingssuggestie naar je site gekomen zijn, of hoeveel de "I feel lucky" knop gebruikt hebben. Ik heb zelf onderzocht of men veel "In Nederland" of "Het internet" zoekt. De mogelijkheden zijn redelijk eindeloos.

Ga na welke URL het populairst is ipv alleen toplijsten per domein

Last but not least: het nieuwe rapport laat de populairste verwijzende URL's zien terwijl het originele "verwijzende sites" rapport alleen domeinen laat zien:

Het is in een lijst met simpelweg alle URL's onder elkaar makkelijker om met de geavanceerde filters de toppers er uit te halen qua weigeringspercentage, omzet of behaalde doelen.

Hoe stel ik dit mooie filter in?

Maak allereerst een nieuw profiel aan zodat je niet de data van je hoofdprofielen gaat verfilteren. Op dat profiel plaats je vervolgens dit simpele maar doeltreffende filter:

De opgeslagen verwijzende sites komen vervolgens in het "Door de gebruiker gedefinieerd" rapport.

Succes met de nieuwe inzichten. En laat het weten waar je het zelf al voor gebruikt of waarvoor je het wil gaan gebruiken

Gerelateerde artikelen:

Breng snelheid in je site voor gebruikers en zoekmachines

André — Sun, 24 Jan 2010 21:06:46 +0000

Het is een hot onderwerp: de snelheid van je site wordt steeds belangrijker. Bezoekers hebben snelle sites altijd al prettig gevonden en Google gaat het daarom nu ook meenemen in het bepalen van je ranking. Mede hierom ben ik eens flink bezig gegaan met het optimaliseren van mijn site. De genomen stappen en de resultaten wil ik graag met jullie delen.

Welk stappen heb ik genomen

Om de snelheid van het laden van mijn site te versnellen heb ik de software (WordPress), de server, de broncode (HTML, CSS en Javascript), de plaatjes aangepakt. Elke verbetering heb ik vervolgens gemeten met de tools Google Page Speed en Yahoo! YSlow, beide weer aanvullingen op de populaire developers tool Firebug. Een hoop kleinere wijzigingen zal ik hier niet behandelen, maar de echte impact-makers zal ik zeker noemen.

Caching aangezet
De eerste stap was het implementeren van de W3 Total Cache plugin voor WordPress. Deze zorgt er voor dat alle pagina's in mijn site van te voren alvast in elkaar gedraaid worden tot kant en klare HTML. Wanneer een bezoeker dan een pagina opvraagt kan direct de HTML geserveerd worden en hoeven er dus geen PHP of enkele database verzoeken aan te pas te komen. Extra voordeel is dat de broncodes van alle javascript, CSS (zie voorbeeld van mijn site) en HTML ontdaan worden van onnodige elementen als spaties en commentaren.
De 2de stap in het caching verhaal is het aanzetten van zogenaamde caching headers. Hiermee vertel je aan een browser dat bijvoorbeeld een bepaald plaatje niet elk bezoek opnieuw opgehaald hoeft te worden omdat hij toch niet veranderd. Zo blijven de plaatjes in de cache van de bezoeker staan en dat scheelt laadtijd. Op mijn type server (Apache) kon dat simpel door de volgende regels op te nemen in het .htaccess bestand:

ExpiresActive On ExpiresDefault A300 ExpiresByType image/x-icon A4838400 ExpiresByType application/x-javascript A4838400 ExpiresByType text/css A4838400 ExpiresByType image/gif A4838400 ExpiresByType image/png A4838400 ExpiresByType image/x-icon A4838400 ExpiresByType image/ico A4838400 ExpiresByType image/jpeg A4838400 ExpiresByType text/plain A4838400 ExpiresByType application/x-shockwave-flash A4838400 ExpiresByType video/x-flv A4838400 ExpiresByType application/pdf A4838400 ExpiresByType text/html A300
Per type bestand wordt een houdbaarheidsdatum meegegeven. A4838400 staat gelijk aan 56 dagen (4838400 secondes) vanaf het moment dat het bestand opgevraagd wordt (A).

GZip
Wat veel tijd kan schelen is het inpakken van alles wat je over de kabel verstuurd. Bijna elke server beschikt wel over een module die dit kan regelen. De GZip module is wellicht de meest bekende. Zodra een HTML pagina geserveerd wordt zal hij eerst ingepakt worden, en na ontvangst wordt hij weer uitgepakt. Het werkt zo'n beetje hetzelfde als het zippen van een bestand op je eigen pc. Het is een beetje afhankelijk van je hosting pakket of deze module wel of niet geïnstalleerd is.

CSS Sprites

Een mooie truc die ook vaak bij games gebruikt wordt zijn de zogenaamde CSS Sprites. Dat zijn plaatjes die bestaan uit een aantal (tientallen tot honderden) andere plaatjes. Om even duidelijk te maken wat ik bedoel kun je het beste kijken naar de sprite die ik voor deze site gemaakt heb. Je ziet in dat plaatje precies 10 plaatjes die daarin samengevoegd zijn. Met behulp van handige CSS positionering plaats ik deze sprite zo dat alleen het gewenste deel zichtbaar is op de juiste plek.
Wat is dan het voordeel? In plaats van 10 HTTP connecties hoeft er nu maar 1 gemaakt te worden die het plaatje binnenhaalt. Dat scheelt tijd en resources die door andere elementen gebruikt kunnen worden. Het plaatje staat vervolgens in het geheugen van de PC en kan zo vaak gebruikt worden als dat nodig is. Het 2de voordeel is simpelweg het aantal kb's. Deze 10 plaatjes afzonderlijk waren in totaal 29.882 bytes groot. De sprite is maar 15.812 bytes. Dat betekent een besparing van 48%.

Verkleinen van diverse afbeeldingen
Ik heb niet simpelweg alle plaatjes in mijn site geopend en als .JPG opgeslagen met een kwaliteit van 5%, dat zou te simpel zijn. Met behoud van kwaliteit is het mogelijk om bijna alle bestanden te verkleinen. Dat kan omdat een heleboel grafische formaten allerlei extra zaken in een bestand opslaan die eenvoudig verwijderd kunnen worden. Check deze pagina voor een aantal handige tools.

Opruimen
De meeste simpele manier van allemaal: opruimen. Is alles wat je op je site toont echt nodig? Kan er niet het een en ander weg? Of zou je het externe logo niet zelf kunnen hosten? Een extern iets op je site kan het laden enorm vertragen. Elk ander domein dat nodig is bij het laden van je site betekent ook een extra DNS aanroep. Gebruik deze externe zaken dus met mate.
Op deze site stond een grapje: als je over mijn neus heen ging kreeg je een tekstballon met een mededeling. Geinig, maar totaal overbodig. Er moest extra HTML, CSS, Javascript en een plaatje ingeladen worden. Dit 'grapje' is nu dus ook verleden tijd.

Asynchrone Google Analytics code
Google lanceerde onlangs een nieuwe asynchronous meetcode die een aantal mooie voordelen bevat. Hij kan bovenin de broncode geplaatst worden omdat het script dusdanig geladen wordt dat het laden van de site hier niet op hoeft te wachten. En zodra het script binnen is vindt direct de meting plaats. Door de bank genomen zal de meting nu eerder plaatsvinden dan wanneer de meetcode helemaal onderaan je pagina had gestaan, en daardoor zul je meer pageviews en bezoekers gaan meten.

En wat zijn de resultaten

In de kerstvakantie ben ik hier mee begonnen en heb in de loop van januari nog enkele stappen genomen in het optimaliseren van de site. Ik kan op dit moment nog niet zeggen of de wijzigingen effect hebben op mijn SEO rankings, maar het bezoek vanuit die hoek is wel harder gestegen dan de rest.

Wat zeggen de WebMaster Tools
De Google Webmaster Tools heeft 2 mooie grafieken in de rapportage zitten. De eerste laat zien hoe lang de Google Spider doet over het downloaden van de pagina's in je site:

Je kunt goed zien dat begin januari de downloadsnelheid van gemiddeld 1,5 naar 1 seconde is gegaan. Dat heeft deels te maken met de instellingen die ik gemaakt heb. Maar daarnaast is ook de snelheid van de hosting partij een belangrijke factor waar je wat moeilijker invloed (verhuizen) op kunt uitoefenen.

En de 2de grafiek laat zien hoe lang vervolgens het renderen (het samenbrengen van de JS, CSS, HTML en plaatjes om daar een werkende pagina van te maken) van die pagina duurt:

Een mooie daling in de loop van de tijd. De berg zo rond half december werd veroorzaakt door een externe toolbar (Wibiya) die ik even getest heb. Helaas wogen de voordelen niet op tegen de nadelen. Buiten die berg om loopt de daling mooi door tot een 2,9 secondes per pagina gemeten op 22 januari.

Google Analytics
Er zijn een aantal wijzigingen te zien in Google Analytics. Maar of de veranderingen te wijten zijn aan de nieuwe plaats van de asynchrone code (bovenaan de broncode) of de laadsnelheid van de site is moeilijk te zeggen. Beide factoren tezamen leveren dit als resultaat:

Het organische verkeer laat de normale kerstdip zien en stijgt vervolgens flink zonder aanwijsbare reden. Ik had al een tijdje niet meer geblogd en ook niet aan linkbuilding oid gedaan. Toch heb ik vaker dit soort stijgingen in januari gezien en durf er dus niet keihard conclusies aan te verbinden.

Een andere duidelijk stijging is te zien in het weigeringspercentage. Dat was voorheen altijd onder de 70% en is nu opeens rond de 73% constant. Dat betekent dat bezoekers die voorheen al wegklikten zonder dat de Google Analytics code geladen was nu wel gemeten worden. De site en de nieuwe GA code laden zo snel dat vrijwel iedereen gemeten wordt.

Rankings
Op dit moment zie ik nog niet echt een positieve invloed op mijn rankings, maar ik verwacht dit ook pas over een langere termijn te kunnen zien. En dat maakt het ook weer moeilijk om te isoleren, er gaan in een langere periode andere zaken meespelen die de data vertekenen.

Conclusie

Het was leuk om te doen. Nerd als ik ben wilde ik met de Google Page Speed module toch minimaal een score van 85 neerzetten. Alle kleine details moesten aangepakt worden. Resultaat is nu wel dat de site aanmerkelijk sneller ingeladen wordt. En daar draait het uiteindelijk toch om, een trage site is één van de grootste ergernissen tegenwoordig.

Iemand anders nog tips of ervaringen die gedeeld moeten worden?

Gerelateerde artikelen:

Google Analytics ecommerce transacties annuleren

André — Tue, 19 Jan 2010 09:52:55 +0000

Vorige week kreeg ik het verzoek om in het account van een klant een aantal ecommerce transacties te annuleren. Wat was er namelijk gebeurd: er was een nep-bestelling geplaatst met een gigantisch hoog bedrag:

Je denkt dat de linkerkant van de lijn op 0 staat, maar in werkelijkheid zijn hier goede omzetten gemaakt. Ze vallen alleen in het niet door de enorme uitschieters aan de rechterkant. Dat ging om enkele transacties van ongeveer €5.000.000 totaal.

De nadelen

De nadelen kun je wel raden, ontzettend veel rapporten leveren rare cijfers. De gemiddelde orderwaarde gaat enorm omhoog. De omzetten van de campagnes die de bezoeken aangeleverd hebben gaan omhoog. De waarde per bezoek van die campagne klopt niet meer, enz, enz. En in de komende maanden en jaren dat je deze periode in een analyse meeneemt zul je steeds deze rare piek zien. Ik zou haast zeggen: je data is gewoon niet meer werkbaar.

De halve oplossing

De meeste simpele oplossing is door het eenvoudigweg maken van een segment waarin je alle bezoeken met rare transacties uitsluit. Dat kan er zo uit zien:

Dit werkt alleen als de rare transacties duidelijk van de normale te onderscheiden zijn. In andere gevallen moet je toch de echte oplossing gebruiken:

Hoe annuleer je een transactie

Om een transactie te annuleren moet je op zoek gaan naar alle gegeven die je over de transactie kunt vinden. Dus welke affiliatie, producten, SKU's, bron, medium, zoekwoord, enz. zijn er gebruikt in de meting op de bedanktpagina. Ik neem als voorbeeld een transactie die er als volgt uit ziet, de gegevens die hier staan heb ik stuk voor stuk uit Google Analytics gehaald:

pageTracker._addTrans("order-123", "", "1090170.00", "0.00", "0.00", "Assen", "", "Nederland"); pageTracker._addItem("order-123", "prod-456", "Duplo blokje", "Speelgoed", "36339.00", "30"); pageTracker._trackTrans();

Het totaal bedrag is net over de 1 miljoen heen. Stel dat ik deze transactie wil annuleren moet ik de volgende code gebruiken:

pageTracker._addTrans("order-123", "", "-1090170.00", "0.00", "0.00", "Assen", "", "Nederland"); pageTracker._addItem("order-123", "prod-456", "Duplo blokje", "Speelgoed", "36339.00", "-30"); pageTracker._trackTrans();

Let op: in de transactie wordt het orderbedrag negatief, hetzelfde doe je met de 2 velden er na (belasting en verzendkosten). En in de item regel blijft het bedrag positief maar wordt het aantal bestelde producten negatief neergezet.

De juiste bron
de volgende stap is het opzoeken van de bron van het bezoek. Stel dat het in dit geval iemand is geweest die op "duplo" heeft gezocht in Google en op de AdWords advertentie heeft geklikt. Je gaat naar je betreffende site, je gooit al je cookies van die site weg. Dan ga je naar Google en doe je dezelfde zoekactie. Je klikt op de AdWords advertentie en landt op de site. Als je dit niet doet heb je kans dat AdWords bijvoorbeeld 1 miljoen in de plus staat en direct verkeer 1 miljoen in de min. De transactie is dan wel geannuleerd, maar de data binnen de verkeersbronnen klopt nog steeds van geen kant. (Deze fout had ik dus gemaakt en hoeven jullie nu niet meer te maken )

Vervolgens kun je de nieuwe annulerende ecommerce code via de adresbalk aan Google Analytics doorgeven:

Plak de volledige code als 1 regel voorafgaand met "javascript:" in je adresbalk en druk op enter. Er wordt nu een ecommerce meting verstuurd die de foutieve transactie annuleert.

Het resultaat

Het resultaat is dat wanneer je het transactie rapport bekijkt en een periode selecteert waarin beide transacties staan (de foute en de annulerende) ze beide niet meer zichtbaar zijn. In de omzet grafiek zie je nog wel een piek, maar ook een dal op de plek van de annulering. De omzetten die toegekend worden aan de verkeersbronnen kloppen weer, enz. enz. Een veel betere situatie met mooie opgeschoonde data.

In mijn geval moest ik 5 transacties annuleren en dat kostte me dik 2 uur, eerst 5 keer fout, toen 5 keer goed maar met verkeerde bron, toen 5 keer om de omzetten van de verkeersbronnen goed te krijgen, en als laatste nog 2 omdat ze niet allemaal goed doorgekomen waren. Elke keer de cookies verwijderen en ook controleren of je in Analytics niet je eigen IP adres uitsluit, anders moet je dat filter even uit zetten. Het is dus niet heel makkelijk, eigenlijk zou in Google Analytics zelf een "verwijder" knop naast de transacties moeten komen te staan

Gerelateerde artikelen:

Zoekt men in Google op “Het Internet” of in “het Nederlands”?

André — Mon, 31 Aug 2009 13:52:43 +0000

Een leuke mogelijkheid van het SEO Rankings filter dat ik onlangs geupdate heb is dat je eigenlijk alle opties van de Google zoekmachine kan meten.

Naast het doormeten van de posities waarop zoekwoorden zich bevinden kun je ook de gekozen dataset naar Google Analytics brengen:

Google geeft namelijk mee welke van deze 3 opties gebruikt is tijdens het zoeken. Ik heb dit doorgemeten in Google Analytics en kom uit op de volgende getallen na een tiental miljoenen bezoeken voor typische Nederlandse sites:

Het internet: 96,69%
Pagina's in het Nederlands: 3,28%
Pagina's uit Nederland: 0,03%

Er zijn dus relatief weinig mensen (alhoewel, 3% van een paar tientallen miljoenen is ook een hoop) die de moeite nemen om de te zoeken taal of het land van de hosting te selecteren.

Reinout Wolfert noemde al de mogelijkheid om Sitelinks beter door te kunnen meten, dit had ik ook laten zien in een artikel op Webanalisten. Wie ziet nog meer interessante zaken die je uit de verwijzende URL's van Google kunt halen?

Gerelateerde artikelen:

Hoe ontstaan de verschillen tussen de AdSense/Analytics rapportage en AdSense zelf

André — Fri, 21 Aug 2009 10:55:21 +0000

Een goede vraag die ik regelmatig tegenkom op diverse kanalen: waarom zijn de AdSense cijfers die je in Google Analytics ziet niet gelijk aan de cijfers die je in AdSense zelf ziet? En de verklaring hiervan is niet simpel omdat er ontzettend veel factoren meespelen in de metingen hiervan.

Allereerst het fenomeen in cijfers. Ik heb de getallen van een beschikbaar account in Excel naast elkaar gezet, wat rapporteert Analytics en wat rapporteert AdSense. Deel deze getallen door elkaar en je krijgt een verhouding zoals in onderstaande grafiek (exacte cijfers mag ik volgens de TOS van AdSense niet publiceren):

Lees verder op het Traffic4u weblog »

Gerelateerde artikelen:

Lisa is geboren

André — Tue, 30 Jun 2009 22:03:11 +0000

We hebben er een tijdje op moeten wachten, door de voorweeën dachten we 3 weken geleden al dat ze kwam, hier en daar zelfs al een nacht opgebleven. Maar nu is het dan echt zo ver, vanmiddag vanaf 12 uur werd het steeds heftiger, en zo rond 4 uur hebben we de verloskundige gebeld. Ruim 2,5 uur later zo rond half 7 is Lisa dan eindelijk geboren.

Trotse ouders:

Trotse papa:

Enthousiaste broer en zus:

We zijn ontzettend blij en dankbaar met dit wonder.

Geen gerelateerde artikelen.

Kaas Drop Utrecht op pagina 1

André — Mon, 15 Jun 2009 21:28:19 +0000

Rare titel voor een blog zou je denken, maar dat is niet zonder reden. Ik werd onlangs door een pop quiz organiserende collega getipt over de volgende mail:

Steeds meer bedrijven ontdekken het gemak van de Lo...[knip] Bedrijfspagina. Op eenvoudige wijze trekken zij meer bezoekers op hun website zonder dure aanpassingen aan de eigen website te hoeven verrichten.
Zoek in Google eens op "kaas drop utrecht" en zie hoe Au Marché met haar Lo...[knip] Bedrijfspagina op de eerste pagina van de zoekresultaten verschijnt.
Wilt u ook meer klanten? Voor slechts € 99,- (ex BTW) heeft u een heel jaar lang uw eigen Lo...[knip] bedrijfspagina. Begin nu met profiteren en ga naar mijn bedrijf. Werkt deze link niet ga dan naar [knip]

Je krijgt dus eigenlijk (het staat er niet letterlijk) een soort garantie voor een pagina 1 resultaat en meer bezoekers op je site. Is dat zo?

Ik zie op de landingspagina maar 1 link naar de site van de klant. Die gaat via een 302 redirect naar de echte site van de klant toe. Dat betekent dat de populariteit van de link niet naar de klant gaat maar op de gids blijft. Tevens werkt de link in mijn geval maar 1 keer aangezien ik bij klik 2 een 304 (Not Modified) header krijg en geen redirect meer. De linktekst "Bezoek website" is verder ook niet heel interessant.

Waarom doen?
Waarom zou je dan €99 betalen om een zogenaamde bedrijfspagina te hebben? Misschien om daarmee de top 10 van de zoekresultaten op je bedrijfsnaam te vullen met allerlei bedrijfspagina's? Er zijn tientallen van dit soort gidsen in de omloop, keus genoeg dus. Maar of het effectief is? Ik kan door 1 zelfgemaakte pagina (deze blog dus) ook scoren op "kaas drop utrecht", daar heb ik geen externe gids voor nodig.

Waarom dan dit artikel? Omdat ik een beetje flauw ben van de zoveelste gids. Er zijn tientallen gidsen met geautomatiseerde en bijeengeraapte content, makkelijke Google maps er naast en affiliates links met "stuur dit bedrijf een bloemetje". Er zit 0,0 meerwaarde in, want zeg nou zelf, wie maakt gebruik van dit soort gidsen? Er zijn in Nederland hooguit 2 a 3 die bestaansrecht hebben, en de rest heeft geen meerwaarde. Misschien moet Google zijn duplicate content filter ook eens op de gidsen toepassen.

Zelf doen
Ook is het veel makkelijker, en loont het meer om zelf content op je site te hebben die voorziet in informatie over bepaalde onderwerpen. Je vangt zelf de bezoekers af en bent niet afhankelijk van een externe gids die de bezoekers niet heel efficiënt doorstuurt.

Trouwens, ik wilde nog een Analytics gidsje maken, iemand die een vermelding wil? €199 per jaar

Gerelateerde artikelen:

Een pagina onmiddellijk verwijderen uit Google?

Google Analytics, P3P, iframes, Internet Explorer en cookies

André — Mon, 20 Apr 2009 19:55:04 +0000

Wat hebben deze termen met elkaar gemeen? Dat de combinaties van de laatste 3 vaak problemen opleveren voor een Google Analytics meting. En de 2de term een onderdeel is van de oplossing.

Dit zijn de problemen:

Google Analytics cookies doorgeven aan een (i)frame
Cookies in (i)frames met inhoud van externe domeinen worden geblokkeerd in Internet Explorer

Google Analytics, frames en iframes

Om op een goede manier het bezoek binnen een frame te meten moeten er een aantal zaken in het Google Analytics meetscript geregeld worden. Het ligt aan de situatie welke oplossing er het beste toegepast kan worden. Hieronder de diverse situatie met de bijbehorende oplossing:

Pagina met (i)frame op hetzelfde hoofddomein

voorbeeld.nl/hoofdpagina.html
voorbeeld.nl/pagina-in-frame.html

Omdat zowel de hoofdpagina als de pagina die in het frame geladen wordt op hetzelfde domein staan zijn er geen problemen met de meting. Op beide pagina's wordt er gebruik gemaakt van dezelfde cookies en hoeft er dus niets te gebeuren.

Pagina met (i)frame op een subdomein van hetzelfde hoofddomein

voorbeeld.nl/hoofdpagina.html
sub.voorbeeld.nl/pagina-in-frame.html

Omdat technisch gezien de beide pagina's op een ander domein staan maken ze allebei standaard gebruik van hun eigen cookies. Wat er dan gebeurd is dat in het (i)frame de hoofdpagina.html als verwijzende bron in de cookies geplaatst wordt. Dit is niet een gewenste situatie omdat je dan je eigen site als externe verwijzende bron gerapporteerd ziet worden. Er zijn 2 oplossingen. De eerste is door op het subdomein ook gebruik te maken van de cookies op het hoofddomein. Dit kan gedaan worden door de volgende regel in de Google Analytics meetcode op te nemen op beide domeinen:

pageTracker._setDomainName(".voorbeeld.nl");

De cookies worden dan op 1 centrale plaats gebruikt. Helaas werkt dit niet voor 2 letter domeinen, daar moet de cookie op "www.xx.nl" gezet worden.

De tweede oplossing (die je dus ook bij 2 letter domeinen moet gebruiken) is door de cookies van het hoofddomein mee te geven aan het subdomein. Dit kan gedaan worden door het (i)frame met javascript in de pagina te plaatsen:

Let op: de Google Analytics functies (ga.js) moeten wel al ingeladen zijn voor dit script gebruikt word. De _getLinkerUrl functie zorgt er voor dat de Google Analytics cookies meegegeven worden aan de URL van het (i)frame.

Pagina met (i)frame op een ander (sub)domein dan het hoofddomein

voorbeeld.nl/hoofdpagina.html
example.com/pagina-in-frame.html

Deze situatie komt bijvoorbeeld vaak voor bij externe boekingssytemen. Op een of andere manier wil je de Google Analytics cookies toch meesturen om zo de uiteindelijke conversie aan de juiste bezoekersbron toe te kennen.

In principe kan voor deze situatie dezelfde oplossing gebruikt worden als in bovenstaande situatie: schrijf het (i)frame met javascript in de pagina.

Maar dan komt het echte probleem: Internet Explorer ziet pagina's van externe domeinen die geladen worden in een (i)frame als Third Party Content. Oftewel: cookies vanaf deze pagina's worden door de beveiligingsinstellingen geblokkeerd. En omdat de cookies geblokkeerd worden zal er ook geen Google Analytics meting plaatsvinden. Dit kun je dan weer oplossen met P3P.

P3P en Internet Explorer

Wat is P3P dan precies? P3P staat voor "Platform for Privacy Preferences Project". Ik ga niet uitleggen wat het precies is, daar zijn anderen beter in en herhaling is ook zo saai. Maar de korte samenvatting is: "je koppelt een privacy beleid aan je site met een door computers en mensen te begrijpen inhoud".

Wat is er dan zo mooi aan? Met het juiste P3P privacy beleid zal Internet Explorer de cookies van het externe domein in het (i)frame keurig accepteren en zal er dus een Google Analytics meting plaatsvinden. De voordelen zijn:

Wanneer je site ingeframed wordt door een externe site zal dit keurig gemeten worden
Dit geldt dus ook voor de Google Image Search die ineens wel meetbaar wordt
Je Google Analytics meting is weer een stapje vollediger en betrouwbaarder

Een duidelijke zaak dus dat je dit geïmplementeerd wil hebben. Wat moet er voor gebeuren, hieronder stap voor stap de acties:

Toevoeging in de
In de moet een element opgenomen worden dat verwijst naar de plek waar de P3P instellingen te vinden zijn. Dit ziet er als volgt uit:

De locatie die ik hanteer is tevens de standaard locatie waar dit bestand zou moeten staan.

Inhoud van het P3P XML bestand

/*

Zoals je ziet staat hier weer een verwijzing in naar de plek waar de voor de computer te begrijpen privacy instellingen te vinden zijn. De inhoud van dat bestand kun je hier bekijken. Daarin staat het privacy beleid wat je voert beschreven, tevens een link naar de voor mensen te begrijpen privacy statement.

Toevoeging in de headers van je site
Bekijk eerst de HTTP headers van mijn site (handige tool om ook redirects te controleren). Zoals je kunt zien staat deze zin er in:

p3p: policyref="http://andrescholten.nl/w3c/p3p.xml", CP="NOI DSP COR CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT"

In deze header staat ook een link naar het P3P XML bestand en tevens een verkorte notatie van het privacy beleid. In WordPress kun je in je header.php op regel 1 op deze manier de header toevoegen:

De afronding
Nadat je zelf ook een publieke privacy statement online hebt gezet (wat verplicht is als je Google Analytics gebruikt), kun je je beleid valideren. Als alles goed is gegaan worden nu ook cookies van externe domeinen in een (i)frame geaccepteerd.

Tipje: ik heb deze P3P editor gebruikt. En alsjeblieft: ga me niet naar de verkorte notatie vragen die in de headers gebruikt worden. Zo zwaar heb ik me daar niet in verdiept, ik was alleen op zoek naar een oplossing voor Google Analytics

De resultaten

Wanneer ik nu mijn site in een (i)frame laadt vanaf een andere site worden toch de Google Analytics cookies geplaatst. Dit is bijvoorbeeld de (ingeknipte) inhoud van de utmz cookie wanneer ik een ingeframed bezoek doe vanuit de Google Image search:

__utmz
utmcsr=images.google.nl
utmccn=(referral)
utmcmd=referral
utmcct=/imgres

Lees ook hoe ik dit weer gebruik om de Google Image Search als zoekmachine door te meten inclusief het gebruikte zoekwoord.

Gerelateerde artikelen:

Google Image Search doormeten met Google Analytics

André — Mon, 20 Apr 2009 19:51:02 +0000

Dit artikel staat al even op mijn to-do lijst als reactie op deze post op Webanalisten. Daar werd beweerd dat de Google Image Search niet door te meten is met Google Analytics. Maar ik voelde dat dit prima zou moeten kunnen, dit heb ik ook nog in de comments genoemd. En vandaag is het dan zo ver, er is een oplossing.

Om de gebruikte zoekwoorden en verwijzingen van Google Images door te meten moeten er een aantal stappen gezet worden.

Google Images als zoekmachine toevoegen

Ten eerste moet Google Image Search als zoekmachine bekend gemaakt worden aan Google Analytics. Een gedetailleerde uitleg daarover staat hier: Zoekmachines toevoegen in Google Analytics. De regels waarmee de Image Search toegevoegd kan worden zijn dus als volgt:

pageTracker._addOrganic("images.google.com","prev"); pageTracker._addOrganic("images.google.nl","prev"); pageTracker._addOrganic("images.google.be","prev"); pageTracker._addOrganic("images.google","prev");

Zoekwoord opschonen

Zoals hierboven te zien is wordt er naar de "prev" parameter in de URL gekeken om het zoekwoord uit te halen. Deze bevat nog meer zaken dan alleen het zoekwoord:

&prev=/images%3Fq%3Dvingerhoedje%26gbv%3D2%26hl%3Dnl%26safe%3Doff%26sa%3DG

Om de extra zaken uit de URL te filteren moet het volgende filter ingesteld worden:

Kopieerbare tekst: images?q=([A-Za-z0-9_-+]+)&

P3P toevoegen

Bij het bekijken van een plaatje wordt je site ingeladen in een frame:

En Internet Explorer blokkeert cookies van pagina's in frames die vanaf een ander domein geladen worden. De oplossing hiervoor staat beschreven in dezelfde post: P3P. Wanneer je dit geïmplementeerd hebt staat alles klaar om de nieuwe zoekopdrachten binnen te laten komen.

Voor een aantal sites kan dit zeer interessant zijn. Van 1 site weet ik dat hij veel bezoek krijgt uit de Images Search (en terecht). Hebben jullie nog voorbeelden, is het handig?

Gerelateerde artikelen:

Waarom is de Site Overlay in Google Analytics stuk?

André — Fri, 13 Mar 2009 22:01:16 +0000

Er wordt mij vaak gevraagd waarom de Site Overlay functie in Google Analytics het niet doet. Nou, dat kan aan een aantal zaken liggen die ik hieronder 1 voor 1 ga behandelen, en als je geluk hebt kun je het dus oplossen. Ook leg ik direct een paar nadelen uit, en een paar alternatieve rapporten die ook mooie inzichten verschaffen.

De Siteoverlay

De Site Overlay staat in het "content" menu als logisch onderdeel omdat het te maken heeft met de content op de site. Je kunt de functionaliteit starten zodat je eigen website verschijnt met daarop kleine indicatoren bij elke link. De metric die de indicator weergeeft kun je zelf instellen zodat je zowel 'visits' als '$-index' kunt weergeven. Het visualiseert een beetje de links die vaak aangeklikt worden vanaf de bekeken pagina. En vooral omdat het visueel is, is het een redelijk populaire functionaliteit.

Dan de instellingen die goed moeten staan voor de meeste kans op een werkende Site Overlay:

Website URL

De eerste instelling die goed moet staan is de "Website URL" in de eigenschappen van het profiel waarin je de Site Overlay wil gebruiken. Deze instelling is te vinden door naast het profiel op "Edit" te klikken en vervolgens naast "Main Website Profile Information" weer op "Edit" te klikken. In het scherm dat dan verschijnt staat een invulveld "Website URL". Deze moet altijd met een keurige URL ingevuld zijn, in mijn geval ziet dat er als volgt uit:

URL's in Analytics

De 2de controle die je uit moet voeren gaat over de URL's die in Analytics gerapporteerd zijn. Komen deze exact overeen met de URL's in de site? Wanneer Google Analytics de Site Overlay laat zien zoekt hij bijvoorbeeld bij een link naar "Fietsen.html" het aantal kliks op. Hij kijkt of hij informatie over de URL van die link heeft en toont die. In het geval van uitgaande links zal hij dus geen informatie kunnen vinden en wordt er ook geen informatie getoond, logisch. Maar het kan dus gebeuren dat hij bij een interne link ook geen informatie kan vinden. De URL in Analytics is dan niet gelijk aan de echte URL, en de redenen kunnen zijn:

Sessie ID's (Fietsen.html?sessie-id=afjn324njwej42njk4)
Hoofd- en/of kleine letters (fIeTsEn.HtMl)
Verfiltering (is dat Nederlands?) (Fiets.html)
pageTracker.trackPageview('fiets'); (fiets)

Als je site met Sessie ID's werkt betekent het dat een bezoeker elke keer een nieuwe unieke code in de URL krijgt. Deze wordt dan ook doorgemeten in Google Analytics. Maar als je vervolgens zelf met de Site Overlay gaat kijken krijg je weer een nieuwe Sessie ID en zal Google Analytics de URL met de andere ID's er in niet meer herkennen. Hetzelfde geldt voor de andere 3 redenen, de gemeten URL is anders dan de echte URL en de Site Overlay kan geen informatie meer vinden over de links.

Gooi je cookies weg

In sommige gevallen was het weggooien van de Google Analytics cookies van een site al genoeg om de Site Overlay te laten werken. Ook kan het proberen in een andere browser soms een oplossing zijn.

Mocht er nu nog geen werkende Site Overlay zijn: dan heb je hoogstwaarschijnlijk pech, maar er zijn alternatieven, lees verder.

De Nadelen van de Site Overlay

Naast de veelal niet werkende Site Overlay kleven er ook andere nadelen aan. De grootste is dat er geen onderscheid wordt gemaakt tussen links die naar dezelfde pagina verwijzen. Wanneer je bijvoorbeeld in je hoofdmenu een link hebt naar je "Appels" pagina en die ook midden op de pagina hebt staan zal de Site Overlay bij beide links dezelfde getallen weergeven. En dat is nou juist wat je niet wil, je wil zo graag zien welke link men gebruikt heeft.

Er is wel een truc: bij 1 van de links voeg je iets aan de URL toe, maar dat is weer niet goed voor je SEO. Ook al kun je het op de "Appels" pagina weer opvangen met de meta-canonical, handig is het niet.

Nog een nadeel is dat je niet kunt welke links in eerste en welke in 2de instantie aangeklikt zijn. Alles wordt gewoon op 1 grote hoop gegooid.

Alternatieve pad analyse informatiebronnen

Een andere manier om te bekijken hoe bezoekers over je site gaan is de "Navigatie Analyse". Dit rapport staat gelinked op de "Content Overview" pagina. Ga naar dit rapport en zet 1 van je belangrijke pagina in het midden. Direct zie je welke 10 pagina's men voor deze pagina bezocht hebben en welke 10 ze vervolgens bezocht hebben:

Een rapport dat hier dichtbij ligt is het "Entrance Paths" rapport. Deze geeft je de mogelijkheid om vanaf een landingspagina te zien welke 2 pagina's na die pagina bezocht zijn. Ook kun je meer dan 10 pagina's tevoorschijn halen:

En de 3de mogelijkheid voor een pad analyse is door een "funnel" in te stellen op een aantal stappen. Je kunt dan in de "funnel visualisation" zien hoeveel bezoekers bepaalde stappen hebben gedaan en waar en waarheen ze afgehaakt zijn. Voor deze vorm van pad analyse zul je wel al van tevoren bepaalde paden (goal funnels) in moeten stellen.

Pad Analyse in het algemeen

Dan nog een algemene mening over het nut van pad analyse: het lijkt sexy, maar lees eens goed dit artikel van Avinash door. De korte samenvatting is dat pad analyse weinig zin heeft behalve wanneer de navigatie keuzes beperkt zijn (bijvoorbeeld in een bestel proces). Dit verwijst ook weer naar het 3de alternatief dat ik noem: de funnel analyse, en dan specifiek voor een bestel proces.

Succes

Gerelateerde artikelen:

Optimaal een nieuwsbrief doormeten met Google Analytics

André — Fri, 20 Feb 2009 08:34:05 +0000

In Google Analytics wil je graag al je externe campagnes keurig gerapporteerd zien. Dat doe je door deze campagnes te voorzien van Google Analytics campagne tags. Maar hoe richt je dit nou zo goed mogelijk in? In dit artikel wil ik ingaan op een goede manier van het doormeten van een nieuwsbrief. Hiermee wil ik niet zeggen dat dit de beste manier is, maar wel een manier die veelal de juiste informatie levert. Tevens geldt dit voorbeeld ook als inspiratie om andere soorten campagnes in kaart te brengen.

Welke tags hebben we

In Google Analytics kun je gebruik maken van een vijftal kenmerken om een campagne te beschrijven: bron, medium, content, woord en campagne. Deze beschrijving kun je toevoegen aan een link die naar je eigen site verwijst. Wanneer een bezoeker dan met deze waardes in de URL op je site komt weet Google Analytics precies welke campagne hier voor verantwoordelijk was.

Stel dat ik een link op een startpagina en een verzamelgids wil plaatsen en deze per klik moet betalen. Dan zou ik de URL's van deze links als volgt inrichten:

andrescholten.nl?utm_source=startpagina&utm_medium=cpc&utm_campaign=paidlinks
andrescholten.nl?utm_source=verzamelgids&utm_medium=cpc&utm_campaign=paidlinks

Wanneer er dan iemand op de betreffende pagina's op mijn link klikt zal ik hem in Google Analytics terug kunnen zien met als bron "startpagina" of "verzamelgids", en als medium "cpc". Ook kan ik in het campagne rapport een totaal overzicht krijgen van de "paidlinks" campagne.

Google heeft overigens een tool die je kan helpen bij het taggen: de URL Builder.

Hoe passen we dit toe bij een nieuwsbrief

Om een nieuwsbrief optimaal door te meten willen we graag een aantal zaken achteraf kunnen bekijken/rapporteren/analyseren:

Aantal bezoekers vanuit de nieuwsbrief
Aantal bezoekers per artikel, welk artikel was dus populair
Totaaloverzicht van alle nieuwsbrieven

Deze punten zijn te bereiken met de juiste campagne tags. Een goede opzet om deze tags te vullen is als volgt:

utm_source
In de bron vullen we de naam van de specifieke nieuwsbrief in. Zo is achteraf goed te zien hoeveel kliks er vanuit de verschillende nieuwsbrieven gekomen is. Ook kun je in het verkeersbronnen rapport de verschillende nieuwsbrieven naast elkaar zetten om ze de best presterende er uit te halen.

utm_medium
Als medium gebruiken we "email", "mail", "e-mail" of iets anders wat bij jou de standaard is. Zolang er maar 1 versie voor alle email gerelateerde campagnes gebruikt wordt. Anders worden die campagnes over meerdere mediums verdeeld.

utm_content
Deze hoeft niet in alle gevallen gebruikt te worden. Veelal wordt deze ingezet om elk bericht een eigen naam te geven. Maar dit is niet nodig aangezien je aan de landingspagina's van een nieuwsbrief prima kunt zien welke artikelen veel aangeklikt zijn. Een meer gangbare toepassing is het aanduiden van links op plaatjes, titels, of "lees meer" links. Zo kun je achteraf zien welke elementen eerder leiden tot een doorklik voor een artikel, dit kun je namelijk niet zien aan de landingspagina's.

utm_campaign
Als campagnenaam gebruiken we "nieuwsbrief". Dit doen we voor alle nieuwsbrieven zodat we in het "campagnes" rapport niet alle nieuwsbrieven als aparte items terug zien. Dit geeft je ook de mogelijkheid om na een jaar een totaaloverzicht te krijgen van de nieuwsbrieven ten opzichte van andere campagnes.

utm_nooverride
Een redelijk onbekende toevoeging is de zogenaamde utm_nooverride. Deze zorgt er voor dat de nieuwsbrief campagne geen andere campagnes mag overschrijven. Zonder deze toevoeging zal, wanneer men eerst via bijvoorbeeld AdWords op de site gekomen is en vervolgens via een nieuwsbrief terugkomt, de nieuwsbrief als bron bewaard worden. Toekomstige conversies en e-commerce transacties zullen dan ook aan de nieuwsbrief toegekend worden. Het nadeel hiervan is dat veel vaste bezoekers constant nieuwsbrieven krijgen en hiermee hun oorspronkelijke bronnen overschrijven.

Als je wil dat dit niet gebeurd kun je de utm_nooverride tag gebruiken. Wanneer men dan via AdWords komt en vervolgens via een nieuwsbrief, blijft AdWords bewaard als oorspronkelijke bron van het bezoek. Of het gebruik hiervan verstandig is ligt geheel aan de aard van de nieuwsbrief/mailing en de getallen die belangrijk zijn in de evaluatie.

Hoe zien links voor de nieuwsbrief er dan uit

Stel dat we een nieuwsbrief hebben met 2 artikelen waarin men op de titel of het bijbehorende plaatje naar de site kan klikken. De links zouden er dan als volgt uit kunnen zien:

andrescholten.nl?utm_source=nieuwsbrief-jan-09&utm_medium=email&utm_campaign=nieuwsbrief&utm_content=titel&utm_nooverride=1
andrescholten.nl?utm_source=nieuwsbrief-jan-09&utm_medium=email&utm_campaign=nieuwsbrief&utm_content=image&utm_nooverride=1

Voor beide artikelen kun je weer dezelfde links gebruiken want achteraf kun je aan de hand van de landingspagina's prima zien vanuit welk artikel er geklikt is.

Hoe zie het resultaat er uit

Als alles goed is getagged ziet het verkeersbronnen rapport er als volgt uit (getallen zijn fictief):

Om de populairste berichten te zien klik je in bovenstaand rapport op een specifieke nieuwsbrief. Vervolgens kies je in de "Dimension" pulldown voor "Landing page". De pagina's die dan verschijnen laten goed zien waar naar toe geklikt is:

En om een totaaloverzicht van alle nieuwsbrieven te zien kun je naar het campagne rapport gaan:

Best practice

De hierboven beschreven manier is 1 van de manieren waarop je een nieuwsbrief kunt taggen. Maar de ervaring leert dat dit tevens dé manier is die de meest handige informatie oplevert.

Succes met het taggen

Gerelateerde artikelen:

De Search Engine Strategies komt naar Amsterdam

André — Mon, 02 Feb 2009 10:01:00 +0000

Tot voor kort was de Search Engine Strategies (SES) een fenomeen waar je een flink reis voor moest maken. Ik ben er zelf nog in 2007 bij geweest in het Business Design Centre in Londen. Maar dat is nu verleden tijd want we hebben vanaf dit jaar onze eigen SES in Amsterdam. Waar we voorheen naar New York of Londen moesten om een glimp op te kunnen vangen van de grotere namen op SEO en SEA gebied, komen ze nu naar Amsterdam om hun verhaal te doen.

Het evenement is opgedeeld in 2 stukken: de eerste dag worden praktische trainingen gegeven, en de tweede dag is een congres waarop diverse presentaties bijgewoond kunnen worden. Een flink aantal interessante sprekers gaan los op allerlei onderwerpen die te maken hebben met SEO + SEA + Analytics. Als internationale sprekers kunnen we Bill Hunt en Kevin Ryan verwelkomen.

Ik heb er in ieder geval zin in, wie is van plan hier ook naar toe te gaan?

Gerelateerde artikelen:

Controleer of je een ban of penalty hebt van Google

André — Tue, 20 Jan 2009 19:38:14 +0000

Lees het volgende bericht van Mediadonis en bekijk voor jezelf of je een ban of penalty te pakken hebt. Er zit een tijdelijke fout in het pagerank algoritme dat speciaal voor Hyves lijkt te zijn gemaakt. Wanneer je voor je eigen site een hyves subdomein op pagerank controleert krijg je ook daadwerkelijk een pagerank terug. En afhankelijk van het getal wat je krijgt kun je zien of je een ban of penalty hebt.

Als ik met deze tool een aantal pageranks controleer zie ik dit:

http://hyves.andrescholten.nl, PageRank (7/10)
http://fake.andrescholten.nl, PageRank (0/10)
http://hyves.verzamelgids.nl, PageRank (7/10)
http://hyves.overzicht.nl, PageRank (4/10)
http://hyves.jouwpagina.nl, PageRank (0/10)

Ik heb op dat subdomein een pagerank 7: dus niets aan de hand. Heb je een 4 dan heb je waarschijnlijk een penalty omdat je links verkocht hebt. Heb je een 0 dan kon je wel eens een ban aan de broek hebben.

Disclaimer: het zijn geen feiten, maar de getallen lijken toch aardig te kloppen. Zo hebben enkele link-verzamelgidsen (startpagina klonen) een 4 of een 0. Ook worden er sites met een 3 of 5 waargenomen, waar dat voor staat is onbekend. En wees snel: want voor je het weet werkt het niet meer.

Gerelateerde artikelen:

SEO Rankings meten met Google Analytics

André — Tue, 23 Dec 2008 19:40:10 +0000

Een paar maanden geleden heb ik een filter gemaakt die SEO rankings van keywords zichtbaar kan maken in Google Analytics. Een goede reden om een nieuwe blog te maken dus.

*update: in plaats van het doormeten van pagina's kun je nu ook posities doormeten: SEO rankings meten met Google Analytics II

SEO Rankings meten?

Nou ja, je meet niet exact op welke positie een bepaald woord in Google staat. Maar wat je wel kunt achterhalen is de pagina waar hij op stond toen er op geklikt werd. Zo kun je er achter komen dat een woord met normale ranking software altijd op plek 15 lijkt te staan terwijl uit Google Analytics blijkt dat hij vaak op pagina 1 staat (plek 1 t/m 10). Dit kan bijvoorbeeld komen doordat veel mensen een bepaalde site hoger zien verschijnen door de 'personalised search' feature van Google. En andersom kan natuurlijk ook

Het filter instellen

Om de rankings naar voren te halen moet er een filter ingesteld worden die het een en ander combineert. Dit ziet er als volgt uit:

De titel van dit filter heeft een 3, filter 1+2 zijn bedoeld om alleen organic verkeer vanuit Google in het nieuwe profiel te filteren. Ja, een nieuw profiel: dan wordt er geen data overschreven in het origineel. En vervolgens doet filter 3 weer zijn werk daar op. Een kleine aanpassing is ook mogelijk door niet het zoekwoord uit de Referral te halen zoals ik doe, maar daar te kiezen voor "Campaign Term" en "(.*)".

De rankings

Als het filter enige tijd zijn werk heeft gedaan zien de resultaten er als volgt uit:

Je ziet achter de zoekwoorden een nummer staan. Dit nummer staat voor het nummer van het eerste resultaat op de pagina. Een 10 betekent dus pagina 2 in Google, en 40 pagina 5. En als er geen nummer staat maar alleen (pagina: ) dan heeft het woord op de 1e pagina gestaan. Wellicht is "pagina:" beter te vervangen met "minimale positie:". Dit kun je makkelijk in het filter aanpassen.

Wanneer je wilt zoeken naar woorden op positie 10 of hoger (pagina 2 en verder) kun je onderaan de lijst met zoekwoorden in het filter veldje filteren op "$pagina: \d{2,3}$". Dat bekent dat je digits (getallen) zoekt met een lengte van 2 of 3 cijfers.

Gerelateerde artikelen:

Een lage bouncerate door het gebruik van setvar?

André — Wed, 17 Dec 2008 21:36:27 +0000

Heb je wel eens gezien dat je weigeringspercentage of ook wel bouncerate flink omlaag ging bij het gebruik van de setvar functie in Google Analytics? Dat kan kloppen, hier heeft Google naar mijn mening een 'feature' ontwikkelt die zich niet in alle gevallen juist gedraagt.

Setvar?

Even een kleine uitleg over de setvar functie: hiermee kun je bezoekers een naam/groep/categorie geven. Je kunt bijvoorbeeld mensen die inloggen op je site "member" noemen. Of als je om de leeftijd van bezoekers vraagt kun je die er in opslaan. Deze waardes kun je vervolgens in je rapporten weer naar voren halen om te zien wat bijvoorbeeld je "members" doen ten opzichte van de andere bezoekers. Een handige functie dus die op een simpele manier wat eigen waardes in Google Analytics kan plaatsen.

* update, probleem speelt niet meer.

Lagere bouncerate?

Maar helaas zit er wel een neveneffect aan het gebruik van deze setvar functionaliteit. Google Analytics ziet een bounce namelijks als volgt: een bezoeker die binnenkomt op de site en vervolgens geen andere pagina's meer bezoekt. Maar nu komt de clou: die bezoeker mag ook geen andere acties meer verrichten.
Wat wordt er dan verstaan onder die andere acties? Alle handelingen die tot communicatie met de Google server leiden. Dus wanneer bijvoorbeeld een e-commerce script of de eerdergenoemde setvar functie geplaatst is vindt er communicatie plaats.
Dit houdt concreet in dat wanneer je op bijvoorbeeld je homepage de setvar functie gebruikt een bezoeker achtereenvolgens 2 aanroepen aan Google doet: een pageview en de setvar. En op dat moment is er dus geen sprake meer van een bounce. Je homepage zal in de rapportage dan ook een bouncerate < 1% laten zien.

We hebben dit aan Google voorgelegd omdat wij vinden dat een aanroep aan de setvar functie niet persé een actie is die door de gebruiker wordt gedaan. Hij mag dus ook niet meegenomen worden in het bepalen van de bouncerate. Vele andere analisten waren het hier mee eens, Google zou hier nog eens opnieuw over nadenken. Maar tot die tijd:

De oplossing

Wil je toch gebruik maken van deze functie zonder de metingen te verstoren kun je gebruik maken van de volgende truc:

var fakeTracker = _gat._getTracker("UA-1"); fakeTracker._setVar("member"); var pageTracker = _gat._getTracker("UA-xxxxxxx-y"); pageTracker._trackPageview();

Wat er nu gebeurd is dat de setvar handeling niet goed naar Google gestuurd wordt vanwege het verkeerde accountnummer. Maar de waarde wordt wel in de Google Analytics cookies opgeslagen. Vervolgens wordt er een pageview gedaan waarin vanuit de cookies ook de nieuwe setvar waarde wordt meegenomen. Het resultaat is dat je geen bounce hebt en wel gebruik maakt van de setvar functie.

Om dus vertekening van je data te voorkomen zou je altijd deze code moeten gebruiken.

Update

Google heeft het gedrag veranderd: de setvar heeft geen invloed meer op de bouncerate en tijd. Alle administrators van een Google Analytics account hebben hierover een mail gehad.

Gerelateerde artikelen:

Sfeerverslag bezoek Google Mountain View met Traffic4u

André — Fri, 05 Dec 2008 06:48:01 +0000

Het heeft even geduurd, en mijn blog is even inactief geweest, maar dat is voornamelijk te danken aan Google. Ze hebben een hele gave update gedaan waar heel veel mensen vragen over hebben. Daarnaast moesten we als Google Authorized Analytics Consultant (GAAC) ons melden op het hoofdkantoor. Vlak daarvoor nog een presentatie bij het Noordelijk Informatie Netwerk gedaan (binnenkort nog een keer) en vlak er na een presentatie bij Nyenrode-Bizz-Zibb-Reed Business-Elsevier. Samengevat: druk dus.

San Francisco

Ik zal hier niet heel lang op in gaan, maar San Francisco is een hele gemoedelijke en relaxte stad. Iedereen is vriendelijk en er is een overvloed aan leuke eettentjes, restaurants en kroegjes. Met een topless dubbeldekkerbus hebben we (ik en 2 collega's) als uber-toerist ons rond laten leiden langs de meeste bezienswaardigheden in San Francisco, prachtig en indrukwekkend. De hoogtepunten waren natuurlijk de Golden Gate met het uitzicht op Alcatraz en de skyline van San Francisco.

Fisherman's Wharf was leuk, maar meer ook niet. Men kent het fenomeen "terras" namelijk niet, en wij als rechtgeaard terrasliefhebber wilden op de werf van het uitzicht op de Golden Gate genieten al brandend in de zon en nippend aan een Anchor Steam (lokaal bier met vieze nasmaak). Een verdwaalde tafel van een restaurant werd hier dan maar voor misbruikt.

Verder is alles groot daar: de auto's, de koppen koffie, de tv's, enz. We zaten op een namiddag in een kleine kroeg aan Columbus Street een hapje te doen waar we tegelijkertijd op 4 LCD's, 3 plasma's en 2 oudere beeldbuizen een American Football wedstrijd konden volgen. Op elk stukje vrije muur hing gewoon een tv.

Na het weekend hebben we met de gehuurde SUV (ja, je wil je wel een beetje Amerikaans voortbewegen) een grote rondrit gedaan rondom de San Francisco Bay. Een lekker ontbijt in Sausalito tussen de arbeiders, een mooi uitzicht in de wijnvelden rondom de Napa vallei, een kort uitstapje op de campus van Berkeley behoorden allemaal tot de activiteiten. Aan het einde van de rit zijn we vlak na Stanford University in ons 2de hotel neergestreken om zo dicht in de buurt van Google te zitten.

Google, Mountain View

Er stond ons een vierdaags programma te wachten midden op de grote Google campus. Als oud SEO'er en inmiddels GA'er het heilige der heiligen. Daar gebeurt het allemaal, daar wordt aan het algoritme gesleuteld, daar heeft iedereen geheimen. Dit bleek dus wel mee te vallen aangezien het team dat ons en de andere partners ontving ontzettend open waren (hierover hieronder meer). Er hangt een hele goed sfeer rondom de gebouwen, werken bij Google is daar een 'way of live'. Je ontbijt er, je luncht er, je laat je hond daar door de uitlaatservice uit, je gebruikt 1 van de honderden Google fietsen, je dineert er (mits je tot 6 uur op kantoor bent). Tussen de werkzaamheden door kun je fitnessen, beachvolleyballen, basketballen, enz. De enige reden dat de werknemers een huis hebben is om te slapen, de rest van je leven speelt zich bij Google af. En ik kan me er wel wat bij voorstellen, we mochten meedoen met de 3 maaltijden per dag, en die waren niet misselijk. Het bevatte de gemiddelde luxe die je normaal alleen in een goed restaurant verwacht.

Dag 1: Google Website Optimizer

Deze hele dag stond in het teken van de Google Website Optimizer. Er werd gediscussieerd over bugs en features. Er was een verkiezing waarbij we uit een aantal presentaties over nieuwe functies de gewenste functie mochten kiezen. Met daarna een sessie waarin we openlijk met de developers konden praten over de wensen die er vanuit de partners waren. Er werd een roadmap + visie voor 2009 gepresenteerd en aansluitend nog enkele nieuwe technische snufjes die de tool nog krachtiger maken.

Dag 2 + 3: Google Analytics

Deze dagen waren inhoudelijk gelijk aan die van de Website Optimizer, behalve dat het dan om Google Analytics ging. We hebben nieuwe features gezien, we konden nieuwe features inleveren en uitgebreid discussiëren over allerlei issues binnen Google Analytics. We kregen van Google alle informatie die we wilden hebben, er was veel openheid. Eén ding is in ieder geval zeker: Google Analytics is nog niet uitontwikkeld, en er komen nog verschrikkelijk gave features aan.

De eerste dag werd trouwens geopend door Vint Cerf, de uitvinder van het TCP/IP protocol. Hij wordt daarom wel de Vader van het internet genoemd. Toch grappig zoals hij uitlegde dat hij 2 kantoren en een rijdend busje met elkaar in verbinding kon brengen, dat was de grondlegging voor het internet zoals wij het nu kennen. Tegenwoordig houdt hij zich bezig met het interlinken van ongebruikte satellieten om zo een netwerk in de ruimte te hebben waarover data verstuurd kan worden.

In de avond stond nog een kart-sessie gepland waarin 80 man zich mengden in een strijd om de eerste plaats. Collega Tim en ik plaatsten ons voor de finale-race (Janco had volgens eigen zeggen een kapotte kart...) die ik afrondde in een 3de plek. Ja Verstappen, zo doe je dat op internationale circuits

Dag 4: Urchin dag

De laatste dag was de Urchin dag. Veel bedrijven maken nog steeds gebruik van deze lokaal te installeren versie van de software. Uit de presentaties die dag bleek wel dat Google 100 keer zoveel programmeurs op Google Analytics heeft gezet dan op Urchin. Hier gaan wij dan ook waarschijnlijk niet veel aandacht aan schenken. Toch lijkt het in Duitsland nog veel gebruikt te worden, tenminste: onze Duitse partner had veel vragen over allerlei implementaties.

Partner zijn van Google

Het heeft ons verbaasd wat we allemaal te horen hebben gekregen op deze dagen. We hebben live omgevingen gezien waarin nieuwe functies al werkten. Screenshots van toekomstige features in aanbouw. We worden dus echt gewaardeerd als partner en dat doet ons goed. Ook werd er veel stilgestaan bij de vraag hoe Google ons het beste kan ondersteunen in het promoten van en helpen bij Google Analytics. Google levert alleen maar een dienst en is in de ondersteuning daarvan afhankelijk van de partners. Het is dan ook logisch dat ze die met zo veel mogelijk kennis op pad willen sturen.

Tot slot

Ik heb ongetwijfeld zaken overgeslagen in dit verslag, maar we hebben zoveel gezien en meegemaakt. Dit zijn in ieder geval de hoogtepunten. Ik zou zeggen: hou Google (en dit blog) het komende jaar in de gaten want er komt nog veel leuks aan.
Dan nog de groeten doen Alan, Jordan, James, Simon en Trevor (greetings from Holland), en daarnaast Michel en Simone als andere aanwezige Nederlanders.

Voetnoot: we staan natuurlijk wel onder NDA, daarom ga ik geen uitspraken doen over wat we exact allemaal gehoord en gezien hebben, daar naar vragen heeft dus geen zin

Gerelateerde artikelen:

Wat hebben Google Earth, Google Sketchup en Traffic4u gemeen?

99% van de Google Analytics implementaties is illegaal

André — Wed, 24 Sep 2008 21:43:17 +0000

Het klinkt nogal cru, maar toch is het waar: 99% van de Google Analytics implementaties staat illegaal gegevens te verzamelen. Google heeft namelijk de volgende passage in de Gebruiksvoorwaarden voor Google Analytics staan:

8.1 U mag gegevens afkomstig van Uw eigen Website(s) niet combineren (of derden toestaan gegevens afkomstig van hun eigen website(s) te combineren) met persoonlijk identificeerbare informatie uit welke bron dan ook. U dient zich te houden aan alle van toepassing zijnde privacy wet- en regelgeving met betrekking tot Uw gebruik van de Service en het verzamelen van informatie van bezoekers van Uw websites. U dient op een prominente plaats op Uw Website een adequaat privacybeleid op te nemen (en U daaraan te houden). U dient ook redelijke inspanningen te leveren om de aandacht van websitegebruikers te vestigen op een verklaring die in alle wezenlijke opzichten als volgt luidt:

"Deze website maakt gebruik van Google Analytics, een webanalyse-service die wordt aangeboden door Google Inc. ("Google"). Google Analytics maakt gebruik van "cookies" (tekstbestandjes die op Uw computer worden geplaatst) om de website te helpen analyseren hoe gebruikers de site gebruiken. De door het cookie gegenereerde informatie over Uw gebruik van de website (met inbegrip van Uw IP-adres) wordt overgebracht naar en door Google opgeslagen op servers in de Verenigde Staten. Google gebruikt deze informatie om bij te houden hoe u de website gebruikt, rapporten over de website-activiteit op te stellen voor website-exploitanten en andere diensten aan te bieden met betrekking tot website-activiteit en internetgebruik. Google mag deze informatie aan derden verschaffen indien Google hiertoe wettelijk wordt verplicht, of voor zover deze derden de informatie namens Google verwerken. Google zal Uw IP-adres niet combineren met andere gegevens waarover Google beschikt. U kunt het gebruik van cookies weigeren door in Uw browser de daarvoor geëigende instellingen te kiezen. Wij wijzen u er echter op dat u in dat geval wellicht niet alle mogelijkheden van deze website kunt benutten. Door gebruik te maken van deze website geeft u toestemming voor het verwerken van de informatie door Google op de wijze en voor de doeleinden zoals hiervoor omschreven."

Je moet dus op een prominente plek je bezoekers duidelijk maken dat ze gemeten worden met Google Analytics.

Maar wat als je dat niet doet? Ik ken nog geen voorbeelden van sites/accounts die geblokkeerd zijn door Google om deze reden. Is het dan puur een indekking van Google om bij privacy-gerelateerde zaken de meldplicht bij de website eigenaar te leggen ipv zichzelf?

Als we naar de websites van Brian Clifton en Avinash Kaushik kijken zien we dat beide heren dit keurig voor elkaar hebben. Zij hebben of de hele overeenkomst (waar normale mensen binnen 1 seconde op doorklikken) doorgelezen of ze hebben een opdracht gekregen van de (voormalig) baas. Ik vermoed het laatste, en zo lijkt het dat ze er bij Google wel degelijk op letten.

Je bent dus gewaarschuwd (net zoals ik)

Gerelateerde artikelen: