Skip to content
Back to Growth & Acquisition

Growth Data Stack

Build the data infrastructure (events, warehouse, transformation, dashboarding) that lets the growth team self-serve answers in minutes.

Why

The growth team's velocity is gated by how fast they can answer data questions — 'what's the activation rate for users from Reddit?' should take 2 minutes, not a 3-day ticket to the data team. A self-serve data stack (event tracking → warehouse → dbt transformation → BI tool) lets the growth team query, explore, and dashboard without a bottleneck, which is the difference between 3 experiments/week and 1. The stack also creates a single source of truth: when everyone queries the same transformed tables, there are no more 'my dashboard says 12%, yours says 15%' debates that waste meeting time. The investment is front-loaded (3 months to build) but permanent (the team self-serves for years), and it compounds as the accumulated transformed tables become a library that makes each new analysis faster. Without a data stack, the growth team is flying instruments-blind, making decisions on gut and partial data.

When

When the growth team asks 5+ data questions/week. Build the stack before scaling experimentation; data bottlenecks kill cadence.

How

1. Instrument events with a tracking SDK (Segment, Rudderstack): every user action (signup, activate, invite, pay) with user_id, timestamp, properties
2. Load events into a cloud warehouse (BigQuery, Snowflake) via the SDK's native connector; this is your single source of raw data
3. Transform with dbt: build models for users, sessions, funnels, cohorts, retention curves — versioned, tested, documented
4. Connect a BI tool (Mode, Looker, Metabase) to the warehouse; give the growth team query access, not just pre-built dashboards
5. Build 5-10 core dashboards: growth model, AARRR funnel, experiment results, retention curves, channel attribution — these are the daily tools
6. Write a data dictionary: every metric, its definition, its dbt model, its owner — so 'activation rate' means the same thing to everyone
7. Set up self-serve templates: SQL snippets for common questions (activation by channel, retention by cohort) that the team can parameterize
8. Measure data velocity: time from question to answer; target <10 min for the growth team, and re-audit as new question types emerge

Example

# Growth data stack
Events:    Segment SDK → every action tracked with user_id + props
Warehouse: BigQuery (raw events, 2 years retained)
Transform: dbt (models: users, sessions, funnel_steps, retention_curves)
BI:        Mode (growth team has SQL access + 8 dashboards)

# Core dashboards (daily tools)
1. Growth model: WAU = new + returning + reactivated + referred
2. AARRR funnel: per-stage conversion, by cohort and channel
3. Experiment results: live A/B tests with CIs and guardrails
4. Retention curves: D1/D7/D30 by cohort and channel
5. Channel attribution: CAC, payback, incremental lift per channel

# Data dictionary (excerpt)
activation_rate = count(users who performed core_action within 24h of signup)
                 / count(signups)
  dbt model: mart_growth.funnel_activation
  owner: @alice  |  refreshed: hourly

# Self-serve (question → answer time)
"Activation rate for Reddit users last 4 weeks?"
→ 2 min (parameterized SQL template, run in Mode)
# Before the stack: 3-day ticket to data team

Common Problems

  • ⚠No event tracking, so the growth team can't answer any behavioral question without a new logging ticket.
  • ⚠Multiple definitions of the same metric across teams, so every meeting starts with 'why is your number different from mine?'.
  • ⚠Pre-built dashboards but no query access, so any new question is a 3-day ticket to the data team.
  • ⚠No dbt transformation layer, so every query re-derives 'activation rate' from raw events and they all disagree.

Best Practices

  • ✓Instrument every user action with a tracking SDK; without events, the growth team is blind and every question is a logging ticket.
  • ✓Use dbt to build a single transformation layer with one definition per metric; this ends the 'why is your number different' debate.
  • ✓Give the growth team SQL access to the warehouse, not just pre-built dashboards; new questions need query access, not tickets.
  • ✓Write a data dictionary with every metric's definition, dbt model, and owner; shared definitions are the foundation of self-serve.