Stop Burning Your Shopify App List: Run a Re‑Permission Journey Before You Purge

When Lena at CartWizard finally pulled the plug on their old Mailchimp account, she exported a CSV with 48,327 “subscribers.”

Half hadn’t opened an email in over a year. A few thousand came from a partner’s list the team had inherited. Nobody could say, with a straight face, that all 48k still wanted CartWizard tips and feature updates.

The temptation was obvious: upload the whole thing into a new tool and send a big “We’re back!” campaign. The risk was just as obvious: spam complaints, a damaged sender reputation, and future onboarding sequences landing in Promotions or spam for the people who actually pay the bills.

The sequence at the top of this page is the whole journey, end to end. It’s a re‑permission flow you run before you send anything serious to an inherited or aged list. Instead of blasting everyone blindly, you ask them—clearly and politely—if they still want to hear from you, then automatically:

• Keep and tag the people who re‑confirm.

• Put the non‑responders into a non‑marketing bucket so they stop hurting your list health.

For a Shopify or e‑commerce app doing $20k–$200k MRR, this is boring work that quietly protects a very non‑boring asset: your ability to reach store owners when it actually matters.

Let’s break down how this journey works in Spreeflo, node by node, and how to adapt it to your own app.

Why old lists quietly kill SaaS and app revenue

If you’ve been building for a few years, you probably have at least one of these:

• An old Intercom or Mailchimp list you’ve exported.

• A CSV of merchants from an early beta or closed alpha.

• A list acquired from a partner app or co‑marketing campaign.

Most teams do one of two things:

1. Blast everyone and hope for the best.

2. Ignore the list forever “to be safe.”

Both options leak lifetime value.

Blasting everyone tanks deliverability. ISPs see low opens and a spike in “spam” button clicks. That reputation hit doesn’t just affect this one send; it follows your domain into future launches, product announcements, and renewal nudges. Your real customers become harder to reach.

Ignoring the list leaves money on the table. There are real store owners in there who would happily re‑engage, upgrade, or install a second app from you—but not if you never talk to them again.

A re‑permission journey is the middle path: you give people a clear, respectful choice. Those who raise their hand stay in your marketing universe. Everyone else is safely parked as non‑marketing so they stop dragging down your metrics.

This is exactly where marketing automation earns its keep for a tiny team: you design the flow once, then every cold or inherited contact is handled the same way without manual review. If you haven’t used Spreeflo’s visual editor before, the overview on how to build a journey is a good primer.

The strategy in one sentence

The journey at the top of this page:

Finds risky contacts based on profile + engagement, asks them “still want this?”, waits for a concrete yes, and automatically suppresses everyone else from marketing.

You can run it as a one‑off clean‑up on an inherited list, or leave it live as an ongoing hygiene filter for contacts who age into “cold” status.

Here’s how each node contributes.

1. Criteria Match trigger: define “risky” precisely

We start with a Criteria Match trigger, not a one‑time campaign, because we’re reacting to a profile state: “this contact is now considered aged or inherited.”

Configuration:

• Trigger type: Criteria Match

• Re‑enrollment: off (isReEnrollment=false) so each contact only goes through this re‑permission flow once.

• Criteria: built with the same segment builder you use for segments.

For a Shopify app, a sensible first pass for “risky” might be:

• Email subscription status is Subscribed.

• Marketing status is Marketing.

• Contact added date is before a date 6–12 months ago.

• Email Activity did not open any email in the last 180 days (over all time minus 6 months).

• Optional: Tag does not contain do-not-contact or similar.

You can get fancy—filter only by geography, plan, or app installed status—but the core idea is simple: you’re pulling in people who technically can be emailed but haven’t engaged in a long time.

Why Criteria Match here?

• You don’t have to create and maintain yet another saved segment just for this one flow.

• If you leave the journey running, any future contacts that drift into this cold profile will automatically enter.

2. Add Tag: mark re‑permission candidates

Next, we attach an Add Tag action:

• Tags: repermission_candidate

• Force tag trigger: usually off (no need to fire downstream Added Tag journeys).

This does two things:

1. It gives you a quick way to pull a report or export of everyone who ever entered the re‑permission flow.

2. It makes it trivial to exclude this cohort from other journeys while they’re mid‑re‑permission if you want to.

It’s a tiny node but pays off the next time someone asks, “how many old contacts did we clean up?”

3. First Send Email: plain‑spoken “still want this?” ask

After tagging, we send the first re‑permission email with a Send Email action.

Key choices:

• Keep “Send only once” on. Nobody should ever receive this exact re‑permission email twice.

• Use a very clear subject line and CTA. For example:
  - Subject: “Still want [Your App] updates?”
  - Button: “Yes, keep me on the list”

• Point the confirmation button to a simple hosted page (even a static route in your app) that thanks them and sets expectation. Link tracking will handle the segmentation on the Spreeflo side.

You can build this quickly with Spreeflo’s email builder, or paste in your own HTML if you prefer.

Why send this first instead of jumping straight to suppression?

Because some of these merchants installed your app three years ago on a side project. They haven’t thought about it since, but they’re still a good fit. Giving them a clean, low‑friction way to re‑opt in salvages that LTV instead of silently throwing it away.

4. Wait Condition: give them time to click

After the first email, every path goes through a Wait Condition:

• Condition: Email Activity has clicked this specific re‑permission email at least 1 time in the last 7 days.

• Timeout: 7 days.

This wait accomplishes two things:

• It spaces your emails so you’re not pinging people repeatedly in a short window.

• It lets engaged people move on as soon as they click, instead of forcing them to sit in a fixed delay.

Spreeflo’s Wait Condition uses the same criteria model as segments, so you can say “clicked marketing email X at least once in the last 7 days” very directly.

When either the click happens or the 7 days pass, contacts move to the next node.

5. If/Else: split confirmed vs quiet

Right after the wait, we drop an If/Else process on the canvas.

• Condition: identical to the Wait Condition (clicked the re‑permission email in the last 7 days).

Two branches come out:

• Yes branch: confirmed.

• Else branch: has not confirmed yet.

We could rely solely on the Wait Condition, but making the split explicit with If/Else makes the journey easier to reason about and extend.

On the Yes branch:

1. Add an Add Tag node: set repermission_confirmed. This permanent marker becomes useful when you want to see how many contacts saved from the purge later buy or upgrade.

2. Optional but recommended: add an Update Contact Attribute node that sets a timestamp attribute like last_repermission_at to “Set to now.” This gives you a hard record of when consent was refreshed.

We don’t send a “thanks for confirming” email here yet. Both confirmation paths will merge later so you can keep that message in one place.

On the Else branch, we’re not giving up; we just move towards a second attempt.

6. Time Delay + second Send Email: last chance

Cold contacts who didn’t click the first email hit a Time Delay:

• Delay: 1 day (or more if your brand voice is conservative).

That gap is non‑negotiable if you care about not looking spammy. Spreeflo enforces a minimum 1‑hour delay node between marketing emails on the same path; in practice, 24 hours feels much more respectful for a Shopify merchant’s inbox.

After the delay, we add a second Send Email:

• Subject: “Final reminder: keep [Your App] emails?”

• Copy: shorter than the first, with a very explicit “This is the last email we’ll send if you don’t confirm.”

The CTA again drives to a confirmation page or even the same button URL; on the Spreeflo side, we’ll look for clicks on either of the two re‑permission emails.

7. Second Wait Condition + If/Else: make the call

After the second email, we repeat the pattern:

1. Wait Condition:
   - Condition: Email Activity has clicked either re‑permission email at least 1 time in the last 7 days.
   You can express this as an OR group in the criteria: “clicked email #1 OR clicked email #2.”
   - Timeout: 3–7 days, depending on how patient you want to be.

2. If/Else:
   - Same condition as the Wait.

Now we have two sets of “Yes” branches:

• People who clicked the first email.

• People who ignored the first but clicked the second.

Both need to end up in the same “confirmed” treatment. This is where a Merge node comes in.

Connect the Yes branch from the first If/Else and the Yes branch from the second If/Else into a Merge. From the Merge’s output, we run the shared “you’re confirmed” steps:

• Optional Send Email:
  - Subject: “You’re all set, here’s what to expect from [Your App]”
  - Content: remind them how often you send and what kind of content they’ll get. Maybe link to a preferences center if you have one elsewhere.

• Confirmatory tagging / attribute updates if you didn’t already set them:
  - repermission_confirmed
  - last_repermission_at timestamp

Because both confirmation paths converge into the Merge before this email, every confirmed contact gets exactly one confirmation send, spaced by at least one Wait Condition after the last marketing email they saw.

8. Suppress the non‑responders safely

The final important branch is the Else path after the second If/Else: people who have ignored both emails and never clicked.

This is where the “purge” happens, but without deleting data you might still need for reporting.

Here we chain a couple of actions:

1. Update Contact Attribute:
   - Attribute: Marketing Status
   - Update type: Update
   - Value: Non-marketing

2. Optional Update Email Subscription Status:
   - Status: Non-subscribed

3. Add Tag:
   - Tag: repermission_suppressed

Helpful if you ever want to quickly see “who we deliberately stopped marketing to” or exclude that group from any future experiments.

There are no more Send Email nodes on this branch. They’ve had two clear opportunities to say “yes” and chose not to. Continuing to email them only harms your sender reputation and pushes your cold metrics in the wrong direction.

9. Seeing if it worked: what to track

A re‑permission journey doesn’t feel glamorous, but the impact shows up quickly in a few numbers:

• Re‑confirm rate
  Of everyone who entered the journey, what percentage ended up on the confirmed path? For an aged SaaS/app list, 10–30% is common. Treat that as “LTV recovered” that you might otherwise have suppressed or lost.

• List health
  In the weeks after you finish the re‑permission sweep, watch the open and click‑through rates on your regular broadcasts. With a smaller but cleaner list, both should trend up. So should inbox placement.

• Complaint rate and bounces
  Complaints per thousand emails and hard bounces should go down, because the worst‑quality addresses are no longer being mailed. This is especially visible if you’re migrating from an older platform and running your first campaigns out of Spreeflo.

Because Spreeflo separates marketing and non‑marketing contacts in its billing model, you also tend to see a secondary win on cost: you’re no longer paying for tens of thousands of ghosts. The pricing explainer on about Spreeflo’s plans and marketing contacts walks through exactly how that math works.

10. Adapting this pattern to your app

A few ideas to tailor the journey for your specific e‑commerce app:

• Tighten the criteria for high‑risk cohorts.
  If you acquired a partner’s customer list you barely know, you might only target contacts whose Contact Added Date is before a certain hand‑over date and who never triggered your app_installed custom event.

• Make the copy app‑specific.
  For an analytics app like ShopMetrics, the re‑permission angle could be: “We only want to send data‑driven content you care about. Still want our weekly revenue breakdown tips?” For a cart recovery tool, it might focus on “flash sale” and optimization content.

• Layer in internal alerts for whales.
  Add a Send Internal Email node off the confirmed path that alerts your team if a big merchant (say, MRR over a threshold in your own billing system) re‑confirms. That’s a great moment for a personal reach‑out.

• Turn it into ongoing hygiene.
  Once the initial clean‑up run is finished, tweak the Criteria Match so it targets “subscribed + marketing + did not open any email in the last 12 months,” and leave the journey running. Any contact that drifts into long‑term inactivity is automatically re‑permissioned before you keep sending broadcasts.

If you’re starting from another tool, the migration guide for importing contacts is worth a skim before you turn this on. Get the attributes and tags in place first, then light up the journey.

The quiet way to protect your future launches

Most Shopify app teams obsess over acquisition: App Store SEO, content, partnerships. Then they point all that effort at a list where a third of the contacts are ghosts and another third barely remember who you are.

That’s how lifetime value leaks out: not because you stopped building, but because your messages stopped reaching the people who would have upgraded, reinstalled, or tried your new product.

A re‑permission journey won’t make a splash in your changelog. But it does something more important for a founder‑led team: it gives you confidence that the merchants you’re emailing still want to hear from you, and it quietly retires the rest without drama.

Design it once in Spreeflo’s campaign and journey automation, let it run, and future you—mid‑launch, staring at a revenue dashboard—will be very glad your list is full of people who actually raised their hand.