In Amplitude's Retention Analysis, how does N-Day retention differ from Unbounded retention?

## The shared setup Every Amplitude retention chart has the same three ingredients: a **starting event** that defines the cohort (often `Any Active Event` or a specific milestone like `Onboarding Completed`), a **return event** that counts as coming back, and a **date range** that decides which users enter the cohort. Day 0 is the day the starting event happened, for each user individually — the cohort is aligned on the user's own clock, not on a calendar week. Then, for each day N, the chart asks: what share of that cohort satisfies the return condition? The three retention modes differ only in what "satisfies" means. ## N-Day retention: exactly on that day N-Day counts a user in the day-N bucket only if the return event occurred on day N itself. A user who was active on day 1, silent through day 6 and active again on day 7 contributes to buckets 1 and 7 and to nothing in between. The practical consequence is the shape of the curve. It is **not** monotonic — it can go up and down freely — and for products with a weekly rhythm (payroll, invoicing, team retros, fantasy sports) it produces a sawtooth with spikes on multiples of seven. Read naively, day 3 looking terrible is not a churn signal; it is the shape of a weekly product. N-Day is the right lens when your product genuinely aspires to daily use, because then "came back exactly today" is the metric you care about. ## Unbounded retention: on that day or any day after Unbounded asks a weaker, more forgiving question: did the user return on day N *or at any point later*? Because the condition for day N is a superset of the condition for day N+1, the curve is **monotonically non-increasing** and sits at or above the N-Day curve for the same cohort and the same events. It answers "of the users who reached this point, what fraction were not permanently gone" rather than "what fraction use us every day". That superset relationship is worth being able to state out loud, because it is the cleanest way to prove you understand both definitions: any user who returned exactly on day N also returned on day N or later, so N-Day can never exceed Unbounded. Unbounded has one structural quirk: the most recent days in the window are unreliable. A user who will return next week has not had the chance yet, so the tail of the curve is depressed simply because the future has not happened. Interpret only the portion of the curve where the whole lookback has had time to elapse. ## Bracket retention: your own buckets Bracket retention lets you define custom day ranges — days 1–7, 8–14, 15–30 — and asks whether the user returned within each bracket. It is the pragmatic middle ground for products whose natural cadence is neither daily nor "ever again": a user counts once per bracket regardless of how many times they came back inside it, which smooths the sawtooth without collapsing everything into a cumulative curve. ## Choosing, and the mistakes around choosing The honest answer to "which one should we use" starts with the product's expected usage frequency, and that is usually the follow-up an interviewer is fishing for. A messaging app is daily: N-Day. A tax product is annual: bracket, or a very long unbounded window. A B2B tool used on weekdays: N-Day will show a weekend trough that means nothing, so either use brackets or read only weekday points. Three recurring errors: 1. **Comparing curves computed with different modes.** A dashboard showing last quarter's unbounded curve next to this quarter's N-Day curve will always suggest a catastrophic decline that is pure definition change. 2. **Choosing the return event too loosely.** `Any Active Event` includes app-open events, push-notification opens and background pings, which can make retention look strong while nobody is doing anything valuable. Retention on a meaningful action is a harder and more useful number. 3. **Reading the unripe tail.** As above, the last few days of an unbounded curve are mechanically low. ## Why an interviewer asks a data engineer this This is a definitions question, and definitions are the reason product analytics numbers disagree across teams. If marketing quotes unbounded retention and product quotes N-Day, both are correct and the meeting is useless. A data engineer who can state precisely which comparison the chart is making — and reproduce it in SQL against the exported event stream when someone disputes it — is the person who ends that argument. That is also why this sits as a differentiator rather than a screening question: nobody is failed for not knowing the chart names, but knowing them signals you have actually worked the tool rather than only shipped events into it.