meal-kit-analytics

What the project answers

The first box loses money

Shipping is free on every plan and the acquisition offer takes 40% off the first order, which leaves the opening box at minus $6.70 of contribution. A customer is not worth anything until their second delivery, and 95.2% of them get there. See the payback curve →

A quarter of customers carry more than half the business

The longest-tenured 19.7% of customers produce 50.9% of all contribution. The two shortest bands are 38.0% of customers and 6.3% of it. See the distribution →

Free shipping costs a fifth of gross margin

$3,152,165 absorbed across every box, with nothing collected against it, against $15,307,489 of margin earned on the food. It is not the heavy users who make it expensive: shipping runs 254% of margin on the lightest band and 20.5% on the heaviest. See the cost →

Going quiet is a weak signal, and worth saying so

A three-week skip streak raises the chance of cancelling in the next 28 days by 1.27x against a normal delivered week. Real, and smaller than the intuition that a quiet customer is a lost one. See the streaks →

Only two support categories predict cancellation

A meal-quality complaint moves the cancel rate +19.2 points and a delivery complaint +17.4. A billing question moves it +2.1 points. See the comparison →

mart_retention_cohorts

How does retention decay by signup cohort?

Percentage of each signup cohort still active. Read a row across to see one month's signups decay. Read a column down to see whether the business is getting better at keeping people.

Skipping is not churning

mart_skip_behavior

Boxes ship weekly and a customer can skip any week for free, so going quiet and leaving are different states. Treating every skip as a loss would send win-back offers to people who were always coming back. Each week a subscription was live counts as an event, and each is followed 28 days forward to see whether a cancellation arrived.

mart_customer_value · mart_box_sequence_economics

Which customers are worth having?

Retention matters because of what sits behind it. Sorting customers by how long they lasted and adding up what each group actually contributed, after food and delivery costs, gives a distribution that is far more lopsided than the headcount suggests.

A quarter of customers carry more than half the business

The two shortest bands are 38.0% of customers and 6.3% of contribution. The longest band is 19.7% of customers and 50.9%. Any retention work that treats those groups as equally worth saving is spending against the wrong end of the distribution.

The first box pays for almost nothing

The acquisition offer takes $34.37 off the first box, which leaves $1.59 of contribution on it. Every box after earns about $34. So a new customer contributes essentially nothing until their second delivery, and the whole question is whether they get there. 95.6% do.

mart_churn_drivers

Which support contact precedes cancellation?

Split by category, only two categories carry any signal. A customer whose box arrived damaged or inedible is leaving. A customer with a billing question is behaving like everybody else.

Account contact keeps a −5.3 point gap that the correction did not remove. With roughly 300 exposed subscriptions behind it, that sits inside the range chance produces, and it is reported here as an open question instead of a fifth finding.

Why this is a case-control design

“Customers who ever contacted support churn more” is true of almost any dataset for a boring reason: longer-tenured customers have more opportunity both to contact support and to cancel. Scoping exposure to a fixed 30-day window before the span closes puts churned and active subscriptions on the same footing. Active subscriptions serve as the controls, censored at the analysis end date, so a customer who complained last week and is still here counts as exposed and did not churn.

mart_shipping_economics · mart_product_mix

What free shipping costs, and who consumes it

Shipping is free on every plan, so the business absorbs the delivery cost of every box it sends with nothing collected against it. Across the whole dataset that is $3,152,165 against $15,307,489 of margin earned on the food, or 20.6% of gross margin spent on getting it there.

Where the revenue actually comes from

Three product lines at different price points. Dinner kits are the plan itself; breakfasts and lunches ride along as add-ons.

Add-ons appear in about a fifth of boxes and carry 9.1% of revenue between them, which is the clearest piece of headroom in the model: the customers are already there and the delivery is already paid for.

Where the build time actually goes

Profiling this project produced three results that contradicted what I would have guessed. Two turned into changes worth keeping, and the third turned out to be a mistake in how I was reading the numbers.

Nearly half the build runs before the first query

The obvious thing to profile is the SQL. On a project this size that is the smaller half of the problem. A full dbt build takes 14.2 seconds of wall clock, and dbt reports 7.5 of those as its own elapsed time. The rest is fixed startup, paid once per invocation whatever you select:

Bare Python starts in 0.10s, so that first row is dbt-core's own import cost and nothing can be done about it from here. The effect is sharpest on the small selective runs that are supposed to be the fast loop: dbt build --select stg_customers, one trivial view, takes 7.4 seconds to do 1.0 second of work. It is the strongest argument in the project for one large build over many narrow ones, and the reason the staging_only and unit_tests_only selectors are mostly overhead.

One part was recoverable. dbt sends anonymous usage statistics, and turning them off in dbt_project.yml took 1.68 seconds off an otherwise identical build, 18.41s to 16.73s. The cost scales with node count and is not fixed per invocation, because dbt emits a tracking event per node: the same switch is worth only 0.7 to 0.9s on dbt parse or a single-model run.

Tests cost more than models, but no test is slow

Tests were 22.1 seconds of node time against 10.4 for all 20 models, which reads like a signal to go optimize test SQL. It is not. The median test ran in 104ms, the fastest in 39ms, and the slowest in 400ms, against a fixed per-node floor of about 83ms. Roughly three quarters of the time was overhead between queries, and 138 of the 198 tests were single-column not_null checks.

Collapsing those into one columns_not_null test per model took the suite from 198 data tests to 96 and 2.54s off the build. Together with the telemetry switch above that is 18.41s to 14.19s, and the two account for the whole difference. The merged test counts every column in a single pass and returns the offending column name with its null count, so a failure is more specific than the 124 tests it replaced, not less. Sources kept their per-column tests, because their severities differ deliberately: an empty region warns, a missing customer id errors, and one merged test can only have one severity.

The parallelism number was measuring the wrong thing

This section used to read: node time totals 34.8 seconds while the wall clock reads 10.8, so parallelism is returning about 3.2x. It treats node time as a fixed amount of work being divided between threads. It is not, and running the identical build at three thread counts shows why:

Wall clock does not move. Node time rises almost exactly in proportion to the thread count, because each concurrent query is slowed by its neighbours by about the factor it gains from running beside them. That is what serialisation inside a single embedded DuckDB process looks like, and the ratio can be made to read anything from 1.7x to 3.9x without the build ever getting faster.

The slowest operator was not in a mart

EXPLAIN ANALYZE on the heaviest downstream query, expecting the range join in fct_subscription_months to dominate. This is the profile before the fix below, with staging still materialized as views:

The range join costs 68 ms. The row_number() deduplication in stg_orders cost 1,932 ms, roughly thirty times the thing I went looking for. Because staging was materialized as a view, that window re-executed for every model and every test reading stg_orders, which is most of the project.

Re-running the same profile today returns no WINDOW operator at all. It is gone because the dedup is now computed once into a table instead of on every read, which is the clearest confirmation available that the change did what it was meant to.

Both halves fell by about a third, which is the confirmation the diagnosis was right: models and tests alike were paying for that window every time they read staging. Both rows were measured on the same dataset, one after the other, with only the materialization changed.

Model build times

Two models are half of model build time. stg_orders sits second by design: the cost moved there from everywhere else, which is the whole idea.

Incrementality

fct_orders is the only incremental model, and after a week of new deliveries lands it processes 6,815 rows instead of 476,840:

The model itself is 4.8x faster. Counting the upstream rebuild the honest figure is 1.78s against 2.02s, so the table materialization still wins, by much less than the model timing alone suggests. On a full build or a test run it wins clearly.

How it is built

DuckDB and dbt-core, running on a laptop. No warehouse account, no credentials, no cost. Seven staging models, three intermediate, ten marts, one SCD Type 2 snapshot, six singular tests. Every model, source, snapshot and column carries a description, so the generated data dictionary is complete.

Tests run at three layers, each doing a different job

• Source tests warn. Raw genuinely contains 120 duplicate order ids, 140 empty regions, and 80 orders referencing a subscription that does not exist. Those are upstream problems, asserted at warn severity so the build stays green while the defect stays visible on every run. Deleting the test would hide a real problem. Erroring would block a pipeline over something this project cannot fix at the source.
• Staging repairs. Deduplication happens once, at the layer that owns grain, so every model downstream may assume order_id is unique. Empty-string regions collapse to NULL, because empty and unknown are different things and only one of them aggregates correctly.
• Staging and mart tests error. Once staging has done its job, uniqueness becomes a hard contract. If it fails, the repair broke.

The arithmetic closes: 476,960 raw orders, minus 120 duplicates removed in staging, minus 80 orphans dropped by the inner join in fct_orders, gives the 476,760 rows in the fact table.

Keys and enumerations are not enough

Uniqueness, not-null and referential integrity say nothing about whether a number is right. A flipped sign on a credit, COGS computed off the wrong base, or a shipping cost that went missing passes every one of them. Six singular tests cover the assertions that generic tests cannot express:

• Revenue arithmetic. Six rules on every order: net never exceeds gross, gross revenue and delivery cost both stay positive, COGS never goes negative, and both net revenue and contribution margin reconcile to their components within a cent. Failures return the order id with the rule it broke.
• Retention denominator stability. Cohort size must be identical on every row of a cohort. Recomputing it per period is the one bug that leaves the grain correct, nothing null, and every percentage inside 0 to 100 while making the whole table wrong.
• Fact-to-staging reconciliation. Fact rows equal staging rows holding a valid subscription. The inner join is meant to drop orphans and nothing else, and a duplicated dimension row would fan out and silently add rows instead. The arithmetic above, enforced.
• No week both skipped and delivered. Skips and deliveries are the two outcomes of one weekly decision, so they are mutually exclusive by construction. If they ever coexist, mart_skip_behavior counts the same week twice and every risk multiple it publishes rests on an inflated denominator. Both rows would be individually valid and no key test would notice.
• Order totals against line items. Every meal is priced independently, so a box total is the sum of what is in it. That makes an order carrying the wrong number of meals, carrying one twice, or drifting away from its items all detectable, and none of them trips a key test.
• No overlapping subscription spans. A real business rule this dataset cannot currently violate, since each customer holds exactly one subscription. Documented as passing trivially.

Every materialization here was chosen

Staging and intermediate are views, because nothing queries them directly and rebuilding costs nothing. Marts are tables, because a dashboard hits them repeatedly and the build cost is better paid once.

fct_orders is incremental with delete+insert. Append would be faster, but it assumes the incoming slice never overlaps what is already stored, so a late-arriving delivery would be counted twice. Deleting matching ids first makes re-running the same window idempotent. Measured on roughly 500k orders: 2.02s full refresh against 0.42s incremental.

Portability is a profile swap

DuckDB is a profile choice. The architecture does not depend on it, and the models move to Snowflake or BigQuery by pointing profiles.yml at a different adapter. Exactly two places would need editing, both commented in place: the date_diff spelling, and the deduplication in stg_orders, which could collapse to QUALIFY on warehouses that support it.

Slowly changing dimensions

The subscriptions source holds current state only, so a plan change overwrites the old value and the history disappears. That makes “did revenue rise because we raised prices or because people upgraded” unanswerable. A snapshot writes dbt_valid_from and dbt_valid_to alongside each version, so a point-in-time join can ask what plan a subscription was on when a particular box shipped.

Honest notes

What is modeled into the generator

• Churn hazard highest in the first three tenure months, rising in December.
• Hazard roughly doubles after a delivery or meal-quality complaint.
• A skip streak raises hazard, which is what makes skipping an early signal.
• Skips run about 15% of live weeks, rising to 30% in December.
• Three classes of defect planted deliberately, so the tests have something to catch.

What is absent

Acquisition channel has no effect, and the data says so. Active rates sit between 43.6% and 45.3% across all five channels, with lifetime revenue between $1,952 and $2,046. This is an absence in the simulation. It says nothing about whether channel matters in a real business, since no channel effect was ever put in. The dimension stays in dim_customers because a real business would segment on it, and reporting the flat result seemed more useful than quietly dropping the column.

Also absent: pauses and reactivations, so each customer holds exactly one subscription. That means the singular test asserting no customer holds two overlapping subscriptions passes trivially. It is a correct test of a real business rule that this dataset cannot currently violate.

Scope

The exercise here is modeling and testing. Half a million rows is enough to make grain, incrementality and join correctness matter, and small enough to rebuild in thirty seconds.