The Unit Economics of Freemium Abuse: Costing Each Farmed Account

“Free tier abuse is bad” is easy to agree on. It doesn’t help you decide whether to block the third account on a device, ask for a phone number or do nothing. That decision needs two numbers: what an abusive account costs you, and what stopping it costs you. Most teams have neither, so they argue from anecdotes.

This article sets out a worksheet for both sides. It doesn’t quote industry averages, because yours are the only figures that matter and you already have the data in your invoices, logs and billing system.

Side one: the cost of a farmed account

Split the cost into what the free plan hands out directly and what abuse does to the rest of the business.

Direct costs

These scale with every account an abuser opens:

Line item	Where to find it	Formula
Compute and GPU	Cloud bill by service	free-tier usage per account × unit cost
LLM / model tokens	Provider invoice	avg tokens per free account × blended price per token
Storage and bandwidth	Cloud bill	GB per account × monthly cost × months retained
Messages sent	Email/SMS provider	messages per account × price per message
Third-party API calls	Vendor invoices	calls per account × price per call

The trap is using your average free user. Abusers don’t behave like the average user. They max out the allowance, because collecting it is the whole point. Pull usage for accounts you already suspect, such as clusters sharing a device or payment method (see finding multi-accounters in SQL), and cost those instead. For AI products the gap is usually widest on tokens, which is why AI credit abuse gets its own treatment.

Indirect costs

These are harder to price and tend to be ignored for that reason:

• Support time. Farmed accounts open tickets, request extensions and file chargebacks on the occasional paid step. Use minutes per ticket × loaded hourly cost.
• Email reputation. Throwaway and disposable inboxes bounce, and abandoned accounts never open mail. Bounce and complaint rates feed into how mailbox providers treat your real onboarding emails. Price this as a risk rather than a line item: what does a week of onboarding mail in spam folders cost?
• Metric pollution. Activation rate, free-to-paid conversion and cohort retention all use signups as the denominator. Farmed accounts inflate it, so dashboards show a worse funnel than real users experience. That leads to wrong product decisions, which can cost more than the compute.
• Downstream fraud. Some farmed accounts are staged for something worse: referral payouts, resale of API quota, spam sent through your product. If you’ve seen this happen, add the realized losses.

Putting it together

cost_per_farmed_account =
    direct_usage_cost          # at abuser-level usage, not average
  + support_minutes × hourly_rate / 60
  + downstream_losses / farmed_accounts_in_period

Leave email reputation and metric pollution as qualitative notes next to the number. You’ll still want them in the room when you decide.

Side two: the cost of stopping it

Every control has a price, and you pay it in legitimate users.

False positives

A device limit catches some honest people: a family sharing one laptop, a teacher signing up students in a computer lab, a consultant creating accounts for clients. The cost is:

cost_of_false_positives =
    honest_signups_caught
  × free_to_paid_rate
  × expected_customer_value

You can’t measure honest_signups_caught until the rule runs, which is why you run it in flag mode first. Flag everything the rule would have blocked, change nothing for the user, and come back in a few weeks. Count how many flagged accounts converted to paid, how many look clearly farmed, and how many you can’t tell.

Friction

Softer responses like phone verification or a card on file cost some honest drop-off too. That’s measurable directly: compare completion rates for users who saw the step against those who didn’t, over the same period. Abusers drop off far more steeply than honest users. Repeating the step for each farmed account is exactly what makes farming stop paying.

Running cost

Count the cost of the detection itself: the identification volume on your plan and the engineering and review time. With flat plans this is predictable. Prynt’s pricing is per month by identification volume, so the line item stays fixed when abuse spikes.

Turning the two sides into a limit

With both numbers, the decision becomes arithmetic. For each candidate rule, such as “block at 2 other accounts on the device” or “verify at 1”:

net_value = (abusive_accounts_stopped × cost_per_farmed_account)
          − cost_of_false_positives
          − friction_cost

An illustrative example, using made-up round numbers: say a farmed account burns 4 units of model cost, honest users caught by the rule would convert at your normal rate, and the flag-mode review shows the rule catches nine abusive accounts for every honest one. Each honest user caught then “costs” the nine abusive accounts stopped alongside them, 36 units of savings. If an honest user’s expected value (free-to-paid rate × customer value) is below 36 units, a hard block pays for itself. If it’s higher, verify is the better action. The abuser still pays per account, and the honest user still gets in.

Two patterns usually come out of this exercise:

1. Expensive free tiers justify strict limits. When each account consumes GPU time or tokens, even a modest abuse rate outweighs the occasional honest user who has to contact support.
2. Cheap free tiers should rarely block. If a free account costs almost nothing to serve, the main damage is metric pollution. Flagging and excluding those accounts from analytics may be enough.

Where the inputs come from

The device side of the worksheet needs one fact per signup: how many of your accounts already exist on this device. Prynt returns that as accountsOnDevice on the server-side event, along with a decision and riskScore. With the Node SDK:

const event = await prynt.getEvent(requestId);
const otherAccounts = event.accountsOnDevice.count;   // your linkedIds on this device
const abuseLikely = otherAccounts >= 2 || event.decision === 'block';

Log that alongside the user record from day one, even before you enforce anything. That log is the dataset the flag-mode review runs on. How to tune fraud thresholds covers turning it into a precision and recall view per rule. Protecting free plans from abuse covers the menu of responses beyond block.

Review it quarterly

The inputs change. Model prices move, the free tier gains features, abusers adapt. Re-run the worksheet when any input moves materially, and at least once a quarter. A limit that was right when free accounts were cheap can be wrong once they’re expensive, and the reverse holds too.

Start by costing a single farmed account with your own invoices. Then run your strictest candidate rule in flag mode for a few weeks. The difference between those two numbers tells you what to enforce.