Browser push notifications

Browser push notifications is implementing and setting up web push notifications on a site: connecting a push service/SDK, a correct permission request (opt-in — a soft pre-prompt before the system request), collecting subscribers, segmentation, scenarios (welcome/triggered/promo/abandoned cart), a frequency policy (frequency capping), copy/icons/CTA, metrics (delivery/clicks/opt-outs). The work: implementation, opt-in, scenarios, frequency, metrics. Honestly about 'only with permission', this is key and fundamental: web-push is received only by users who explicitly allowed notifications in the browser; you cannot 'deliver to everyone' — reach is limited to those subscribed and not having revoked permission. Honestly about 'limited support': web-push is supported in desktop and Android browsers, but on iOS/Safari support appeared late and only for sites added to the home screen as a web-app — a significant part of the mobile iOS audience is unavailable. Honestly about 'delivery is not guaranteed': a push arrives when the browser is running/in the background and permission is active; with a closed browser/revoked permission/limitations delivery is not guaranteed. Honestly about 'frequency is double-edged': too-frequent/irrelevant pushes annoy and lead to mass opt-outs — the strategy is about a balance of value and frequency, not 'bombing'. Honestly about 'high opt-out rate': web-push is easy to disable, opt-outs are higher than in email — this is the channel's norm, we account for it. Honestly about 'pushes ≠ sales': pushes can bring a user back and raise engagement for part of the audience, but this is not a guarantee of conversion/sales — they depend on the offer/product. Honestly about the effect: it implements web-push with correct opt-in, segments, scenarios, frequency control and metrics, helping bring value to part of the subscribers without annoyance, but pushes go only with permission, support is limited (especially iOS/Safari), delivery is not guaranteed, the opt-out rate is high, pushes ≠ sales. Honestly about access: a site (HTTPS), a push service, traffic/subscribers are needed. An important boundary: this is web-push (implementation); push strategy overall (incl. mobile app-push) — 560; in-app messages — 567. The base price starts from 18,000 ₽ for implementation/setup (depends on the scope of scenarios).

• Pushes are sent chaotically/too often — mass opt-outs grow.
• A misconception that web-push reaches everyone and delivery is guaranteed.
• Not knowing about limited support (especially iOS/Safari) and about the mandatory permission (opt-in).
• A misconception that web-push = sales; an aggressive auto permission request right on entry (low opt-in).

• Connecting a push service/SDK to the site (HTTPS), a correct permission request (a soft pre-prompt + system)
• Collecting subscribers, segmentation
• Scenarios (welcome/triggered/promo/abandoned cart), a frequency policy (frequency capping)
• Copy/icons/CTA, metrics (delivery/clicks/opt-outs)
• An honest assessment: what part of the audience web-push is available to and what depends on the offer
• Honest boundaries (only with permission; support is limited — especially iOS/Safari; delivery is not guaranteed; high opt-out rate; pushes ≠ sales)
• Documentation and handover
• Review with you

• Implemented web-push with correct opt-in, segments, scenarios and frequency control + metrics
• A balance of value and frequency — value to part of the subscribers without mass opt-outs
• An honest assessment: what part pushes are available to and what depends on the offer/product
• Honest boundaries (only with permission; support is limited; delivery is not guaranteed; pushes ≠ sales)

• We implement the push service/SDK, set up correct opt-in (a soft pre-prompt), collect subscribers
• We set up segments/scenarios/frequency/copy/metrics
• We honestly set boundaries (only with permission; support is limited; pushes ≠ sales) and hand over

• Will web-push reach all site visitors?

  No, honestly: they are received only by those who allowed notifications in the browser. Plus support is limited (on iOS/Safari it appeared late and only for sites added to the screen as a web-app), and delivery is not guaranteed (browser closed, permission revoked). We honestly set it up for the real reach, without 'delivering to everyone'.

• The more pushes, the more sales?

  A dangerous misconception, honestly: too-frequent/irrelevant pushes annoy and lead to mass opt-outs (and web-push is easy to disable). Pushes can bring back and engage part of the audience, but this is not a guarantee of sales — they depend on the offer, product, moment. The strategy is about a balance of value and frequency, not 'bombing'.

• Can I auto-subscribe everyone right on entry?

  Doing so is harmful, honestly: an aggressive auto permission request right on entry gives a low opt-in and annoyance. We set up a soft pre-prompt (explaining the value before the system request) — this is more honest and effective. Subscription is always with the user's explicit permission, there is no other way.