The “You Haven’t Tried X Yet” Journey That Quietly Lifts Your Shopify App’s LTV

By the time Lena at CartWizard noticed the pattern, it was almost embarrassing.

Their Shopify app was doing $100k MRR. Power users were installing, setting up basic cart recovery, and sending campaigns every week. But the advanced “Email Platform Integration” feature they’d spent a month building? Barely touched.

The kicker: stores that did use the integration had 40% lower churn.

Lena’s team tried the usual broadcast: a “New integration!” email to the entire list. Open rates were fine, click-through decent. Adoption barely moved. The wrong people were getting the right message.

So they built a tiny automation: “If you’re already a power user and you haven’t tried integrations yet, we’ll send a single, contextual nudge with a deep link into the app.”

That automation did more for feature adoption than any blog post or big launch.

The sequence at the top of this page is that journey, end to end. In this article, we’ll walk through why it’s built the way it is, how to adapt it to your own Shopify or e‑commerce app, and where it plugs into Spreeflo’s triggers, segments, and emails.

Why dormant features quietly kill retention

For e‑commerce apps, LTV isn’t just about getting more installs. It lives in how many users actually depend on your deeper features.

If you ship something like:

• A Klaviyo/Mailchimp sync inside a cart recovery app

• A “multi-store rollup” dashboard inside an analytics app

• An “automation builder” inside a review app

…those features are usually where the real stickiness and expansion happen. Customers who adopt them:

• Integrate you into more of their workflow

• Pull in more of their team

• Think twice before churning

But those same features also tend to be:

• Hidden behind secondary navigation

• More complex to set up

• Easy to ignore once the “basic” use case is working

Most teams respond with generic marketing: a product update email or a changelog entry every few weeks. That treats every contact the same. Power users who would absolutely benefit from Feature X get the same message as inactive trials who barely remember you.

Spreeflo is built around a different idea: capture detailed behavior on each contact so you can speak to them uniquely. That means you don’t announce “we have integrations.” You say:

“You’ve sent 18 recovery campaigns this month. You haven’t tried the Email Platform Integration yet. Here’s a 2‑click setup link.”

That’s what this journey does.

What this journey is designed to do

At a high level, the journey you see at the top of this page:

1. Finds users who are clearly getting value from your app.

2. Filters down to only those who haven’t touched a specific feature (e.g. integrations).

3. Sends one or two contextual nudges with deep links into that feature.

4. Watches whether they adopt.

5. Tags and timestamps the result so you can measure “retention by feature use.”

It’s built as a Journey in Spreeflo (continuous, behavior-driven) using:

• A Criteria Match trigger

• A few Send Email, Time Delay, and Wait Condition actions

• A couple of If/Else branches

• Simple data hygiene via Update Contact Attribute and Add Tag

You can build a journey like this once and let it run in the background while you work on your product.

Let’s walk node by node.

Step 0: Instrument the events and attributes once

Before any automation, you need enough data for Spreeflo to tell who is “ready” for the feature and who hasn’t used it.

For a CartWizard-style Shopify app nudging an “Email Platform Integration,” you’d want:

1. A custom event that proves the user is active
   - Example: recovery_campaign_sent or flow_running
   - Track this from your backend or client using the Spreeflo API or the JavaScript SDK described in the web tracking and analytics docs.

2. A custom event for the feature itself
   - Example: integration_connected (fired once when they connect their ESP)
   - This is the event the journey will watch for.

3. A simple plan or eligibility attribute
   - Custom contact attribute plan with values like Free, Pro, Plus.
   - Only Pro/Plus stores see the integration, so only they should get the nudge.

4. A couple of helper attributes/tags
   - Boolean integration_nudge_sent (have we already nudged them?).
   - Timestamp integration_adopted_at (when did they finally connect?).
   - Tags like integration_user and integration_not_interested for later segmentation.

All of these become usable in Spreeflo’s segment builder, which is the “brain” behind this journey.

Node 1: Criteria Match trigger – “this is relevant, but unused”

We start the journey with a Criteria Match trigger, because we care about profile state, not a single event.

In plain language, the criteria look like:

• Plan is Pro or Plus

• Email subscription status is Subscribed

• They’ve used the core app recently
  - e.g. Custom Event recovery_campaign_sent at least 3 times in the last 14 days

• They have never used the integration
  - Custom Event integration_connected has not triggered over all time

• We haven’t nudged them before
  - Attribute integration_nudge_sent is blank or not true

Under the hood, that’s a single condition group in the segment builder, using:

• Contact Attributes rules for plan and integration_nudge_sent

• Email Subscription Status rules

• Custom Event rules for both “active user” and “has not triggered” checks

A couple of important choices here:

• Re-enrollment is off. This journey should only run once per contact for this feature. If you later want a second nudge version, make it a separate journey gated on different attributes.

• We gate on activity, not just tenure. A store that installed last month but hasn’t sent anything doesn’t need an integration yet. Power use is the real signal.

This single trigger ensures the journey fires only when X is both relevant and unused.

Node 2: Update Contact Attribute – mark the nudge

Next, we immediately add an Update Contact Attribute action to set integration_nudge_sent to true.

Why set this before even sending the email?

• It guarantees that even if they drop out of the journey (unsubscribe, etc.), they won’t be re-enrolled by accident.

• It gives you a durable flag you can use in other segments and reports (for example, to compare churn between “nudged” and “never nudged”).

Configuration is simple:

• Attribute: integration_nudge_sent

• Update type: Update

• New value: true (boolean)

Later, we’ll also set integration_adopted_at via an Update Contact Attribute node once they successfully connect.

Node 3: Send Email – the first contextual nudge

Now we send the core message using a Send Email action.

This isn’t a feature announcement. It’s an individual suggestion based on behavior:

• Subject: “Connect CartWizard to your email platform in 2 clicks”

• Body:
  - Acknowledge their existing usage: “You’ve been recovering a lot of carts this month.”
  - Explain why the integration matters: “When you connect your ESP, you’ll see recovery stats right next to your campaigns.”
  - One clear CTA: a deep link to the integration settings in your app.

Use our email builder to design a clean, mobile-responsive layout, then pull in dynamic bits (store name, plan, etc.). If you want to experiment with subject lines and snippets at scale, the AI options in the editor plus personalize with AI variables can give you a starting point, but the key is context: this email only goes to people who fit the criteria you defined.

Leave “Send only once” turned on. This is not a message you want the same contact to get twice.

Node 4: Time Delay – give them space to act

After Email #1, we add a Time Delay of 3 days.

Configuration:

• Unit: Day(s)

• Value: 3

This does two things:

1. It respects pacing. You don’t want another email hitting their inbox immediately.

2. It creates a window where motivated users can explore and connect the integration without feeling chased.

Three days is a good starting point for most Shopify apps, but you can adjust based on your own usage patterns. If most customers set up automations within hours, shorten it. If they’re more “once a week” operators, lengthen it.

Node 5: If/Else – did they adopt quickly?

Next, we add an If/Else process node to branch the journey:

• Condition: Custom Event integration_connected triggered at least 1 time in the last 7 days.

This gives us two paths:

• Yes branch: they saw the email (or stumbled into the feature) and connected quickly.

• Else branch: they’re still active, still eligible, but have not adopted.

Using the event with a time window instead of “over all time” keeps the logic tightly tied to this specific nudge window.

Fast adopters branch: Tag and (optionally) alert the team

For the “yes” branch, we keep it light:

1. Add Tag action
   - Tag: integration_user
   - This tag becomes a powerful filter for future campaigns (“showcase new integration capabilities” only to integration users, for example).

2. (Optional) Send Internal Email
   - If you have any kind of success or sales-assist motion for higher-value stores, an internal notification like “Store X just connected the ESP integration” can be useful.
   - Use a simple template that pulls in contact attributes so your team has context.

3. Merge
   - We’ll bring this branch together with later adopters using a Merge node so any downstream actions (like setting the adoption timestamp) only need to be configured once.

No more marketing email goes out here. They did exactly what we asked.

“Not yet” branch: a single, more helpful follow-up

For contacts in the Else branch of the first If/Else, we assume interest but friction. Maybe they’re unsure what the integration does, or scared it will break their existing flows.

Here’s what this branch does:

1. Send Email #2 – education and reassurance
   
   Content-wise, this second Send Email should:
   
   - Start from their current state: “You’re already recovering abandoned carts. The next win is bringing that data into your email platform.”
   - Tackle common objections: show that connecting doesn’t affect sending, outline permissions clearly, mention that it’s reversible if that’s true for your app.
   - Include a short “How it works” section, ideally 2–3 steps with a single screenshot or GIF.
   - Again, one primary deep-link CTA.
   
   Because of the earlier Time Delay and branching, there’s healthy spacing between Email #1 and Email #2.

2. Wait Condition – watch for adoption without spamming
   
   After Email #2, we add a Wait Condition:
   
   - Condition: Custom Event integration_connected triggered at least 1 time over all time.
   - Timeout: 7 days.
   
   This step pauses the journey until either:
   
   - They connect the integration (condition met).
   - A week passes without action (timeout).
   
   It’s a clean pattern for “wait and react” without guessing the perfect delay.

3. Second If/Else – final fork: adopted vs. still ignoring
   
   We then add a second If/Else node, using the same condition as the Wait:
   
   - Yes branch: they eventually adopted after the second nudge.
   - Else branch: they’ve had two chances and a week. Time to stop pushing.

For the “yes” branch, we mirror the fast adopter path:

• Add Tag integration_user.

• (Optional) Send Internal Email to your team.

• Then into the same Merge node the fast adopters use.

For the “still ignoring” branch, we deliberately downshift:

• Add Tag integration_not_interested.

• End the journey.

That tag lets you exclude these contacts from future pushes about this specific feature. Respecting their decision is as important as nudging them in the first place.

Downstream of the Merge: timestamp and analytics

Both adopter paths flow into a Merge process node, then into a final data step:

• Update Contact Attribute
  - Attribute: integration_adopted_at (timestamp)
  - Update type: Set to now

This is your anchor for analysis. With that timestamp and the tags set, you can now:

• Build segments like “integration users vs. non-users” or “adopted within 7 days vs. after 30 days.”

• Compare churn and expansion metrics across those groups.

• Trigger other journeys, such as an “advanced integration tips” onboarding, again using a Criteria Match trigger.

Over time, this is where Brand Message 3 shows up in your numbers: most of your LTV lift comes from nurturing engagement with specific, sticky features. The journey quietly moves people along that path.

Variations you might layer on

Once the basic pattern works, you can extend it without changing the core logic:

• Per-feature journeys. Clone this journey for each high-value feature (e.g. automation builder, multi-store dashboards), swapping in different events and attributes.

• Join Segment instead of inline criteria. If you already have a saved “Power users” segment, you can use a Join Segment trigger and move only the feature-specific conditions into the journey.

• Email behavior-aware branches. Insert a Check Email Activity node after Email #2 to, say, send a different follow-up to people who opened but didn’t click versus those who ignored it entirely.

• Plan-aware messaging. Use If/Else with Contact Attributes to adjust copy for Plus vs. Pro customers while keeping a single underlying journey.

Whatever you change, keep two guardrails:

1. Only message contacts for whom the feature is both relevant and unused.

2. Always give them an obvious way to say “no thanks” (either by ignoring the last email or via preferences that adjust attributes/tags).

Reading the results where it matters

The surface-level metrics for this journey are:

• Feature adoption rate (before vs. after turning it on).

• Deep-link click-through rates on the nudges.

• Time-to-adoption from first eligibility.

The more important metric lives one layer deeper: retention by feature use.

Because this journey tags integration_user and timestamps integration_adopted_at, you can:

• Compare churn and expansion for integration users versus non-users.

• See how long it usually takes a power user to adopt the integration once they’re eligible.

• Decide whether you should invest in similar nudges for other features.

For a team like CartWizard, nudging integration adoption among already-active stores was one of the highest-ROI changes they could make. It didn’t add more installs. It stopped valuable customers from quietly churning.

The quiet win: speaking to each user’s actual behavior

This pattern is simple on paper: a trigger, a couple of emails, some waits and branches. The impact comes from how precisely it treats each store:

• It knows who’s actually using your app heavily.

• It knows who doesn’t see a particular feature yet.

• It asks, once or twice, with a clear path to success.

• Then it listens.

That’s what “capture detail on every customer so you can speak to each uniquely” looks like in practice. Spreeflo’s event tracking, web tracking and analytics, and journeys give you the wiring. You bring the judgment about which features matter.

Set this up once, let it run, and turn your “you haven’t tried X yet” moment into a quiet, compounding lift in both adoption and retention.