The Referral Journey That Emails Both Sides (Without You Touching It)

CartWizard had what most Shopify app teams want: 2,000 active stores, $98k MRR, and a referral program that looked great on paper.

Merchants could share a unique link, earn months free when a friend installed, and see a little progress bar inside the app. But in Stripe and the Shopify Partner dashboard, the numbers didn’t lie: only a tiny fraction of customers ever referred anyone. And of the stores that did come through referrals, a lot never activated the app.

The code for the referral program was solid. The leak was everything around it.

Advocates didn’t get a clear “you did it” moment when a friend converted. New stores referred by a trusted peer got the same generic onboarding as everyone else. The viral loop depended on users guessing that their referrals worked.

The sequence at the top of this page is the whole journey, end to end. It fixes that by wiring a single referral event into two automated paths:

• a “thanks for referring” experience for the advocate

• a referral-aware welcome and activation path for the new store

All built once inside Spreeflo, then left to run.

This article walks through that journey, node by node, and how to adapt it to your own Shopify or e‑commerce app.

Where your referral program is quietly leaking revenue

For most e‑commerce apps, a referral program ships in three parts:

1. Backend logic to issue codes, track who referred whom, and award credit.

2. UI inside the app to show a link, maybe a progress bar.

3. A one-off announcement email or blog post saying “we now have referrals”.

What’s missing is everything that should happen when a referral actually lands:

• The advocate getting a specific, timely “your friend just converted, here’s your reward” message.

• The new merchant getting onboarding that acknowledges the referral and pushes them to their first win fast.

• The data you need to see which advocates are power users and which referred stores actually stick.

Without that layer, you are leaving two things on the table:

• Higher lifetime value from existing customers who would happily keep referring if the loop felt responsive.

• Higher conversion from referred signups who arrive warm but never see communication that reflects that context.

Founder-led teams win on leverage, not headcount. The referral flow in the sequence above is how you capture those extra dollars without adding a human to “run referrals”.

Let’s start with the data model behind it, then walk the journey.

The data model: one event, two automations

You only need two pieces of tracking to make this pattern work:

1. A custom event for the advocate when a referral is fully qualified.

2. A contact attribute on the new store that marks it as referred.

Your backend already knows when a referred store crosses whatever line earns a reward: finishes trial, installs your Shopify app, reaches a revenue threshold, whatever “counts” for you.

At that moment, from your backend you:

• Fire referral_converted event for the advocate’s contact using the Spreeflo API.

• Upsert the new store’s contact with Spreeflo.identify() from the frontend and set an attribute like signup_source = "referral" (and optionally referred_by = advocate_email).

That single decision means you can:

• Trigger an Custom Event journey from referral_converted for the advocate.

• Trigger a Criteria Match journey for any contact whose signup_source is "referral".

From there, Spreeflo’s campaigns and journeys handle the rest.

Now let’s walk each arm of the sequence.

Arm 1: Thanking and upgrading the advocate

This is the part most apps skip. You ship a referral UI and maybe a dashboard count, but no real communication loop with the advocate. The advocate should feel like a VIP every time their link actually produces value.

In the sequence at the top of this page, the left-hand arm is for the advocate.

1. Custom Event trigger: when a referral really lands

Node: Custom Event

• Event name: referral_converted (or whatever you use in your backend)

• Re-enrollment: turned on

Every time your backend fires referral_converted event for a merchant, this trigger enrolls them.

Re-enrollment is on because you want the same advocate to go through this path for every successful referral. The mid-journey lock in Spreeflo prevents them from being enrolled twice in parallel, but this flow is short, so that is rarely an issue.

If you only want to reward certain referrals (for example, only those who end up on your “Pro” plan), you can add property conditions on the event. For instance:

• Property plan is Pro

• Property billing_status is paid

Those conditions are configured inside the trigger using the same engine as the segment builder.

2. Tag and count this customer as a referrer

Right after the trigger, the journey applies two data-side actions:

Node: Add Tag

• Tag: referrer

Node: Update Contact Attribute

• Attribute: referral_count (NUMBER)

• Update type: Increment

• Value: 1

This does two things:

• You can instantly pull a segment of all referrers by filtering on the referrer tag.

• The referral_count attribute becomes a reusable metric across journeys, email personalization, or even your in-app UI.

Both of these updates happen silently; there is no customer-facing message yet.

3. Send the “thanks for referring” email

Node: Send Email

Configuration:

• Template: “Referral reward: your friend just joined” (or similar)

• Send only once: turned off, so they get this for every referral, not just the first

This is the moment of delight. The email spells out:

• Who they referred (if you store that name on the contact)

• What they earned (credits, free months, extra features)

• How close they are to the next tier (using referral_count if you surface it)

You can build this in minutes with Spreeflo’s email builder, using AI to adapt the subject and body to each app’s tone.

Important: Spreeflo enforces healthy pacing. There are no other Send Email nodes before this one on the advocate path, and every subsequent email is separated by a wait.

4. Add breathing room before tier logic

Node: Time Delay

• Delay: 1 day (minimum 1 hour)

This wait accomplishes two things:

• It keeps you from hitting the same person with back-to-back emails about the same event.

• It ensures any backend attributes that depend on the referral (like updated plan status) have settled before you branch on them.

If you want more real-time feel, set it to 1 hour. For most SaaS referral programs, a day works fine.

5. Branch advocates into tiers

Node: Multi-way Split

Here the condition is based on referral_count. For example:

• Branch A: referral_count is 1 or 2

• Branch B: referral_count is 3 to 4

• Branch C: referral_count is 5 or more

• Else branch: catches anyone without the attribute yet

Each branch uses the segment builder to define the condition:

• Type: Contact Attributes

• Attribute: referral_count

• Operator: GREATER_THAN, LESS_THAN, or IS

Now you can treat each tier differently.

New referrers (Branch A)

Actions might be:

• Add Tag: referrer-tier-1

• No additional email yet, to keep noise low

These are the folks you watch to see if your basic “thanks” email is enough to turn them into repeat referrers.

Growing advocates (Branch B)

Actions:

• Add Tag: referrer-tier-2

• Optional: Webhook to your own backend if you want to sync tiers there

You might also enqueue them into a separate nurture later focused on optimization tips, since they clearly like your product.

VIP advocates (Branch C)

Actions:

• Add Tag: vip-referrer

• Send Internal Email to your team: “New VIP advocate”

• That internal alert uses the Send Internal Email node, not a customer-facing Send Email, so it doesn’t affect message pacing. The body can include:

• The advocate’s email

• Their referral_count

• Their plan

• A suggestion to reach out personally

If you want to go further, add a Webhook node to post this into Slack or a CRM endpoint.

Finally, all three branches feed into a Merge node so the canvas stays clean.

The result: every successful referral gets a personal thank-you, your data gets richer with each event, and your team sees who is driving real growth.

Arm 2: Turning the referred store into a power user

The right-hand arm in the sequence is for the new store, the one that came in through a referral link.

The goal: treat them differently from a cold install, without writing custom logic in your app’s codebase.

1. Criteria Match trigger for referred signups

Node: Criteria Match

Condition (using the segment builder):

• Contact attribute signup_source is "referral"

• Email Subscription Status is Subscribed

Re-enrollment is left off. Each referred store should only go through this path once.

This trigger fires the moment your frontend calls Spreeflo.identify() and passes signup_source = "referral" for the new user. That can happen at the end of an install wizard, a signup form, or when they first open your app.

2. Tag referred users for later analysis

Node: Add Tag

• Tag: referred-user

This is a simple but valuable move:

• You can compare churn between referred-user and non-referred users.

• You can build segments like “referred users on Starter plan” for future upsell journeys.

3. Send a referral-aware welcome email

Node: Send Email

This is your main welcome email, but written specifically for referrals:

• Acknowledge that they were referred (“You’re here because Store X trusts us with their cart recovery”).

• Reaffirm what your app did for the advocate’s store.

• Make the “first success” CTA painfully obvious (e.g., “Turn on your first recovery flow in 2 clicks”).

Again, you build this quickly using the email builder. If you populate a referred_by or advocate_store_name attribute when you call Spreeflo.identify(), you can merge that into the subject or body for extra relevance.

After this Send Email node, the journey does not send another email until there’s a delay, to respect pacing.

4. Wait up to 7 days for activation

Node: Wait Condition

Condition:

• Custom Event app_setup_completed triggered at least 1 time in the last 7 days

• Timeout: 7 days

You’ll emit app_setup_completed from your app when the merchant finishes whatever you consider “activated”:

• For CartWizard, maybe that is “first recovery flow turned on”.

• For an analytics app, maybe “first report viewed”.

You can track that via the SDK and see it in web tracking and analytics, but the key here is that Wait Condition:

• If they activate quickly, they flow through as soon as the event hits.

• If they never do, they move on after a week, marked as not yet activated.

5. Branch on activation outcome

Node: If/Else

Condition (same as the Wait Condition):

• Custom Event app_setup_completed triggered at least 1 time in the last 30 days

If the condition is true, they go down the “activated” path. If false, they go down the “stalled” path.

Activated referred users (Then branch)

Node: Send Email

This email assumes success and pushes depth of use:

• “You’re live. Here are three ways power users get more from CartWizard.”

• Case studies from other stores with similar traffic.

• A soft nudge to explore higher tiers or advanced features.

You could also:

• Add Tag: referral-activated

• Update Contact Attribute: set onboarding_stage to "activated"

Both give you better cohorts later.

Stalled referred users (Else branch)

Node: Send Email

This is a rescue email, not a scold:

• Acknowledge they might be busy.

• Offer a 5-minute checklist or a loom-style walkthrough.

• Invite them to reply or open a support ticket if they’re stuck.

At this point you have:

• Used the warm context of a referral in the first email.

• Given them a week to succeed.

• Reached out again only if they look stuck.

No manual intervention, no spreadsheets of “referred users to follow up with”.

Measuring referral activation and referred conversion

You shipped the journey. How do you know it is doing its job?

Spreeflo’s segmentation makes both core metrics in this pattern straightforward.

Referral activation rate

Question: what percentage of your eligible customers actually refer at least one paying store?

Build two segments:

1. “Referral-eligible customers”
   - Tag contains active-customer
   - Plan attribute is not “Trial”
   - Contact Added Date is more than 30 days ago

2. “Active advocates”
   - Custom Event referral_converted triggered at least 1 time in the last 90 days

Referral activation rate is:

Active advocates / Referral-eligible customers

If this number is low, your problem is top-of-funnel for the referral program (awareness and incentive), not the journey described here. You might add a Cyclic-triggered campaign to gently remind long-time customers about the program.

Referred conversion rate

Question: of the stores that arrive through referrals, how many truly activate?

Again, build two segments:

1. “Referred signups”
   - Contact attribute signup_source is "referral"

2. “Referred and activated”
   - Same as above
   - Custom Event app_setup_completed triggered at least 1 time over all time

Referred conversion rate is:

Referred and activated / Referred signups

The journey you just built is specifically about lifting this metric by:

• Making the welcome more relevant.

• Giving them time to activate.

• Offering targeted help if they stall.

Because all of this logic is based on events and attributes, not lists you hand-maintain, it continues to work as you add new products, pricing, or markets.

Why this pattern keeps earning its place

For founder-led Shopify app teams, the temptation is to bake everything into the product itself: “we’ll just send the referral email directly from our backend”.

That usually leads to:

• Hard-coded messages that never get optimized.

• No segmentation by tier, country, or plan.

• Analytics that stop at “referrals per month” instead of activation by cohort.

By moving the referral flow into Spreeflo:

• Every advocate and every referred store gains a richer profile over time, so you can speak to each one uniquely.

• You plug a lifetime-value leak that most teams never see clearly, because they don’t connect referral behavior to onboarding outcomes.

• You set up a system that keeps running while you focus on features and App Store Optimization, not on manually nudging referrers.

You only design this journey once. After that, every new referral quietly routes through the same intelligent flow.

When you are ready to go beyond “we have a referral program” to “our referrals actually compound”, this is the kind of automation worth taking an afternoon to build.