The Rippl bridge: why we built attribution into the promoter-to-install loop

The gap we kept hearing about

When we launched Attribr, we solved a real problem for indie developers: knowing where installs came from without paying £500 a month for an attribution SDK. But we kept hearing the same follow-up question from studios using Rippl, the community performance-marketing platform.

Rippl lets developers post CPI offers that community promoters can run. A promoter installs your app, drives real users, and gets paid. The system works. But there's a friction point. Rippl tells you an install happened. Your app's analytics tell you an install happened. But they don't talk to each other. A developer would have to manually cross-reference Rippl's promoter list with the installs in their dashboard, then guess which promoter drove which batch of users.

For someone running their first performance campaign on a budget, that's not just annoying. It's blind. You can't optimise if you don't know which promoter's audience is actually engaging with your game or utility.

The moment we decided to build it differently

We could have said no. Built Attribr as a standalone attribution tool and stopped there. Other SDKs do exactly that. They give you installs and retention data, and if you want to layer on a performance platform, that's your problem.

But that felt incomplete. Rippl's model is fundamentally different from traditional ad networks. It's about community trust and individual promoters, not algorithmic media buying. And that meant the attribution question had to change too.

So we built a direct bridge. When you use Attribr with Rippl, the SDK catches the install and matches it to the exact promoter who drove it. No manual work. No guessing. Three lines of code in Swift or Kotlin, and suddenly you know not just that you got an install, but which Rippl promoter sent it and whether that user is still active at day 7, day 14, day 30.

I won't claim this was obvious. It wasn't. It meant coordinating with the Rippl team, understanding their API, and building something that only made sense if you believed both platforms were worth using together. But once we started, it felt inevitable.

What changed for developers who use it

A studio in Berlin ran three Rippl campaigns last quarter. Their CPI was around £0.40 per install. After a fortnight, they had maybe 150 users from one promoter, 220 from another, and 80 from a third. Without the bridge, that data lived in two places and never spoke. With it, they could see day 7 retention by promoter. One of them was retaining 55% of users. Another was closer to 30%.

They increased budget to the first promoter. The second one they dropped. Simple decision, real ROI impact.

That's the point. Attribr's core job hasn't changed. It's still a 50KB SDK with zero dependencies that tells you where installs come from and whether users stick around. Deterministic matching when ATT permission exists; probabilistic when it doesn't. Works on iOS 14.5 and up without asking permission at all.

The Rippl bridge is just the logical extension of that. It means your attribution doesn't exist in a vacuum. It connects directly to the platform your community promoters are using, so the feedback loop is instant and clear.

Why this matters more than you might think

There's a philosophy embedded in this. We built Attribr because indie developers and small studios shouldn't have to choose between knowing their data and staying solvent. Most of you will never have a £50K annual ad budget. You won't qualify for enterprise pricing. You'll use Rippl or TikTok or word of mouth or a mix.

The Rippl bridge is part of that same thinking. If you're running CPI campaigns through a platform that matches your scale and budget, your attribution tool should work with it, not against it. Should feed into it. Should make the decision loop tighter and faster.

We ship this in the Free tier, the Growth tier (£29 a month for up to 25,000 installs), and above. No paywall. Because if you're serious enough to run campaigns, you deserve to understand the results.

What we learned building it

The technical side was interesting. Matching an install to a promoter in real time requires coordination without adding latency. Our SDK sits at 50KB for a reason. We didn't want to bulk it up for this feature. So we sent the integration work upstream, to Attribr's dashboard and the Rippl webhook, not the SDK itself.

That meant the SDK stays lightweight. The intelligence lives in our backend. When a Rippl campaign fires, a signal reaches us. When the app opens and the install fires, we cross-reference. By the time the user sees your dashboard, you know which promoter brought them in.

Sub 50ms launch overhead. Still. The bridge doesn't break that promise.

The question we're still asking

We've had Attribr in the wild for a while now. We've seen it used for everything from puzzle games to productivity apps to games that probably shouldn't exist but do anyway. We've watched small teams make smarter decisions about where to invest marketing budget next.

What we haven't done is stop. The Rippl bridge felt right because it solved a real gap. But there are other platforms, other questions, other friction points between your installs and your decisions.

If you're using Attribr right now, what else would you want to see connected? Not features for the sake of it. Things that would actually change how you run your campaigns.