Push permission is a retention contract, not a growth hack

Why this matters

MDN notes that the Push API lets web applications receive server-pushed messages whether or not the app is in the foreground or even loaded. That is a powerful retention channel for installed web apps. It also raises the bar for user trust, because the app is asking for permission to interrupt the user outside the current browsing session.

What changed

Push depends on an active service worker and a subscription endpoint. MDN warns that push subscription endpoints are capability URLs and should be kept secret, and that PushManager subscription flows must protect against CSRF and XSRF issues. In other words, push is not only a UX feature; it is a security and lifecycle feature.

What builders should check

• Ask for push only after the user has experienced clear value.
• Explain the notification category before showing the permission prompt.
• Protect subscription endpoints and server-side subscription changes.
• Provide unsubscribe and preference controls inside the app.
• Measure opt-in quality, not just raw opt-in rate.

OpenPWA angle

OpenPWA should evaluate push as a retention contract. A good listing can explain whether notifications are transactional, editorial, collaboration-based, or marketing-oriented. That helps users decide whether installing the app will make their device more useful or simply noisier.

Sources:

• MDN: Push API