GA4 Scopes Begrijpen

Om jullie GA4-data correct weer te geven in onze app, moesten we begrijpen waar de verschillen vandaan komen tussen wat je ziet in de GA4-interface en wat wij zien via de GA4 API. We hebben ook net een GA4 BigQuery-implementatie gedaan voor een klant met een GA4 premium account, en ook hier hadden we dezelfde gesprekken met de business:

"Waarom is onze data anders in de (aangepaste) rapporten vergeleken met wat we zien in de UI!?"

Dit artikel begon als een Jira-ticket voor intern onderzoek en uitleg. Maar het werd behoorlijk diepgaand en ik denk dat het je kan helpen bij het beter begrijpen van data in GA4.

1. Waarom GA4 Scopes Belangrijk Zijn

In mijn jaren van werken met Google Analytics heb ik nooit zoveel verwarring gezien over data-nauwkeurigheid als met GA4-scopes. Ik heb dus uitgebreid onderzoek gedaan voor onze setup in Flipstream Pulse. Mijn conclusie van een veel voorkomende fout? Het mengen van verschillende scopes.

GA4's scope-systeem is als een meerlaagse taart - elke laag heeft een specifiek doel, maar mix je ze verkeerd, dan heb je een puinhoop. Helaas zie ik dit dus regelmatig gebeuren.

Wanneer je verschillende scopes mengt in je rapporten, toont GA4 in principe geen foutmeldingen ( stupid ), maar de data kan ( is ) behoorlijk onnauwkeurig zijn. De standaardreports zijn prima ingericht in de basis. Vooral bij gebruik van de rapportbouwer waar je zelf bepaald wat je ziet, krijg je altijd gewoon data terug. Maar zonder dat je het beseft vergelijk je soms appels met kantoorgebouwen 😬.

1.1 Impact op data-nauwkeurigheid

Stel je voor dat je de prestaties van je Black Friday-campagne in GA4 analyseert. In het User Acquisition rapport zie je dat Facebook advertenties 1.000 purchase conversies hebben gegenereerd. Dit rapport is gebaseerd op de eerste bron die de gebruiker naar je site heeft gebracht (user scope).

Vervolgens wil je in de rapportbouwer onderzoeken of er verschillen zijn in de devices die gebruikers gebruiken. Je gebruikt Session source / medium (een session-scoped dimensie) en purchases (een event-scoped metric) in je rapport om de conversies per sessiebron te analyseren. Je verwacht min of meer een vergelijkbaar resultaat voor Facebook als in het User Acquisition rapport. Tot je verbazing zie je in het aangepaste rapport een ander aantal conversies toegeschreven aan Facebook en een andere verdeling qua devices.

Het aangepaste rapport gebruikte de verkeerde scope. Het mengen van gebruiker-scoped dimensies met event-scoped metrics (conversies) en session Source ( of primary channel ) leidt tot allerlei misverstanden.

• Onjuiste conversiepercentages

• Misleidende verkeersbrondata

• Onnauwkeurige campagneprestatiemetingen

• Onbetrouwbare omzetrapportage

Met andere woorden: volledig foutieve data.

1.2 Veelvoorkomende misvattingen

• ❌ "Alle dimensies kunnen worden gebruikt met alle metrics"

• ❌ "Als GA4 de combinatie toestaat, moet het correct zijn"

• ❌ "Meer gedetailleerde data betekent altijd betere data"

• ✅ Realiteit: "In GA4 moeten rapporten alleen worden gemaakt met dimensies en metrics die tot dezelfde scope behoren" https://www.optimizesmart.com/ga4-scopes-explained-user-session-event-item-scopes

  
  

2. GA4's data hiërarchie begrijpen

GA4's datastructuur heeft een duidelijke hiërarchie waar je je bewust van moet zijn. Elke laag is anders en beïnvloedt de volgende, wat een complexe maar logische structuur creëert.

2.1 De Piramide van Datacollectie

Gebruiker (Hoogste Niveau)
   ↓
Sessies
   ↓
Events
   ↓
Items (Laagste Niveau)

Deze hiërarchie is niet zomaar voor de show - het beïnvloedt fundamenteel hoe GA4 je data verwerkt en rapporteert. Elk niveau legt logisch verschillende aspecten vast van gebruikersinteractie met je website of app. Zie https://support.google.com/analytics/answer/11080067 voor meer diepgang.

Ik weet dat als je dit zo leest, het voor de hand liggend klinkt. Maar ik ben veel situaties tegengekomen waar mensen zich niet bewust zijn van deze hiërarchie.

2.2 Hoe scopes met elkaar werken

Wanneer data door GA4 stroomt, volgt het een strikt hiërarchisch patroon:

1. Gebruikers bevatten meerdere sessies

2. Sessies bevatten meerdere events

3. Events kunnen meerdere items bevatten (in e-commerce)

Hier is het cruciale deel: Je kunt data niet betrouwbaar optellen van een lagere scope naar een hogere scope

• De eerste bron van een gebruiker (user scope) blijft constant

• Sessiebronnen kunnen veranderen bij elk bezoek

• Events kunnen hun eigen unieke bronnen hebben ( meeste sessie )

Daarnaast werkt het niet als we simpele "normale" wiskunde gebruiken zoals de som(data). Dit komt van hoe Google data opslaat in hun database. Daar kom ik in de volgende paragraaf op terug. ( dual tables )

3. Technische Aspecten van GA4 Scopes 🔧

3.1 API vs Report Builder: Verschillende Aanpak

Tijdens mijn analyses heb ik ontdekt waarom de GA4 Report Builder vaak andere getallen laat zien dan onze API-calls. Dit gebeurt tenzij je exact dezelfde aanvraag doet. Maar dat is niet echt mogelijk, omdat Google niet deelt hoe ze hun eigen tabellen bevragen. De Report Builder gebruikt waarschijnlijk een vergelijkbare API, maar blijkbaar niet dezelfde API als waar wij toegang toe hebben. Hierdoor kunnen we nooit garanderen dat er exact dezelfde query wordt uitgevoerd via de Report Builder als via de API. De officiële documentatie van Google https://support.google.com/analytics/answer/13644080 bevestigt dat dit by design is.

Een andere query betekend niet dat de data altijd anders of altijd hetzelfde is. Het komt vaak genoeg voor dat we exact dezelfde waardes terug krijgen. Het zijn vooral de averages die duidelijk anders zijn. En ook de sessies zit een verschil in van 1 - 3% over het algemeen.

Belangrijke kanttekening: hoe meer dimensies je toevoegt, hoe groter de kans dat de data verschilt van wat je via de API ziet. Laat staan als je het vergelijkt met BigQuery. GA4 in BigQuery vereist dat je de data zelf modelleert, en ook daar kun je op 12984 miljoen manieren de mist in gaan. Daarom zal ik deze vergelijking verder niet meer maken.

3.2 GA4's Dual Table System ⚡

Het meest frustrerende is dat wanneer je data downloadt via de GA4 API en vervolgens bijvoorbeeld de sessies optelt die waren opgesplitst per dimensie, ze simpelweg niet hetzelfde aantal opleveren als GA4 toont in de "totalen" wanneer je dezelfde setup gebruikt in hun report builder.

Fun fact: Niet veel mensen realiseren zich dit; maar de data die Google toont in de tabellen en de grafieken telt NIET op tot hetzelfde aantal als het totaal dat erboven staat als totaal. Dit wordt veroorzaakt door GA4's Dual Table System.

Ik heb daarom ( voor zo ver dat mogelijk was ) onderzoek gedaan naar GA4's architectuur. Er is niet veel over te vinden, maar ze delen wel wat vereenvoudigde informatie over het feit dat ze twee verschillende soorten tabellen gebruiken. https://support.google.com/analytics/answer/9371379

Waarschijnlijk een geavanceerde vorm van gematerialiseerde views (sorry als ik nu iemand bij GA4 beledig 😂) - maar het vereenvoudigt het punt. Een ander technisch detail is dat wanneer we count(distinct pages) doen op een BigQuery-tabel of pandas dataframe met GA4 premium account data (dus enórm veel data), we niet dezelfde methoden gebruiken als zij in hun geavanceerde databases waar ze tools zoals hyperLogLog algoritmes gebruiken voor preciezere (en snellere) tellingen op de ruwe data. Wij gebruiken dit trouwens ook voor de tools die ons wél meer ruwe data geven 🙌

Dit zijn de tabellen die Google benoemd te hebben:

Snelle Antwoord Tabellen (Fast Tables)

• Gebruikt voor standaard rapporten

• Vooraf geaggregeerde data ( totalen, averages, de getallen die bovenaan de tabellen staan )

• Lagere granulariteit maar snellere respons

• Beter voor inzichten op hoofdlijnen

Gedetailleerde Tabellen (Detail Tables)

• Gebruikt voor aangepaste verkenningen

• Ruwe event-level data

• Hogere granulariteit maar langzamere respons

• Kan andere resultaten tonen dan snelle tabellen
  
  

3.3 Sampling en Drempelwaarden 📊

Bij het analyseren van data in GA4 is het cruciaal om rekening te houden met twee belangrijke factoren die de nauwkeurigheid kunnen beïnvloeden: sampling en drempelwaarden (thresholding). Beide mechanismen worden door GA4 gebruikt om respectievelijk de verwerking van grote hoeveelheden data te versnellen en de privacy van gebruikers te beschermen. Hoewel ze essentieel zijn voor de werking van GA4, kunnen ze ook leiden tot vertekeningen en onnauwkeurigheden in je rapporten. Het is dus belangrijk om te begrijpen wanneer en hoe sampling en drempelwaarden van invloed zijn op je data-analyse.

Sampling Triggers (Wanneer GA4 een steekproef neemt):

• Je datavolume te hoog wordt (bijvoorbeeld miljoenen sessies)

• Je complexe queries uitvoert (bijvoorbeeld veel berekeningen)

• Je meerdere dimensies tegelijk gebruikt

• Je lange tijdsperiodes analyseert

Het gevolg? Je ziet niet meer alle data, maar een statistisch relevante steekproef.

Threshold effecten ( Drempelwaardeffecten ? )

Google heeft drempelwaarden ingebouwd om de privacy van gebruikers te beschermen.

Wat zijn drempelwaarden?

Drempelwaarden zijn de grenzen die GA4 gebruikt om te bepalen welke gegevens wel of niet beschikbaar worden gesteld, vooral bij lage gebruikersaantallen. Wanneer het aantal gebruikers in een bepaald segment te laag is (bijvoorbeeld minder dan 50), worden de gegevens verborgen om de privacy van gebruikers te beschermen. Dit kan leiden tot een onderdrukking van belangrijke gegevens, zoals demografische informatie of specifieke gebruikersacties.

Dit werkt als volgt:

Scenario 1: Lage Gebruikersaantallen

• Gevolg: Data Onderdrukking

• Bijvoorbeeld: Als er minder dan 50 gebruikers in een segment zitten

• GA4 verbergt deze data om privacy te waarborgen -> (Not set) bijvoorbeeld.

Scenario 2: Hoge Gebruikersaantallen

• Gevolg: Betrouwbaardere Data

• Voldoende gebruikers voor privacy-bescherming

• Volledige data wordt getoond

Het is dus belangrijk om niet alleen de term drempelwaarden te begrijpen, maar ook het effect ervan op de datanauwkeurigheid in je analyses. Wanneer je bijvoorbeeld een lage gebruikersbasis hebt, kun je te maken krijgen met gemiste gegevens die essentieel kunnen zijn voor je rapportages. Dit moet je altijd in gedachten houden bij het analyseren van data in GA4, vooral als je te maken hebt met kleinere segmenten of gedetailleerde analyses.

4. Best Practices voor GA4 Scopes 📋

Een effectief raamwerk voor het werken met GA4 scopes, gebaseerd op de officiële Google documentatie https://support.google.com/analytics/answer/11080067.

4.1 De Juiste Scope Kiezen: Beslissingsmatrix voor Scopes

User Scope (Gebruik voor):

• Eerste interacties met je website/app

• Lifetime value berekeningen

• Eigenschappen die weinig veranderen

• Initiële acquisitie analyse

• Voorbeeld: First User Source voor acquisitie-analyse

Session Scope (Gebruik voor):

• Analyses op bezoek-niveau

• Campagne performance

• Verkeersbronnen per bezoek

• Conversieratio's per sessie

• Voorbeeld: Session Source voor campagne-effectiviteit

Event Scope (Gebruik voor):

• Individuele interacties

• Real-time gedrag

• Specifieke conversiepunten

• Customer journey analyse

• Voorbeeld: Events voor specifieke acties zoals 'add_to_cart'

Item Scope (Gebruik voor):

• Product performance

• E-commerce metrics

• Product-specifieke attributen

• Koopgedrag analyse

• Voorbeeld: Item Revenue voor productomzet

4.2 Data Validatie Technieken

Wanneer je zelf, een collega of klant vragen heeft over de data, controleer dan het volgende:

Kwaliteitsindicatoren voor Goede Data

• Consistent gebruik van scopes binnen één rapport ( wij helpen je hier bij als je pulse gebruikt )

• Logische verhoudingen tussen metrics

• Realistische waardebereiken

• Correcte attributiepatronen

Waarschuwingssignalen ⚠️

• Gemengde scopes in één rapport

• Onverklaarde dalingen in data

• Niet-matchende totalen

• Attributieconflicten

5. Geavanceerde Scope Overwegingen 🎓

5.1 Attributie Modellen

Scope heeft een directe impact op je attributie keuze. Ik weet dat dit nogal technisch klinkt, maar het is cruciaal om hier bewust van te zijn. We hebben zelf twee dagen verspild aan het uitzoeken van een verschil tussen de UI en GA4 in BigQuery, simpelweg omdat we per ongeluk user scope gebruikten in plaats van session scope voor onze brontabellen 🤦‍♂️. We kregen nooit dezelfde conversiegetallen. Zo'n foutje sluipt er echt zo in.

Deze fout is zo makkelijk gemaakt en zo moeilijk te spotten. En wij zijn experts! Hoe kun je het dan iemand kwalijk nemen die geen data/GA4 expert is en één keer per maand in de report builder werkt? Ze selecteren "source" en "sessions" waar ze eigenlijk "sessionSource" hadden moeten gebruiken. Het gevolg? Ze tellen nu sessies op basis van de "event source".

Impact van Attributiemodellen per Scope:

User-Scope

• Standaard first-click attributie

• Permanente waardetoewijzing

Session-Scope

• Last non-direct click model

• Waarden resetten per sessie

Event-Scope

• Data-driven attributie (standaard)

• Flexibele modelkeuze

• Meest gedetailleerd attributieniveau

5.2 Cross-Scope Analyse

De belangrijkste richtlijnen bij het werken met meerdere scopes:

✅ Gebruik aparte tabellen per scope
✅ Join alleen op gemeenschappelijke identifiers
✅ Accepteer verschillen in datavolume

❌ Vermijd direct scope mixing
❌ Vergelijk niet over scope grenzen heen

Stel je wilt een Google Ads campagne analyseren waar gebruikers meestal meerdere bezoeken nodig hebben voor ze converteren. Je zou dan kunnen denken: "Laat ik first_user_source (user scope) combineren met session_campaign (session scope) om de volledige reis te begrijpen."

Waarom dit niet werkt:

Een gebruiker komt eerst via organische zoekresultaten, maar converteert later via je Google Ads campagne:

• User scope: Kent de conversie toe aan organic search (eerste bezoek)

• Session scope: Kent de conversie toe aan Google Ads (converterende sessie)

De betere aanpak:

• Analyseer eerst hoe gebruikers je site ontdekken (user scope)

• Analyseer daarna apart hoe je campagnes presteren in conversies (session scope)

Dit geeft je een accurater beeld van zowel acquisitie als conversie performance.

6. Tot slot 🎯

De kern van nauwkeurige GA4-rapportage is eigenlijk verrassend simpel: Je moet scopes respecteren en er bewust mee om gaan.

6.1 Essentiële aandachtspunten

1. De Data Beschikbaarheid Paradox

• Meer detail ≠ Meer data ( wordt uitgesloten voor privacy bijvoorbeeld )

• Drempelwaarden beïnvloeden gedetailleerde weergaven

2. De Scope Hiërarchie

• User (Hoogste niveau)

• Session

• Event

• Item (Meest gedetailleerd)

6.2 Eindaanbevelingen

1. Voor Standaard Rapportages

• Kies het juiste scope niveau

• Blijf consistent in scope combinaties

• Accepteer de ingebouwde beperkingen

2. Voor Geavanceerde Analyses

• Gebruik BigQuery voor volledige controle ( je count distinct zélf de sessies bijvoorbeeld )

• Handhaaf scope scheiding

• Documenteer scope beslissingen

Onthoud:

• Consistentie is belangrijker dan complexiteit

• Test je rapportages grondig

• Bij twijfel: kies de simpelere optie

• Documenteer je keuzes voor toekomstig gebruik

Gebruikte bronnen:

1. OptimizeSmart GA4 Scopes Article (2024): https://www.optimizesmart.com/ga4-scopes-explained-user-session-event-item-scopes/

2. Google Analytics Help - Traffic Source Dimensions (2024): https://support.google.com/analytics/answer/11080067

3. Google Analytics Help - Reporting Surfaces (2024): https://support.google.com/analytics/answer/13644080

4. Google Analytics Help - Data Differences (2024): https://support.google.com/analytics/answer/9371379

5. MeasureSchool GA4 Scopes Guide (2024): https://measureschool.com/ga4-scopes-of-traffic/

6. Google Analytics 4 Documentation: https://support.google.com/analytics/

7. GA4 API Documentation: https://developers.google.com/analytics/devguides/reporting/data/v1