Cohort windows are not innocent
A seven-day retention window looks hygienic. It is round, it fits in a slide, and most tools offer it before you have had coffee. It is also a claim about how often a human being should want your app.
In Product Telemetry Studio we ask a dull question first: what is the natural rhythm of the job to be done? A weekly meal-plan product that reports seven-day retention is marking its own homework. A shift-work roster tool that uses the same window will look sick because people do not live in calendar weeks.
The window writes the story. Tighten it and you manufacture urgency. Lengthen it and you hide decay. Neither is immoral; pretending the number arrived from nature is.
Pick the return event before the number of days
Teams often reverse the order. They inherit “D7” and then hunt for an event that makes D7 respectable. That hunt produces vanity returns: opening the app, viewing a home feed, dismissing a tooltip. A return should be the same class of action as the start event — funded a transfer, published a list, completed a route.
If you cannot name the return without looking at a dropdown of auto-captured clicks, you are not ready to choose fourteen versus thirty.
Write the window in English
We keep a sentence in the dictionary: “A user is retained if they do X within N days of first doing Y.” If the sentence sounds cruel or silly when read aloud, the chart should not go to leadership. Cruelty sometimes is the truth; silliness never is.
United Kingdom teams we teach often discover that a month-end billing product needs a window that respects payday, not a Silicon Valley default. That is not localisation. It is product.