Start with the customer task
A notification prompt is a request for ongoing access to a person’s attention outside the shop page. It should follow a concrete customer choice, not a marketing target or an engineering wish to test a new feature. Ask what event the customer genuinely wants to hear about: an order being ready for collection, for example, differs from every new product announcement. Specify the event, its expected timing, and the action the customer can take after receiving it. If the information is already visible in the account or order page, the browser alert may be an optional convenience rather than the only route to essential information.
Chrome’s Lighthouse documentation flags permission requests made on page load. Its guidance is to offer a specific notification type and ask after the user opts in to that type. This is a product decision as much as an implementation detail. A visitor who has not bought anything cannot assess a vague “allow updates” request. After an order, a choice such as “Notify me in this browser when pickup is ready” explains the benefit and scope. The page should state what happens if the person ignores it, and the purchase should already be complete before permission enters the flow. Avoid making the operating-system prompt look like a condition of checkout.
Before adding browser notifications, compare less intrusive channels already used by the business. A visible order-status page gives customers a place to check deliberately. An email can carry durable detail, though delivery and inbox attention have their own limits. An in-page message helps while the customer remains on the site. Browser notifications add value when timing matters and the person has chosen that channel on that device. Document which message is authoritative if channels disagree. For example, the order record, rather than a notification delivery result, should decide whether pickup is actually ready. That prevents a missed alert from becoming a missed operational state.
Design one clear opt-in path
The page can first show a plain-language choice for one alert category. After the customer activates that choice, code can check whether the Notifications API is supported and read the current permission state. MDN describes three values: default, granted and denied. Default means no decision has been recorded; it must not be treated as permission. Granted allows the feature to proceed. Denied requires a usable alternative and a restrained explanation of how the customer could change browser settings if they want to. Do not repeatedly force a browser prompt after refusal or imply that a page toggle can override a browser-level denial.
MDN says permission requests should be made in response to a user gesture, such as clicking a button, and that a secure context is required in supporting browsers. It also notes restrictions on cross-origin frames. Accordingly, place the actual request behind an intentional action on the shop’s own secure page. Test the behaviour on the browsers and devices customers use rather than assuming one desktop demonstration covers mobile. For mobile delivery, MDN warns that constructing a Notification directly is unsuitable on most mobile browsers and points developers to service-worker registration methods. This article focuses on the permission decision; any push delivery design needs its own implementation review.
Treat the site-level preference and the browser permission as separate facts. A customer may once grant browser permission, then turn off pickup alerts in their account. The shop should honour that narrower choice even though the browser still says granted. Conversely, a customer can select pickup alerts in the site interface while the browser says denied; the interface must not promise delivery. Store only the preference details needed to operate the choice and provide an obvious place to change it. Explain whether the choice applies to this browser, an account, or every device, because those are different expectations and may require different engineering.
Work through a pickup example
Imagine a shop that offers next-day collection at a counter. Immediately after payment, its confirmation page displays the order number and a link to the authoritative status page. Below that, the customer may choose an optional browser alert for “ready for collection.” If they press the opt-in button, the page checks permission. If it is default, the site requests permission in response to that press. If it is granted, the site can register the preference. If it is denied or still default after the request, the page returns to a neutral state and points to order status. The order itself remains confirmed throughout.
Next ask what the message should contain. “Order ready for collection” with a path back to the relevant order is more useful than a generic promotional phrase, but a lock-screen notification can be visible to other people. Avoid putting sensitive order contents or personal details in the alert unless the business has deliberately assessed that exposure. The notification should be linked to the same business event that updates the status page. A late or duplicate event should not create a misleading flood of prompts. The site may choose to combine repeated changes into one useful update, but it must not claim that a browser notification was delivered simply because the server attempted to send it.
Now consider a refusal. A customer who blocks notifications should still see the confirmation page and be able to find the order later. The shop may offer its normal email or account page according to the customer’s existing choices, without silently enrolling them in another alert. Staff answering a pickup enquiry should look at the order record and explain the available status route. This case shows why the browser permission must be an optional layer over a complete service. It also gives the team a testable outcome: purchase succeeds, alert preference is accurate, and the customer can reach the current status regardless of permission.
Test refusal, change and relevance
Use a fresh browser profile to test the first visit, because an existing permission decision can hide the request path. Test default, granted and denied separately, including a prompt that is dismissed without choosing either option. Check that no request fires on page load and that the click clearly describes the alert before the browser asks. Repeat on a supported mobile browser and keyboard-only navigation. Confirm that the button label and status message remain understandable in both English and Traditional Chinese. This is a functional test, not evidence that customers want the feature; only actual customer research and measured use can support that conclusion.
Review the preference lifecycle, not just the first grant. Let a customer turn a category off, sign out, switch device and revisit the order page. Decide what a new device should display when the account preference exists but local browser permission does not. Check how the interface responds if permission is changed in browser settings while the site is open. The precise mechanics vary across browsers, so phrase user instructions around the observed interface rather than an assumed universal settings path. Test that a denied state does not leave an enabled-looking toggle promising alerts that cannot appear.
Finally, review the alert catalogue at a regular product meeting. Remove categories that no longer serve a time-sensitive customer task, and make sure the wording still matches what the system actually sends. A shop may discover that a clearer order page answers most enquiries and that browser prompts add little value. Without reliable measurement, treat that as a hypothesis to test, not a reported outcome. The acceptance standard is modest and concrete: a person understands the specific benefit before being asked, can decline without losing the service, can later change a site preference, and can always find the underlying order information.
Before you proceed
- Is the alert tied to a specific customer-chosen event, with a clear fallback?
- Does the browser request follow a deliberate action on a secure page, and do all permission states work?
- Can customers decline or change the site preference without affecting the order journey?
