Why Is It So Hard to Follow What a Customer Does?

It sounds simple.

A person visits a website, clicks around, maybe signs up, maybe leaves, maybe comes back later. You’d think we could see that whole story clearly.

But in real life, tracking that path is painful.

It doesn’t matter if a company has its own engineers or uses tools like Google Analytics, Mixpanel, or Datadog.

Everyone hits the same wall: You can only understand what happened if you collected the right information in the first place.

And that’s where things get hard.

The main problem: keeping tracking up to date is never-ending work

To follow a customer’s journey, you need to track events (like clicks or signups).

Events need instrumentation. That means deciding what to track, writing code for it, naming things clearly, and sending extra details so the data makes sense later.

Most of this work is separate from building the actual product.

Engineers are busy shipping new features and fixing bugs. Tracking often comes last.

So the product keeps changing, but the tracking doesn’t always keep up.

A new page gets added → tracking missing
A checkout flow changes → old tracking breaks
A button gets renamed → events stop matching
A feature moves → data gets confusing
A backend service changes → events disappear

Each small change can quietly create a gap in your journey data.

That’s the real challenge: Customer journey tracking isn’t a one-time setup. It’s ongoing maintenance.

When that maintenance gets ignored, companies end up with:

Missing events
Confusing event names
Duplicate events
Data that exists but doesn’t explain what really happened

So when someone asks: “What did users do right before they left?” or “Which path led to a purchase?”. The answer is often much harder to find than expected.

That’s exactly the problem we’re building Zinzu to solve

Our goal is simple: help companies understand customer journeys with far less effort . Without constantly chasing missing data, renaming messy events, or rebuilding tracking every time the product changes.

Zinzu is being built to turn raw customer activity into a clear, complete story, with much less manual work.

I’ll explain how we do this in another post.

visit zinzu

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