> For the complete documentation index, see [llms.txt](https://docs.amply.tools/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amply.tools/recipes/reactivation-after-inactivity.md).

# Reactivation after inactivity

Detect when a user returns after a quiet stretch and route them into a welcome-back flow instead of the normal home screen.

**Use this when** you want a calendar-based signal — days since last open — and a coarse "they drifted" cutoff is good enough to act on. **Don't use this when** you have behavioral data that can detect slowdowns before the calendar gap opens; reach for [Winback at-risk users](/recipes/winback-at-risk.md) instead. Also skip for apps with high daily-use cadence where a 7-day gap is noise.

## Goal

A user who returns after a 14-day gap is effectively a new user again — they have forgotten where things are, what the value was, and why they were paying. Dropping them on the home screen wastes the moment. This recipe fires a reactivation flow on the first session back: a short recap, a contextual offer, or a reminder of the one feature they used most.

## Setup

### In the dashboard

* Create a campaign `reactivation-inactive-7d`.
* Trigger: session start.
* Conditions: `days_since_last_session >= 7` and `days_since_last_session < 30` and `subscription_status = "free"`.
* Action: fire `yourapp://reactivation/welcome-back` with a trial extension or a feature recap.
* Create a second campaign `reactivation-inactive-30d` with `days_since_last_session >= 30`. Use a stronger offer; these users are closer to uninstall.
* Frequency: once per returning session. A user who comes back, leaves again, and returns a week later should see it fresh.
* Exclude paying users unless you specifically want to retain lapsed payers.

### In the app (engineering hand-off)

* On every session start, compute the gap from the last session timestamp and write it before Amply evaluates campaigns:

  ```swift
  amply.setCustomProperty(key: "days_since_last_session", value: gapDays)
  amply.setCustomProperty(key: "last_core_feature", value: lastFeatureUsed)
  ```
* Register `yourapp://reactivation/welcome-back` to present the recap screen. Populate it with `last_core_feature` so the screen refers to something the user actually did.
* Track the outcome:

  ```swift
  amply.track("ReactivationShown")
  amply.track("ReactivationConverted")
  ```

## How it runs

1. User installs, uses the app for a week, then stops.
2. Fourteen days later, the user opens the app. SDK starts a session.
3. App reads `last_session_at` from local storage, computes `days_since_last_session = 14`, writes it as a user attribute.
4. Amply evaluates campaigns. `reactivation-inactive-7d` matches.
5. Amply fires `yourapp://reactivation/welcome-back`. The app shows the recap screen with the user's previous favorite feature and a trial-extension button.
6. User either converts (app tracks `ReactivationConverted` and the campaign stops matching for this session) or dismisses. Either way, next time the user opens the app within a few days, the gap is small and the campaign no longer matches.

## Metrics to watch

* Return-session-to-conversion rate. Compare the cohort that saw the reactivation flow to a hold-out.
* 7-day retention after the reactivation session. The point of the flow is to restart the habit, not just extract one purchase.
* Uninstall rate in the 72 hours after the flow. A pushy offer can accelerate churn it was meant to prevent.
* Feature re-engagement: did the user actually use `last_core_feature` again in this session?

## Related

* [Post-trial recovery](/recipes/post-trial-recovery.md) — reactivation for the trial-specific case
* [Winback at-risk users](/recipes/winback-at-risk.md) — a finer-grained version triggered by a behavioral signal, not a calendar gap
* [Sessions and events](/concepts/sessions-and-events.md) — how session boundaries are defined
* [Targeting an audience](/user-guide/targeting-an-audience.md) — composing the inactivity condition
* [Tracking events](/developer-guide/tracking-events.md) — instrumenting the reactivation outcome
* [AI-assisted integration](/getting-started/ai-assisted-integration.md) — describe this campaign in plain language and have your AI assistant build it


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.amply.tools/recipes/reactivation-after-inactivity.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
