Uber Databook

Migrating tracking from Universal Analytics to GA4

When Google mandated the shift from Universal Analytics to GA4, I led the migration for Databook end to end. The two platforms don't share a data model — UA tracked interactions through a flat category/action/label structure, while GA4 is built entirely around events and parameters — so existing tracking couldn't be ported over as-is. I went through the tracking event by event, deciding how each UA hit should be represented in GA4's event/parameter structure, and rebuilt it accordingly.

The harder problem was structural, not mechanical: GA4 doesn't have "views," which is how UA had handled filtering and segmenting data for different teams. I worked out how to replicate that functionality using GA4's data filters, and made sure the migration didn't break continuity with the historical data teams already relied on for reporting.

Alongside the migration itself, I wrote the reference documentation the team uses to understand the new setup — the full event mapping, the views-to-filters approach, and the reasoning behind each decision, including how to set up the GA4 equivalent of views. It's still the doc people go to when they need to work with the new tracking.

Fixing a stale-data bug at its root

Rows kept reverting to stale values after a save. Chasing it past the network and the resolvers, I traced it to Apollo's cache identity: dynamically generated row IDs meant every backend update looked like a brand-new object to the client cache. Switching to a static, content-derived ID let Apollo match and merge updates against the existing entity instead of shadowing it.

A schema builder that speaks the data model

Adding a governed field to a dataset meant filing a ticket and waiting. I built a self-serve field composer that lets owners construct nested types — arrays, structs, and primitives — with a live type preview, so a request that took days now takes a minute.