Data Warehouse

Modern SaaS data warehouses use a cloud-native ELT (Extract, Load, Transform) architecture. Raw data is extracted from source systems (Salesforce, Zendesk, Stripe, Amplitude, PostgreSQL application database) via dedicated connectors (Fivetran, Airbyte, Stitch), loaded into the warehouse in raw form (Snowflake, BigQuery, or Redshift provide the cloud warehouse), then transformed into structured analytical models using a transformation layer (dbt — data build tool — is dominant). The resulting clean, modeled data is served to BI tools (Looker, Metabase, Tableau) for self-service analysis. Product Ops and Support Ops access this through pre-built dashboards, while analysts query directly in SQL. The warehouse enables questions no single operational system can answer: "What is the CSAT score for customers who have more than 5 tickets in their first 30 days, broken down by plan tier?"

The data warehouse unlocks cross-system analytical use cases that operational tools cannot support. Top use cases for Support Ops: ticket volume forecasting (combining historical helpdesk data with product release calendar and seasonal patterns), agent performance trending (CSAT and AHT over time with statistical significance), and deflection modeling (correlating help center article reads to subsequent ticket avoidance). Top use cases for Product Ops: cohort retention analysis (combining product event data with billing data to study how feature adoption affects renewal rates), activation funnel analysis (full funnel from email click to activation to conversion), and feature impact measurement (comparing behavioral metrics before and after an experiment). The unifying theme: these analyses require combining data from 3+ source systems, which is only possible through a centralized warehouse.

Data governance ensures the warehouse provides trustworthy, consistent metrics rather than conflicting numbers from different teams using different definitions. Core governance practices: a metric definitions registry (a documented, agreed-upon definition for every Key Metric — "CSAT" means exactly this field from this table, calculated this way); a data catalog (searchable index of all tables and their purpose, with field-level descriptions maintained by table owners); data quality monitoring (automated alerts when key metric values deviate abnormally from historical patterns); access controls (row and column-level security for sensitive data); and a data contract process (teams that consume data from a source system are notified before schema changes that would break their models). Product Ops typically co-owns data governance with the Data Engineering team.