Paying for customers, not for signups

Every customer on this site has a referral code from the moment their account exists. Send the link to somebody, and when that person places their first paid order, a five euro voucher appears in your account. That is the whole promise, and it fits in two sentences on purpose.

Underneath it there are perhaps a dozen decisions, and most of them are about fraud, timing and what counts as a referral. They are the interesting part, because a referral scheme that gets them wrong does not fail loudly. It quietly pays for signups that were never going to become customers.

The moment the reward is earned

This is the decision everything else hangs from, and there are three candidates.

Reward on click. Nobody does this, for obvious reasons.

Reward on signup. Common, simple, and an invitation. Accounts are free to create, email addresses are free to obtain, and any scheme that pays for a registration is paying for something that costs the other side nothing.

Reward on the first paid order. What this site does. The voucher is created when the referred customer’s first order is actually paid, which means the business has received money before it gives any away.

The third option is the only one that is self funding, and it changes the shape of the code. The reward cannot be issued by the signup flow, because the signup flow does not know whether a purchase will ever happen. It has to be issued by whatever hears about payment, which on this site is three separate WooCommerce events: payment completed, order moved to processing, order moved to completed. All three are listened to, because different payment methods take different routes, and the claim logic makes it safe for all three to fire.

Attribution, and the window

A referral link carries a code. When somebody arrives with one, the code is put into a cookie that the browser cannot read, and the click is counted so the referrer can see that the link is being used even before anybody buys.

When an account is created, the code is attached to it. Then four rules run:

• The code must belong to somebody who is not you. Referring yourself with a second account is the first thing anybody tries.
• The email addresses must differ. A second check on the same attack from a different angle.
• The account must be new. The attachment only works within twenty four hours of registration. An existing customer cannot be retroactively attributed to a referrer, which closes the loophole where somebody claims every customer they can find.
• The pair must be unique. The database refuses a second record for the same referrer and the same referred customer, rather than the code checking first and writing afterwards.

That last one matters for the same reason it matters everywhere else in this system. Two requests arriving together both pass a check and both write, unless the database is the thing that says no.

What the referrer sees

A code, a link, and three numbers: how many people clicked, how many signed up, and how many bought. Plus the vouchers earned and whether each has been used.

Showing clicks before there are signups is not decoration. A referral scheme with no visible activity feels broken, and somebody who can see that eleven people followed their link will send it again. Somebody who sees nothing assumes it does not work and stops.

The voucher, and why it is boring on purpose

The reward is an ordinary WooCommerce coupon, locked to the referrer’s email address, usable once, for a fixed amount rather than a percentage.

Locking it to an email is what makes the whole scheme safe to operate in public. The codes can be posted anywhere and shared with anyone and they will simply refuse to apply, because they only work for the person who earned them.

The coupon also carries the identifier of the referral that produced it, and the order that triggered it gets a note recording that a voucher was issued and which one. Six months later, when somebody asks why a particular discount exists, the answer is in the order rather than in somebody’s memory.

The edge cases that decide whether you can run this

Three of them, and each is a commercial decision before it is a technical one.

The referred order is refunded. The business has now paid a referral reward for revenue it gave back. This site removes the reward if the coupon has not been used, and the coupon usage counters are tracked in both directions so that an unused reward can still be withdrawn. Somebody has to decide what happens when the voucher was already spent, and the honest answer for most businesses is that it is a cost of doing business and it should be small.

Two people claim the same customer. Somebody clicks one link, then another, then signs up. Whichever code is attached at registration wins, and the record is unique per pair, so the second cannot be added later.

The referrer deletes their account. Coupons outlive users unless somebody decides otherwise. Worth deciding on purpose rather than discovering.

Why this is rarely a plugin

Referral plugins exist. They are usually built as a self contained world: their own dashboard, their own idea of a customer, their own reward currency, and their own set of rules about what counts.

The trouble starts where that world meets yours. The reward has to be spendable in your cart, which means it has to become a coupon your cart understands. The trigger has to be your definition of a paid order, which on a shop taking bank transfers or cash on delivery is not the same as somebody else’s. And the numbers have to reconcile with your reports, which they will not if the discount lives in a parallel system.

The version described here is a few hundred lines, and the reason it is small is that it does not implement any of those things. It writes coupons WooCommerce already understands, listens to events WooCommerce already fires, and stores two small tables of its own.

What this generalises to

Two sided rewards. The obvious extension: the referred customer also gets something on their first order. This usually doubles conversion and it is a configuration change rather than a rebuild, because the machinery for issuing a voucher to a person already exists.

Affiliates. The same attribution with commission instead of a voucher, paid on revenue instead of on a first order, with a payout process attached. Structurally the same, commercially a different animal, and the difference is mostly accounting.

Business to business introductions. Where the reward is a discount on a renewal or a credit on an account rather than money off a basket.

Anything with a waiting list. Position moved by invitations rather than money. The counting is identical.

Four questions before anybody estimates it

• What earns the reward, a signup or a purchase? This is the entire economics of the scheme in one answer.
• One sided or two sided? Rewarding both people converts better and costs more.
• How long is the attribution window? Twenty four hours from registration is tight and safe. Thirty days from click is generous and needs more defence.
• What happens on a refund? Answer this before launch, because the first person to find the gap will be deliberate about it.

A referral scheme is the cheapest acquisition channel a shop can own, and it is the one most likely to be built carelessly because it looks trivial. It is not trivial. It is just small, which is a different thing.

The numbers that tell you whether it works

A referral scheme produces a funnel with three steps, and each one fails for a different reason.

Customers who share. If this number is near zero, nothing downstream matters. The usual causes are that the scheme is invisible, that the reward is not worth the social cost of asking a friend for a favour, or that sharing takes more than one tap.

Clicks per sharer. Low numbers here mean the link was sent once, to one person, and forgotten. This is where the reward size and the wording do their work.

Purchases per click. If clicks are healthy and purchases are not, the problem is not the referral scheme at all. It is the page the link lands on, and no amount of referral tuning will fix it.

Separating those three is the reason the referrer is shown clicks, signups and purchases rather than only the rewards earned. It is also the reason the business can tell, within a week of launch, which of the three is broken.

Two small decisions that change the outcome

Where the link lands. A referral link that drops somebody on the home page asks them to find their way. One that lands on the product the referrer actually buys converts better, because the recommendation and the page agree with each other.

How the reward is described. Five euro off is a number. A free can delivered is a thing. Identical cost, different response, and the wording is a fifteen minute change rather than an engineering one.

Neither of those is visible in an architecture diagram, and both of them move the result more than any of the code described above.

The part that is genuinely hard

Not the mechanism. Getting people to use it.

A referral scheme buried in an account tab is found by the small number of customers who were already going to recommend you. The ones that work are the ones that appear at the moment somebody is pleased: on the order confirmation, in the dispatch email, on the page they land on after a second purchase.

That is a content and lifecycle problem rather than a technical one, and it is worth saying plainly because it is where most referral projects actually fail. The code is a week. The placement is the campaign, and the campaign is what determines whether the week was worth spending.

This shop is a working demonstration of what a headless WooCommerce build is capable of, and everything described here is running on it. If you are weighing a build of your own, it was made by Pavels Web Solutions.