---
title: Cohort Start Event: Install or First Purchase
description: How to define cohorts by choosing a start event: install, first open, sign-up or first purchase, what each answers, survivorship bias, day boundaries, channels.
url: https://retentioncohorts.com/learn/cohort-start-event/
---

[Home](https://retentioncohorts.com/) / [Guides](https://retentioncohorts.com/learn/) / Choosing the cohort start event: install or first purchase

# Choosing the cohort start event: install or first purchase

How to define cohorts by choosing a start event: install, first open, sign-up or first purchase, what each answers, survivorship bias, day boundaries, channels.

**Short answer**

The cohort start event is the action that sets Day 0 for every user in a cohort. Install cohorts measure acquisition quality across everyone you brought in, while first-purchase cohorts measure repeat behaviour among buyers only, so their retention always looks higher and the two should never be compared.

## What is a cohort start event?

A cohort start event is the action that puts a user into a cohort and fixes their Day 0, so every later Day N is counted from that moment. It is the first choice to make in any [cohort analysis](https://linkrunner.io/glossary/what-is-cohort-analysis?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=learn-cohort-start-event&utm_content=inline).

**Start event:** the anchor action, such as install, first open, sign-up or first purchase. The day it happens is Day 0 for that user.

**Return event:** the action that counts a user as active on a later day, such as any app open or a meaningful action like placing an order.

Every retention number on this site, whether [classic, rolling or cumulative](https://retentioncohorts.com/learn/classic-vs-rolling-vs-cumulative/), divides users retained on Day N by the users who did the start event. Change the start event and you change both the top and the bottom of that fraction. Day 0 activity is never a return, whatever anchor you choose.

## The four common start events

Pick the question first, then the event.

| Start event | Who is in the cohort | Question it answers |
|---|---|---|
| Install | Everyone who installed on that day | How good is the traffic we acquired? |
| First open | Everyone who launched the app at least once | Same as install, minus installs that never opened |
| Sign-up | Users who created an account | Do registered users come back? |
| First purchase | Users who bought at least once | Do customers buy again? |

- **Install cohorts** are the default for acquisition work, because they include the people who bounced on Day 0.
- **First-purchase cohorts** answer a customer question such as repeat purchase or renewal. They are a product and CRM view, not an acquisition view.

The longer argument for keeping both an install view and a purchase view is set out in this [guide to defining cohorts by first install or first purchase](https://linkrunner.io/blog/how-to-define-cohorts-%28first-install-vs-first-purchase-guide%29?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=learn-cohort-start-event&utm_content=inline).

## Why do first-purchase cohorts show higher retention?

Because a first-purchase cohort leaves out everyone who never bought, it only contains your most committed users, so its retention is always flattering next to an install cohort.

This is survivorship bias. Hypothetically: say 1,000 people install on Monday and 100 of them buy that week. If 40 of those buyers open the app on Day 7, the first-purchase cohort shows 40% Day 7 retention. The install cohort for the same Monday might show far lower, because it also counts the 900 who never bought and mostly drifted away.

- Neither number is wrong; they describe different groups.
- Never put an install-cohort curve next to a first-purchase curve and call one better.
- If you report both, label the start event on every chart and table.

## Choosing the return event

The return event matters as much as the anchor.

- **Any open** is the broadest choice. It is easy to compute and easy to compare across cohorts and channels.
- **A meaningful action** (a search, an order, a lesson finished) is stricter and closer to value. It will always give lower numbers than any open.
- Count a user once per day, however many times they do the event that day.

Keep the return event fixed across cohorts and channels, and start a new series if you change it. The [SQL and spreadsheet formulas](https://retentioncohorts.com/compute/) on this site count an app open as the return; to use a different action, filter the activity table to that event first.

## Day boundaries and time zones

Day N has to mean the same thing for every user, and there are two ways to define it.

- **Calendar days:** Day 1 is the next calendar day after install, in a fixed time zone. A user who installs at 11:50 pm can be a Day 1 return ten minutes later.
- **24-hour windows:** Day 1 is the 24 to 48 hours after the install moment. Fairer to late-night installs, harder to line up with daily reports.

Practical rules:

- Pick one time zone for the whole report and state it.
- A cohort only has a Day N value once Day N has fully passed for every user in it.

## Assigning the cohort to a channel

To compare channels you need each user's acquisition source attached to their start event.

- For install cohorts, attach the attributed channel or campaign at install.
- For later anchors such as first purchase, keep the original install channel. Otherwise a paid user who buys after an email looks like an email user.
- Watch the share of installs from each channel over time, because a shift in mix moves blended retention even when each channel is flat. The [channel mix section](https://retentioncohorts.com/read/#mix) of the reading guide shows this with the site's sample app, a made-up app.

Events attached to installs are also what ad networks optimise on, which is covered in this [explainer on events, postbacks and ROAS](https://appattributionguide.com/events-postbacks-and-roas/). For channel-level reading, see [retention by channel](https://retentioncohorts.com/learn/retention-by-channel/).

## A decision table

| You want to know | Start event | Return event | Definition to use |
|---|---|---|---|
| Is this channel bringing users who stay? | Install | Any open | Classic Day 1 and Day 7 |
| Is onboarding working? | Install or first open | Any open or key action | Cumulative Day 7 |
| Do registered users stick? | Sign-up | Key action | Classic, weekly |
| Do customers buy again? | First purchase | Purchase | Cumulative Day 30 |

Try different definitions on the [interactive cohort explorer](https://retentioncohorts.com/) to see how much the choice moves the numbers.

**Note:** Example numbers come from a made-up app to show the method, not a benchmark.

See this on your own app

Linkrunner's retention views count from the install, the acquisition view this guide recommends as the default.

- [How To Define Cohorts? (First Install Vs First Purchase)](https://linkrunner.io/blog/how-to-define-cohorts-%28first-install-vs-first-purchase-guide%29?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=learn-cohort-start-event&utm_content=panel)
- [Create a free account (25k installs free)](https://dashboard.linkrunner.io/sign-in?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=learn-cohort-start-event&utm_content=panel)

## Questions

**What is the most common cohort start event?**

Install is the most common anchor for app retention, because it includes every acquired user and lets you judge channels fairly. Later anchors suit product questions.

**Can I compare install cohorts with first-purchase cohorts?**

No, because the first-purchase cohort excludes everyone who never bought. Its retention will look higher purely because of who is in it, not because anything is working better.

**Does Day 0 activity count as retention?**

No. Day 0 is the day of the start event, and activity on that day is not a return. Retention starts counting on Day 1.

**Should I use calendar days or 24-hour windows?**

Either works if you use one consistently and state the time zone. Calendar days are easier to line up with daily reports, while windows treat late-night installs more evenly.

**Which channel does a first-purchase cohort belong to?**

Keep the channel that acquired the install. Reassigning it to whatever touched the user before the purchase hides which acquisition source produced your buyers.

**What is the difference between classic, rolling and cumulative retention?**

Classic counts users active on exactly Day N. Rolling counts users active on Day N or any later day, and cumulative counts users active at least once from Day 1 to Day N. They use the same raw activity but answer different questions.

## More guides

- [01 **Classic vs rolling vs cumulative retention** Classic, rolling and cumulative retention count different users on the same day. See the definitions, a ten-user worked example and when to use each one.](https://retentioncohorts.com/learn/classic-vs-rolling-vs-cumulative/)
- [02 **How to read a retention curve** A retention curve plots one cohort's retention against Day N. Read the early drop, the flattening point and smile curves, and why shape depends on definition.](https://retentioncohorts.com/learn/read-a-retention-curve/)
- [03 **Why paid D1 retention is lower than organic** Paid D1 retention below organic is partly normal, as organic users arrive with intent. See the causes, from targeting to measurement errors, and how to check.](https://retentioncohorts.com/learn/paid-d1-lower-than-organic/)
- [04 **Retention by channel and campaign** Blended retention hides what each channel does. Learn to cut a cohort table by channel, campaign and creative, keep naming clean and spot a channel mix shift.](https://retentioncohorts.com/learn/retention-by-channel/)
- [05 **Retention for weekly-use vs daily-use apps** Why classic Day N retention undercounts apps people use weekly, and how cumulative windows, weekly cohorts and DAU/MAU give a fairer read of weekly-use apps.](https://retentioncohorts.com/learn/weekly-vs-daily-use-apps/)
- [06 **Turning retention into decisions: LTV, payback and budget** How to turn app retention into decisions: which definition feeds LTV and forecasts, a simple LTV from a retention curve, cost per retained user and payback.](https://retentioncohorts.com/learn/retention-to-decisions/)