Three lines of code. That's all.

Last October, a developer emailed us. They'd spent four hours trying to integrate a major attribution SDK into their indie game. Four hours. By the end, they'd added 2MB to their binary and weren't even sure it was working. They asked if we had something simpler. We didn't, then. So we built it.

The problem wasn't the concept. It was the baggage.

Attribution is straightforward on paper: you launch an app, someone downloads it from an ad, you log that connection. Done. But the major platforms have built their SDKs like they're running on servers with unlimited resources. Dependencies. Network calls. State management. Bloat.

For an indie developer with a tight budget and a game that's maybe 15MB, adding AppsFlyer or Branch felt like choosing between proper analytics and app install performance. Most chose neither, which meant they had no idea where their users came from or whether those users stuck around past day seven.

We started with a constraint: what if we made something so small and so fast that it felt like adding nothing at all? The answer was 50KB. Zero third-party dependencies. Sub-50ms launch overhead. Not because we're smarter, but because we stopped trying to be everything.

Three lines because setup shouldn't be the hardest part of launch week

The integration itself is almost comically simple. Swift? Add three lines. Kotlin? Three lines. That's init, a user identifier (or null if you don't have one yet), and one method to call when a download happens. No delegate patterns. No configuration plists. No hunting through documentation to find which parameter enables which feature.

The reason it works is that we made hard choices about what goes into the SDK and what doesn't. We handle the two attribution methods that actually matter for indie scale: deterministic matching (you knew this user, you can prove it) and probabilistic matching (high-confidence educated guess based on device signals). We track retention at day 7, 14, and 30, because that's what indie developers ask us about most. We skip everything else.

A studio in Stockholm integrated Attribr in 22 minutes. They sent us a screenshot of the dashboard showing where their first 400 installs came from. No support ticket needed. No call with a solutions engineer. They just copied three lines, called the method, and had data.

It works on iOS 14.5 without asking for permission

This matters more than it sounds. After Apple's privacy changes, a lot of developers gave up on attribution entirely. They figured if they couldn't ask users for ATT permission, tracking installs wasn't possible. That's not quite true. It's messier, sure, but not impossible.

Attribr works via the combination of deterministic and probabilistic signals. Deterministic: if you run your own ad account or send users through an email link, you know exactly who they are. Probabilistic: we can match a new install to a user with high confidence using device characteristics that don't require permission and aren't personally identifiable. You get both. You don't have to pick.

This means a developer using Attribr gets useful data on day one of launch. They see which campaigns converted real users. They see retention curves by traffic source. That information helps them decide which ads to double down on before they've spent a lot of money.

The Rippl bridge: where indie attribution meets community-driven promoters

Here's where Attribr does something no other attribution SDK does. We built a direct connection to Rippl, the performance marketing platform built for creators and community figures who promote apps. If one of your promoters drives an install through Rippl, Attribr knows about it. You see which promoter brought which user. You see if that user stayed active.

A casual game developer might work with 20 or 30 promoters across TikTok, YouTube, and Discord. Traditionally, you'd ask each one 'how many installs did you get?' and hope their numbers matched yours. With the Rippl bridge, you don't ask. You know. You see it in the dashboard next to your other install sources. It's not a separate tool. It's part of the same picture.

For teams scaling from 10K to 100K installs a month, this matters. You stop flying blind on community partnerships.

What three lines can't do (and that's fine)

Attribr isn't trying to replace Adjust or AppsFlyer for enterprise teams running 10 million installs a month across global campaigns with complex MMP requirements. That's not the story we're telling. We're telling the story of the developer who has real constraints: a small budget, a need for good data, and an allergy to bloat.

If you need fraud-signal analysis or the ability to roll up custom ad networks, that's in our Pro tier. It exists because some studios ask for it. But the core three-line experience and retention tracking? Free at 1,000 installs a month. Growth plan at £29 for up to 25,000. That's the ceiling for most indie work.

The constraint wasn't an accident. It was the point.

Why simple is harder than complex

The email from that developer in October who spent four hours on setup has shaped almost everything we've built. Complexity is cheap. Adding features is easy. Making something that saves someone four hours without losing information, that's the actual work.

We ran the three-line integration past indie developers before we shipped it. We asked them what would make them actually use attribution instead of guessing. The answer, over and over, was: just make it dead simple and don't slow my app down. We did both.

Now when a developer emails to ask about integration, the answer is simple. Three lines. A method call. A dashboard with your data. No follow-up calls needed.

If you've built something and shipped it without knowing where your installs came from, would you change anything if you knew?

Want to try Attribr?

Visit Attribr →