GA4 implementation deep-dive: events, exports, and the gotchas in between

GA4 is the default measurement tool on the open web, which means most tracking debt in the wild is GA4-shaped. This guide covers the platform mechanics that matter at implementation time: the event model, the two deployment paths, the BigQuery export, the reporting distortions (thresholding, sampling, cardinality), and Consent Mode. For the vendor summary and alternatives, see the directory entry; for how it grades on privacy, see the scorecard.

The event model

GA4 has exactly one data primitive: an event with parameters. There are no hit types, no category/action/label, no session-scoped custom variables set at collection time. A page_view is an event; a purchase is an event; a scroll is an event. Every event carries up to 25 parameters (more via the Measurement Protocol and 360), plus user properties set separately.

Events come in four tiers, and the tier determines how much you get for free:

1. Automatically collected — page_view, first_visit, session_start, user_engagement. You do not send these; the SDK derives them.
2. Enhanced measurement — scrolls, outbound clicks, site search, video engagement, file downloads, form interactions. Toggled per web data stream in the UI, implemented by Google’s listeners, and a common source of double-counting when teams also fire their own versions.
3. Recommended events — names Google reserves with defined parameters (login, purchase, add_to_cart, the ecommerce suite). Use these names exactly: Google’s reporting surfaces, audiences, and Ads integrations key on them.
4. Custom events — anything else, subject to your own taxonomy. The dataLayer & Event Taxonomy Spec exists to keep this tier from becoming a landfill.

The most-missed step in the entire platform: custom parameters are invisible in reports until you register them as custom dimensions or metrics (event, user, or item scope) in the property settings. The data is collected either way — it appears in the BigQuery export and in DebugView — but standard reports and explorations only see registered dimensions. Registration is not retroactive for reporting surfaces, so register dimensions when you ship the event, not when someone asks for the report. Standard properties cap registrations (as of mid-2026, 50 event-scoped and 25 user-scoped custom dimensions), which is a real governance constraint: audit before you register, because slots are hard to reclaim.

gtag.js vs Google Tag Manager

Two deployment paths send identical hits to the same endpoint:

• gtag.js — the Google tag loaded directly, with gtag('config', 'G-XXXXXXX') and gtag('event', ...) calls hardcoded in the page or app code. Simple, explicit, version-controlled with your application — and every measurement change is a code deploy.
• GTM — a container with a Google tag for configuration plus GA4 event tags mapped from the dataLayer. Measurement changes ship without app deploys, at the cost of a second system with its own discipline requirements.

The practical rule: teams with a real tagging function use GTM; single-property sites with engineering ownership of analytics are often better served by gtag directly. What you should not do is both — a hardcoded gtag snippet and a GTM-deployed Google tag on the same page is the classic cause of doubled page_view counts. Use network inspection (or the Beacon Decoder on a captured request) to confirm exactly one collect request per logical event.

Server-side additions go through the Measurement Protocol, which requires a measurement_id and an api_secret and is designed to augment client-side collection — MP events attach to an existing client_id/session rather than creating full sessions with attribution, so it suits refunds, offline conversions, and backend milestones, not full replacement of the web tag.

The BigQuery export

The native BigQuery export is the single strongest reason serious teams tolerate GA4’s reporting layer: raw, unsampled, un-thresholded event-level data, free on standard properties. You get a daily events_YYYYMMDD table and optionally a same-day events_intraday_ streaming table in BigQuery.

Three things to internalize before you query it:

• The schema is nested. Parameters live in event_params as an array of key/typed-value structs; you UNNEST and pivot:

SELECT
  event_date,
  event_name,
  (SELECT value.string_value FROM UNNEST(event_params)
    WHERE key = 'page_location') AS page_location,
  (SELECT value.int_value FROM UNNEST(event_params)
    WHERE key = 'ga_session_id') AS session_id
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260710'
  AND event_name = 'page_view';

• The export is not the report. Sessions, engagement, attribution, and user counts in the GA4 UI come from Google’s processing (including modeled and blended identity); your warehouse rebuild from raw events will legitimately differ. Reconciliation is a modeling exercise — see sessionization — not a bug hunt.
• Standard properties have an export ceiling. As of mid-2026 the daily export is limited to around one million events per day on free properties; sustained overage pauses the daily export (streaming export is the workaround, at BigQuery ingestion cost). Plan for this before a high-traffic launch, not after.

Set the export up on day one even if nobody queries it yet: BigQuery only receives data from the day you link, and there is no backfill.

Thresholding, sampling, and (other)

Three distinct distortions get conflated as “GA4 is lying to me”:

• Thresholding hides rows, it does not estimate them. When a report could expose data about individual users — typically when demographics/Google-signals-derived dimensions are in play — low-count rows are withheld and the report shows the ⚠ identity icon. Totals stay right while breakdowns quietly lose rows. Mitigations: device-based reporting identity for the view, or the BigQuery export, which is never thresholded.
• Sampling applies to explorations (not standard reports) past a per-query event quota — on the order of 10M events per query for standard properties as of mid-2026. The exploration header discloses the sample rate. Shorten the date range, or move the question to BigQuery.
• Cardinality overflow produces the (other) row: when a dimension exceeds the daily unique value limits in standard reports, the tail is aggregated. High-cardinality values (search terms, full URLs with IDs, transaction IDs as dimensions) belong in the export, not in registered dimensions.

The pattern across all three: the reporting UI is a summarization layer with privacy and cost constraints; the export is the record. Decide per question which surface you trust.

Consent Mode

Consent Mode is Google’s mechanism for making tag behavior conditional on consent state. Version 2 (required for EEA ad features since 2024) defines four signals: analytics_storage, ad_storage, ad_user_data, and ad_personalization. Two implementation rules dominate everything else:

1. Defaults must be set before any Google tag fires. The gtag('consent', 'default', ...) call belongs above the tag snippet (or in a Consent Initialization trigger in GTM); the CMP then issues gtag('consent', 'update', ...) on user choice. Defaults set late are defaults ignored.
2. Know which mode you are running. Basic consent mode blocks Google tags entirely until consent — no data, no modeling input. Advanced mode fires cookieless pings while consent is denied, which feeds GA4’s behavioral modeling of unconsented traffic. Advanced mode collects data pre-consent; whether that is acceptable is a legal judgment for your jurisdiction and DPO, not a tagging default to copy from a blog post.

Verify the wiring end to end: consent state on the beacon (the gcs/gcd parameters, visible in the Beacon Decoder), not just the CMP’s own dashboard.

An implementation checklist

• One collection path per event — no gtag/GTM double-deployment.
• Recommended event names for anything Google defines; spec-governed names for the rest.
• Custom dimensions registered the day events ship; slots audited quarterly.
• BigQuery export linked on day one; streaming enabled if you are near the daily ceiling.
• Consent defaults before tag load; consent parameters verified on the wire.
• Data retention raised from the 2-month default to 14 months (the maximum on standard properties) — it only affects exploration lookback, and shorter buys you nothing.

GA4 rewards teams that treat the UI as a convenience layer over an event stream they own. The event model and the export are genuinely solid; most of the pain lives in the defaults.