Somewhere in your reporting there’s a customer who arrived through one system and paid in another.
Here’s how it usually looks. A paid campaign sends someone to your site. They read two pages and leave. Eleven days later they install your app. They poke around for a week, hit the paywall, and subscribe.
Now ask three tools what happened.
The ad platform claims credit for an install. Web analytics shows a bounce. Your CRM has a new customer with no visible origin. And the subscription sits in a billing dashboard with no campaign attached to it.
Nobody is lying. The systems just don’t share a graph. And the further you get from the browser, the worse the disagreement gets.
That’s why we built native SDKs for iOS and Android. But the reason isn’t “we added mobile support.” The reason is that two shifts are landing on the phone screen at the same time, and both of them punish a measurement stack that stops at the web.
The browser was the easy half
For all the noise about the death of third-party cookies, first-party measurement on the web is mostly a solved problem. You own the domain. You control the script. You can follow a journey, resolve identity, and connect a form fill to a deal in your CRM.
Apps never got that treatment. App measurement got outsourced to a different discipline with different rules, built on platform attribution frameworks and mobile measurement partners.
Those tools have real limits. An AppsFlyer analysis of SKAdNetwork found that roughly 32 percent of non-organic installs were misattributed as organic, and that the framework captured only about 64 percent of revenue driven by non-organic installs. Apple’s App Tracking Transparency opt-in has plateaued around 27 percent globally. Which means most iOS attribution decisions now rest on probabilistic or postback modeling instead of a deterministic match.
None of that is a knock on anyone’s engineering. It’s a description of the surface. On the web, first-party is the default. On mobile, third-party estimation is the default, and the numbers quietly reflect it.
So a platform that claims to show where revenue comes from, but can only see the web half of the journey, is describing a business it can only partially observe.
Meanwhile, the app became the storefront
Mobile has been the majority of ecommerce for a few years now: roughly 57 percent of global ecommerce sales in 2024, with projections near 59 percent for 2025.
The more interesting number is where inside mobile the buying happens. About 54 percent of mobile commerce runs through apps rather than mobile browsers, per J.P. Morgan data. The in-app purchase market itself was valued near $190 billion in 2025.
Put those together and the shape of the problem is hard to miss. The surface we measure worst is carrying the most revenue. And it’s growing.
For a subscription business, that isn’t a rounding error. App stores are where the subscription starts, where it renews, and sometimes where it dies. If the only record of that is a platform postback with a fuzzy campaign label, the revenue number and the acquisition number never actually meet.
And the phone is where agents arrive first
Here’s the part that made this urgent instead of just overdue.
Both platforms are turning apps into callable surfaces for AI agents. Apple’s June 2026 developer announcements describe App Intents as the mechanism connecting apps to Siri’s personal context, app actions, and onscreen awareness. Google’s equivalent, AppFunctions, is blunter about it. The documentation calls AppFunctions “the mobile equivalent of tools within the Model Context Protocol,” letting apps behave like on-device MCP servers whose functions an agent can discover and execute. It runs on Android 16 and up, and it’s in private preview with Gemini today.
That’s the WebMCP argument, arriving on mobile ahead of the web.
The implication takes a minute to land. When an agent books, orders, subscribes, or cancels on someone’s behalf by calling a function inside your app, the interaction may never render a screen. No pageview. No click. No session in any sense you’d recognize. A function invocation, a result, and a change in your database.
If the only record of that event is a platform postback, you’ve rebuilt the exact blind spot we started this company to fix, right at the moment it becomes most expensive.
Agents don’t need a prettier dashboard. They need a system of record that knows who the person is, what they authorized, and what it was worth. Which is the same thing your revenue team needs. And the same reason attribution has to live in a first-party graph instead of inside any single platform.
What “native” had to mean
Supporting mobile could have meant a thin wrapper that ships events to a third party and calls it done.
That would have missed the point. So we built the SDKs around four commitments that matter more than any feature list.
Identity has to survive the app lifecycle. People use an app for weeks before they sign in. They sign out on shared devices. They hold more than one account. The SDKs keep anonymous and identified user information across launches, so a late sign-in can still be reconciled against everything that came before it. Logout resets identity, and switching accounts rotates it. That last detail is what stops a shared iPad from fusing two people into one customer record.
Consent has to be a gate, not a setting. Neither SDK collects before consent is granted, and withdrawal is treated as a real state change: pending events get cleared, identity resets, an active upload is asked to cancel. Consent that only stops future collection leaves data sitting on the device and in flight. That’s the version most teams discover during an audit.
Delivery has to assume the network will fail. Mobile clients lose connectivity, get force-quit, and interrupt uploads mid-flight. Pending events live in local SQLite so they survive restarts, move in compressed batches, and are retained and retried when delivery fails or an acknowledgement isn’t recognized. You can also inspect queue depth, dropped events, and the last delivery error. “The SDK said it sent it” is not the same as knowing.
The event has to carry its own context. Campaign parameters and referrer values get extracted from the links that actually drive installs, and every event carries app version, OS version, locale, timezone, and SDK version. That’s what lets you tell a regression in your app apart from a change in a campaign. Getting that distinction wrong costs real money.
What the SDKs don’t do
Purchase observations describe activity your app reported. On their own, they are not a verified record of money that changed hands.
Verified payments, refunds, renewals, and subscription status still require a server-side billing integration with Apple or Google.
I’d rather say that plainly than let an app-reported purchase pass for settled revenue. A number that quietly overstates revenue is worse than one that admits what it’s missing.
Why this belongs in the same graph
The temptation with mobile is to treat it as its own discipline. Its own tooling. Its own reporting.
That’s how you end up with an app dashboard, a web dashboard, and a CRM that agree on nothing.
App events belong in the same place as campaigns, calls, CRM records, orders, and closed revenue. A journey that starts on a phone and closes in your pipeline should read as one journey. A feature interaction three days before a subscription should be visible next to the campaign that created the account.
That’s the whole idea behind the Revenue Graph. And it doesn’t hold if a meaningful share of commerce happens outside it.
The browser was the first surface. The app is the next one. The agents are already on their way.
Setup details are on Convertmax for iOS and Convertmax for Android. If you want to talk through identity stitching or rolling this out across your stack, email help@convertmax.io.