The fraud signals we built because developers kept asking
Three months after launch, a developer who'd integrated Attribr sent us a message. Her CPI looked perfect on paper, then overnight her retention tanked. She'd been hit with a flood of fake installs from a single ad network, and she had no way to see it coming. That email changed how we built the Pro tier.
Why attribution without fraud visibility is half the picture
Install attribution is a solved problem now. You can track where a user came from with reasonable accuracy. The problem nobody talks about is the one that developer faced: knowing an install happened is useless if you don't know whether it's real.
We'd designed Attribr to answer three simple questions. Where did this install come from? Is the user still active at day 7, 14, 30? And, uniquely, was this a Rippl promoter conversion? Those were the foundations. But watching developers use it, we realized we'd missed the fourth question: is this install legitimate?
The indie and studio developers we built Attribr for don't have fraud analysts on staff. They don't have dedicated budget for detecting anomalies. They're writing code, shipping updates, watching retention metrics. When a network goes bad, they need to spot it quickly, not three months later when their cohort data looks like a crater.
So we added fraud signals to the Pro tier. Not as a separate tool. Not as something bolted onto the dashboard. But as part of the attribution flow itself, built from the install data we were already collecting.
What fraud signals actually tell you
Fraud signals aren't magic. They're patterns. When you're seeing 50 installs from a device with no unique identifier, or 200 installs from the same IP in 30 seconds, or users who install and never open the app, those are signals. Real ones.
Attribr's fraud signals flag suspicious installs in three ways. Device-level anomalies catch installs that look recycled or synthetic. Network-level clustering catches volume anomalies from a single source. And cohort velocity flags installs that never activate, which is the clearest sign something's wrong.
A developer using Pro tier sees these flags right in the dashboard. Install source, fraud status, retention status, all in one view. It means when a network starts pushing bad volume, you see it in the next refresh, not the next month.
The second part of Pro is the ad-network roll-up. You're probably running installs across three, four, maybe five networks. Branch. Google. Facebook. A smaller performance network you found last quarter. The nightmare is stitching those together. Each one reports differently, each one has latency, each one has its own definition of an install.
Attribr's roll-up unifies those networks into a single view. Same retention calculation, same fraud flags, same timestamps. You see which network actually delivered day-30 retained users, not which network reported the most installs.
A specific moment: the network that looked perfect until it didn't
The developer who sparked this feature had integrated five networks. Three big ones, two smaller ones she'd found through performance communities. For six weeks, everything looked solid. CPI was reasonable, retention looked decent, metrics were tracking her growth plan.
Then something shifted. Her retention cohorts started diverging by network. One network's day-7 retention was 45%. Another was 12%. But her aggregate install metrics looked fine.
Without fraud signals, she would've blamed herself. Bad creative? Wrong audience? She would've tweaked targeting, shuffled budgets, chased her tail. Instead, she enabled fraud signals on Attribr Pro. Within 24 hours, the dashboard showed her the truth: the network with 12% retention was pushing installs that never opened the app. Device-level anomalies were flagged on 60% of that network's installs.
She paused that network. Shifted the budget. Watched her overall cohort retention climb back up. And she sent us another message: this is what was missing.
That's when we knew we'd built something that mattered. Not something flashy. Something useful.
Why this matters for developers without enterprise budget
Enterprise attribution tools have fraud detection because enterprises have money and demand it. They also have the complexity to justify it. Adjust and AppsFlyer have 100-person teams. Their fraud module is one specialist's entire job.
For an indie developer or small studio, those tools are overkill. You don't need 50 dimensions of fraud analysis. You need to know if a network is garbage and whether your retention is real. That's what we built.
Attribr Pro is £99 a month. You get fraud signals, ad-network roll-up, cohort charts, funnel tracking, retention dashboards, and the Rippl bridge for performance-marketing community installs. It scales to 100,000 monthly installs per app. For a developer shipping 5,000 to 50,000 installs a month, that's enterprise visibility for a subscription cost, not an annual contract.
The other thing worth saying: this isn't a separate product. It's not fraud detection bolted onto attribution. The SDK is still 50KB. Still zero third-party dependencies. Still sub-50ms launch overhead. We didn't bloat the foundation to add fraud signals. We built them into the data pipeline from the start.
Bring your own network, or use ours
One more thing that matters. You might not use the networks we've pre-built. You might have a custom ad partner, or an in-house system, or a network we haven't integrated yet. So Pro tier includes bring-your-own network integration. You can wire up any source. Attribr will match the installs, run the same fraud signals, roll them into the same cohort view.
It means you're not locked into a specific set of networks. You're building your attribution on your terms, with the partners you choose, and the same visibility as developers using the built-in networks.
If you're running installs across multiple networks and you've never had a clear view of which ones actually delivered real, retained users, does that feel familiar or like someone else's problem?