GA4 Pipeline -Episode 1: Google Tag Manager | Where GA4 Events Begin

Previous Episode 0: The GA4 Pipeline in One View

We’ll start with the first layer (Define) of the pipeline.

This is where Google Tag Manager comes into the picture.

Imagine you’re a marketer or analyst.

Your site already uses GA4, and GTM has been set up once.

Now you want to track visits to a specific page.

Without GTM

Ask engineers to change code
Wait for a sprint and deployment
Everything slows down

With GTM

Create an event in GTM
Name it and set a trigger (for example, page load)
Publish the change and deploy instantly
No application code change

What GTM enables

Define tracking without touching application code
Speed up launches
Test ideas without developer help

Code stays steady.

Tracking evolves fast.

What you define in Google Tag Manager

When you “create an event” in Google Tag Manager, you are defining three things.

Event nameA clear name that describes what happened(for example: page_view_pricing).
TriggerThe condition that decides when the event fires(for example: when a page loads or a button is clicked).
Metadata (parameters)Additional context sent with the event(page URL, button text, page category, content from textbox etc.).

That’s it. Everything else in GTM exists to support these three ideas.

Google Tag Manager as a data modeling layer

Google Tag Manager is often described as a “tagging tool.”

That description is incomplete.

In practice, GTM decides:

What events exist
When they are considered meaningful
What context is attached to them

These are data modeling decisions, not implementation details.

Once an event name, trigger, and metadata are defined in GTM, every downstream system sees the world through that model.

If the model is clean, analysis is easy.

If the model is messy, no report can fix it.

Common GTM pitfalls

Most GA4 issues don’t start in reports. They start earlier.

Inconsistent event naming
Events firing at the wrong time
Overloaded or unclear metadata

Small decisions here have large downstream impact.

GTM defines the shape of your data.

What’s next ?

Once events are defined, the next step is straightforward but often misunderstood:

How do events actually leave your site or app?

In the next episode, we’ll look at the send layer; gtag.js and mobile SDKs and clarify what this layer does, and just as importantly, what it does not do.

→ Next Episode 2: Send | gtag.js / Mobile SDKs

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