Six months in, we realised probabilistic matching was a red herring
A developer emailed us in March with a simple question: "Your SDK says it uses probabilistic matching. Does that mean my data isn't reliable?" It was the third message like that in two weeks. That's when we understood we'd spent the first half of Attribr's life talking about the wrong thing entirely.
The marketing trap we fell into
When we launched Attribr, the industry narrative was everywhere. Probabilistic matching was the future. Deterministic was dead. Apple's privacy changes meant fingerprinting was the only way forward for indie developers who couldn't afford enterprise SDKs. We believed it. So we built it, and then we led with it.
The first four months of our messaging was essentially: "We do probabilistic matching. It's clever. It works without ATT." We'd talk about the algorithm. We'd compare match rates to other solutions. We'd position it as the advanced option for developers locked out of deterministic data.
The problem was immediate and obvious once we saw it. Developers didn't care about probabilistic matching. They cared about knowing where their installs came from, and they cared whether users were still opening the app two weeks later. The mechanism was invisible to them. It should have been invisible to us too.
Why the match rate conversation missed the point
We spent energy comparing our probabilistic accuracy to other fingerprinting approaches. Are we 85% accurate or 90% accurate on install attribution? Does it matter if you're an indie studio with 3,000 monthly installs?
The honest answer is no. Not really. What matters is cohort reliability. If you're running a campaign and you need to know whether the users who installed from that campaign are still active at day 7 and day 30, the accuracy threshold is different. A probabilistic match on an install source that's then validated by retention data across 50 users is actually more useful than a single perfect match on 50 users with perfect ATT permission, which you won't get.
We stopped talking about match rates around month five. Instead we started asking: "Can you see which promoter from Rippl drove the CPI install, and is that user still active?" That's the three-line integration question. That's what indie developers actually need to answer.
The deterministic and probabilistic thing isn't a choice
This was the real unlock. We'd framed it like deterministic was the gold standard and probabilistic was the fallback for privacy reasons. Wrong framing.
What actually works is using both in parallel. Deterministic matches when the data is there, probabilistic when it isn't. No philosophy. Just pragmatism. You capture the signal you can get from ad networks, device IDs, and Rippl promoters. You fill the gaps with probabilistic signals. The user gets one answer per install: "This came from Source X and the user is still active at day 14."
The moment we stopped positioning these as competing approaches and started treating them as complementary layers, developer questions shifted. They stopped asking whether probabilistic was "real" attribution. They started asking whether the SDK was lightweight (it is, 50KB), whether it integrated in three lines (it does), and whether it connected to Rippl for CPI tracking (it does). Those are the actual product decisions we made. The matching method was just how we kept the overhead low.
What we should have led with
If we were writing the first announcement again, it would say something like this: "Attribr tells you three things with zero third-party dependencies. One, where each install came from. Two, whether those users are still active at day 7, 14, and 30. Three, which Rippl promoter drove the CPI install. It works on iOS 14.5 without ATT permission, it launches in under 50 milliseconds, and you integrate it in three lines of code."
Notice what's missing. No mention of probabilistic matching. No algorithm talk. Just outcomes. We spent the first six months of Attribr positioning a technical implementation detail, when we should have been positioning the problem it solved: indie developers need attribution that's lightweight, reliable, and doesn't require enterprise budgets or permissions they'll never get.
The probabilistic matching is real. It's clever. It does the heavy lifting in the background. But it's not the story. The story is that a studio of four people can now answer the questions that used to require Branch, AppsFlyer, or Adjust, and they can do it without bloat, without dependencies, and without paying £10,000 a month.
The lesson that actually stuck
Every feature you build needs a reason it matters to the person using it. Not why it's technically interesting. Why it matters to them, in their specific constraints.
For indie developers and small studios, those constraints are real. You're not going to get ATT permission from most of your users. You're not going to integrate three SDKs. You're not going to pay enterprise pricing. You need something lightweight that gives you signal. The probabilistic matching is how we deliver that. But the value isn't in the matching. The value is in the answer: "I know where my install came from and I know if the user is still here at day 14."
Once we understood that distinction, everything else on the product roadmap made sense. Retention cohorts. Funnel charts. The Rippl bridge. Fraud signals. These weren't features. They were answers to questions we should have asked from the beginning.
If you're building for developers, what problem are you actually solving? And are you talking about that, or are you talking about how you solved it?
Ready to try Attribr by MRVL?
One tap to download. No sign-up wall.