Why rates live on programs, not collaborators

Siren doesn’t let you set a commission rate on an individual collaborator. You can’t open an affiliate’s profile and type “25%” into a rate field. That’s a deliberate design choice, and it surprises people coming from platforms where per-affiliate overrides are the default way to handle “some of my affiliates earn more than others.”

The question is almost always reasonable. You probably do have a few affiliates who earn more, either because they perform better, because they negotiated a better deal, or because they’re friends. The problem isn’t the use case. The problem is that per-collaborator rate fields are a low-quality tool for solving it. This page explains what Siren does instead and why.

If you’d rather read the underlying philosophy in a narrative form, the blog post at how multiple programs make Siren easier to maintain walks through the same reasoning with examples. This page is the shorter, more technical version you can link collaborators to when they ask.

The case against per-collaborator rate overrides

There are three specific reasons Siren avoids this pattern.

Audit trail clarity

When rates live on programs, the question “what deal is this collaborator on?” has a simple answer. You look at which programs they’re enrolled in, you read the rate on each program, you’re done. The programs list itself is the source of truth.

With per-collaborator overrides, the same question requires three lookups. First you check the override field on the collaborator. Then you check the program rate. Then you check which of those two wins, which depends on whatever priority rule the platform uses. Multiply that across 200 affiliates and the audit picture becomes opaque. You can’t look at a single screen and understand who earns what. You have to cross-reference fields that could diverge at any time.

Change safety

Editing a program rate updates everyone on that program at once, predictably. If you change the rate from 20% to 22%, every future conversion on that program calculates at 22%. There’s no ambiguity.

Editing one collaborator’s rate override silently creates drift between collaborators who are supposedly on the “same” program. The next person who opens the program and sees 20% has no idea that some collaborators are actually earning 22%, 25%, or a flat rate because someone negotiated with them months ago. The program rate is no longer the source of truth, but nothing on the program screen tells you that. This is how programs slowly decay into the spaghetti of “special cases” that make affiliate tooling so painful to maintain.

Pattern enforcement

If you find yourself wanting to set rates one collaborator at a time, you almost always have a tier pattern hiding underneath. Your top three performers. Your strategic partners. Your friends and family. Your beta group. Whatever shape the pattern takes, it’s usually not “50 bespoke one-off rates with no structure.” It’s “three or four tiers that I’ve been implicitly carrying in my head.”

Forcing the discipline of creating a program for each tier surfaces that pattern and makes it explicit. You end up with a “Standard Affiliate” program and a “Top Affiliate” program instead of a spreadsheet of custom rates you have to remember. That’s the shape that stays maintainable a year from now.

The patterns that replace per-collaborator rates

Siren has three concrete answers for the use case you probably actually have.

Tiered programs in a program group

This is the most common answer. Create a “Standard Affiliate” program at 15% and a “Top Affiliate” program at 25%. Put them both in a program group so only one fires per conversion. Enroll each collaborator in the tier they belong to. If someone earns their way into the top tier later, move them between programs.

The tiered affiliate program recipe installs this pattern directly. The AffiliateWP migration guide walks through converting a per-affiliate override structure into this shape.

Bespoke deals as their own programs

If you’ve negotiated a one-off rate for a strategic partner, create a program named “Strategic Partner: Acme Corp” at the agreed rate and enroll only Acme in it. That might feel like overkill for a single collaborator, but it’s the right shape. The deal is written down in an auditable place, the rate is visible in the programs list, and if you renegotiate later you update one program instead of hunting for a hidden override field.

The friction of naming the deal explicitly is the right friction. If you’re constantly creating bespoke programs for individual partners, that’s a signal that your rate structure is under pressure and you should probably consolidate, not that the tool is getting in your way.

Performance-weighted distributors for variable bonuses

If the variable amount depends on aggregate performance rather than a pre-negotiated rate (top affiliate of the month gets a bonus, contributors to a campaign split a pool, monthly leaderboard prizes), don’t try to encode that logic into per-collaborator rates at all. Use a distributor instead.

Distributors run on a schedule, track metrics over a period, and distribute a reward pool based on the structure you pick. Top Score Wins gives the whole pool to the best performer. Performance Weighted Pool splits it proportionally. Shared Engagement Pool splits it equally among everyone who participated. These patterns are what people usually mean when they say “I want top performers to earn more,” and they scale cleanly without touching individual rates.

Engaging the 200-affiliate criticism

The honest pushback on all of this sounds like: “That’s fine for a new program, but I have 200 existing affiliates with custom rates I’ve been negotiating for years. Converting them to tiered programs is a huge amount of audit work.”

That’s true. Migrating an existing program with lots of historical custom rates does mean doing the audit work of grouping people into tiers. You’ll probably discover that your 200 affiliates actually fall into four or five rate buckets when you look closely, plus a handful of genuine one-offs. That audit is real work, and we’re not going to pretend it isn’t.

The payoff is that after the migration, you have a tiered structure that’s auditable and changeable in one place, instead of 200 individual rate fields that could drift from each other at any time. The pain is front-loaded. The maintenance cost afterward is dramatically lower. If your current structure works well enough and you don’t want to do the audit, staying on your current tool is a legitimate choice. Siren’s design is optimized for the long tail, not for a zero-cost migration.

When you’d want this anyway

There’s a small set of cases where per-collaborator rate overrides would genuinely be better than Siren’s model. The most honest example is a program with hundreds of bespoke negotiated deals where no tier pattern exists, each rate was truly individual, and there’s no way to consolidate them without losing the business relationships. If that’s your situation, Siren isn’t the right tool for you today. We’re not going to pretend it is.

For most programs, though, the per-collaborator rate instinct comes from the habits of legacy tooling rather than from the underlying problem. The patterns on this page cover the vast majority of real cases. If you’re still not sure your use case fits, the blog post at how multiple programs make Siren easier to maintain has more detail on the underlying philosophy and a few worked examples that might match your situation.