#The Commission Line That Didn't Match the Growth
A creator posts your app to her story on a Tuesday night. By Wednesday morning the attribution dashboard shows a spike: installs up, commission owed up right along with it. Normal. Except the revenue line doesn't move.
Not "moved less than expected." Didn't move.
That's the moment every founder running an affiliate program eventually hits: the installs are real, on paper, and the commission is real, on your invoice, but the actual behavior (people opening the app, starting a trial, buying something) never showed up. You start wondering if you're paying for users you'd have gotten for free anyway, credited to someone else's link by pure coincidence of timing.
It's not coincidence. It's a race condition, and a piece of software on the phone won it before your creator's link ever got a chance to.
#Lesson 1: The Install That "Claims Credit" Before It's Even Finished
Here's the mechanism, in plain terms: click injection is a fraud technique where a malicious app already sitting on someone's phone watches for a new install starting, then fires off its own fake referral click in the split second before that install finishes.
The user never clicked anything from the fraudster. They found your app organically, through search, through a friend's recommendation, whatever. They tap "Install." And in that few-hundred-millisecond gap between tap and completion, the malicious app injects a click claiming "this install came from me," beating the real referral, or beating no referral at all, to the finish line.
The install completes normally. The user never notices anything. You just see an attributed install from a source that, functionally, contributed nothing. If that source is one of your paid creators, you now owe commission on a user you'd have gotten free.
This is a known, named pattern in affiliate fraud, not a theoretical one. It sits in the same family as cookie stuffing and forced redirects, all designed to steal credit that belongs to someone else, or to no one.
#Lesson 2: Real Clicks Have a Human Pause. Injected Ones Don't.
A real person doesn't tap a link and land in the store half a second later. They read the caption, maybe watch a few seconds of video, get distracted, then open the store. Legitimate installs typically land 30 seconds or more after the click: that's the human pause, the hesitation, the context-switching, the actually deciding to install.
Injected clicks don't have that pause because there's no human deciding anything. The fake click and the real install completion happen almost back-to-back, because a program is generating the click the instant it detects the install event, not a person reading a caption.
So: short gap between click and install, suspicious. Long gap, clean.
Here's the catch, though. This signal breaks on its own when a creator does well. A viral TikTok drop can produce a wave of installs where people tap through fast because everyone's watching the same clip at the same moment. Fast isn't automatically fake. It's necessary but not sufficient, which is exactly why you can't stop at timing.
#Lesson 3: Why We Bucket by IP and a Fixed 5-Minute Window, Not by Click Count
The naive fix is "same IP, multiple clicks, block it." That fix breaks the moment a real creator gets popular, because dozens of her followers can share one IP: a campus Wi-Fi network, a corporate office, a carrier-grade NAT gateway used by an entire cell tower's worth of phones.
What actually separates an attack from a crowd is the shape of the timing, not the raw count. Click injection has to fire its fake click inside the tiny window between tap and install completion. That's the whole exploit. It can't spread itself out over ten minutes, because the install it's racing against finishes in seconds.
So the filter we run groups raw clicks from the same IP into fixed, non-overlapping 5-minute buckets. Every click landing in the same window collapses into one canonical click, the one that actually gets credited and paid. Picture dozens of clicks landing on the same IP inside a tight three-minute burst: that's one canonical click, one commission. Now picture the same volume of clicks spread across ten minutes, the normal rhythm of a real audience clicking a link during a livestream, some right away, some after the replay. Those stay separate. Nothing gets collapsed, because nothing about that pattern matches the exploit.
Fixed, not rolling, matters here too: an attacker can't keep the window open indefinitely by drip-feeding one click every few seconds forever. Once a bucket closes, it closes.
#Lesson 4: A Suspicious Pattern Isn't Proof — Check the Money Too
A tight cluster of same-IP clicks tells you something looks off. It doesn't tell you whether it cost you anything. The only way to know that is to check whether real revenue actually landed inside your attribution window. For us, that means confirming the purchase through whichever validation path is active: the RevenueCat webhook path, or the Store-Direct path talking straight to Apple's or Google's servers. (You run exactly one of these at a time; running both means double-counting the same purchase, which is its own kind of overpayment. We wrote up the mechanics of that in handling Store-Direct commitment data.)
If the canonical click is suspicious and no purchase ever validates against it, you've got your answer with actual evidence, not a hunch. If it's suspicious but a real subscription shows up and sticks, you probably just have a fast, enthusiastic audience.
This two-step check is the difference between guessing and knowing. One documented case in the wider affiliate industry involved a partner using click injection to claim credit for traffic that was really organic search. The company's payouts had doubled against only a fraction of that in real revenue growth, until server-to-server verification caught it and recovered the loss.
#Lesson 5: The Creators Most Likely to Get Falsely Flagged Are Your Best Ones
This is the part that stings if you get the filter wrong: a naive fraud rule doesn't punish fraudsters evenly. It punishes success.
Your top creator's best day, the livestream that actually converts, the story that gets forwarded around a group chat, produces exactly the kind of click burst a lazy filter is built to catch. Lots of clicks, tight timing, shared networks. Statistically, at a glance, it can look identical to an attack.
The difference is timing shape, not volume. An attack has to squeeze into the tap-to-install gap; a real audience spreads across minutes because people watch, scroll, come back later, install from a different room on a different Wi-Fi network. A system that only counts clicks per IP can't tell these apart. A system that buckets by fixed time windows can.
Get this wrong and you don't lose a little trust with your best creator. You cap her earnings on the exact day she earned the most, and she notices. If you're running campaigns in regions or channels where click injection shows up more often, the better move is tightening that bucket window just for those segments rather than tightening it globally and putting your cleanest creators' best days at risk.
#What We'd Do Differently
Two things we'd tell a founder setting this up today, before the first fraud ticket ever lands.
Never trust IP alone. Shared networks are normal; the fixed time window, not the address, is what carries the fraud signal.
Always pair a suspicious click pattern with a revenue check before you call it fraud or refuse a payout. A click looking odd and a purchase never validating are two separate facts, and you need both to act.
InfluTo runs canonical-click deduplication (fixed 5-minute IP buckets) and purchase validation against RevenueCat or Store-Direct automatically, so you're not building this filter from scratch. Free to start, 10% platform fee on attributed revenue.