The case for small: why Attribr's SDK weighs less than a screenshot
Last November, a developer messaged us on Twitter. She'd integrated a popular attribution SDK into her iOS app and watched her launch time tick up by 200 milliseconds. Two hundred. For a game that needed to feel instant. That email landed in my inbox at 6 AM, and I remember thinking: attribution shouldn't cost you your first impression.
What we inherited, and what we threw away
Before Attribr, I'd spent years watching indie developers choose between two bad options. Either they'd go without attribution at all, operating blind on where their installs came from. Or they'd integrate one of the enterprise SDKs, trade away 1.5 to 2 MB of their app bundle, accept hidden dependencies they didn't control, and watch launch times crawl. The middle ground didn't exist.
When we started designing Attribr, we made a deliberate choice: stop inheriting the infrastructure decisions that made sense at scale but strangled smaller apps. Enterprise attribution services are built to handle millions of installs across dozens of ad networks and custom measurement partners. They pack in fraud detection, cross-device tracking, multi-touch attribution, and integration points for the entire ad ecosystem. It's comprehensive. It's also heavy.
We asked ourselves what an indie studio actually needs. Not what they might need someday, or what a Fortune 500 would demand. What does a developer with 10,000 active players, three ad networks, and a weekly build cycle actually solve for? The answer was cleaner than the existing options: tell me where this install came from, tell me if that player came back day 7, and ideally, tell me which community promoter drove it if they used Rippl.
50 kilobytes is a choice, not an accident
The size matters because the size matters. A 50 KB addition to your app bundle isn't abstract. On a device with limited storage, on a network that measures bandwidth like currency, that 50 kilobytes stays reasonable. Your users don't notice it. Your build process doesn't groan.
Getting there required saying no to everything that wasn't essential. We stripped out the third-party SDKs that other solutions relied on as glue. We didn't build layers of redundancy. We didn't add a telemetry stream running parallel to your own analytics. Zero third-party dependencies means you control the dependency tree. If there's a security issue, it's yours to patch directly. No waiting. No surprise updates that came bundled with something you didn't ask for.
The sub-50 millisecond launch overhead was the harder fight. Every millisecond spent initializing attribution when your app boots is a millisecond the user isn't seeing your content. We profiled everything. We moved initialization off the critical path. We made the SDK asynchronous by default so your app launches, users see something, and then we do our work in the background. A developer at a studio in Berlin told us that overhead was why she'd hesitated to add attribution at all. After integration, she said the launch time barely budged. That's not a coincidence.
Deterministic and probabilistic without the catch
Post iOS 14.5, tracking consent became the rule, not the exception. A lot of attribution solutions responded by going purely probabilistic: statistical best guesses based on device fingerprints and network signals. It's better than nothing. It's also noisier than it needs to be.
Attribr uses both deterministic and probabilistic matching, but the logic is inverted. We start with what we can know for certain. If the user clicked a link in an ad network that reported the install back to us, that's deterministic. That's fact. From there, we fill the gaps probabilistically for the installs we didn't see a click for. In practice, that means your retention cohorts are built on firmer ground. When you're running at indie scale, noise matters more. Ten thousand monthly installs, and a 10 percent error rate means you're making decisions based on inaccurate data.
And it works without ATT permission. If a user hasn't opted in to tracking, we still answer your core questions. We know where the install came from. We know if they're still active at day 30. You don't need them to grant a permission prompt that half your users will decline.
The Rippl bridge: attribution that feeds growth
Here's where Attribr diverges most clearly from the enterprise model. We built a direct connection to Rippl, the performance-marketing platform for independent developers. It's not a feature we bolted on. It's the reason we thought about this problem differently in the first place.
Rippl lets developers run paid campaigns through their community. Real marketers who promote indie apps earn a cut. It's collaborative. It's bottom-up. And when a user installs your app through a Rippl promoter, Attribr connects that install directly back to the person who drove it. You see not just that a Rippl install happened, but which promoter's audience converted at what CPI. Over time, you optimize spend toward the partners actually moving the needle for your game or app.
No other attribution SDK does this. It's not useful at 100 million installs a month. But at 5,000 or 25,000 monthly? It's the difference between blindly hoping a marketing channel works and seeing exactly which partners deliver real, engaged players.
A dashboard that doesn't need a manual
We kept the analytics surface simple. Cohort breakdowns by install source. Retention curves for day 7, 14, and 30. Funnels if you're running the Pro plan. No custom dimensions that require three days of setup. No event schema that demands a PhD in data modeling. Your app launches, players engage, and within hours you're seeing which ad networks or Rippl promoters delivered users who stuck around.
A studio in Stockholm spent forty minutes integrating Attribr. They told me they spent two hours the previous month trying to understand the dashboard of their old solution. Dashboard complexity isn't innocent. It's a cost. We minimized it.
The money question
Enterprise attribution costs money because enterprise infrastructure costs money. Adjust and AppsFlyer didn't build systems designed for efficiency because efficiency is easier. They built them because they need to recoup development costs across thousands of customers. That's honest. It's just not your constraint.
The Free plan covers 1,000 monthly installs. Growth starts at £29 a month for 25,000. Pro is £99 for 100,000, including fraud signals and the ability to bring your own ad-network partner. Above that, reach out for Business or Agency pricing. We're not hiding SKUs behind a sales team because we don't need to. You know what you're paying for. You can test before you upgrade.
It's priced for someone who runs an indie studio or a small team. Not for someone shopping for the enterprise tier.
The question I keep asking myself is why attribution SDKs ever got so heavy in the first place. The answer, I think, is that they were built for a different world. A world where app size didn't matter, where launch time was a rounding error, where everyone had a budget for enterprise tools. That world is real. But it's not the whole story. Does your app really need 2 MB of attribution infrastructure, or did you inherit that assumption from someone else's requirements?