Customer Journey Examples
End-to-end walkthroughs of how Siren handles common attribution scenarios: simple sales, multi-program payouts, and platform-specific cases for WooCommerce and LifterLMS.
Last updated: April 9, 2026
This page walks through a handful of real customer journeys so you can see how Siren’s engagement, conversion, and obligation pipeline actually runs end-to-end. It’s aimed at anyone who’s finished setting up their first program and wants to confirm the pieces fit together the way they expect. Each scenario uses concrete numbers and names so you can follow along, compare against your own admin, and catch misconfigurations before they turn into payout surprises.
A simple affiliate sale
Start with the most common scenario. Affiliate A shares their referral link, a visitor clicks it, and Siren records that click as an engagement tied to Affiliate A. The association is stored in a cookie so Affiliate A keeps credit even if the customer doesn’t buy right away. How long that credit lasts is determined by the expiration time you set when you created the program.
The visitor browses, adds a beanie and three belts to the cart, and checks out for $183. When the order is placed, Siren creates a transaction for the order details and a conversion linked to Affiliate A’s program. You can find the new conversion under Siren > Conversions in the WordPress admin.
If your payment gateway finalizes orders automatically (like Stripe), the conversion goes straight to complete and an obligation is created for the calculated commission. If you’re using something like check payments that puts the order on hold, the conversion sits in “depending” status until the order is marked completed in your commerce plugin. Once the order is completed, the obligation appears and shows exactly what you owe Affiliate A (in this case, $10.95). Nothing else needs to happen until you’re ready to pay them out.
Multiple programs paying out on one sale
Siren can create more than one conversion from a single transaction, as long as the programs aren’t competing inside the same program group. This is how you stack rewards for different kinds of contributions without them interfering with each other.
Picture a site with two programs running side by side. The first is an affiliate program that pays 3% on sales. The second is a blog content program that pays 1% to authors whose posts get read before a purchase. Neither program is in a group, so they evaluate independently. A customer arrives through Affiliate A’s referral link, then later reads a blog post written by Author B before heading to the shop and buying $180 worth of product. At that point, Siren has two engagements on file: one for Affiliate A (the referral click) and one for Author B (the blog post view), attached to two different programs that don’t share a group.
When the order completes, Siren evaluates each program separately. The affiliate program fires for Affiliate A and creates a conversion worth $5.40. The blog content program fires for Author B and creates a separate conversion worth $1.80. One transaction, two conversions, two obligations, two collaborators getting paid for different contributions to the same sale. The transaction screen in the admin shows both obligations and the total payout across all programs for that order.
This is what Siren does by default. As long as programs aren’t grouped, every program that matches a transaction will fire. That’s the opposite of how most affiliate plugins work, and it’s intentional: it lets you reward different kinds of contributions (referrals, content, co-marketing, product ownership) without forcing them to compete for the same payout.
Using a program group to prevent double-pays
Now flip the scenario. Say you want a standard affiliate program at 3% and a super-affiliate program at 5% for your top performers. You don’t want both to fire when a super-affiliate makes a referral, because that would pay them twice for the same sale. This is exactly what program groups are for. You bundle the two affiliate programs into a group (for example, using newest engagement wins), and Siren will pick exactly one winner per conversion.
With the group in place, a super-affiliate’s referral fires only the super-affiliate program. A standard affiliate’s referral fires only the standard affiliate program. Even if a customer somehow ends up with engagements from both (say they clicked a standard affiliate’s link on Monday and a super-affiliate’s link on Wednesday), the group’s structure decides who wins. Newest engagement wins picks whichever click or view happened most recently, so the super-affiliate gets the credit in that example. A blog content program that’s left outside the group keeps paying independently, because grouping is only about programs that would otherwise overlap. If you’re not sure which structure fits your setup, the structure comparison page walks through the options.
Course platform: instructor royalty plus external affiliate
LifterLMS sites often layer a royalty program on top of their affiliate programs, which creates a useful case study for how grouped and ungrouped programs interact. Imagine three programs on a course site:
- A standard affiliate program at 25%, open to anyone.
- An instructor affiliate program at 47%, reserved for course creators promoting their own work.
- An instructor royalty program at 50% that pays the course owner whenever their course sells, no matter who referred the buyer.
The two affiliate programs are wrapped in a program group using newest engagement wins. The royalty program is deliberately left out of the group because it rewards authorship, not marketing, and should always pay regardless of who made the referral.
Say Author B owns a $100 course. When Author B shares their own referral link and a student buys through it, Siren creates two conversions. The first is from the instructor affiliate program ($47), because Author B’s referral engagement won inside the affiliate group. The second is from the instructor royalty program ($50), because Author B owns the course and the royalty program isn’t in the group. Author B walks away with $97 of the $100 sale, and the platform keeps $3.
Now swap the referrer. Affiliate A shares the same course and a different student buys. This time Affiliate A earns $25 from the standard affiliate program, and Author B still earns $50 from the royalty program because they own the course. Two collaborators, two conversions, one transaction. The royalty program fires regardless of who referred the sale, because it isn’t in the affiliate group and isn’t competing with anything. This layering is how course platforms reward instructors for both making the content and bringing in students, without accidentally double-paying or forcing a choice between the two roles.
What to verify in the admin
After you’ve run a test purchase through your own site, here’s what to check:
- Open Siren > Conversions and confirm a new conversion appears for the order. If it’s stuck in “depending,” the underlying order probably hasn’t reached completed status in your commerce plugin yet.
- Click into the transaction to see the line items, totals, and the calculated payout amount across all programs that fired.
- Click the obligation ID to confirm the correct collaborator got credit and the amount matches what your program’s incentive structure should produce.
- If you expected multiple conversions (like the scenarios above) and only see one, double-check your program groups. A program you expected to fire independently might be grouped with another one by mistake.
Running through a test purchase yourself is the fastest way to catch setup problems before real customers and real money are involved. A private browser window, a collaborator’s referral link, and a cheap test product are usually all you need.