One SDK. One picture. Why tool fragmentation is costing gaming studios more than they think.

There is a tab open right now on a UA manager’s second monitor. It has been open for three days. It is the analytics dashboard for a game that launched six weeks ago. Next to it, on the primary screen, is the MMP. Two windows. Two logins. Two completely different pictures of what is happening with this game.

The UA manager is trying to answer one question: why did ROAS drop on this network last Tuesday? The MMP shows the install numbers. The analytics platform shows what those users did after they installed. But the two tools do not talk to each other. So the answer to that one question requires exporting a CSV from one platform, uploading it to the other, and hoping the date ranges and event definitions align closely enough to be comparable.

By the time the answer arrives, it is Thursday. The budget decision was made Wednesday morning.

This is not a rare edge case. This is the standard operating model for the majority of independent gaming studios running serious UA today. And almost nobody talks about what it actually costs.

How we got here

The MMP category was built in a specific moment in mobile gaming history. The problem it was solving was simple: did this install come from this campaign? That is an attribution problem. The tools that emerged were attribution tools. They were not built to understand what happened after the install, because that was someone else’s job.

Game analytics platforms emerged separately, solving a different problem: what is happening inside the game? Level progression. Ad view rates. IAP conversion. Churn at day seven. Important questions, but questions that lived in a completely separate data universe from the acquisition side.

For a long time, this split made sense. The teams were different. The budgets were different. The vendors were different. Nobody questioned whether it was efficient to run two parallel systems, because everyone else was doing the same thing.

Then the market changed. ATT arrived. IDFA became scarce. The cost of acquiring a user went up. The tolerance for wasted spend went down. And suddenly, the question of why a specific cohort was performing well or badly stopped being a UA question or a product question. It became both at once. The tools had not kept up. The split remained.

What fragmentation actually costs

Let me be specific, because the industry tends to talk about this in vague terms like “data silos” and “lack of alignment.” Those phrases are accurate but bloodless. Here is what it looks like in practice.

A studio I spoke to recently had three full-time analysts whose primary job was reconciling data between their MMP and their analytics platform. Three people. Reconciling data. Not analysing it. Not acting on it. Moving it from one place to another and checking whether it matched.

Another studio had a weekly ritual where the UA team and the product team would meet to compare numbers. UA would bring their cohort data. Product would bring their retention curves. They would spend forty-five minutes arguing about why the day-seven retention numbers did not match between the two systems, only to discover the two systems defined the cohort differently. One counted day seven from the attributed install date in UTC; the other counted it from the user’s first session in the account’s local time. The two “day seven” cohorts were never the same set of users, and that definitional gap had invalidated two weeks of comparative analysis.

These are not technology failures. They are structural failures. Two systems built by different companies with different definitions of the same events, running on different SDKs, producing different outputs, and requiring a human being to sit in the middle and translate.

The cost is not just the analyst’s time, or the weekly meeting, or the wrong budget decision made on Wednesday. The cost is the speed at which a studio can act on what it knows. In a market where a good creative runs hot for eleven days before the algorithm finds it and scales it to exhaustion, the difference between a two-day insight loop and a two-hour insight loop is a meaningful competitive advantage.

The SDK problem nobody talks about

There is a second cost that is almost never discussed publicly, because it lives in engineering rather than growth, and growth is usually the one writing about this topic.

Every SDK you add to a game is a performance cost. It is startup time. It is memory footprint. It is network calls. It is a potential crash surface. It is a dependency that needs to be updated, tested, and maintained every time a platform changes its requirements.

Two SDKs is not twice the cost. In practice, it is more, because the two SDKs will occasionally conflict, because updating one requires re-testing against the other, and because when something breaks in production you now have two vendors to call and two codebases to investigate before you can isolate the cause.

The engineering teams at gaming studios are not large. In an independent studio of thirty people, you might have five engineers. Those five are also building the game, maintaining the game, shipping updates, and handling platform compliance. The overhead of a two-SDK measurement stack is not trivial for them, and measurement is rarely the only SDK in the build. A game that monetises through ads already ships one or more ad and mediation SDKs it can’t remove. Every extra measurement SDK stacks on top of that, so the real question isn’t one SDK versus two, it’s how many you can avoid adding to an already crowded app. It is a material tax on their time and attention, and the UA team rarely hears about it, because engineering swallows the cost quietly and gets on with it. But the cost is there.

Why the incumbents never solved it

The honest answer is incentive. MMP providers were built to sell MMP services. Analytics providers were built to sell analytics services. Neither had a strong reason to become the other, because the market rewarded specialisation and the category definitions were set.

There were integrations, of course. The MMP would pull in some analytics events. The analytics platform would accept MMP postbacks. But these were always bolted-on partnerships, not native architectures. The data models were different. The user identification was different. The event schema was different. You were connecting two things that were never designed to be connected.

The larger providers eventually tried. They built “unified platforms” that were, in practice, acquisition dashboards with an analytics tab added, or analytics platforms with a measurement module bolted on. The seams always showed. Studios would use the combined platform for one thing and a specialist tool for the other, and the fragmentation would return.

The category never got solved because the category was the problem. Two separate markets, two separate incentive structures, two separate vendor relationships. The idea that these should be one thing was obvious to the studios experiencing the problem and invisible to the vendors profiting from the split.

What one platform actually changes

I want to be precise about this, because “one platform” can mean a lot of things and most of them are not what I mean.

I do not mean a portal that aggregates data from two separate systems and displays it in a single dashboard. That is a presentation layer, not an architecture change. The data is still siloed. The definitions are still inconsistent. The latency is still there. You have just hidden the problem behind a cleaner UI.

What I mean is a single SDK that captures the signals needed for attribution and in-game events in the same data stream, with the same user identification, at the same moment, with definitions that are set once and applied consistently across everything.

When that is true, a question like “why did ROAS drop on this network last Tuesday” can be answered in a single query. The install event and the session event and the IAP event and the ad view event all live in the same place, tagged to the same user, in the same time zone, with the same event definitions. The analyst does not need a second screen. The UA manager does not need to export a CSV. The Wednesday budget decision is made with Thursday’s level of information.

That is the competitive advantage. Not the platform. The speed at which truth is available.

The broader argument

I have been talking to gaming studios for long enough to know that the tool fragmentation problem is not just an operational annoyance. It is a compounding disadvantage.

Every week a studio runs its measurement stack in two separate systems, it is making slightly worse decisions than it could be making. The decisions are not catastrophically wrong. They are directionally right, most of the time, within reasonable confidence intervals. But “directionally right within reasonable confidence intervals” is not how the studios at the top of the UA performance curve operate. Those studios have faster insight loops, cleaner data, and lower overhead. And that gap compounds over months and years into a structural difference in how efficiently they can grow.

The studios that will win the next phase of mobile gaming are not the ones with the biggest budgets or the most creative talent, though both help. They are the ones who can close the loop between acquisition data and behaviour data fastest, and act on what they see before the window closes. That requires one picture. Which requires one SDK.

Why I am writing this

justtrack is my answer to this problem. I joined as MD because I believe the argument above, and because I believe the moment to build this is now, not five years ago and not five years from now.

The independent studio that figured this out a decade ago would have had to build it themselves. Today, the platform exists. The SDK is live. Studios are using it, replacing both their MMP and their game analytics tool with a single integration, and finding that the insight loop they imagined was actually faster than they expected.

I am not writing this to sell you on justtrack specifically. I am writing this because the conversation in the industry is still too focused on which MMP is best, or which analytics platform has the cleanest UI, or which vendor offers the most integrations. Those are the wrong questions if the architecture is broken.

The right question is: how many platforms does it take to answer a single question about your game? If the answer is more than one, you have a fragmentation problem. And that problem is costing you more than you think.

If you are a gaming studio thinking about this, I want to talk to you. Not to pitch you. To understand where your data lives, what questions you cannot currently answer, and whether there is a path to getting to one picture faster than you think.

Reach out. gunnar.neumann@justtrack.io or justtrack.io

Frequently asked questions

What is tool fragmentation in mobile UA?

Running attribution (an MMP) and game analytics in two separate systems, with two SDKs, two logins and two sets of event definitions, so acquisition data and in-game behaviour data never fully line up.

Why is running an MMP and a separate analytics tool a problem?

The two tools use different SDKs, user identifiers and event definitions, so their numbers rarely match. That forces manual reconciliation, slows down decisions, and adds engineering overhead from maintaining two SDKs.

What does a single SDK for attribution and analytics change?

It captures attribution signals and in-game events in one data stream, tagged to the same user with one set of definitions. Questions that used to take a CSV export and a day can be answered in a single query.

Does adding a second SDK hurt app performance?

Yes. Every SDK adds startup time, memory use, network calls and a crash surface, and two SDKs can conflict and multiply testing and maintenance work for a small engineering team.

Can justtrack replace both my MMP and analytics platform?

Yes. Studios use justtrack as a single integration in place of a separate MMP and game analytics tool, so acquisition and behaviour data live in one place.

Built for studios that want to win. Not just measure.

Start your free trial today, or talk to us first. Either way, we’ll give you a straight answer about what justtrack looks like for a studio at your scale.

Start free trial

No credit card required