Stop Wasting Push Prompts: A Permission Primer Playbook for Shopify Apps

The first time Olivia shipped web push for her Shopify app, it felt like flipping on a money printer.

CartWizard, her abandoned-cart recovery app, was doing about $80k MRR. She added a simple browser permission prompt the moment a merchant opened the app: “Allow notifications from CartWizard?” If they said yes, she could send real-time alerts on recovered revenue, broken flows, and flash-sale performance.

A month later she checked the numbers.

Fewer than 6% of merchants had granted permission. Most had clicked “Block” without thinking. And because browsers make it painful to re-request, that decision was effectively permanent.

Push hadn’t failed. The way she asked for it had.

The pattern in this article fixes that. It’s a push permission primer: a soft, in-product explanation of what notifications will be used for, followed by a timed, behavior-driven permission request and a journey that reacts differently to “Allow”, “Block”, and “Ignore”.

The sequence at the top of this page is the whole journey, end to end. This article walks through why it’s structured that way and how to adapt it to your own e‑commerce app.

We’ll frame it for a fictional Shopify app, CartWizard, but the same playbook works for any e‑commerce SaaS or headless stack.

Why blind push prompts quietly kill a powerful channel

Push notifications are high-friction. Your users have been burned by noisy apps, so the default move is to hammer “Block” and get on with their day.

For Shopify apps and e‑commerce tools, three problems show up again and again:

1. Wrong timing. You ask for permission on first load, before the merchant has configured anything or seen value. They can’t yet imagine what “notifications from this app” would do for them.

2. Wrong person. The first person to open your app might be a junior staffer on a dev store. They see a generic browser dialog and block it on instinct. Now the actual decision-maker never even gets the chance.

3. No memory. You don’t store who said yes, who said no, and who never saw the prompt. You treat everyone the same in later messaging, so you can’t be precise: “only send push about a critical outage to merchants who explicitly asked for it.”

All three are data problems. You’re not capturing enough detail on each customer to speak to them uniquely.

A push permission primer solves this by:

• Showing a clear in-app explanation of what you’ll send and why.

• Asking at a moment when notifications obviously add value.

• Tracking the result as a first-class event, so your journeys and segments stay in sync with each person’s choice.

Spreeflo gives you all the pieces: Web Push, custom events from the SDK, and behavior-based campaigns and journeys. Let’s wire them together.

What this journey does at a glance

Before we go node by node, zoom out.

The journey behind the sequence at the top of this page does three things:

1. Orchestrates the primer and permission request. Your app shows a friendly in-product primer and, when the user clicks “Turn on alerts”, calls the browser’s native permission prompt.

2. Tracks the outcome with events. When the user grants, denies, or dismisses, your app sends a custom event into Spreeflo.

3. Responds differently to each outcome. A Spreeflo journey, powered by Custom Event triggers, tags the contact, then:

• Sends a “you’re all set” push to confirm for those who granted.

• Sends an email alternative for those who denied.

• Sends a light-touch follow-up later for those who dismissed.

Along the way, it builds a clean data layer you can use in the segment builder, your reporting, and future campaigns.

Let’s walk through how to build it.

Step 1: Track the right push-permission events

Everything starts with good data. If you only know “we showed a prompt to 1,000 users and 70 clicked Allow,” you can’t do much beyond a rough opt-in rate.

Instead, instrument three explicit custom events from your app via the Spreeflo SDK or the Spreeflo API:

• push_primer_shown – when your in-app primer UI appears.

• push_permission_result with status = "granted" – when the browser permission is granted and subscription succeeds.

• push_permission_result with status = "denied" or status = "dismissed" – when the user blocks or closes the prompt.

You’ll also want a standard install or activation event such as app_installed or first_campaign_launched. Those are the behavioral anchors that tell you when to show the primer.

Because custom events are first-class in Spreeflo, you can:

• Trigger journeys directly from them using the Custom Event trigger.

• Use them as filters inside segments and If/Else conditions.

• Analyze them alongside web data in web tracking and analytics.

This is where the “capture detail on every customer” message becomes real. Once you’re recording every permission decision, you never have to guess who is push-capable, who preferred email, and who hasn’t been asked yet.

Step 2: Design the soft primer UI with Web Push

Next, you want the actual primer experience to feel human, not like a raw browser prompt.

In Spreeflo’s Web Push setup you choose an opt-in pattern. For this playbook, pick the Dialog pattern rather than going straight to the native prompt. That dialog is your primer.

Inside that configuration (see the web push setup guide), you can:

• Write clear copy: what notifications are for, how often, and who should enable them.

• Emphasize value specific to your app: “Revenue alerts when we recover an abandoned cart,” “Real-time alerts when a sales flow breaks,” “Weekly summary of the revenue we added.”

• Avoid vague promises like “product updates” that sound like marketing blasts.

Then, in your app UI, only show this dialog when the user has done enough to care. For CartWizard, that might be:

• Installed the app (app_installed).

• Connected at least one store.

• Created or enabled their first recovery flow.

At that moment, your app calls Spreeflo.webpush.showPrompt() in response to a clear button in your own UI, such as “Turn on revenue alerts”. The dialog appears, and if the user accepts, the browser’s native prompt follows.

Right here, you’ve already improved the quality of opt-ins. You’re asking the right people, at the right time, with the right context.

Now let’s wire the journey that reacts to what they chose.

Step 3: Handle “Allow” with a Custom Event trigger and a welcome push

The first branch in the sequence handles successful permission grants.

1. Trigger: Custom Event (granted)
   - Node: Custom Event trigger
   - Event name: push_permission_result
   - Property condition: status is "granted"
   - Re-enrollment: on
   
   Re-enrollment is important here. If a user changes their mind in browser settings months later and grants permission, you want this path to run again. Journey re-enrollment in Spreeflo is scoped at the journey level, so turning it on for this trigger guarantees they can re-enter after exiting.

2. Tag the contact as push-capable
   - Node: Add Tag
   - Tags: push-opted-in
   
   This makes it trivial to build a “can receive push” segment later. You could also write to a custom attribute with Update Contact Attribute, but a simple tag is usually enough.

3. Wait before sending anything
   - Node: Time Delay
   - Delay: 1 hour
   
   You do not want to blast someone with a marketing-style notification the second they click “Allow”. The OS has just shown them a system dialog; give that moment a breather.

4. Send a primer-confirmation push
   - Node: Send Web Push
   - Content: a short, specific “you’re set” message:
   - Title: “You’ll now get revenue alerts from CartWizard”
   - Body: “We’ll only notify you about recovered revenue, stalled flows, and billing issues. You can change this anytime in Settings.”
   
   Toggle “Send only once” in this node so a user who flips permissions back and forth doesn’t keep getting the same confirmation.

This branch uses push immediately, but in a respectful way. It sets the expectation: you’re not going to spam them; you’re using notifications exactly for what the primer promised.

Because Web Push is part of Spreeflo’s Professional plan, this entire path lives in the same campaigns and journeys environment as your emails and other automations.

Step 4: Handle “Block” with an email fallback

Some users will block notifications on principle. You should respect that choice and still keep them in the loop.

1. Trigger: Custom Event (denied)
   - Node: Custom Event trigger
   - Event name: push_permission_result
   - Property condition: status is "denied"
   - Re-enrollment: on
   
   Again, re-enrollment stays on so if they unblock later and you re-prompt, you can process the new decision cleanly.

2. Tag the contact as push-off
   - Node: Add Tag
   - Tags: push-denied
   
   This becomes your long-term “don’t assume they get push” qualifier.

3. Pause before following up
   - Node: Time Delay
   - Delay: 1 day
   
   If someone just blocked a permission prompt, the last thing they want is an immediate email argument about why they were wrong.

4. Send a “we’ll use email instead” message
   - Node: Send Email
   - Built with: your usual templates or Spreeflo’s email builder
   
   The email is straightforward:
   
   - Acknowledge their choice: “You opted not to receive browser notifications from CartWizard.”
   - Explain how you’ll reach them instead: “We’ll email you summaries of recovered revenue and critical issues.”
   - Offer a clear path to change their mind later: “If you ever want instant alerts, you can enable notifications under Settings → Notifications.”

This is where cross-channel coordination matters. Because everything runs from one automation canvas, you can be confident a merchant who blocked push is getting an appropriate email sequence instead of silent failure.

Step 5: Handle “Dismissed” with a gentle nudge

The third group are the undecided users who close the prompt or ignore it.

1. Trigger: Custom Event (dismissed)
   - Node: Custom Event trigger
   - Event name: push_permission_result
   - Property condition: status is "dismissed"
   - Re-enrollment: on

2. Tag as undecided
   - Node: Add Tag
   - Tags: push-undecided
   
   This helps you exclude them from heavy-handed retry campaigns. They saw the primer; they just weren’t ready.

3. Give them time to activate
   - Node: Time Delay
   - Delay: 7 days
   
   In that week, they’ll hopefully get more value from your app: more flows configured, some revenue generated, a better feel for why alerts might matter.

4. Send a light-touch education email
   - Node: Send Email
   
   This message is less about “please enable push” and more about social proof and clarity:
   
   - “Merchants who turn on revenue alerts see issues 3x faster.”
   - “Notifications are only sent for X, Y, and Z – never generic marketing.”
   - A short CTA pointing to where they can switch it on later.

No nagging. Just one well-timed reminder that connects notifications to outcomes they care about.

Step 6: Build segments that treat each group differently

Now that the journey is tagging contacts based on their decision, you can create three simple segments with the segment builder:

• Push-ready merchants: contact is tagged with push-opted-in

• Email-only merchants: contact is tagged with push-denied

• Undecided: contact is tagged with push-undecided

Those segments let you:

• Target real-time promotions or outage alerts only to push-ready merchants.

• Ensure critical updates always go by email to email-only merchants, even if you also send a push blast.

• Exclude undecided from aggressive re-prompt banners in-app and stick to occasional education.

Because Spreeflo stores everything on a single contact record, you can combine these tags with behavior:

• “Push-ready + opened at least 3 emails in 30 days” for your most reachable users.

• “Undecided + recovered revenue > $500” for a one-off “it might be worth turning alerts on” campaign.

This is the heart of the brand promise: you’re not yelling the same message at everyone. You’re using detailed, per-contact data to choose the right channel, cadence, and copy.

Step 7: Measure opt-in rate, session lift, and CTR

You don’t want a “feels better” solution; you want numbers.

Here’s how to track the three key metrics from this pattern.

1. Push opt-in rate
   
   Use your push_primer_shown and push_permission_result events:
   
   - Total primers shown = count of push_primer_shown.
   - Total grants = count of push_permission_result where status = "granted".
   
   The ratio is your opt-in rate. Track it over time as you tweak primer copy, timing, and the behaviors that trigger it.

2. Downstream session lift
   
   With web tracking enabled (Professional plan), build two segments:
   
   - Segment A: contact is tagged with push-opted-in
   - Segment B: contact is not tagged with push-opted-in
   
   In the web tracking and analytics dashboard, compare Visitors, Sessions, and New vs Returning for each segment. Over a month or two, you should see higher return visit rates and more sessions from Segment A if your notifications are pulling people back into the app.

3. Notification click-through rate
   
   Every web push template in Spreeflo tracks sent, delivered, clicked, and dismissed. For the confirmation push and any future alerts, keep an eye on CTR in that analytics view.
   
   If CTR is low, you might:
   
   - Tighten the use cases you send notifications for.
   - Personalize copy with AI variables while still matching the primer’s promise.
   - Split-test different content using a Random Split node upstream of Send Web Push in a separate journey.

Because contacts carry both their push tags and behavior history, you can constantly refine who you ask, what you promise, and what you deliver.

Putting it all together for a Shopify app like yours

Back to Olivia at CartWizard.

Before this pattern, she hard-prompted every new install, got a 6% permission rate, and had no idea who clicked what. Notifications felt risky, so the team underused them.

After implementing the push permission primer with Spreeflo:

• She only asked for notifications after a merchant enabled their first recovery flow.

• The primer dialog spelled out three specific alert types and nothing else.

• A Spreeflo journey handled the three outcomes, tagging each contact and sending either a confirmation push or an email alternative.

Within a couple of weeks, her opt-in rate climbed above 30%. More importantly, she had clean segments and accurate events. That let her ship a “high revenue alert” push for top merchants without blasting her whole base.

She didn’t hire a marketer to do it. She spent an afternoon wiring up events, configuring Web Push, and building one journey.

That’s the advantage small, founder-led teams have when they use automation well: you build a system once and it speaks to each customer differently from then on.

The takeaway: treat permission as part of your product, not a checkbox

Push isn’t a switch you flip. It’s a relationship you either respect or burn.

A soft, behavior-driven permission primer backed by a thoughtful journey:

• Asks the right people at the right time.

• Keeps a precise record of every decision.

• Routes each contact down a different path based on what they chose.

Spreeflo’s web push, events, and journeys give you the control to do this without bolting on extra tools or writing your own notification backend. If you already have tracking in place, this is an easy pattern to add. If not, the same SDK that powers push also feeds your analytics and segments.

Either way, the outcome is the same: you stop wasting permission prompts and start using push as a trusted, high-signal channel for the merchants who actually want it.