Why We Designed Our Data Pipeline Around Cohorts

If your reporting tool cannot slice on cohort natively, every interesting question becomes a custom query, and custom queries don't scale with curiosity.

The cost of rebuilding cohorts after the fact

Many pipelines treat cohorts as something you reconstruct after the fact. Every retention question means joining events back to a signup date, each join is written slightly differently, and two people can easily get two different numbers.

The result is a slow tax on curiosity. The questions worth asking are exactly the ones that need a new query, so most of them never get asked. The data is complete on paper and hard to use in practice.

The tell: If two people answer the same metric question with two different numbers, look at the data model before the people: it is making an easy question hard.

Cohorts as a first-class dimension

That is why we designed Startup Suite to treat cohorts as a dimension every metric inherits, rather than a report built afterwards. The aim is to put retention, CAC payback and contribution margin a single group-by away.

The principle is simple: anything you will want to slice by should be a dimension carried by the data, not a calculation bolted on later. Cohort was the obvious first candidate because nearly every interesting question about a subscription business is really a question about a cohort over time.

The design choice: Startup Suite is designed so every event carries its acquisition cohort from the moment it is written. Re-slicing history by that cohort should then need no backfill.

Stamp the cohort at write time

The engineering decision the product is built around is to resolve and store the acquisition cohort on the event as it is written, instead of inferring it at query time. It adds very little to each write and avoids a backfill of history when the next question arrives.

• Resolve the cohort once, at the moment the event is recorded
• Store it alongside the event so every downstream metric inherits it
• Avoid recomputing history: as long as the cohort definition holds, the answer is already in the row

What it makes possible

Forecasts get sharper when you can see which cohorts behave differently and why. The model stops averaging away the signal.

• Retention by cohort, without a custom query each time
• CAC payback compared across acquisition channels on the same basis
• Contribution margin sliced by the month a customer arrived, as well as by who they are

A blended average can hide one strong cohort and one weak one.

What to decide before you write the first event

Choose the dimensions every metric must carry while the pipeline is still empty, well before two dashboards start disagreeing. Migrating a pipeline is expensive. Stamping one extra field on a new event costs almost nothing.

The shape of your data decides which questions are cheap to ask, and a busy team mostly asks the cheap ones. Build the pipeline so the important questions are the easy ones.