The story behind Attribr's dashboard: cohorts, funnels, and the metric that actually matters
Three months before we shipped Attribr's first dashboard, a developer emailed us: 'I have 50,000 installs this month. Why do I feel like I'm failing?' That single message changed how we thought about what data matters.
The install vanity trap
When we first built Attribr's core SDK, we solved the attribution problem cleanly: show developers where each install came from, deterministic or probabilistic, in 50KB and three lines of code. We launched the dashboard as almost an afterthought. Raw install numbers by source. A table. Done.
Then the emails started coming in. Not feature requests. Confusion. One studio in Berlin told us they'd spent £8,000 on paid user acquisition in a week and watched their day-7 retention drop from 23% to 9%. They had no way to see it without manually cross-referencing spreadsheets and Google Analytics. Another developer, working alone, said they couldn't tell if their Rippl promoter network was bringing in quality users or just volume.
The problem wasn't attribution. The problem was that knowing where users came from meant nothing if you couldn't see whether they stuck around.
Building retention into the core view
We spent a week sketching. Not what enterprise teams need, but what an indie developer working at 11pm on a Thursday actually looks at. Not a data warehouse. A dashboard they can glance at in 90 seconds and know whether the week went well.
That's when we settled on cohorts. Not as an afterthought, but as the primary lens. Instead of 'here are your installs by source,' we made it 'here are your users grouped by install date and source, and here's what percentage of each cohort came back on day 7, 14, and 30.' Suddenly the story became visible. You could see that iOS users from TikTok ads had a retention cliff on day 3, but your organic users from Reddit stayed stable. You could run an experiment on day 1 onboarding and watch the retention curve shift within two weeks.
We paired that with a funnel chart, because attribution only matters if you know where users drop. An install from a great source who never opens the app past the loading screen isn't a win. So we connected the dashboard directly to any custom events you log through the SDK. Track a 'tutorial completed' event, a 'purchase' event, a 'subscription started' event. The funnel chart shows you how many installs from each source actually made it through.
The retention chart nobody asked for
Here's the part that surprised us. We built the retention chart as a way to collapse 30 days of data into a single line graph. Instead of rows and rows of daily cohort numbers, you could see your actual retention curve and compare it across sources.
A developer using Attribr Pro emailed after two weeks: 'This is the first time I've ever actually known my retention.' Not in some abstract dashboarding sense. He'd spent two years building his game. He'd never had the tooling to see whether his monetisation tweaks or onboarding changes actually moved the needle. The retention chart made it visible. He changed his day-1 tutorial based on what he saw in the chart, ran it for a week, and watched his day-7 retention move from 18% to 26%. He'd never done that before because he'd never had the data in a form he could act on.
That's when we realised the dashboard wasn't really about analytics. It was about decision-making speed. An indie developer or a small studio doesn't have a data analyst. They have themselves, at night, trying to figure out whether the money they spent on user acquisition actually worked. The dashboard needed to answer that question in under two minutes.
Connecting to Rippl shifted everything
The final piece fell into place when we integrated Attribr with Rippl, our performance marketing platform. Suddenly, the dashboard could show you which specific Rippl promoter drove an install, and then track that user's retention. You weren't looking at 'organic from Reddit' anymore. You were looking at 'promoter @mikesgamedev on Rippl, drove 47 installs, day-7 retention 31%.' It turned Rippl from a one-way channel into a feedback loop.
A studio using both tools told us that visibility changed their entire acquisition strategy. They'd been treating all community-driven installs as equally valuable. The dashboard showed them that certain promoters consistently brought higher-retention users. They doubled down on those relationships, cut spend with others, and cut their effective CPI by 40% without sacrificing day-30 retention.
What we didn't include, and why
We said no to a lot. No custom date ranges for core metrics (cohort tracking works off install date; that's it). No real-time updates (cohort data settles after a few hours; pushing live numbers would be misleading). No machine learning predictions or forecasting (we're not going to guess your day-30 retention). No custom dashboard builder (we optimised for one view because we know what matters).
The reason is simple: complexity kills understanding. Every option we added made it take longer to see the truth. We optimised for speed instead. A developer opens Attribr, looks at their cohort chart, checks their retention split by source, glances at their funnel. They know.
The dashboard exists because install attribution without retention data is like knowing where your customers came from but not whether they ever bought anything. The question we asked wasn't 'what data should we show?' It was 'what's the minimum someone needs to see to make a real decision about their user acquisition strategy?' That's what sits behind those three charts. Does that match what you're actually looking for when you check your app metrics?