The case for install-source attribution

Most indie developers have no idea where their users actually come from

There's a quiet assumption in indie app development that if you're not spending tens of thousands a month on user acquisition, attribution doesn't matter. You get installs. Your app runs. That's enough.

It isn't. And I'm saying that as someone who built apps under exactly those constraints.

The truth is bleaker: without knowing where an install came from, you're flying blind on the decisions that cost real money. You're running ads across five networks and assuming the cheaper one is doing better because the CPC is lower. You're turning off a campaign because it "feels" less effective, when really your retention is better and the numbers just weren't visible. You're renewing contracts because you've always renewed them, not because you know they work.

Most of the indie developers I talk to are not dismissing attribution out of arrogance. They're dismissing it because every attribution tool they've heard of costs £200 a month minimum, requires an army of documentation to integrate, and wants their entire analytics pipeline handed over in exchange. That math doesn't work when you're doing 2,000 installs a month.

So they skip it. Then they wonder why their unit economics feel soft.

The enterprise tools were never built for your actual scale

Branch, AppsFlyer, Adjust. Each one is brilliant at what they do. If you're a publishing partner or a mid-market studio, they're probably the right choice. They solve the hard problems at scale: complex multi-touch attribution, LTV curves across thousands of campaigns, fraud detection across billions of events.

But that feature set is overkill if you're running three ad networks and need to know which one's retention cohorts are actually strong. You're paying for capabilities you will never use. You're integrating against APIs designed for teams with a dedicated product analytics hire. The onboarding friction alone often kills the decision before you even start.

There's also a philosophical problem. Those tools were built when iOS had a different privacy model. They lean hard on probabilistic matching because deterministic matching wasn't always possible. That made sense at the time. But now, on iOS 14.5 and above, deterministic matching is entirely feasible without asking the user for ATT permission. You don't need fingerprinting if you can get real data.

The indie developer problem isn't a scaled-down version of the enterprise problem. It's a different problem entirely. You need to answer three specific questions: where did this install come from, is that user still active at day 7, and which promoter or network drove it. You need it in three minutes, not three weeks. You need it to cost less than the installs themselves.

Knowing your retention cohorts changes how you allocate spend

Here's what happened after that developer I mentioned earlier got visibility into their sources. They started running weekly cohort reports. They noticed that their organic users had a 35% day 7 retention rate. Their paid users from Network A had 28%. Network B had 22%.

On paper, Network B was cheaper per install. So they'd been scaling it. But the retention delta meant that Network A users were worth roughly 60% more in LTV terms, even at a higher CPC. They rebalanced their spend the next week. Eight weeks later, their blended CPI was higher but their seven-day cohort retention had climbed to 31% across all channels. They were acquiring fewer users, but better ones.

That's not magic. It's just visibility. And visibility only matters if it arrives while you can still act on it. If attribution data takes three weeks to populate, you've already spent the money.

Attribr runs the matching in real-time. Deterministic matching (URL parameters, fingerprints) fires on launch. The cohort reports refresh hourly. Your dashboard shows you which networks are driving which retention curves right now, not last month. That speed matters more than any statistical improvement.

It also matters because indie developers often run very small campaigns. A 1,000-install test might be your entire quarterly budget for one network. You need to know in days whether it worked. You don't have the volume to wait for statistical significance to emerge from a SaaS dashboard.

The weird case of CPI promoters and community-driven installs

One of the stranger conversations I've had with indie developers is about Rippl. They're a community-driven CPI platform. You pay per install, same as any network. Except the installs come from real users in a Slack community, not algorithmic spend.

The advantage is that the install quality is often higher. The disadvantage is that Rippl promoters are individuals, not campaigns. You get a message: "user bought your app for £1.20." You don't automatically know which of your hundred ads they clicked, or from where they came.

So someone asked us: can Attribr connect Rippl promoters directly to individual installs? Can we show you not just that someone bought your app, but which Rippl user drove it?

We built that bridge. It's the only attribution SDK with a direct connection to Rippl's promoter list. It meant diving into Rippl's API, handling deferred deep links properly, and making sure the latency was tight enough that the matching worked in real-time. But now if you're using Rippl for CPI, you can see which promoters are driving the best retention, which ones are delivering fraud, and whether Rippl overall is outperforming your paid networks.

It's a small feature. It only matters if you're using both Attribr and Rippl. But that's exactly the point. Attribution tools should fit your actual workflow, not force you to reshape it.

The engineering decision that made this possible

Most attribution SDKs are opinionated. They want to own your analytics pipeline, your event schema, your data layer. That's necessary when you're building a full-stack platform. But it also means integration takes weeks and you're locked into a specific approach.

We chose the opposite constraint. Attribr is 50KB with zero third-party dependencies. It launches in under 50ms. It integrates in three lines of Swift or Kotlin. You can drop it into an app you shipped three months ago without rebuilding anything.

That tiny footprint and fast launch weren't accidents. They were deliberate tradeoffs. We don't ship a full analytics SDK. We don't run your crash reporting or your session tracking. We answer the attribution question and we answer it fast. You wire the answers into whatever analytics you're already using, or into your own logs.

That approach also meant we could make some unconventional choices about privacy. Most attribution tools fingerprint because they need to be network-agnostic and scale to billions of events. We use fingerprinting as a fallback. Deterministic matching is our primary path, and it's accurate enough for indie use cases that we can often skip the fingerprint entirely and still land the right install source.

The other thing: no third-party dependencies means no surprises. No waiting for a dependency to update. No subtle bugs hiding inside someone else's code. You integrate Attribr and you own exactly what's running in your app.

The question you should ask yourself about your current setup

If you're running ads right now, you're spending money on something. Probably multiple things. You have a budget for Google, Facebook, TikTok, maybe a smaller network or two. Each one tells you how many installs they delivered and what it cost.

What they don't tell you is whether those installs were any good. Whether the users they sent are still opening your app on day 7. Whether they're better or worse than organic users. Whether one network is worth scaling and another isn't.

Most indie developers make that guess by gut feel. Some by spreadsheets. Very few by actual data, because the friction of adding real attribution has been too high.

The case for attribution isn't mysterious. It's just economics. You're optimizing for the wrong metric if you're only looking at cost per install. You should be optimizing for cost per acquired user who comes back. The tools to measure that have been enterprise-only for too long.