Multi-account farming cost us $0.27
I checked the scale before picking a countermeasure. At $0.27 the answer was to do nothing, and to remove one existing defence that was causing more harm than it prevented.
Is someone creating multiple accounts just to harvest the free credits?
That question arrived as soon as users surged. Every signup gets free credits, and every AI analysis those credits buy costs real money, so it was a question I'd been expecting.
There was reason to suspect it. Clusters of similarly named accounts were visible, and Google accounts can be created without limit. Candidate countermeasures came quickly too: device attestation, store integrity checks, IP limits, identity verification.
I applied none of them. Instead I deleted one defence that was already there.
Check the size first
Before choosing a countermeasure there is a prior question. How much am I losing right now?
I wrote read-only query scripts and pulled weekly signups against usage distribution, duplicates after email normalisation, name clusters, referral status and per-account AI cost.
The numbers ended the discussion. Adding identity verification costs far more than $0.27. The drop in signup conversion exceeds that figure before you even convert it to money.
There was a control group
Still, one question remains: what if today's four become four hundred? Today's numbers can't answer that. It takes the trend.
Here I got lucky. This app had a natural control group.
There are several sign-in providers, and Kakao requires phone verification to register. Kakao accounts are hard to mass-produce. Google has no such limit. So if farming were actually happening, Google usage patterns should differ from Kakao's. A farmer's account burns its free credits and is abandoned, so the share of short-lived accounts should be higher on Google.
Three measures, compared.
| Measure | Kakao | |
|---|---|---|
| Share using 11–20 times | 34.3% | 40.9% |
| Used one day then left | 71.9% | 73.7% |
| Never used | 28.9% | 28.7% |
None of them separated. The gap in the first row is z=1.24, not significant, and it points the wrong way: farming would push Google higher, and Kakao is higher.
Mean usage per account does differ in the raw numbers — Kakao 14.6, Google 10.7, Apple 16.1. The distribution test found nothing significant.
The conclusion settled as: farming exists but hasn't grown to a measurable size, and if it starts growing the control group will show it first.
Why farming loses money
I also worked out why it doesn't grow. The referral reward carries a qualifying condition: the invited account must complete ten analyses before any reward is paid.
That condition inverts the arithmetic of farming.
Each sub-account grants fifteen free credits, but qualifying for the reward means spending ten analyses from it. The more accounts you add, the faster consumption outruns acquisition. In the observed data a three-account farmer burned 45 analyses to obtain 30 credits.
And I removed a defence
During the investigation I found that a defence already switched on was causing the problem instead.
To block self-referral, device fingerprints were being compared. That fingerprint was a hash of basic device details like user agent, language, core count, screen size and timezone. With no canvas or WebGL, its entropy is low.
Two unrelated people on the same phone model and OS produce the same hash.
Inviting a friend who uses the same phone — in a dormitory, at school, entirely legitimate — was judged self-referral and the reward was withheld.
The cost of a miss was near zero and the cost of a false positive landed directly on users.
The false-positive cost exceeded the false-negative cost. Self-referral was already blocked economically by the qualifying condition, so the check added almost nothing. Its false positives, meanwhile, were taking real rewards away from real users.
The check was removed. The remaining defences are the qualifying condition, an IP signal and a monthly cap. Fingerprint collection stayed, for measurement only.
The account with 253 analyses
One account surfaced in the name-cluster report as a suspected abuser. Its usage was an overwhelming 253 analyses, and it looked like textbook multi-account farming. It was my single best paying customer.
Had an automatic blocking rule been in place, I'd have cut off my best customer.
When to look again
One threshold is written down. If AI cost attributable to free users passes $100 a month, it gets revisited. It currently runs around $8.
That $100 line is poorly justified, though. It's a number picked as a tolerable ceiling on loss, with no analysis behind it. I can't explain it beyond "about ten times current cost". I wrote elsewhere that thresholds should be measured rather than chosen, and here I chose one.
The control group was an accident. That one provider requires phone verification isn't something I designed; it simply is the case, and it handed me a comparison for free. There is no guarantee the next decision of this kind will have one.
Putting fingerprints back into judgement is a long way off. It would need canvas or WebGL for entropy, and recent Safari injects noise for anti-fingerprinting so its values change every time and must be excluded from matching. That means a different rule per browser. That complexity isn't worth $0.27.
End