> 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/optimize-your-setup/webhook-matching/reporting-identity-in-ga4.md). # Reporting Identity in GA4 What the Reporting Identity setting in GA4 does, the three available options, and the pros and cons of each for reading your data. ### What is Reporting Identity? Under **Admin → Data display → Reporting Identity**, GA4 decides how it stitches individual events — from the same visitor, on the same or a different device — into a single user/session before they land in your reports. This setting doesn't change which events come in, but it does change how GA4 assigns them to users and sessions — which directly affects the numbers you see in Reports, Explorations, and conversions. There are three options, in decreasing order of "how many identification methods GA4 is allowed to use": | Option | Uses | | ------------ | --------------------------------------------------- | | Blended | User-ID → Google signals → device ID → **modeling** | | Observed | User-ID → Google signals → device ID (no modeling) | | Device-based | Device ID only (`client_id`) | Important to remember: as soon as a User-ID is available, both **Blended** and **Observed** give it priority over the device ID (`client_id`) when deciding who caused an event. That makes these two options stronger for cross-device recognition, but also more sensitive to mistakes in how User-ID is sent — see the caveat at the bottom of this page. ### Option 1 — Blended Blended is the default setting for new GA4 properties. Besides User-ID, Google signals and device ID, GA4 also applies **modeling** here: for visitors who did not consent to `analytics_storage` (denied consent), Google uses machine learning to estimate their behavior based on the behavior of similar visitors who did consent. Google calls this *behavioral modeling for consent mode*. This modeling only happens once a property has enough volume: at least 1,000 events per day with `analytics_storage=denied` over a 7-day period, and at least 1,000 daily users with granted consent on at least 7 of the last 28 days. Below those thresholds GA4 shows no modeled data and the result stays the same as Observed. **Pros for reading your data** * Fills the gap left by cookie banners/consent refusal, so sessions, users and conversions sit closer to reality than the other two options — especially relevant with a low consent rate. * Best cross-device coverage: links visits across multiple devices to a single user whenever a User-ID or Google signals are available. **Cons for reading your data** * Modeled data is a statistical estimate, not a count — reports show a data-quality icon once estimated data is included, but beyond that most standard reports don't show which part of a number is modeled. * Modeled behavioral data isn't used in: audiences, some Exploration types, sequenced segments, Loyalty reports, predictive metrics, and BigQuery export — there you only see the observed portion. * Yesterday's data is often not (fully) modeled yet — day-over-day comparisons can look different on day one versus a few days later. * Because User-ID takes priority over `client_id` here, this option is the most sensitive to mistakes in how User-ID is supplied (see the caveat below). ### Option 2 — Observed Observed uses the same hierarchy as Blended (User-ID → Google signals → device ID), but without the modeling step for consent gaps. Whatever wasn't observed simply stays missing instead of being estimated. **Pros for reading your data** * Still has cross-device recognition via User-ID/Google signals, so it's better than Device-based for clients with logged-in accounts or Google signals. * All numbers are purely observed — no modeling, so no uncertainty about "is this number partly estimated". **Cons for reading your data** * No compensation for consent refusal: with a low consent rate this can come out noticeably lower than Blended, purely from visitors who aren't counted. * Same sensitivity to User-ID mistakes as Blended, because User-ID also takes priority over `client_id` here. ### Option 3 — Device-based Device-based uses only `client_id` (the cookie/device ID). User-ID and Google signals are ignored entirely, even if they are being sent. **Pros for reading your data** * Simplest, most predictable count: one `client_id` equals one "user", always based on what actually comes in. * Immune to mistakes in the User-ID implementation, since User-ID simply isn't taken into account — a wrong or inconsistent User-ID can't do any damage here. **Cons for reading your data** * No cross-device linking: the same person on phone and laptop counts as two users. * No compensation for consent refusal — usually the lowest numbers of the three, especially with a lot of cookie refusals. ### Caveat: User-ID mistakes can throw off counts under Blended/Observed Because Blended and Observed give User-ID priority over `client_id`, how you supply User-ID determines whether switching to one of these two options improves your data or distorts it. GA4's User-ID is a reserved, top-level field, meant only for a stable identifier of logged-in users, set consistently (for example via `gtag('config', ...)` before other events, and reset to `null` on logout). If a User-ID value doesn't meet those requirements — for example because it doesn't belong to the same session/`ga_session_id` as the rest of the visit, or because it's actually an internal matching ID that happens to also be called `user_id` — GA4 can end up counting events that actually belong to the same visit separately, under a different "Effective User ID". Concretely: purchase events that normally get deduplicated on `transaction_id` within one session can get double-counted as soon as you switch from Device-based to Blended/Observed — purely because of how User-ID was supplied, not because of any change in actual visitor behavior. See the **Webhook Matching** article for a concrete example of this: accidentally forwarding AdPage's internal BasketKey matching ID as GA4's `user_id`. ### Which option should you pick? * **Default advice:** leave Blended (the GA4 default) in place as long as User-ID is used correctly and consistently — or not sent at all. This gives the most complete numbers. * **When in doubt about the User-ID implementation** (for example while investigating a measurement discrepancy): temporarily switch to Device-based to check whether a discrepancy disappears. If it does, the problem is in the User-ID mapping, not in the underlying tracking data. * **No User-ID used or wanted at all** (e.g. a purely anonymous B2C shop without accounts): Observed and Device-based then give the same result as Blended without modeling — choose based on whether or not you want the consent modeling. ### Source Based on [\[GA4\] Behavioral modeling for consent mode](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/optimize-your-setup/webhook-matching/reporting-identity-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.