Cohort Analysis
Cohorts group subscribers by a shared starting point — the period they were acquired, or the period they first did something — and track how each group keeps engaging, converting, and spending over the following periods. The output is the classic retention triangle on Insights → Cohorts: rows are cohorts (newest on top), columns are period offsets (P0 = the joining period), and each cell is the share of that cohort active in that period.
Reading the triangle
- The denominator is fixed at acquisition: a cohort's size is the number of subscribers who joined in that period, and every cell divides by it. Percentages can only tell you about the original group — that's what makes cohort curves comparable.
- Blank cells have not elapsed yet — that's the triangle's edge, not missing data. A
0%cell is an honest zero: the period passed and nobody in the cohort did the thing. - Buckets use your workspace timezone (the delivery timezone in Settings), truncated to the grain — daily, weekly (ISO weeks, starting Monday), or monthly.
Cohort kinds
- Acquisition date — subscribers bucketed by when they were created in Hober. Works for every tenant with no integration.
- First event — subscribers bucketed by the first time they performed a tracked event you name (e.g.
signup,purchase). Requires server-side or SDK event tracking.
Metrics
| Metric | A subscriber counts in a period when they… | Requires |
|---|---|---|
| Engagement (default) | opened or tapped any notification | nothing extra — every sending tenant has this signal |
| Any tracked event | performed any behavioral event | track() integration |
| Conversion | performed a configured conversion event | conversion tracking |
| Revenue | — cells show the cohort's summed conversion value instead of a percentage | conversion tracking with values |
Engagement is the default because it exists for every tenant that sends through Hober; an events-based default would show empty grids for tenants without event tracking.
Ad-hoc grids vs saved cohorts
The builder computes ad-hoc grids live, looking back up to 90 days of raw activity — enough to validate a cohort definition at daily or weekly grain.
Saving a cohort removes that cap. Saved cohorts get a nightly rollup (around 02:00 UTC): membership is frozen the first time a subscriber qualifies, and each period's cells are written once, after the period closes, while the raw activity still exists. Written cells are final — so a saved cohort's grid keeps growing month after month, long past the raw-event retention windows, up to the 24-month history promise. The current, still-open period is computed live and may still move until it closes.
Practical consequence: save cohorts you care about early. The rollup can only capture a period while its raw activity exists — history before a cohort was saved (beyond the 90-day window) cannot be reconstructed.
Retention promises
- Saved-cohort grid history: 24 months of cohort buckets.
- Conversion and touch records: 24 months (aligned with the grid promise).
- Raw behavioral events: 90 days; notification interactions: 12 months — unchanged, and the reason the rollup exists.
Worked example
A weekly acquisition cohort with the engagement metric answers: "Of the subscribers we acquired the week of July 6th, what share still opened or tapped a notification 1, 2, 3… weeks later?" Comparing the rows tells you whether your onboarding changes are improving early retention — if the August rows hold their P1–P4 percentages better than the June rows did, they are.