Choosing the Wrong Materialization Is Burning Warehouse Spend

A finance team flags that your warehouse bill jumped noticeably last month. Investigating, you find:

• int_orders_with_payments, an intermediate model joining orders to aggregated payments (a moderately expensive join across ~40M rows), is materialized as view. It's ref()'d by four different marts models (fct_orders, fct_revenue_by_region, fct_customer_ltv, and fct_refunds), each queried directly by a Looker dashboard that auto-refreshes every 5 minutes.
• stg_page_views, a thin staging model over a raw clickstream table with light column renaming and no joins, is materialized as table, rebuilt in full on every hourly run even though only one downstream model (int_sessions) ever reads it, and it's rebuilt completely every run regardless of how much new clickstream data actually arrived.

1. Explain the specific cost mechanism behind each of these two choices — why each one is more expensive than it needs to be.
2. Propose the correct materialization (or strategy) for each model, and justify the trade-off you're accepting by changing it.
3. stg_page_views sits at the very top of the DAG, directly on a source table with genuinely new rows arriving continuously. Would you consider incremental for it, or is a different fix more appropriate here — and why?