Natuurlijk: je wil dat je transactiedata in Google Analytics overeenkomt met de salesdata in de backend van je webshop. Marketingbeslissingen maak je immers op basis van je Google Analytics data. Helaas is het zo dat deze getallen in de praktijk nooit overeenkomen.
Dit heeft verschillende redenen:
- Verschil ten gevolge van verwerkingstijd.
- Verschil ten gevolge van retouren.
- Verschil ten gevolge van geblokkeerde cookies.
- Verschil ten gevolge van bepaalde gebruikerskenmerken.
- Verschil ten gevolge van cross-domain trackingproblemen.
- Verschil ten gevolge van één betaalmethode.
Wat is een acceptabel verschil?
Om te kunnen bepalen of je te maken hebt met een acceptabel of onacceptabel verschil tussen je Google Analytics data en de data in de backend kun je de onderstaande richtlijn aanhouden:
Acceptabel (< 5%). Blijf het verschil monitoren, het is niet nodig om een gedetailleerd onderzoek te doen.
Waarschuwing (5% – 10%). Controleer je transactiecode. Probeer de issue te reproduceren door de transactiedata uit de backend naast de data in Google Analytics te leggen.
Niet acceptabel (> 10%). Grote kans dat er een fout zit in je Google Analytics configuratie. De data die je gebruikt om het succes van je campagnes te meten is waarschijnlijk niet juist.
Maar.. wat zorgt er nou eigenlijk precies voor dat er verschillen zijn in de transactiedata tussen Google Analytics en de backend van je webshop.
1. Verschil ten gevolge van verwerkingstijd
Een klassiek voorbeeld: wanneer de betaalgegevens ontvangen worden na werktijd en pas de volgende dag in de backend verwerkt worden. Andere systemen verwerken transacties in batches – pas op het moment dat ze een aantal transacties hebben ontvangen. Google Analytics daarentegen rapporteert deze transacties op het moment van de aankoop. Helaas is er weinig wat je hiertegen kan doen.
Tip: zorg ervoor dat de tijdzone geconfigureerd in Google Analytics overeenkomt met de tijdzone in je backend.
2. Verschil ten gevolge van retouren
Of het nu gaat om verkeerd geleverde of beschadigde producten of om consumenten die zich bedenken na het doen van een aankoop: alle e-commerce organisaties hebben te maken met retouren. Deze retouren worden wel geregistreerd in je backend maar vaak niet in Google Analytics. Dit terwijl het wél mogelijk is om retouren te rapporteren in Google Analytics. Ik zou het alleen niet aanraden – en wel om deze twee redenen:
Retouren zijn niet representatief voor je marketinginspanningen. Een voorbeeld: als ik online zoek naar “hardloopschoenen” en vervolgens een paar schoenen aankoop, dan is dat een transactie. Een transactie die een weerspiegeling is van je marketinginspanningen. Indien ik besluit om de schoenen te retourneren (vanwege de slechte kwaliteit van de schoenen), dan is dit het gevolg van het product. Dit staat dus los van de marketinginspanningen die geleverd zijn. De investering in de marketing hoeft dus niet te veranderen.
Het combineren van web analytics-data met interne systemen is vaak lastig. Dit omdat retouren vaak pas veel later na de aankoop plaatsvinden – en zich daarom in rapportages in een andere periode bevinden. Dit resulteert dan weer in verwarring.
Met andere woorden, Google Analytics is een tool om de reis die je klanten afleggen inzichtelijk te maken. Zo kun je op basis van inzichten je marketinginspanningen optimaliseren. Het is dus géén tool waarmee je retouren inzichtelijk moet maken.
3. Verschil ten gevolge van geblokkeerde cookies
Een groot gedeelte van de bezoekers blokkeert of verwijdert de trackingcookies van Google Analytics. Wanneer dit het geval is wordt er geen data verzameld (gebruiker blokkeert cookie) of wordt de gebruiker dubbel geteld (gebruiker heeft cookie verwijderd). Je kan dit probleem minimaliseren door een duidelijk, makkelijk te lezen en toegankelijk privacystatement op je website op te nemen.
Wil je weten of jouw gebruikers Google Analytics tracking blokkeren? Dat is mogelijk:
Mathijn Hoiting schreef er een interessante blogpost over.
4. Verschil ten gevolge van bepaalde gebruikerskenmerken
Soms kan het probleem zich alleen voordoen bij gebruikers die een gemeenschappelijk kenmerk delen. Kijk daarom altijd naar de verschillende browsers en browserversies in het rapport ‘Browser en Besturingssysteem’ in Google Analytics.
5. Verschil ten gevolge van cross-domain trackingproblemen.
In dit scenario refereer ik naar het gebruik van een betaalomgeving buiten het eigen domein. De bezoeker wordt bij het online betalen doorgestuurd naar het domein van de betaalomgeving – bijvoorbeeld iDeal of een Payment Service Provider (PSP). Sommige Payment Service Providers bieden de mogelijkheid om de Google Analyticscode op hun betaalomgeving te plaatsen. Als dit het geval is, dan dien je de cross-domain tracking te configureren.
Stel je dit niet in, dan wordt de sessie afgebroken op het moment dat de bezoeker naar de betaalomgeving gaat. Het gevolg is dat de betaalomgeving de conversie krijgt toegewezen, en dus niet de originele verkeersbron. Deze situatie wil je uiteraard voorkomen. De meeste Payment Service Providers bieden helaas echter geen mogelijkheid om deze aanpassingen door te voeren aan de betaalomgeving. Om toch transacties te kunnen meten heb je drie mogelijkheden:
1. Redirect naar de bedankpagina
Dit is een pagina waar bezoekers op terechtkomen nadat ze hun transactie hebben voltooid. Deze pagina is niet toegankelijk voor andere bezoekers. De e-commerce trackingcode dient dan op deze pagina te worden geplaatst.
Een groot probleem bij deze methode is echter dat klanten niet op de link klikken na het afronden van hun transactie. De transactie is immers afgerond. Natuurlijk is het vaak zo dat je na het afronden al automatisch wordt omgeleid naar de bedankpagina, maar ook hier wachten veel klanten niet op. Kortom, je loopt hierdoor een hoop transacties mis.
Tip: maak je gebruik van een redirect? Zorg dat het domein van je PSP wordt toegevoegd aan de lijst met verwijzigingsuitsluitingen in Google Analytics. Doe je dat niet, dan wordt er een nieuwe sessies gestart en gaat je attributie verloren.
Tip: zorg voor een minimale vertraging tussen PSP en de bedankpagina. Bij sommige PSP’s heb je de mogelijkheid om de melding van de redirect aan de klant te tonen op het moment dat deze ook daadwerkelijk wordt teruggestuurd naar de website.
2. Aankoopintentie
Deze methode trackt de transactie tot het punt waarbij de bezoeker jouw webshop verlaat richting de Payment Service Provider of de betaalomgeving. Je trackt hierbij niet de voltooide transacties, maar juist de aankoopintentie. Wellicht wordt de creditcard van je bezoeker geweigerd of bedenkt een bezoeker zich op het laatste moment. Wat de reden ook is, je e-commerce rapporten in Google Analytics geven hiermee slechts een ruwe inschatting van de werkelijkheid.
Tip: gebruik zoveel mogelijk formuliervalidatie voorafgaand aan de laatste klik. Op deze manier geef je de beoogde koper de best mogelijke kans om de betaling af te ronden en is jouw data zo accuraat mogelijk.
3. Server side callback
Google Analytics meet standaard via een stuk Javascriptcode dat geplaatst wordt op je webpagina’s. Het is ook mogelijk om een ‘data hit server side’ te genereren. Dit kan door gebruik te maken van het Google Analytics Measurement Protocol.
Een en ander werkt door – wanneer een betaling wordt bevestigd – de gateway van bijvoorbeeld een Payment Service Provider te laten communiceren met een zogenaamde ‘listener page’. De listener detecteert en verwerkt deze berichten in de backend. Wanneer je listener page wordt gepingd (de callback), zorg je ervoor dat de benodigde transactiehit met behulp van het Measurement Protocol wordt verzonden. De transactiehit is een gestructureerde URL die rechtstreeks wordt verzonden naar Google Analytics.
Deze methode vergt wel enige inspanningen van je backend developer. Dat wil zeggen dat – voorafgaand aan de aankoop – het Google Analytics ID (clientId), het IP-adres en de user-agent (browser handtekening) opgeslagen moeten worden. Deze informatie wordt opgeroepen en gebruikt in de transactie wanneer de callback wordt ontvangen. Dit moet gebeuren omdat de transactie gekoppeld moet worden aan de rest van de reis die de bezoeker op je website heeft afgelegd. Gebeurt dat niet, dan wordt er een nieuwe sessie gestart en gaat de attributie verloren.
Deze methode is 100% betrouwbaar en zorgt voor de meest zuivere data.
6. Verschil ten gevolge van één betaalmethode
Veel webshops bieden verschillende betaalmethodes aan. Het kan voorkomen dat bij één van deze betaalmethodes transacties niet geregistreerd worden in Google Analytics. Controleer dit door de transactie-ID’s uit Google Analytics te vergelijken met die in de backend. Wanneer je dit constateert doe dan een testbestelling om te controleren waar het mis gaat.
