380,000 Pushes, 4,200 Permanent Opt-Outs: How to Build a Push Notification System — FCM/APNs, Deep Links, Segmentation, and Opt-Out Control

A grocery delivery app: 120,000 installs, 38,000 monthly active devices. During anniversary week they sent 380,000 push notifications — about 1.4 per device per day. The visible numbers looked fine: 310,000 delivered, a 1.6% click rate, roughly NT$420,000 in attributed revenue. The real invoice arrived three weeks later. The share of iOS users who had switched notifications off climbed from 3.1% to 11.4%, meaning about 4,200 devices would never receive another message — including shipping and delivery alerts. Support tickets rose 34% that month, because those people now had to phone in to ask where their order was. The expensive part of push has never been the build cost.

When it fits, and when it does not

A dedicated push and messaging centre makes sense when

• You own an iOS/Android app and have 3,000+ monthly active devices, so segmentation is meaningful
• You have time-sensitive transactional messages: shipping, pickup ready, queue position, appointment reminders, failed payments
• Marketing and support need to schedule messages themselves instead of filing a ticket every time
• Taps need to land on a specific in-app screen via deep links, not the home tab
• You actually hold segmentation data: purchase history, browsing behaviour, region, lifecycle stage

Skip it for now when

• You have a website but no app. Email and LINE OA will outperform web push, whose iOS constraints and opt-in rates do not justify a first investment
• Monthly actives are under 1,000. The absolute number of people push can bring back is too small; the same budget spent on retention mechanics returns more
• Your only content is promotions with no transactional messages. Notification permission in those apps rarely survives three months
• Nobody owns copywriting and scheduling. A push system is not a machine you switch on; it is closer to a weekly publication
• Users already open the app three times a day. You need in-app messaging, not push

Alternatives compared

The pragmatic answer for most mid-sized teams is a hybrid: transactional messages on self-hosted FCM/APNs, where volume is high and a vendor outage is unacceptable; campaign messages on a SaaS console for its segmentation and A/B tooling.

The build, phase by phase

• Phase 1 — Message inventory (3–5 working days). List every message the product can emit and tag each one: transactional or marketing, trigger condition, destination screen, opt-out eligibility. Tools: a Notion message catalogue, Figma notification mockups. Deliverable: message matrix plus a draft opt-out policy.
• Phase 2 — Channels and permission design (5–8 working days). Generate the APNs auth key under Apple UserNotifications, configure a Firebase Cloud Messaging project, and design Android notification channels so users can mute "promotions" without muting everything. Deliverable: a minimum viable channel delivering to test devices.
• Phase 3 — Backend messaging centre and deep links (15–25 working days). Device token registration and stale-token cleanup, segmentation queries, a scheduling queue (Laravel Queue plus Redis), Universal Links and App Links configured and tested. Deliverable: a console that can schedule, segment, and track delivery and taps.
• Phase 4 — Permission timing and preference centre (5–8 working days). Stop asking for permission on first launch; ask after the user completes something valuable. Ship an in-app preference screen so a single category can be switched off. Deliverable: a pre-permission explainer screen and preference page.
• Phase 5 — Staged rollout and monitoring (3–5 working days). Send to 5% of devices, watch for two hours, confirm deep links resolve, then go full volume. Deliverable: a send SOP, an emergency kill switch, and a delivery dashboard.

What it really costs

• Message inventory and UX planning: 24–40 hours
• Channel integration across iOS, Android and backend: 60–90 hours
• Messaging console (scheduling, segments, templates, reports): 80–140 hours
• Deep links and cross-device testing: 16–28 hours
• Total build: roughly NT$180,000–350,000, depending on segmentation complexity

The line items people forget

• Apple Developer Program at US$99/year; Google Play developer account at US$25 one-time
• FCM and APNs delivery itself is free, but if you move to SaaS, OneSignal's paid plans and comparable products price by reachable subscriber count — user growth becomes fee growth
• SMS fallback when a push goes unread for 24 hours: roughly NT$0.8–1.2 per message
• CDN bandwidth and image cropping for rich notification images
• APNs key and certificate rotation: 2–4 hours a year, and forgetting it takes every notification offline
• The largest line: 4–8 hours a month of copywriting and scheduling, forever

Expectation versus reality

Six traps and how to avoid each

• Trap 1: asking for notification permission on first launch. Show a custom explainer first and only call the system prompt when the user taps yes, so a decline still leaves you a second chance.
• Trap 2: one switch for every message type. Split into orders, reminders, offers and content using Android channels and an in-app preference page, so users mute one category rather than all of them.
• Trap 3: transactional and promotional messages sharing a queue. Run two queues with separate priorities so shipping alerts stay on time when a campaign floods the system.
• Trap 4: no TTL, so users power on to a stack of expired messages. Set a time-to-live on every time-bound message (four hours is a reasonable default) and drop it after expiry.
• Trap 5: overnight sends. Every schedule carries the recipient's time zone and a quiet window (no non-transactional sends 22:00–08:00), enforced as a default nobody can bypass in the console.
• Trap 6: no kill switch. Any bulk send must be abortable mid-flight. This feature repays the entire build budget on the day you send the wrong copy.

Success metrics and the first 90 days

• Day 30. Watch opt-in rate and reachable device count. The goal is a stable opt-in rate and automatic weekly cleanup of dead tokens. Send only transactional messages, so users learn that this app's notifications are useful.
• Day 60. Start segmenting and A/B testing copy length, send time, and rich images. Track click rate together with seven-day retention after the click — a push that people tap and immediately bounce from is spending trust, not earning it.
• Day 90. Promote opt-out rate to your primary KPI. Set a red line (say 1.5% per month) that automatically throttles send frequency when breached. Build automated journeys — cart abandonment, win-back, delivery alerts — so the team shifts from sending manually to maintaining rules.

Decision checklist

• ☐ We have our own app, not only a website
• ☐ Monthly active devices exceed 3,000
• ☐ At least one message type is genuinely time-sensitive
• ☐ We know our current notification opt-in rate
• ☐ We know our current opt-out rate
• ☐ Someone owns push copywriting and scheduling
• ☐ We hold user data usable for segmentation
• ☐ Taps need to reach specific in-app screens
• ☐ We will fund a preference and opt-out centre
• ☐ We accept 4–8 hours of monthly operating effort
• ☐ We agree internally on quiet hours and a frequency cap
• ☐ Legal has reviewed how marketing consent is captured
• ☐ Someone can hit the kill switch within five minutes

Nine or more ticked: start building. Five to eight: fix staffing and segmentation data first. Fewer than five: invest in email and in-app messaging instead.

FAQ

Should we build our own or use OneSignal?

It comes down to volume and data sensitivity. If transactional volume is high and a vendor outage would delay shipping alerts, build it. If campaigns need fast segmentation and A/B tests, the time a SaaS console saves easily exceeds the subscription. Most teams end up running both.

Our opt-in rate is low — can it be recovered?

Yes, but by changing the timing rather than the wording. Move the prompt to just after the first completed order or first saved item, and explain what will be sent with your own screen before the system dialog appears. Users who already declined can only be sent to settings, which almost nobody does — so the first ask decides nearly everything.

Is it push or LINE OA, one or the other?

Neither exclusively. Transactional and real-time alerts belong on app push, which is free and can deep link; promotions and content work well on LINE OA, which reaches people without an install. The one rule that matters: dedupe at the backend so the same user never gets the same message on both channels in one day.

Do we need web push?

Look at your device mix first. The Web Push API works on desktop and Android browsers, but on iOS the user must add the site to their home screen first, which makes real-world opt-in very low. If your core audience is on iOS, those hours usually return more in email and in-app messaging.

How long does the build take?

Six to nine weeks across the five phases, with deep link testing and permission flow design the two most commonly underestimated. Transactional notifications alone, without a segmentation console, compress to three or four weeks.

Next step

ScriptWalker's App Push and Messaging Centre build starts at NT$160,000 and covers the message matrix, FCM/APNs integration, a segmentation and scheduling console, deep links, and a preference centre. A one-off Push Health Check is NT$18,000 and delivers a diagnosis of your opt-in, opt-out and delivery rates with a prioritised fix list within two working days. If you would rather spend 30 minutes deciding between building and buying, reach us here:

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p