> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/documentation/documentation-nl/optimaliseer-je-setup/webhook-matching/rapporteringsidentiteit-in-ga4.md). # Rapporteringsidentiteit in GA4 Wat de instelling Rapporteringsidentiteit in GA4 doet, de drie beschikbare opties en de voor- en nadelen van elk voor het lezen van je gegevens. ### Wat is rapportage-identiteit? Onder **Beheerder → Gegevensweergave → Rapportage-identiteit**, GA4 beslist hoe het afzonderlijke gebeurtenissen — van dezelfde bezoeker, op hetzelfde of een ander apparaat — samenvoegt tot één gebruiker/sessie voordat ze in je rapporten terechtkomen. Deze instelling verandert niet welke gebeurtenissen binnenkomen, maar wel hoe GA4 ze toewijst aan gebruikers en sessies — wat direct invloed heeft op de cijfers die je ziet in Rapporten, Verkenningen en conversies. Er zijn drie opties, in aflopende volgorde van "hoeveel identificatiemethoden GA4 mag gebruiken": | Optie | Gebruikt | | --------------------- | ---------------------------------------------------------- | | Gemengd | User-ID → Google-signalen → apparaat-ID → **modellering** | | Geobserveerd | User-ID → Google-signalen → apparaat-ID (geen modellering) | | Op basis van apparaat | Alleen apparaat-ID (`client_id`) | Belangrijk om te onthouden: zodra er een User-ID beschikbaar is, geven beide **Gemengd** en **Geobserveerd** er prioriteit aan boven de apparaat-ID (`client_id`) wanneer wordt bepaald wie een gebeurtenis heeft veroorzaakt. Dat maakt deze twee opties sterker voor cross-device-herkenning, maar ook gevoeliger voor fouten in de manier waarop User-ID wordt verzonden — zie de kanttekening onderaan deze pagina. ### Optie 1 — Gemengd Gemengd is de standaardinstelling voor nieuwe GA4-property's. Naast User-ID, Google-signalen en apparaat-ID past GA4 ook **modellering** hier toe: voor bezoekers die geen toestemming gaven voor `analytics_storage` (geweigerde toestemming) gebruikt Google machine learning om hun gedrag te schatten op basis van het gedrag van vergelijkbare bezoekers die wel toestemming gaven. Google noemt dit *gedragsmodellering voor toestemmingsmodus*. Deze modellering gebeurt pas zodra een property voldoende volume heeft: minimaal 1.000 gebeurtenissen per dag met `analytics_storage=denied` gedurende een periode van 7 dagen, en minimaal 1.000 dagelijkse gebruikers met verleende toestemming op minstens 7 van de laatste 28 dagen. Onder die drempels toont GA4 geen gemodelleerde gegevens en blijft het resultaat hetzelfde als Geobserveerd. **Voordelen voor het uitlezen van je gegevens** * Vult het gat op dat ontstaat door cookiebanners/weigering van toestemming, zodat sessies, gebruikers en conversies dichter bij de werkelijkheid liggen dan bij de andere twee opties — vooral relevant bij een lage toestemmingsgraad. * Beste cross-device dekking: koppelt bezoeken over meerdere apparaten aan één gebruiker zodra er een User-ID of Google-signalen beschikbaar zijn. **Nadelen voor het uitlezen van je gegevens** * Gemodelleerde gegevens zijn een statistische schatting, geen telling — rapporten tonen een pictogram voor datakwaliteit zodra geschatte gegevens zijn inbegrepen, maar verder laten de meeste standaardrapporten niet zien welk deel van een cijfer gemodelleerd is. * Gemodelleerde gedragsgegevens worden niet gebruikt in: doelgroepen, sommige typen Verkenning, sequentiële segmenten, Loyaliteitsrapporten, voorspellende statistieken en BigQuery-export — daar zie je alleen het geobserveerde deel. * De gegevens van gisteren zijn vaak nog niet (volledig) gemodelleerd — vergelijkingen van dag tot dag kunnen er op dag één anders uitzien dan een paar dagen later. * Omdat User-ID prioriteit krijgt boven `client_id` hier, is deze optie het gevoeligst voor fouten in de manier waarop User-ID wordt aangeleverd (zie de kanttekening hieronder). ### Optie 2 — Geobserveerd Geobserveerd gebruikt dezelfde hiërarchie als Gemengd (User-ID → Google-signalen → apparaat-ID), maar zonder de modelleringstap voor toestemmingshiaten. Wat niet werd geobserveerd, blijft simpelweg ontbrekend in plaats van geschat te worden. **Voordelen voor het uitlezen van je gegevens** * Heeft nog steeds cross-device-herkenning via User-ID/Google-signalen, dus beter dan Op basis van apparaat voor klanten met ingelogde accounts of Google-signalen. * Alle cijfers zijn puur geobserveerd — geen modellering, dus geen onzekerheid over "is dit cijfer deels geschat". **Nadelen voor het uitlezen van je gegevens** * Geen compensatie voor weigering van toestemming: bij een lage toestemmingsgraad kan dit merkbaar lager uitvallen dan Gemengd, puur doordat bezoekers niet worden meegeteld. * Even gevoelig voor fouten in User-ID als Gemengd, omdat User-ID ook prioriteit krijgt boven `client_id` hier. ### Optie 3 — Op basis van apparaat Op basis van apparaat gebruikt alleen `client_id` (de cookie-/apparaat-ID). User-ID en Google-signalen worden volledig genegeerd, zelfs als ze worden verzonden. **Voordelen voor het uitlezen van je gegevens** * De eenvoudigste, meest voorspelbare telling: één `client_id` staat gelijk aan één "gebruiker", altijd gebaseerd op wat er daadwerkelijk binnenkomt. * Ongevoelig voor fouten in de implementatie van User-ID, omdat User-ID simpelweg niet meeweegt — een verkeerde of inconsistente User-ID kan hier geen schade aanrichten. **Nadelen voor het uitlezen van je gegevens** * Geen cross-device-koppeling: dezelfde persoon op telefoon en laptop telt als twee gebruikers. * Geen compensatie voor weigering van toestemming — meestal de laagste cijfers van de drie, vooral bij veel cookie-weigeringen. ### Kanttekening: fouten in User-ID kunnen de tellingen onder Gemengd/Geobserveerd verstoren Omdat Gemengd en Geobserveerd User-ID prioriteit geven boven `client_id`, bepaalt de manier waarop je User-ID aanlevert of overstappen op een van deze twee opties je gegevens verbetert of vervormt. De User-ID van GA4 is een gereserveerd veld op topniveau, bedoeld alleen voor een stabiele identificatie van ingelogde gebruikers, consistent ingesteld (bijvoorbeeld via `gtag('config', ...)` vóór andere gebeurtenissen, en teruggezet naar `null` bij uitloggen). Als een User-ID-waarde niet aan die vereisten voldoet — bijvoorbeeld omdat die niet bij dezelfde sessie/`ga_session_id` hoort als de rest van het bezoek, of omdat het eigenlijk een interne koppelings-ID is die toevallig ook `user_id` — kan GA4 uiteindelijk gebeurtenissen die eigenlijk bij hetzelfde bezoek horen apart tellen, onder een andere "Effectieve User-ID". Concreet: aankoopgebeurtenissen die normaal gesproken worden gededupliceerd op `transaction_id` binnen één sessie dubbel geteld kunnen worden zodra je overschakelt van Op basis van apparaat naar Gemengd/Geobserveerd — puur door de manier waarop User-ID werd aangeleverd, niet door een verandering in het werkelijke gedrag van bezoekers. Zie het **Webhook Matching** artikel voor een concreet voorbeeld hiervan: per ongeluk AdPage's interne BasketKey-matching-ID doorsturen als GA4's `user_id`. ### Welke optie moet je kiezen? * **Standaardadvies:** laat Gemengd (de standaard van GA4) staan zolang User-ID correct en consistent wordt gebruikt — of helemaal niet wordt verzonden. Dit geeft de meest complete cijfers. * **Bij twijfel over de implementatie van User-ID** (bijvoorbeeld tijdens het onderzoeken van een meetverschil): schakel tijdelijk over naar Op basis van apparaat om te controleren of een verschil verdwijnt. Als dat zo is, zit het probleem in de User-ID-mapping, niet in de onderliggende trackinggegevens. * **Helemaal geen User-ID gebruikt of gewenst** (bijv. een volledig anonieme B2C-winkel zonder accounts): Geobserveerd en Op basis van apparaat geven dan hetzelfde resultaat als Gemengd zonder modellering — kies op basis van of je de toestemmingsmodellering wel of niet wilt. ### Bron Gebaseerd op [\[GA4\] Gedragsmodellering voor toestemmingsmodus](https://support.google.com/analytics/answer/11161109?hl=nl\&utm_id=ad) (Google Analytics Help). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.adpage.io/documentation/documentation-nl/optimaliseer-je-setup/webhook-matching/rapporteringsidentiteit-in-ga4.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.