Real-time, unvalidated ingestion into Mixpanel let rogue events spike Monthly Tracked Users, overcounting our user base by 1M+ per month and costing $20K monthly in overage fees — while Mixpanel numbers never matched our Snowflake source of truth. I redesigned the ingestion model around Snowflake and dbt.
Role Hands-on Data Product Manager — built the POC, authored the migration RFC, and led the move from real-time push to an automated Reverse ETL pipeline
Mixpanel's billing was tied directly to Monthly Tracked Users, and our real-time ingestion had no gatekeeper — so any rogue event or duplicate immediately inflated that number.
Artificially inflated MTU counts pushed us over Mixpanel's tracked-user limits, triggering recurring overage charges.
Stakeholders routinely found that Mixpanel's numbers didn't match the Snowflake warehouse treated as source of truth.
In the real-time setup, a failed stream or missing payload attribute meant that data was permanently lost in Mixpanel.
The overcounting, the discrepancy, and the data loss all came from the same source: events reached Mixpanel client-side, in real time, with no validation layer in between.
Without a validation layer, rogue code loops and duplicate event creation in the app spiked Mixpanel's user counts well above the real total.
Events were captured client-side or streamed in real time directly to Mixpanel, with nothing in between to dedupe, filter, or validate.
Re-architecting ingestion meant deprecating live pipelines data engineering depended on — a case had to be made with a working proof, not just a proposal.
I proved the approach with a working POC, then used it to drive an RFC, secure buy-in, and scope the migration to roughly 100 core events synced from Snowflake.
Manually modeled a subset of event data in dbt and synced it from Snowflake into a test Mixpanel project via a Reverse ETL tool, proving an exact match on user ID and event timestamp without real-time pipes.dbt · Reverse ETL
Authored an RFC mapping the exact upstream/downstream pipelines to deprecate, the required Snowflake schema changes, and the idempotency and backfill strategy needed to avoid duplication — then socialized it across data engineering and analytics to reach technical consensus.RFC · Snowflake
Used the $240K/year savings case and the RFC's engineering blueprint to secure resources and scope the migration down to roughly 100 core product and business events.Prioritization
Raw events land in Snowflake first, dbt models deduplicate, filter bot traffic, and standardize identities, then a scheduled Reverse ETL job pulls the cleaned ~100 events into Mixpanel.Snowflake · dbt · Scheduled sync
With Mixpanel running as a governed replica of Snowflake, product managers and leadership could run cohorts and funnels knowing the numbers matched corporate financial reporting — the recurring "two sources of truth" complaints stopped.
If a sync fails on a network issue or API limit, the pipeline simply re-triggers — data is ingested later with zero loss or corruption.
When a user attribute or event property updates after the fact, the pipeline can overwrite or append it post-ingestion, keeping historical data accurate rather than frozen.
Narrowing the footprint to ~100 automated offline events created a governed dictionary that's easy to maintain and scale.
Sacrificing a slight ingestion delay bought back historical mutability and bulletproof reliability — a trade-off proven out by the POC before engineering committed.
Let's talk
Tell me your biggest data or AI bottleneck and I'll send you how I'd approach it — the same way I worked this problem. No résumé dump, no pitch. Just a useful conversation.
Start the conversation →