# Win back dormant app users with tailored push notifications

> Every Monday we find the people who quietly stopped using your app, group them by what they last did, and send each group a message actually worth opening.

- Workflow type: agent
- Services: Firebase, Slack Bot
- Categories: Marketing, Product
- Published: 2026-08-14

## What it does

- Finds everyone who has not opened your app in the last two weeks, while skipping anyone who turned notifications off or already heard from you this month.
- Sorts those people into behaviour based groups, such as signed up but never finished setup, was active then went quiet, or left something in a cart.
- Writes short tailored copy for each group and sends it straight to their phone, instead of one generic blast to everybody.
- Records who was contacted and why, then posts a summary in Slack with the numbers per group, the exact wording that went out, and any devices that could not be reached.

## What you'll need

- A Firebase project with your app users stored in a database collection
- Push notifications already set up in your app, with each user's device registration saved on their record
- A Slack workspace and a channel where the weekly summary should land
- Fields on each user record showing when they were last active and whether they agreed to receive notifications

## Prompt

Every Monday at 10am, run a win-back campaign that wakes up my dormant app users without spamming them, using Firebase and Slack Bot. Use a cron trigger for this rather than a poll trigger: I am targeting an existing cohort of people who already went quiet, not reacting to new records as they arrive.

Start with the Firebase "Run Firestore Query" operation against my users collection to pull the dormant cohort. I want users whose last activity timestamp is fourteen or more days old, who still have push enabled, and who have a stored FCM device token. Firestore structured queries handle "this field is missing or older than X" conditions badly, so pull the dormant and opted-in set in the query itself, then filter out anyone contacted in the last thirty days after fetching, treating a missing last-contacted field as eligible.

Field names like lastActiveAt, fcmToken, notificationsEnabled and lastReengagedAt are illustrative. Call out clearly in the workflow where I need to map them to whatever my own schema actually calls these fields, so nobody assumes these names are magic.

Sort the returned users into a small number of behavioural segments based on what they last did in the app. Sensible starting segments are: signed up but never finished setup, was active for a while then went quiet, and left items in a cart without checking out. Include a fallback segment for anyone who does not fit cleanly. For each segment, write short tailored push copy that speaks to that specific behaviour instead of sending one generic blast to the whole cohort. Segmented, behaviour based notifications such as abandoned cart reminders and personalised offers consistently outperform generic sends, so this segmentation step is the core of the workflow and not a nice to have.

Send each message with the Firebase "Send Push Notification (FCM)" operation, addressed to that user's stored device token, carrying the copy written for their segment. Keep the title short and the body to roughly two lines so it reads well on a lock screen.

Handle token failures explicitly. FCM drops messages to devices it considers inactive, and on Android a registration that has been inactive for 270 days is expired and garbage collected, after which sends to it are rejected. When a send is rejected, do not fail the whole run: record the user and the failure reason, carry on with the rest of the cohort, and surface those stale registrations in the summary so they can be cleaned up. Reference: https://firebase.google.com/docs/cloud-messaging/manage-tokens

After each successful send, use the Firebase "Update Firestore Document" operation to patch that user's document with lastReengagedAt set to the current time and the segment they were placed in. Patch only those fields, do not overwrite the rest of the document. This stamp is the thing that stops anyone being pinged twice inside a month, so only write it for users who actually received a message, never for ones whose send failed.

Apply a sensible volume cap per run, defaulting to around 500 users, so a large dormant cohort does not turn into a mass blast in a single Monday. If the cohort is bigger than the cap, prioritise the most recently active users first and note the leftover count in the summary. Also respect quiet hours: let me configure a send window so notifications land during reasonable daytime hours rather than the middle of the night.

Never message anyone who has not opted in. Push consent is a legal requirement in many markets, so the notifications-enabled flag is a hard filter, and the workflow must never fall back to messaging users whose consent state is unknown or missing.

Finish with the Slack Bot "Send a Message" operation to post a summary in my growth channel. Cover how many users were reached per segment, the exact copy that went out for each segment, and every token that failed along with its reason so we can clean up stale registrations. If a run reaches nobody, post that too, so I can tell the difference between a quiet week and a broken workflow.

## How to customize

- Change the schedule, the fourteen day inactive window, or the thirty day cooldown before someone can be contacted again.
- Add, remove, or rename the behaviour groups, and set the tone of the copy written for each one.
- Cap how many people get contacted in a single run, and choose the hours you are happy for notifications to arrive.

## FAQ

### Will this message people who opted out of notifications?

No. Anyone without notifications switched on is filtered out before a single message is written, and the workflow never messages people whose consent status is unclear. Respecting that choice is both good practice and a legal requirement in many countries.

### Can the same person get this campaign week after week?

No. Once someone is contacted, the date is saved on their record, and anyone contacted in the last thirty days is skipped on future runs. You can raise or lower that cooldown to fit how often you are comfortable reaching out.

### What happens if someone's phone cannot be reached?

Those failures are collected and listed in the Slack summary rather than quietly disappearing. Registrations go stale when someone uninstalls the app or has not opened it for a long time, so the summary doubles as a cleanup list for your team.

### Do I have to write the notification copy myself?

No. Short copy is drafted for each behaviour group based on what those people last did in the app. You can set the tone, rewrite any group's message, or lock in wording you already know performs well.

### Will this suddenly blast thousands of notifications in one go?

No. There is a cap on how many people are contacted in a single run, so a large dormant audience is worked through steadily instead of all at once. You can also set the hours during which messages are allowed to go out.

Use this prompt in General Input: https://www.generalinput.com/prompts/win-back-dormant-app-users-with-tailored-push-notifications