Growth Engineering
Date: 2026-08-16
The engineering a growth team needs built before any of its tactics work: measurement you can trust, experiments you can run safely, releases you can undo, and messaging that fires off real events. It’s infrastructure work judged on commercial outcomes.
A cross-domain view. Ordered as a build sequence — each layer is unusable until the one above it holds.
Draws on Web Development, Analytics, Experimentation and Commerce & Growth.
1. Measurement you can trust
Nothing downstream is worth building until this holds. Every growth team that skipped it spent a year making decisions on numbers that were wrong.
- Event Taxonomy Design — the naming and structure the whole stack inherits
- Tracking Plans — the contract, and the enforcement that makes it real
- The Data Layer — the site declaring its facts once, for every tool
- Ecommerce Event Schema — the inherited convention you don’t get to redesign
- Client-Side vs Server-Side Tracking — the architectural fork
- Schema Enforcement — rejecting malformed events at the edge rather than in a dashboard
- Idempotency and Deduplication — because at-least-once delivery guarantees duplicates
- Identity Stitching — the ceiling on everything user-level
- Consent Management — what may be collected, which constrains the design rather than decorating it
- Guide - Auditing a Tracking Plan — the recurring maintenance
2. Somewhere to put it
- Warehouse-First Analytics — raw events landed, modelled after the fact
- Event Streams vs Aggregates — what each makes impossible
- Customer Data Platforms — one collection point, many destinations, plus a profile store
- BigQuery — where most ecommerce event data ends up
- dbt — transformation as version-controlled, tested SQL
- Cardinality — the limits that quietly truncate what you collected
3. Experimentation infrastructure
- Assignment and Bucketing — deterministic hashing so a user’s variant is stable
- Randomisation Unit — the decision the whole platform is built around
- Experiment Assignment Tracking — recording who saw what; without it there’s no analysis
- Sample Ratio Mismatch — monitored automatically, not checked manually
- Client-Side vs Server-Side Testing — and the flicker problem you inherit with the former
- A-A Tests — the platform’s own regression test
- GrowthBook · Statsig · LaunchDarkly — the build-versus-buy candidates
4. Release safety
The capability that makes fast shipping survivable.
- Feature Flags — decoupling deploy from release
- Progressive Delivery — canary and percentage rollout
- Branching Strategies — trunk-based and its alternatives; long branches are the actual cause of merge pain
- Continuous Deployment — and its confidence prerequisites
- Rollback and Forward Fix — decided before you need it
- Preview Environments — a URL per pull request
- Guide - Shipping Safely — flags, rollout, migrations, rollback, and the flag cleanup nobody does
- Database Migrations — expand-contract, so schema change doesn’t gate a release
5. Lifecycle plumbing
Turning events into messages, which is where most incremental revenue actually comes from.
- Lifecycle Messaging — welcome, browse abandon, cart abandon, post-purchase, replenishment, winback
- Reverse ETL — pushing modelled warehouse data back into the tools that act on it
- Webhooks — reacting to someone else’s system, and the reliability problems it hands you
- Message Queues — decoupling the trigger from the send
- Replenishment Timing — predicting the reorder point, which is most of consumables retail
- Involuntary Churn and Dunning — failed payments as an engineering problem with a revenue number attached
- Klaviyo — the ecommerce implementation most of this lands in
6. Performance as a growth lever
- Core Web Vitals — the measurable definition of fast enough
- Performance and Conversion — the relationship, estimated for your own site rather than borrowed
- Third-Party Scripts — the tags nobody owns, and their measured cost
- Tag Manager Performance — the container anyone can add to
- Performance Budgets — enforced in CI, or it doesn’t hold
- Rendering Strategies — the decision upstream of most of the numbers
7. Knowing when it breaks
- Data Quality Monitoring — alerting on the pipeline, not just the application
- Alerting on Metrics — deviation rather than threshold, and alert fatigue
- Anomaly Detection — a real break versus ordinary variance
- Annotation and Change Logs — deploys and campaigns against the timeline, so spikes stay explicable
- Error Tracking — grouping and prioritising what breaks
- Observability — logs, metrics, traces as three separate questions
8. The commercial half
The part that distinguishes growth engineering from platform engineering: it’s judged on money.
- Contribution Margin — whether the growth is worth having
- Customer Acquisition Cost · Customer Lifetime Value · Payback Period — the three that decide whether to spend
- Cohort Revenue — whether the business compounds
- Growth Loops — acquisition that feeds itself, and the instrumentation that shows whether the loop actually closes
- Incrementality Testing — what a channel actually caused
- Attribution Models — how credit is allocated, and why it isn’t measurement
- Answer Engines — acquisition where the answer arrives without the click, and the measurement gap that follows
- Guide - Unit Economics and Commercial Decisions — the model assembled once, then used
9. Building on models
Both scoped to the durable mechanics, so they outlast whichever product is currently winning. Anything that needs a model name or a price belongs in a landscape note instead.
- Building with Language Models — treating a model as an unreliable metered dependency, which is the framing that makes the rest obvious
- Evaluating Non-Deterministic Systems — how you regression-test something that won’t repeat itself
The failure mode
Growth engineering fails predictably in one direction: the experimentation platform gets built before the measurement layer is trustworthy. It’s the more interesting problem, it demos better, and it produces confident results from data nobody has audited. Sections 1 and 2 are boring and they are the prerequisite.