GA4 Pipeline -Episode 3: Collect | What GA4 Does With Events

Previous Episode 2: Send | gtag.js / Mobile SDKs

In the previous episode, we looked at how events are sent.

Now we move to the next step in the pipeline: Collect

This is where GA4 receives events and processes them before you ever see them.

What “collect” means in GA4

When events reach GA4, they are no longer under your control.

GA4 is responsible for:

Receiving events at scale
Applying server-side processing
Preparing data for reporting and export

At this stage, GA4 is not visualizing data yet. It is processing it.

Events are inputs, not final data

Google Analytics 4 (GA4) doesn’t store or expose data exactly as received.

Events via tags, Measurement Protocol, or uploads are raw inputs to a server-side pipeline that groups, models, and filters them into the insights you see in reports or BigQuery.

What GA4 Receives

Event name: e.g., page_view.
Parameters: Up to 25 key-values (e.g., value=49.99).
Timestamps: Event time and engagement.
Identifiers: User pseudo-ID, anonymized signals.

Queued for processing: real-time in ~30s, full derivations in 24 hours

Examples of processing during collection

Before data is exposed in reports or BigQuery, GA4 applies processing such as (these are only few of large processing):

Session grouping: Events are grouped into visits based on timing and signals.
Attribution processing: Traffic source and campaign information is evaluated.
Privacy enforcement: Consent and privacy rules affect what data is processed and exposed.
Thresholding and aggregation rules: Limits may be applied to protect privacy and support scale.

These steps happen after events are sent, but before you see the data.

Why GA4 feels like a black box

You do not see:

The raw processing steps.
All internal rules
Every decision made during collection

This is intentional.

GA4 is designed to balance: Scale, Privacy & Simplicity for most users

Understanding this prevents false assumptions about “missing” or “incorrect” data.

What’s Next?

Once events are collected and processed, the only thing left is interpretation.

This is where most people interact with GA4 through reports, explorations, and conversions.

In the next episode, we’ll look at interpretation, and why GA4 often struggles to explain behavior even when the data is technically correct.

→ Next Episode 4: Interpret: GA4 Reports & Explorations

Stop Treating Apache Iceberg Like an RDBMS

DATA ENGINEERING & ARCHITECTURE Why applying relational database update patterns to cloud lakehouses causes write amplification, high compute costs, and degraded query performance. Apache Iceberg is getting a lot of attention—and for good reason. It brings capabilities such as ACID transactions, snapshot isolation, schema evolution, time travel, and support

Columnar Storage and Collection Columns: Where Your Arrays and Maps Really Live

Columnar storage formats like Parquet and ORC, and columnar execution engines such as BigQuery, are widely used in analytics systems because they store data column by column on disk instead of row by row. When a query reads only the columns it needs, only those columns are read from disk,

How Block-Based File Formats Enable Parallel Processing

Conversations about data formats often focus on Parquet versus Avro, or columnar versus row-oriented storage. What is discussed less often is the block-based structure that actually enables files to be split and processed in parallel across distributed systems. This article explains that underlying mechanism. A block (e.g.

Own the fire: If you want to be a strong engineer and a real problem solver

Own the fire. * When things break, step forward. * Ownership under pressure is what separates engineers from passengers. * Roll up the sleeves * A fix without understanding is just moving the problem somewhere else. Don’t act blindly on someone else’s suggestion. * If it fails, you own the failure. * If it