Push notification console your growth team runs without engineers

Build me a push notification console that my growth and product team opens whenever they want to message our app users, so nobody has to ask an engineer to run a script. Our app users live in a Firestore collection where each user document carries fields like plan, country, last opened date, app version, notification preferences, a quiet-hours flag, and the FCM device tokens registered for that person. The console has three screens: Audience, Compose, and History. Nothing here runs on a schedule or on an event. A person defines the audience, approves the copy, presses send, and reviews the results afterwards.

The Audience screen is a plain segment builder over the users collection. The user stacks simple filter rows such as plan equals free, last opened before a date, country in a list, or app version at or above a value. Every time they add or tweak a row, refresh a live recipient count using the Firebase Run Firestore Aggregation Query operation, so they can size the segment without pulling documents. Under the count, show a sample of twenty matching profiles using Run Firestore Query, with the fields that were filtered on shown as columns, so they can sanity check that the rows actually select the people they meant. Segments can be named and saved as documents in a push_segments collection with Create Firestore Document, and the saved segment picker loads them with List Firestore Documents, so the team reuses last month's definition instead of rebuilding it from memory.

The Compose screen has a title field, a body field, and a phone-style preview that renders the notification the way it will look on a handset as they type, including a truncation warning when the text runs long. There is a deep link field for the in-app destination, and a choice of delivery target: send to an FCM topic, or send to the device tokens stored on each matched user document. Before the real send unlocks, the sender must run a mandatory dry run to their own test device token using Send Push Notification (FCM) and confirm they received it. Until that dry run succeeds, the Send button stays disabled and says why.

Sending writes a campaign document into a push_campaigns collection capturing the segment definition used, the title and body, the deep link, the delivery target, the audience size, and the delivered and failed counts. Send through Send Push Notification (FCM), then stamp the failed tokens back onto the relevant user documents so dead devices get cleaned up over time: use Batch Write Firestore Documents so one call marks many user records at once, and Update Firestore Document to close out the campaign record with the final numbers. Show live progress while the send is running, and never leave a campaign record half written if part of a batch fails.

The History screen lists past campaigns with the worst failure rate first, since that is the list worth acting on. Each row shows the date, who sent it, the segment name, audience size, delivered, failed, and failure rate, and expands to show the copy that went out. Each campaign has a Slack summary button that posts the result to a team channel using the Slack Bot Send a Message operation: campaign name, segment, audience size, delivered and failed counts, failure rate, and the title and body that shipped.

Add a Draft this campaign button that kicks off a background agent. The agent reads the saved segment definition and pulls a sample of matching user documents with Run Firestore Query, works out what that cohort has in common, and writes three title and body variants taking different angles, for example one value-led, one urgency-led, one curiosity-led, back into the draft campaign document with Update Firestore Document. The marketer opens the draft, picks a variant, edits it in the Compose fields, and sends. Show the agent's status in the app so they know when the variants have landed, and never let the agent send anything itself.

Bake in the guardrails. Users with notifications disabled or a quiet-hours flag set are excluded from both the recipient count and the actual send, so the number on screen is the number of people who will really be reached. Sends go out in throttled batches with a short pause between them rather than one giant blast, with the batch size and pause configurable. And the console refuses to send the same campaign twice: if a campaign with the same segment and the same copy has already gone out, block the send behind an explicit duplicate confirmation.

One more thing to keep clear in how this is built: this is an operated console, not an automation. It is deliberately different from a scheduled win-back workflow that picks its own dormant cohort and fires unattended. Here a human defines and previews the audience, approves the copy, tests on their own device, presses send, and reviews history. Do not add schedules, triggers, or anything that sends without a person clicking.