Self-Referral Prevention

Siren has a built-in, always-on mechanism that prevents collaborators from earning commissions on their own purchases. It runs automatically without any configuration, and you can’t turn it off. This page explains how it works, what it catches, and the situations where it won’t save you.

How it works

When a collaborator (any user with a Siren role) logs into the site, Siren detects the login through the UserLoggedIn event. A listener checks whether the user is a Siren user, and if they are, it invalidates any active opportunity tied to that user. Once an opportunity is marked invalid, no engagements or conversions can be created from it.

In practice, this means a collaborator who logs in and then makes a purchase won’t earn a commission on that purchase, regardless of which referral link or coupon code they used. The login kills the opportunity before the rest of the attribution pipeline has a chance to act on it.

What it catches

The most common case this protects against is a collaborator browsing their own site while logged into their account, clicking their own affiliate link to test it (or to buy something), and completing a purchase. The login event invalidates the opportunity before any engagement can fire, so the commission never materializes.

It also catches multi-session scenarios. If the collaborator was logged in earlier in the day, then opened a new tab and started the purchase flow, the opportunity tied to their user gets invalidated as soon as Siren sees the login, even if the buyer-side activity happens later. The check runs against the user’s opportunity, not against a specific session.

The limitations

The mechanism has real gaps. You should know about them before you rely on it for high-value programs.

Guest checkout

If the collaborator makes a purchase as a guest without logging into their Siren account, the invalidation never triggers. There’s no UserLoggedIn event for that session, so the listener never runs and the opportunity stays active. A determined collaborator can circumvent the protection by using their own link in an incognito browser and checking out without logging in.

Different account email

If the collaborator checks out with a different email address that isn’t linked to their Siren user account, the system won’t recognize them as a self-referral. The invalidation hangs off the user ID, so a checkout under an unrelated email looks like any other customer.

No per-program toggle

The mechanism is always-on and global. There’s no way to disable it for a specific program, and there’s no way to add additional checks (like a shipping address match or an email domain match) through the built-in settings. What you see is what you get.

When you might want stronger protection

For high-payout programs where a determined collaborator could justify the effort of using a guest checkout, combine Siren’s automatic protection with manual review. Hold conversions in pending status (configurable per program) and review each one before approving. Flag anything that looks like the collaborator’s own pattern: the same email domain as the collaborator’s account, the same shipping address on file, or purchase timing that lines up suspiciously with the collaborator’s own activity.

This isn’t something Siren can do for you, because the signals that would catch it vary by business. But the hold-and-review pattern gives you a human checkpoint that the automatic mechanism can’t.

Siren has a couple of other protections worth knowing about. Duplicate transaction binding prevents the same order from being processed twice, so an attacker can’t replay an order to earn multiple commissions. Lead deduplication within the program expiration window prevents the same lead from being credited twice to the same collaborator during an active tracking window. Neither of these is a self-referral check, but together with the login-based invalidation they cover most of the common abuse patterns.

For how refunds interact with the commission pipeline, see How Refunds Work. For the broader picture of what fraud patterns you’re likely to see and how to catch them without paying for a dedicated fraud service, read how to spot and prevent affiliate fraud.

For developers

The listener that handles this is InvalidateOpportunitiesFromSirenUsers at lib/Opportunities/Core/Listeners/InvalidateOpportunitiesFromSirenUsers.php. It subscribes to the UserLoggedIn event, resolves the user’s active opportunity through the mapping datastore, and delegates to OpportunityInvalidationService, which sets the opportunity status to invalid and broadcasts an OpportunityInvalidated event. The “is this a Siren user?” check is the SirenUserValidationStrategy, which iterates the configured Siren roles and returns true if the user has any of them.