GA4 BigQuery Export: Query Raw Event Data Without Writing SQL

For marketing analysts, agency teams, and RevOps operators, a GA4 BigQuery export is the rawest GA4 data source most teams can work with. It gives you event-level data instead of another pre-shaped report. The catch: querying that export has historically meant learning BigQuery SQL, GA4's nested schema, and the difference between user, session, event, and parameter logic.

That is the gap this article covers. You can use GA4 BigQuery export without SQL hand-writing, but you still need the logic to be visible, reviewable, and tied back to the underlying GA4 fields.

What GA4 BigQuery Export Gives You That GA4 Reports Do Not

Google's GA4 BigQuery export documentation says Analytics can export raw events from GA4 properties into BigQuery, where teams can query that data and combine it with other business data.

That is the unlock. GA4 reports answer the questions Google designed the reporting surface to answer. BigQuery export gives you the raw event and user-level rows behind the property, excluding some of the value additions Google Analytics applies inside standard reports and explorations.

The practical differences matter:

• Raw event rows. You can inspect the events GA4 received rather than only the aggregates GA4 chooses to show in a report.
• Nested event parameters. The official export schema stores fields such as event_params, user_properties, and items as nested or repeated records. That is where page URLs, session IDs, campaign details, item details, and custom parameters often live.
• Higher-cardinality analysis. GA4 reporting surfaces can group high-cardinality values into (other) rows. Raw event rows let you work closer to the underlying collected values, subject to your export configuration and limits.
• Custom joins. Once GA4 is in BigQuery, you can join it with CRM exports, ad spend files, product data, revenue tables, or other warehouse data.
• More control over metric definitions. You decide whether a question is event-scoped, user-scoped, session-scoped, item-scoped, or campaign-scoped instead of accepting whatever a prebuilt report implies.

The cost is complexity. Daily exports create events_YYYYMMDD tables. Streaming exports create events_intraday_YYYYMMDD tables. Standard GA4 properties have a 1 million event-per-day limit for Daily batch export, according to Google's setup and limits documentation. Streaming export has no event-count limit, but it is best effort and BigQuery costs apply. If you need the setup flow, schema tour, and SQL examples, use the companion GA4 BigQuery export setup and schema guide.

So BigQuery export is not a magic cleaner version of GA4. It is more flexible, more granular, and easier to misuse.

"Without Writing SQL" Does Not Mean "Without Logic"

This is the part most "no SQL" messaging gets wrong.

BigQuery still needs query logic. The difference is whether you hand-write that logic yourself or ask a workspace like Anomaly's BigQuery analysis tool to generate it from a plain-English question and expose it for review.

For GA4 export work, reviewable logic matters because the schema is not flat:

• event_name tells you what happened.
• event_date gives you the event date in the property's registered timezone.
• event_timestamp gives you a microsecond UTC timestamp.
• user_pseudo_id identifies an anonymous user/device.
• user_id appears only if your implementation sets it.
• event_params stores event parameters as repeated key/value records.
• event_params.value can hold values in string_value, int_value, double_value, or float_value.
• Traffic source fields vary by table type and scope.

If you ask, "Which landing pages drove signups last week?", the generated logic still has to answer several hidden questions:

• Which event counts as a signup?
• Is the landing page stored as page_location, page_referrer, or a custom parameter?
• Are you counting events, users, or sessions?
• Is the query using settled Daily tables or partial intraday rows?
• Does the date window match the GA4 reporting timezone?
• Are source and medium event-scoped, session-scoped, or first-user fields?

No-hand-written-SQL analysis works only when those choices stay visible. If the logic is hidden, you have not avoided complexity. You have outsourced it to a black box.

The No-Hand-Written-SQL Workflow

Use this workflow when you want to query GA4 BigQuery export data without writing SQL from scratch.

1. Start with the business question. Do not begin with fields. Begin with the thing someone will act on: "Which landing pages drove demo requests last week?" or "Which source/medium changed after the campaign launch?"
2. Choose the grain. Decide whether the answer should be event-level, user-level, session-level, page-level, item-level, or campaign-level.
3. Map the GA4 fields. For most marketing questions, inspect event_name, event_date, event_timestamp, user_pseudo_id, user_id, event_params, collected traffic source fields, and session traffic source fields where available.
4. Choose Daily vs Streaming tables. For stable reporting, prefer events_YYYYMMDD. Google's export overview says streaming export is best effort and recommends Daily tables for stable user-attribution reporting.
5. Ask the question in plain English. Be specific about date range, metric, dimension, filters, and expected output.
6. Inspect the generated logic. Check the event filters, date filters, parameter extraction, joins, grouping, and metric definitions before trusting the answer.
7. Validate broad totals. Where possible, compare total event rows or broad event counts against GA4. Do not expect every UI metric to match exactly.
8. Turn the answer into an output. Once the logic is approved, save it as a dashboard, Excel report, Excel-native dashboard export, PowerPoint slide deck, Word doc, PDF, or scheduled reporting workflow.

Here is a plain-English prompt pattern that works well:

Using the GA4 BigQuery export in analytics_PROPERTY_ID, analyze [business question] for [date range]. Use settled Daily tables unless the question needs same-day partial data. Show the event names, event parameters, user/session logic, date filters, and assumptions used. Return the result as [dashboard/report/table], and flag any reason the result may not match the GA4 UI.

That prompt is not magic. It is precise. It tells the analysis layer what to produce and what logic to expose.

Decision Table: Question Type, Fields, Risk, and Anomaly Workflow

The table below maps common GA4 BigQuery export questions to the logic you should inspect before anyone forwards the result.

Question to ask	GA4 BigQuery fields or logic to inspect	Validation risk	How Anomaly helps
Which landing pages drove conversions last week?	event_name, event_params for page_location, conversion or key event name, and date window.	Wrong event name, wrong URL parameter extraction, or event-vs-session scope confusion.	Generates reviewable logic that maps page parameters to your chosen conversion event and turns the result into a dashboard or report.
Which source/medium changed after a campaign launch?	Collected traffic source fields, session traffic source fields where available, and Daily table logic for stable attribution.	Mixing first-user, event-level, and session-level traffic source concepts. See the guide on source, medium, and channel-group logic.	Keeps the field choices, grouping, filters, and date assumptions visible so the discrepancy can be explained.
How did users move from page view to signup?	user_pseudo_id, event_timestamp, event_name, and ga_session_id from event_params.	Incorrect event ordering, session reconstruction mistakes, or double-counting users across steps.	Builds repeatable path or funnel logic that can be inspected before it becomes a stakeholder chart.
Why do active users not match the GA4 UI?	user_pseudo_id, user_id, is_active_user, and reporting identity assumptions.	Comparing exact BigQuery counts with GA4 UI/API approximations, reporting identity settings, or thresholded report rows.	Shows the exact calculation and documents the comparison assumptions so the mismatch does not look like a data failure.
Which custom parameter explains the change?	event_params.key and the corresponding value field: string_value, int_value, double_value, or float_value.	Pulling the wrong value type or flattening a repeated parameter in a way that changes row counts.	Makes the parameter extraction logic visible and turns the approved result into an Excel, PDF, or dashboard output.
Can this become a weekly client report?	Saved metric definitions, source-backed calculations, date windows, and stable Daily table assumptions.	A one-off query becomes recurring report debt if the logic is not reviewed and saved.	Creates dashboards, Excel reports, Excel-native dashboard exports, slides, docs, PDFs, and scheduled reporting workflows with reviewable logic.

How To Validate a GA4 BigQuery Answer

Do not validate GA4 BigQuery answers by demanding exact parity with every GA4 screen. That is a trap.

Google's guide to comparing Analytics reports and BigQuery exports says some discrepancies are normal because Analytics and BigQuery do not always have the same available data. Google also says GA4 exports to BigQuery based on Device ID, so comparisons can be inaccurate if your GA4 reporting identity uses a different identity setting.

Use this checklist instead:

• Check the link and project. Confirm the GA4 property is linked to the expected BigQuery project and dataset.
• Match the date range. Compare the same start date, end date, and property timezone.
• Use settled data for important reports. Daily export tables can be updated for late-arriving events for up to three days after the event date, according to the schema documentation.
• Compare broad event totals first. Google suggests comparing total event rows in BigQuery to total event count in GA4, and notes that a 2-5% discrepancy can be expected.
• Check excluded streams and events. If your BigQuery link excludes a stream or event, your query will not match a GA4 report that includes it.
• Review metric scope. User, session, event, item, and campaign fields answer different questions.
• Account for approximations. The GA4 Data API expectations guide says UI/API unique counts can use HyperLogLog++ approximations, thresholding, sampling, and (other) rows.
• Inspect the query columns. If the broad export is accurate but the answer is off, the generated logic probably used the wrong field, wrong grain, or wrong filter.

If you are fighting a specific mismatch, use the companion guide on why GA4 export totals drift. Most "GA4 is wrong" debates are really scope, identity, date-window, or double-counting debates.

Where Anomaly Fits in a GA4 BigQuery Export Workflow

Anomaly is not trying to turn marketers into data engineers. It is an AI data analysis workspace for turning connected business data into reviewable outputs.

For GA4, that means two useful paths:

• Use GA4 analysis in Anomaly when the standard GA4 API is enough for the question.
• Use AI data analysis for BigQuery when the question needs raw event rows, custom parameters, longer retained history, or joins with other warehouse data.

In the BigQuery export workflow, Anomaly helps you ask the question in plain English, generate the underlying BigQuery logic, and review the logic before you share the answer. The review layer should expose field choices, filters, date windows, joins, calculations, metric definitions, and business rules.

Then the answer can become actual work product: an interactive dashboard, Excel report, Excel-native dashboard export, PowerPoint slide deck, Word doc, PDF report, scheduled report, or scheduled reporting workflow. That matters because the value of GA4 BigQuery export is not the query. The value is the recurring report, dashboard, or decision that survives review.

If your GA4 BigQuery export is already running, the next step is not another SQL tutorial. Connect the dataset, ask the business question, inspect the generated logic, validate the broad totals, and save the output your team can reuse.

FAQ

Can I use GA4 BigQuery export without knowing SQL?

Yes, if you use a workspace that can generate the BigQuery logic and expose it for review. You still need to understand the question, the metric grain, and the validation risks. You do not need to hand-write every UNNEST query yourself.

Does "without writing SQL" mean SQL is not used?

No. BigQuery analysis still runs on query logic. The honest claim is that you do not have to hand-write the SQL, and you can inspect the generated logic before trusting the output.

Why do GA4 BigQuery numbers differ from GA4 reports?

Common causes include reporting identity, time zone, excluded streams or events, sampled or thresholded reports, high-cardinality (other) rows, data freshness, and different user/session/event scopes. Google documents these differences across its BigQuery comparison and Data API reporting guides.

Which GA4 BigQuery fields matter most for marketers?

Start with event_name, event_date, event_timestamp, user_pseudo_id, user_id, event_params, collected traffic source fields, and session traffic source fields where available. The exact fields depend on whether the question is about users, sessions, events, pages, items, or campaigns.

Should I use Daily or Streaming tables for reporting?

Use Daily events_YYYYMMDD tables for stable historical reporting. Streaming events_intraday_YYYYMMDD tables are useful for same-day directional checks, but Google's documentation describes streaming export as best effort and recommends Daily tables for stable user-attribution reporting.

Can Anomaly turn GA4 BigQuery answers into reports?

Yes. Anomaly can turn connected GA4 or BigQuery data into dashboards, Excel reports, Excel-native dashboard exports, PowerPoint slides, Word docs, PDF reports, scheduled reports, and scheduled reporting workflows while keeping the logic reviewable.

Ready to query your raw GA4 BigQuery export without hand-writing SQL? Start with Anomaly, connect your dataset, ask the question in plain English, and inspect the logic before the answer becomes a dashboard, report, or recurring workflow.