Building a marketing funnel model, impression to click to signup to purchase. Debating a single wide fact_funnel_event table with an event_type column versus separate fact tables per stage.
Accepted answer
Separate fact tables make sense once stages genuinely have different grains or measures, like purchase having amount and currency that impression doesn't. Otherwise model those as satellite tables joined by a shared session_id instead of duplicating funnel logic.
Yes, the partial index was the win for us too.
What batch size or interval worked for you at similar scale?
Document the grain decision, most BI bugs turn out to be grain bugs.
In our case the root cause was an implicit cast preventing pushdown.
Simple way to think about it: caching is a bet that you'll ask the same question again soon. If you don't, you're just paying rent on memory for nothing.
Another path: push the compute to the warehouse if the data's already there.
Careful with NULL in join keys, they'll drop rows in an inner join.
A single narrow fact_funnel_event, one row per event with common columns only, plus a conformed event_type dimension usually wins for funnel analysis. It's what lets you compute conversion rates between arbitrary stages without N-way joins.
We replaced custom sensors with data contracts and row count checks.
Sign in to reply.
© 2026 Lakebench, operated by Hunnurji Rao. Bengaluru, Karnataka, India.
No cluster. No install. Just the tab.
