Are there recommended patterns for fact tables? For example, should I have a table of events where

event_name

is a column and use the filters to build metrics per event?

There are many ways to go about setting up your fact tables, because we always wanted to ensure Fact Tables worked with most common event trackers + common data structures we see in users with custom data pipelines. In general, limiting the number of fact tables itself is recommended. However, whether you store that as wide data or long data depends a little bit on what's best for your cost structure with your data warehouse. I find wide a bit more intuitive with our UI, but we explicitly planned for people to have one long events table with ~one column and a variety of filters to create metrics from (as it seems you suggest). One note is we hope to add metric "dimensions" to help you slice your data not just by the user dimensions but also some dimensions of the metrics, so if that's another set of columns in your fact table we should eventually be able to build nice features to leverage that data.

Gotcha; that’s helpful context!