# Give users a reason to return

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-return/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-return/index.md
- **Module:** Retention
- **Time:** 60 minutes for the first scenario

Retention is not about sending more messages. Users return when something personally useful has changed or when they can easily continue an unfinished action.

## Outcome

A return-scenario card with its audience, useful trigger, message, deep link, exclusions, and outcome metric.

## First the reason, then the message

“Come back to the app” describes the team's goal, not the user's benefit. A good scenario starts with an event: a result is ready, a saved item changed, a specific step can be continued, or there is personal progress to see.

## What you will need

- **Segment:** One clear group: did not finish verification, saved an item, or did not return after the first useful action.
- **Channel:** Push, email, or an in-app banner that can exclude active users and those who already completed the action.
- **Screen:** A working deep link straight to the right step, and a person responsible for testing the scenario.

## Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.

## When to use it

Users get their first value or start an important journey but do not come back, while generic messages produce opens without completed actions.

## Where to find a reason to return

Do not start with the notification copy. First find an unfinished or newly useful action for a specific group.

- **Retention report**
  - **Source:** Check D1/D7 for new users and find a group that got the first useful outcome but did not return, or stopped at one step.
  - **If access is unavailable:** Without a cohort report, take two weeks of users in one journey and compare manually who came back.
- **Events and interests**
  - **Source:** Use only confirmed actions: saved an item, started verification, opened a topic, or created a collection.
  - **If access is unavailable:** If there are no events, start with one server-side status the team can reliably update and exclude after completion.
- **The link and exclusions**
  - **Source:** Test the deep link on an installed and a freshly reopened app; exclude recently active users and those who already finished the action.
  - **If access is unavailable:** Until the deep link is ready, use an in-app message or an email with clear manual navigation.

## Build one useful return scenario

1. **Pick one audience.** Describe people through a confirmed action and a time window, not a broad label like “all inactive.”
   - **Where to do it:** In the segmentation tool and the first row of the scenario card.
   - **Example:** Started verification, did not finish within 24 hours, has not opened the app in the last 12 hours.
2. **Name a real reason.** The reason must exist in the product: saved progress, a new result, a change in a followed item, or a ready next step.
   - **Where to do it:** In the trigger event and the message copy.
   - **Example:** The documents are saved; the user can continue from where they stopped without re-entering anything.
3. **Add exclusions.** Do not message people who already completed the action, returned recently, or received a similar message in another scenario.
   - **Where to do it:** In the segment rules before the send.
   - **Example:** Exclude completion=true, active_last_12h=true, and push_sent_last_48h=true.
4. **Lead straight to the continuation.** After the tap, open the promised screen and the saved step. The home screen makes the user search for their reason all over again.
   - **Where to do it:** In the deep link and the iOS/Android test plan.
   - **Example:** After sign-in, the document upload opens — not the home feed.
5. **Measure the useful action.** Look beyond delivery and opens. The main result is whether the user completed the action they returned for.
   - **Where to do it:** In the report 7–14 days after launch.
   - **Example:** Of 500 who got the message, 130 returned and 74 completed verification; compare with a similar group without the message.

## Practical examples

- **Continue the saved step:** After 24 hours the message goes only to those who started verification and did not finish. The deep link opens the saved document step; completed and recently active users are excluded.
- **Return to a personal interest:** When a real update lands in a saved collection, the message names it and leads to that collection. Success is viewing the update — not merely opening the app.

## Finished artifact: First return-scenario card

One scenario — one audience and one reason. Start with a small group so you can judge quality, not send volume.

| Field | Decision | Check |
| --- | --- | --- |
| Audience | Started verification, not finished within 24 hours | Completed and today-active users excluded |
| Reason | The saved step can be continued | The process state is actually saved |
| Message | Continue verification from the document step | No pressure or promises |
| Destination | Deep link to the document upload screen | Works after sign-in on iOS/Android |
| Success | Verification completed within 7 days | Compared with a similar group without the message |

Before launch, run the scenario on a test account: the message arrives once, opens the saved step, and is never sent again after completion.

## Completed template: Build the return scenario

Fill in three fields — a draft message and launch conditions will appear on the right.

- **Who:** Started verification but did not finish it within 24 hours
- **Why now:** Progress is saved — the document step can be continued
- **What to say:** Continue verification from the saved step whenever it suits you.

## Safety and constraints: Do not create pressure

Do not promise income, use fake urgency, or push for a deposit. The message should help continue a useful journey, not force the user back at any cost.

## Launch checklist

Send the scenario to a test group first and walk the whole path yourself, from message to result.

- [ ] The audience is described by an event and a period, not as “all inactive.”
- [ ] The reason to return actually exists in the product.
- [ ] Users who completed the action, were recently active, or got a similar push are excluded.
- [ ] The deep link opens the promised screen on iOS and Android.
- [ ] The main metric is the completed useful action, not just opening the app.

## How to know the scenario helps

- **Return:** The share of message recipients who came back within the chosen window.
- **Useful action:** The share of returners who completed the promised journey after the tap.
- **Trust:** Notification opt-outs, complaints, and repeat messages to users who already finished do not grow.

## Key rule

Do not optimize returns for app opens: success is a useful action after the return, with no rise in complaints and opt-outs.

---

- [HTML version](https://playbook.affpartners.io/en/practices/retention-return/index.html)
- [All practices](https://playbook.affpartners.io/en/)