Three lines of code. That was the brief.

The friction nobody talks about

Most indie developers don't ship attribution. Not because they don't care where installs come from - they do, desperately - but because the friction of getting it in place feels disproportionate to the gain. You've got a working app. You're trying to grow it. The last thing you want to do is spend an afternoon wrestling with an SDK that demands seventeen different delegate callbacks and half your app's dependency budget just to answer a simple question: where did this install actually come from?

When we started building Attribr, that was our starting point. Not 'how do we build the most comprehensive attribution product,' but 'how do we make this so frictionless that an indie developer with an afternoon free can have real attribution data by dinner time.'

Smaller doesn't mean less capable

The 50KB constraint was genuinely difficult to hit. Every feature we wanted to add meant trading something else away. Do we support more ad networks in the SDK itself, or do we keep the binary lean and let developers integrate only what they need? Do we bake in complex statistical models, or do we move that logic to the dashboard and keep the on-device piece simple?

We chose simplicity. The SDK does one thing well: it captures enough data on device to answer your three core questions. Where did this user come from? Are they still here at day 7, 14, and 30? And if they came through Rippl, which promoter drove them? Everything else - fraud signals, ad-network roll-ups, funnel analysis - lives on the server side. That separation meant we could keep the on-device footprint tiny (zero third-party dependencies, sub-50ms launch overhead) while still shipping Pro features for developers who need them.

Integration as a design problem

Three lines of Swift. Three lines of Kotlin. That wasn't a marketing number we reverse-engineered from the feature set. It was what we built toward. Every engineering decision flowed from that constraint.

Most SDKs ask for too much: configuration objects, delegate callbacks, initialization parameters scattered across your AppDelegate and your SceneDelegate. We stripped all of that. You initialise Attribr once with your API key. You track a single event when the install completes. Everything else - network calls, retry logic, device fingerprinting, retention cohort bucketing - happens silently in the background.

The three-line thing matters because it removes the thing that kills adoption: friction. A developer can integrate Attribr in the time it takes to make a cup of tea. No documentation rabbit hole. No debugging cryptic error messages. Just instantaneous data flowing into your dashboard.

Working without the permission slip

iOS 14.5 changed everything for smaller developers. Suddenly, most users wouldn't grant ATT permission. The big players adapted by throwing more compute at the problem - larger fingerprinting models, more sophisticated probabilistic matching. We did the opposite. We built a lightweight system that works well without it.

Attribr uses both deterministic matching (when the data is there) and probabilistic matching (when it isn't), but we keep the probabilistic component lean and honest. You get reliable attribution on the majority of installs, and you get transparency about confidence levels in your cohort data. No false certainty.

That's why Attribr works on iOS without ATT permission. Not because we cracked some magical algorithm, but because we designed for the constraint from the start.

The Rippl bridge changes the equation

There's one feature we built that nobody else has: a direct line from Attribr to Rippl, our performance-marketing platform. When a developer runs a community-driven CPI campaign on Rippl, they can see which promoter drove each install, how long those users stick around, and whether they're profitable. That feedback loop is tight enough to iterate on in real time.

It sounds like a niche feature. It's not. Rippl has become the discovery network for thousands of indie developers. A lot of them were already using Attribr for basic attribution. We just connected the dots so they could close the loop: promotion to install to retention to profitability, all in one view. That kind of integration is why three-line setup matters - it makes the whole ecosystem faster.

Building for the person with 50K monthly installs

We're not trying to be Adjust or AppsFlyer. We're not built for enterprise scale. We're built for the indie developer who has an app with real momentum - maybe 50,000 installs a month - and needs to understand where those installs come from and whether they're any good. At that scale, you need attribution. You don't need a compliance department. You need data you can act on quickly.

The Free tier supports up to 1,000 installs per month. Growth (£29/mo) gets you 25,000. Pro (£99/mo) adds fraud signals and ad-network roll-ups for developers hitting 100,000 installs. If you're bigger than that, you probably want to talk to us about a custom plan. But most of the people we're here for fall squarely into that Growth and Pro range: real apps, real growth, real business.