Push Notification Copy

Demo

Click to play with sound.

---
name: Push Notification Copy
description: Writes push and in-app notification copy that survives lock-screen truncation, ties every send to a user-specific trigger, deep-links to the exact destination, and respects frequency caps. Use when someone asks "write a push notification for this event", "why is our push opt-out rate rising", "draft re-engagement push copy", or is planning lifecycle, transactional, or re-engagement notifications. Do NOT use for implementing the delivery pipeline, tokens, or notification infrastructure - use push-notification-wirer instead; for deciding which lifecycle stage should send push at all, start with lifecycle-journey-map.
---

# Push Notification Copy

Push notifications live one tap away from being blocked permanently. Every send either builds or spends trust, the bar for sending is higher than email, and the margin for error is narrower - one misleading or mistimed push can cost the channel for that user forever. This skill prevents the two fatal patterns: copy that truncates into nonsense on the lock screen, and sends that exist because a calendar said so rather than because something happened.

## Inputs to collect

1. **The triggering event** - what just happened to this specific user (price drop, milestone, message received, task due). If the requester cannot name a user-specific trigger, stop: the send should not exist. Scheduled blasts untied to user events are spam regardless of how well-written they are.
2. **The deep-link destination** - the exact screen the tap opens. A push that dumps the user on the home screen breaks the promise the copy made.
3. **The variable data available** - names, amounts, deadlines, counts. Specifics are what make the body line earn its place.
4. **The user's recent notification history** - what they received in the last 24 hours and 7 days, to check against caps.
5. **Platform(s)** - iOS, Android, browser - for truncation behavior.

## Operating procedure

1. **Verify the trigger.** Confirm the send is the direct result of a user-specific event. No event, no send.
2. **Write the body first, then distill the title from it.** Writing the title last ensures it is the essence of the message, not a generic label. The body adds the detail the title omits - the specific amount, the person's name, the deadline - never a rephrase of the title. Two lines saying the same thing read as padding.
3. **Fit the limits.** Title: target **~40 characters** so it survives every surface; **60 characters** is the hard ceiling before most mobile lock screens truncate. Body: target **~120 characters**; assume anything beyond may be cut on smaller screens or watch faces. The title must stand alone and communicate the value without the body.
4. **Attach the deep link.** Every push deep-links to the exact content it references. Specify the destination alongside the copy so whoever wires it (push-notification-wirer) cannot guess.
5. **Check frequency caps.** Never more than **one push per day per user** - a ceiling, not a target; most users should receive fewer. Caps belong in the infrastructure layer so individual campaigns cannot exceed them by accident; if the system lacks caps, flag that before shipping copy into it.
6. **Set the permission-request timing (for new flows).** Request push permission immediately after the user experiences the product's core value, never on first launch. A user who just completed their first meaningful action has a reason to say yes; a user staring at an empty onboarding screen does not. Correct timing roughly doubles opt-in rates.