What this prompt does
This prompt designs a push-notification strategy for your [app_type] app with [user_count] users. It defines notification categories ([categories]), segmentation rules based on [segmentation_criteria], personalization using [personalization_data], frequency capping ([max_daily] max per day, [quiet_hours] quiet hours), an A/B test framework for [test_elements], triggered notifications for [trigger_events], rich templates with [rich_media], deep-link routing per notification type, a granular opt-in/opt-out flow, and analytics tracking delivery, open, action, and dismiss rates. It specifies implementation with [push_provider], re-engagement campaigns for dormant users, and compliance with iOS and Android guidelines.
The structure works because push success is a strategy problem, not an SDK problem. Segmentation, frequency caps, and quiet hours are what keep notifications from training users to disable them entirely. Building deep-link routing and analytics in from the start means every send is measurable and every tap lands on the right screen, so you can actually tell which [trigger_events] and [test_elements] move engagement.
When to use it
- You're adding push to an app and want a strategy, not just wired-up
[push_provider]SDK calls. - Your opt-out rate is high and over-notifying may be the reason.
- You want segmentation and frequency capping so users get relevant, well-timed sends.
- You need triggered notifications for events like cart abandonment or order shipped.
- You want every notification deep-linked to the right screen and fully measurable.
- You're planning re-engagement campaigns for dormant users without spamming everyone.
Example output
Expect a strategy document: a category taxonomy, segmentation logic over [segmentation_criteria], personalization rules using [personalization_data], frequency-cap and quiet-hours configuration, an A/B framework for [test_elements], trigger definitions for [trigger_events], rich-template specs with [rich_media], deep-link routing per type, an opt-in/opt-out preferences flow, and an analytics plan. Implementation notes target [push_provider] and flag the iOS/Android compliance points.
Pro tips
- Respect
[quiet_hours]and[max_daily]strictly; the fastest way to lose push permission is to over-send, and won-back opt-ins are rare. - Make
[segmentation_criteria]actionable — segment on behavior you can actually query, not attributes you only wish you had. - Tie each
[trigger_events]notification to a specific deep link so the tap lands on the relevant screen, not a generic home view. - Use the A/B framework on
[test_elements]like send time and copy, since timing often outperforms wording for engagement. - Personalize with
[personalization_data]you can keep fresh; a stale "last viewed item" notification is worse than a generic one. - Build the analytics for delivery, open, action, and dismiss from day one, because a strategy you can't measure can't be improved.
