Universal Analytics versus Google Analytics 4- Wat is er precies veranderd?

Een van de meest verwachte functies van GA4 is de mogelijkheid om website- en app-gegevens in dezelfde property te volgen. GA4 maakt gebruik van hetzelfde meetmodel als Google Analytics Firebase (gebruikt voor mobiele apps), waarbij alle interacties worden vastgelegd als gebeurtenissen (meer daarover onder punt 2 hieronder). Dit nieuwe uniforme schema van gegevens tussen een website en een mobiele app betekent dat het veel gemakkelijker wordt om conclusies te trekken aan de hand van data die vanuit beide verzameld wordt.

Een ander belangrijk verschil tussen UA en GA4 is de manier waarop interacties worden vastgelegd. In UA werden interacties telkens vastgelegd in veel verschillende soorten hits, zoals paginabezoeken, transacties en sociale interacties. In GA4 daarentegen wordt elke interactie vastgelegd als een gebeurtenis (event). 

Events bestonden ook in UA; met een bijbehorende categorie, actie en label; maar deze classificaties bestaan niet in GA4. In plaats daarvan werkt GA4 met parameters die betrekking hebben op de gebeurtenissen. Deze geven dan verdiepende informatie over de actie (gebeurtenis) die een gebruiker ondernam. Sommige event parameters worden automatisch verzonden, bijvoorbeeld page_title. Verder ben jij als webbeheerder zelf vrij om aanvullende events te registreren, tot een maximum van 25 parameters bij elke event. 

Aangezien de gegevensmodellen fundamenteel anders zijn, zal Google je aanraden bestaande event logica niet zomaar over te nemen van UA naar GA4, maar nieuwe logica te implementeren die zinvol is in deze nieuwe context. Hoewel het waarschijnlijk wat tijd zal kosten om uit te vogelen hoe jij hier het best op in kunt spelen, zal op den duur waarschijnlijk blijken dat deze verandering zal leiden tot een beter inzicht in de acties die gebruikers op jouw website ondernemen.

Een ander verschil tussen UA en GA4  dat je waarschijnlijk meteen  zal opvallen  als je de  metrics die worden verzameld door beide systemen gaat vergelijken, zijn de verschillende waarden voor sessies. 

In UA staat een sessie voor de periode dat een gebruiker actief bezig is op jouw website. Nadat een gebruiker op jouw site heeft  geklikt, zijn er 3 zaken  te  onderscheiden die Google interpreteert als een eindigende sessie:

• 30 minuten inactiviteit, of een ander aantal minuten dat jij hier zelf voor  hebt ingesteld
• Het begin van een nieuwe dag als  de klok  middernacht slaat. Hier start logischerwijs een nieuwe sessie.
• Het tegenkomen van nieuwe campagne parameters (d.w.z. als je UTM-parameters gebruikt voor interne links op je website. Dit raadt google dan ook af.

In GA4  genereert de session_start event daarentegen een session ID waarmee alle volgende events tijdens de sessie worden geassocieerd. Net als bij UA eindigt een sessie automatisch na 30 minuten inactiviteit , maar sessies kunnen nu worden overgedragen op middernacht en worden niet beïnvloed door nieuwe campagne parameters. Vooral als jouw website door gebruikers van over de hele wereld wordt bezocht, kan het verschil in sessies dat je in GA4 zal waarnemen, significant verschillen met de data uit UA. 
 

Met GA4 zijn BigQuery exports beschikbaar gemaakt voor alle properties (voor UA was dit beperkt tot Analytics 360 properties). Dit betekent dat je in staat bent om ‘raw events’ naar BigQuery te sturen, die vervolgens met SQL kunnen worden opgevraagd. De functie zelf kost niets zolang het gebruik binnen de sandbox-limieten voor BigQuery blijft.  Wat hierbij op te merken valt, is dat de sandbox-omgeving opvallend genoeg geen streaming data ondersteunt.

Enkele van de meer opvallende metrics die in GA4 compleet zijn weggelaten, zijn de waarden  met betrekking tot bounces. In plaats daarvan heeft Google gekozen voor een meer "positieve" benadering en rapporteert het in plaats daarvan een  engagement percentage. Simpel gezegd weerspiegelt deze metric een verhoudingscijfer dat als een percentage wordt gepresenteerd. Deze statistiek wordt berekend door het aantal ‘engaged sessions’ te delen door  het totale aantal sessies.

Hierbij  ben jij  natuurlijk nieuwsgierig naar hoe Google een engaged session dan precies definieert. Hierbij stelt Google de volgende vereisten aan een sessie: deze moet 10 seconden duren, minstens 1 conversie-event ten gevolge hadden of minstens 2 pagina's/schermweergaven genereerden. 

Ik hoor je denken: Bestaat het bouncepercentage dan helemaal niet meer  in GA4? 
In principe bestaat deze nog wel. Waarschijnlijk viel het je de berekening van de engagement rate immers al op dat deze in principe precies het tegenovergestelde van de bounce rate berekent.  In Google Analytics weerspiegelt de bounce rate namelijk het  percentage van de sessies die niet tot engaged sessions worden gerekend. In principe zou je dus alsnog de bouncerate van jouw website kunnen tracken. Deze vind je immers simpelweg door de volgende formule:  bounce rate = 100% - engagement rate. 

Toch kun je dit percentage misschien beter niet 1  op 1 vergelijken met de bounce rate die UA voor je berekende. Deze berekende UA immers  als het percentage gebruikers dat niet meer dan één pagina op jouw website bekeek. Dit verschilt dus ietwat met hoe Google ‘non-engaged sessions’ definieert in GA4.

Als jij eigenlijk alleen gebruik maakte van de basisfunctionaliteiten van UA, kon je die in principe ook zonder Google Tag Manager gebruiken. Je kon om dit te realiseren dan  bijvoorbeeld bestemmingspagina-conversies kunnen maken in Google Analytics zelf. 

Binnen GA4 is dit niet meer mogelijk. Alles draait nu immers om events. Het is  daarom belangrijker dan ooit om je een weg te vinden in Google Tag Manager.  Los daarvan is het sowieso verstandig om Tag Manager (of GTM) goed te begrijpen en ermee te kunnen werken. Zo kun je immers gedetailleerdere data verzamelen. Je hebt het bijvoorbeeld nodig om aangepaste events en aangepaste dimensies te creëren.