GA4 event analysis workflow: from Explorations to BigQuery

1. Start with the trigger, not the tool

The workflow starts before you open Explorations. Name the exact event and the exact change: "signup_complete dropped 14% week over week" is a workflow you can run; "signups feel off" is not. If you haven't used GA4's free-form Exploration before, the GA4 exploration workspace walkthrough covers the UI itself — this article assumes you can already build a report and focuses on a different question: which tool to reach for, and when to stop reaching for a bigger one.

2. Answer with Explorations first — most questions stop here

Before opening a blank canvas, break the event down by three dimensions in this order: device_category, session_source_medium, and one event-specific parameter (for a signup event, that's usually method). In my experience this three-way breakdown resolves the large majority of "why did this event drop" questions on its own — a device split that shows the drop is 90% mobile, or a source/medium split that shows one campaign UTM stopped firing, is usually the whole answer. If the breakdown instead reveals the event is simply missing or misfiring for a specific step, the event quality scorecards article covers catching that systemically before it turns into a one-off investigation.

3. Know the three signals that mean Explorations won't get you there

Three signals mean it's time to stop drilling in the UI: a sampling banner on a high-traffic date range, a data-thresholding notice suppressing a low-volume segment (common with Google Signals enabled), or a question that needs logic Explorations can't express — "users who fired event A within 3 days of event B," for example, or a custom multi-touch attribution window. None of those are a UI skill problem; they're a tool-ceiling problem, and no amount of clicking around fixes them.

4. The BigQuery layer, at the smallest useful scope

GA4's BigQuery export lands one table per day (events_YYYYMMDD), with event parameters stored as a nested, repeated field that needs UNNEST to read. The smallest useful query for the signup-method question above looks like this:

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'method') AS signup_method,
  COUNT(DISTINCT user_pseudo_id) AS users
FROM `project.analytics_XXXXXXXXX.events_*`
WHERE event_name = 'signup_complete'
  AND _TABLE_SUFFIX BETWEEN '20260901' AND '20260907'
GROUP BY signup_method
ORDER BY users DESC

The first time I needed this, I ran a version of that query against the full events_* wildcard without a _TABLE_SUFFIX filter, for what was supposed to be a one-week question — BigQuery scanned four months of raw event data before I noticed. My take: scope the _TABLE_SUFFIX range before you write the SELECT, not after, on every single query against this table. It's the one habit that keeps a five-minute question from turning into a five-dollar one. One limitation worth flagging: the daily export table isn't available immediately — it typically lands about a day behind. If the question is about today's traffic specifically, you're querying the events_intraday_ table instead, and that one is incomplete until the finalized day export replaces it.

5. Close the loop with a decision log, not just an answer

Once a question is answered, write the finding and the query (or a link to it) somewhere shared — a doc, a wiki page, a pinned Slack thread. The analytics tooling decision tree article covers the broader version of this habit: without a log, the same question gets re-investigated from a blank Exploration every time someone new asks it, and the workflow above resets to step one instead of starting from a known answer. Tools like BigQuery's Conversational Analytics can now run a version of this lookup for you in plain English — the escalation judgment in this article still matters just as much once that's true, maybe more.

Make this workflow boring, not heroic

A workflow that only one person can run is a bottleneck with a name attached to it. The goal is for "check Explorations, know the three escalation signals, scope the BigQuery query, log the answer" to be routine enough that it doesn't depend on one analyst's memory. That takes more than one team:

Product supplies the exact user-facing change or release date that turns a vague "signups feel off" into a workflow-ready trigger.
Engineering owns the event schema and parameter names the BigQuery query depends on — a silent rename breaks every saved query downstream.
Data and analytics owns the escalation judgment call and the decision log, so the same question is never fully re-investigated twice.
Marketing and growth are usually the ones asking the question in the first place, and are the audience the answer needs to make sense to.