Skip to main content

​
Why did GA4 sampling change my numbers?

Sampling happens inside GA4, not inside Adriel. When a single query asks for more events than the property’s processing quota allows, GA4 returns an estimate based on a subset of events rather than every event. The connector detects this — whenever GA4 flags a report as sampled, a GA_SAMPLED_DATA warning is surfaced along with the sampling percentage, so a sampled figure is never presented as if it were exact. Sampled results are estimates and will shift between loads. Sampling likelihood rises with:
  • Wider date ranges.
  • More breakdowns applied at once.
  • High-traffic properties.
To reduce or avoid sampling, narrow the date range, apply fewer breakdowns, or split a wide report into smaller queries. A change in a sampled number between two views is expected behavior, not a data error.

​
How do custom GA4 events and fields show up in Adriel?

Available metrics and breakdowns are discovered on demand from the GA4 Metadata API for each property, so custom breakdowns and custom metrics defined in GA4 appear automatically in the field picker — no manual mapping is required. Custom GA4 events surface as selectable event-count metrics: each event name defined in the property becomes its own metric that counts occurrences of that event. Two behaviors are worth noting:
Up to a 12-hour lag on new fields. Property metadata is cached for 12 hours. A newly defined custom breakdown, custom metric, or newly fired event can take up to 12 hours to appear in the field picker after being created in GA4.
  • Cohort fields are excluded. Any metric or breakdown whose GA4 API name contains cohort is filtered out and does not appear in the picker.
  • Event discovery is capped. During field discovery, the event list is limited to keep the picker responsive, so a property with a very large number of distinct event names may not list every one.

​
Why does the GA4 real-time report look different from my Adriel dashboard?

The Adriel data source reads GA4’s standard reports through the Analytics Data API. GA4’s own Realtime report is a separate surface that covers only roughly the most recent activity using unprocessed data, so the two are not expected to match. Standard reports reflect GA4’s current processing state. GA4 typically considers data for the prior day fully processed within 24–48 hours, so very recent rows may still shift slightly as processing completes. For that reason, comparing a just-now figure in GA4’s Realtime report against a standard-report figure on the dashboard will show differences that resolve once GA4 finishes processing the range.

​
Why do my GA4 numbers differ between first-user and session-scoped attribution?

GA4 exposes three attribution scopes for traffic-source breakdowns, and the same date range produces different totals depending on which scope is selected. This is expected, not a discrepancy.
  • Event-scoped (for example source, medium, campaignName) — attributes each event to the source active at the time of that event.
  • Session-scoped (for example sessionSource, sessionMedium, sessionDefaultChannelGroup) — attributes every event in a session to the source that started the session.
  • First-user / acquisition-scoped (for example firstUserSource, firstUserMedium, firstUserDefaultChannelGroup) — attributes events to the source that originally acquired the user.
Because each scope assigns credit differently, a single conversion can be counted under different sources across the three views. When comparing traffic-source numbers, confirm that both figures use the same scope before treating a gap as a problem.

​
Why does a wide GA4 report show an “(other)” row, or drop rows?

Several GA4-side behaviors can make a wide, high-cardinality report look incomplete:
  • High-cardinality folding. GA4 folds high-cardinality breakdowns into a single (other) row once its per-property cardinality limits are exceeded. This is a GA4 processing behavior, not a connector behavior.
  • Privacy thresholding. GA4 may withhold rows with very small user counts for privacy reasons. Those rows do not appear even in an unsampled query.
  • Row cap. A single query returns at most 100,000 rows; wider results are truncated and a GA_ROW_LIMIT warning is raised.
To keep more detail, narrow the date range, reduce the number of breakdowns, or split the report into smaller queries.

​
Why didn’t marking an event as a key event change my historical numbers?

Marking an event as a key event in GA4 only affects reports from the time the change is made forward — it does not reclassify events that were already recorded. Historical key-event counts therefore stay the same after the change, and only data collected afterward reflects the new key event. This mirrors GA4’s own handling and is expected behavior.

​
Common issues

The GA4 metric and breakdown list is dynamic and comes from the GA4 API per property. A custom event or breakdown only appears if it has been created in that specific GA4 property; if the GA4 API doesn’t return it, Adriel doesn’t show it either.Separately, some GA4 connection failures are Google Workspace organization policies that restrict third-party apps. The customer’s Google admin needs to allow third-party apps or whitelist Adriel in the organization’s Workspace settings.
GA4 blend data aggregates at the ad-account level and groups only by UTM Source, UTM Campaign, and UTM Medium. Campaigns that share those three values (differing only in UTM Content) return the same GA4 numbers under each custom breakdown row.When GA4 Session Campaign Name is mapped to a marketing breakdown, the campaign name is applied as a filter — but a Facebook UTM value doesn’t equal Facebook’s own campaign name, so GA4 rows fall out as separate rows named by the session campaign name.Fixes:
  • Add a lower-level condition such as UTM Content to separate the campaigns.
  • Reconsider the campaign-name mapping if it’s forcing unwanted rows.
See also Data integration FAQs for the same behavior described from the blending side.