This is an unfinished draft, a work in progress. If you'd like to provide feedback please email [email protected]

Operations

Metrics To Monitor

A successful refer-a-friend scheme acquires a large number of high quality users. To do this, you need to monitor the quantity of users acquired, their quality, and the virality of referral scheme.

I’d like to emphasise that monitoring the quality of users acquired via RAF is absolutely key, especially if you are giving away cash or cash equivalents. You should monitor their performance daily, particularly if you see a sudden increase in volume of users. It is of great importance you monitor the spread of the channel by geography or nationality. See more on this on the fraud section.

I have found the following (non-exhaustive) list of metrics useful:

Running A RAF Scheme

Do not underestimate the complexity of a simple change to the referral programme. Say you want to change the payout amoutn for You need to change:

Perhaps this seems obvious, but it happens surprisingly often that one or more of these are out of whack with each other. This inevitably leads to user complaints and customer support tickets. Part of the reason for this is that generally different teams tend to own these functions, and they tend to run with different providers. For this reason, a high quality referral campaigns will require collaboration across various teams in a tech company. You will need to work with: - the product & engineering team (to change referral logic, screens and features) - the marketing & CRM team (to notify your customers about the programme and referral campaigns) - the legal team (to draft the terms & conditions of the programme) - the customer support team (to update FAQs and deal with the inevitable inquiries and complaints around the programme) - finance or backoffice support team to deal with payouts - the fraud team to deal with potential issues (more on this later)

If you are building out a scheme, or even modifying an existing scheme, it is highly recommended you notify all these teams.

Due to the potential virality of referral schemes and the large amount of users for whom this is the first interaction with your product, it is important to minimise the number of users who are dissapointed by the scheme. Otherwise, you’ll be flooded by people complaining in customer support tickets. It is surprising how often people get upset about free money.

From this it follows that its important to keep in mind while building out the referral scheme ensure it is “easy” to change things. Ideally, you want to be in a position where means all of the items above can easily changed at the flick of a button.

CASE STUDY: PUBLIC

It would be unworthy of me to pick on a company with a terrible RAF scheme, so instead I picked a good one that is nonetheless facing some of the most common issues. Public runs a tightly managed refer a friend promotion with simple qualification criteria, and a limited time offer. Nevertheless, I experienced the following isues as a referrer:

CASE STUDY: ZILCH

One of the problems we faced at Zilch was that our referral programmes paid out based on when the user created the account.

Lets say I invite a friend when the referrals campaign pays out $5 per user and they create an account, but do not qualify for the referral bonus. A month later, the referral amount increases to $10 dollars for a limited time, and Zilch emails their customers about it. I call my friend and ask him to finish the process, and he ends up qualifying. But we both get $5 instead of the $10 we were expecting, because he created his account under the previous campaign!

This also lead to financial reporting issues, because inevitably we’d have users being paid a wide range of referral bonuses in a given month as they qualify, but the financial models had stricter assumptoins.

Generally, we would increase the payout if people complained via customer support but a more long term solution would be to make referral offers time limited.

International Refer-A-Friend Programmes

Cross-border referrals, i.e. where a customer in one country refers a customer in another country, can get very complicated.

First, there might be a different payout amount. Digital products tend to cost more in the United States than say in India. For this reason, often RAF schemes have different payouts for referrals in India than in the United States. So then, if a user in India refers a user in the United States, should this user receive the Swiss reward or the American reward?

Second, although the user usually sees a single product, the legal entities underlying the product may be different from country to country as they sit under a different regulatory regime. Incentivised referrals may be legal under one jurisdiction for a financial product, but illegal in another. Perhaps your user referred a customer in a state where he cannot legally be paid for a referral. They’ll blame you unless you explain it to them.

My advice is generally to try to keep the programme as simple as possible and avoid using “country of residence” distinctions when setting qualification criteria or reward. If it is unavoidable, simplify the situation by allowing customers to only refer people in their own countries, as this should cover most cases anyway.

Going Viral

It’s just like bacteria in a Petri dish. So what you want to do is try to have one customer generate like two customers. OK? Or something like that. Maybe three customers, ideally. And then you want that to happen really fast.

Elon Musk SpaceX, Tesla, Paypal (2014)

Virality coefficient: Number of users referred by the average user * conversion rate. Navgreferrals * PReferral

If it is greater than 1, then you have an exponentially increasing virality coefficient and will go viral.

The more you incentivise and push users to Refer A Friend, the worse the quality of the acquired user.

Assuming you want to at least make your money back, the equation generally boils down toThis might not always be the case. The initial cohorts of the viral PayPal RAF acquisition likely never paid back, but the resulting network effects were valuable in themselves:

Expected_LTV >= Reward Paid Out

Reward Paid Out = P(Meeting Qualification Criteria) * Expected

= P(Meeting Qualification Criteria) * Expected_LTV_Given_Meets Conversion Crtiteria

P(Conversion|QualificationCriteria) * E(Value|Conversion) = Reward <  = expectedLTV

probs remove the below The reward of an incentivised RAF scheme can vary across companies and industries. It can be extra product features, a discount or even a cash bonus. Generally, you wish to balance the reward you pay with the value of the users you attract, so that you end up paying less than what the user you are acquiring is worth. Similarly, the qualification criteria can also vary: it can be as little as registering to your product (e.g. signing up to an email list or downloading your app), but it might also be as onerous as making several large transactions. Importantly, the qualification criteria and the reward are two sides of the same coin. The more onerous your qualification criteria is, the more you can afford to pay out as a reward.

Fraud & Abuse

Generally, Refer a Friend is inevitably going to lead to a lot of conversations around fraud and abuse within the company.

Many people have some memory about them personally (or someone they know) abusing a refer-a-friend scheme and feeling very clever about it. Second, the process around incentivised referrals usually involves teams that are not usually involved in marketing operations, such as finance, fraud, customer support or operations teams. It is very difficult for finance team analysts or customer support specialists to spot millions of dollars wasted in ineffective Google Search ad spend, but they will easily notice that sometimes you pay out 50 USD for a user that ends up not coming back ever again. For many people, that money feels more “wasted” to them.

For this reason, it is important to establish everyone across the business from the outset that I have stolen this phrase from an excellent essay by Patio11:

The optimal amount of fraud and abuse on a refer a friend scheme is not 0

Some degree of abuse & fraud is fine, it is part of your CAC and you can bake it into your LTV calculations too. Point out that there will be wasted money on all marketing acquisition channels. As long the numbers make sense overall, it is fine.

That being said, every now and then you’ll end up looking at a chart like this:

Chart image

This should scare you. If this happens you rapidly need to figure out which of 3 things has happened:

You need to figure which of these it is, and quickly, because exponential growth will put your tech infrastructure under severe load, it’ll swamp your customer support teams and generally all things will break. You need to figure out if its worth it.

As a sidenote, generally it is good practice to have an anti-fraud / anti-abuse mechanism online that can be finetuned at a moments notice, whereby you can slow down the pace of the referrals without the need for a release or to diverte valuable tech resource. Any friction you introduce (e.g. a 24 hour payout review period) will slow down the momentum down significantly.

Fraudsters are more likely than your users to read the T&Cs, and to think of ways to get around them. Don’t try to bake in every single possible exception to the rules into the T&Cs, just reserve the right to not pay out for inorganic behaviour.

Can usually be mitigated through simple anti-fraud methods involving monitoring the reuse of identities, addresses, payment methods, devices etc. Your anti-fraud method does not have to be perfect, it just has to be better than that of the latest FinTech that raised a lot VC of money. Much like how a gazelle in a hunted gazelle pack doesn’t need to outrun a lion, but just outrun the slowest gazelle. For every little piece of friction you introduce to fraudsters, the less exploiting you is worth it to them, and the more it is worth exploiting your less capable competitors.