Plenty of companies run a site and a mobile app, measure them with two different tools, and discover that the two never agree about anything. The usual response is to pick whichever number supports the argument being had. Here is what is actually going wrong, and what has to be true of a tool for it to cover both without lying to you.

The four things that genuinely differ

It is tempting to treat an app as a site with a worse browser. Four differences break that assumption, and any tool measuring both has to have an answer for each.

There is no URL. A site has a page address that doubles as a name, a hierarchy, and a way to group things. An app has screens, whose names you choose and can change. Nothing enforces consistency, so Checkout, checkout and CheckoutViewController end up as three screens in the same report.

There is no page load. On the web, a navigation is an obvious, observable event that the browser announces. In an app, moving between screens is a function call. If nothing instruments it, nothing is recorded, and no error is raised.

The network is not reliable. A browser tab is usually online. An app is regularly not: a tunnel, a plane, a dead spot. Events have to be queued on the device and sent later, which means a tool that assumes arrival order is time order will misorder them, and one that has no idea an event was queued will timestamp it wrong.

Sessions end differently. A web session times out after a period of inactivity, conventionally thirty minutes. An app gets backgrounded, and may sit backgrounded for days before returning to the foreground with its process still alive. A naive session rule reports one session that lasted four days.

What "one place" should mean, and what it usually means

Most tools that advertise both do one of two things, and the difference matters more than the marketing suggests.

The first is a shared dashboard over two entirely separate datasets. You get one login. You do not get one number, because the two sides count different things and nothing reconciles them.

The second is one dataset with a platform column, so that a report can be filtered or split. This is what people usually think they are buying.

There is a third arrangement, and it is worth stating plainly because it is the one that causes the arguments: an app and a site are genuinely different things, and forcing them into one entity produces reports where neither is right. A screen view is not a page view. An app has versions, and a site does not. An app crashes; a site returns a 500.

The useful arrangement is that they are separate entities with their own identifiers, measured by the same product, reported in the same interface, priced from the same account. You can look at either without the other's shape leaking into it, and you can look at both.

Questions worth asking a vendor

  • How does the SDK behave offline? Specifically: does it queue, how many events, what happens when the queue is full, and does it preserve the original timestamp rather than the send time?
  • What happens to a malformed event? An SDK that retries a permanently rejected event forever is a battery and data-plan problem for your users. The right behaviour is to drop it and count the drop.
  • Is the wire format versioned? Apps do not update in a day. Some fraction of your users will be on a build from a year ago, and the server has to keep accepting what that build sends.
  • How is a screen name decided? If the answer is "whatever you pass", ask what the tooling does to keep it consistent.
  • What is the session rule after a background? A specific number, not "we handle it".

That third question catches more real problems than the rest combined, and it is the one nobody asks. A web tracker can be changed by editing a page and is live that afternoon. An app SDK ships when the app ships, gets adopted over weeks or months, and never reaches everybody. Breaking the format your old builds send is not a bug you can hotfix; it is a fleet of installations that stop reporting.

Where Skomi sits

Skomi treats a tracked app as its own entity with its own key space, alongside sites rather than inside them. The reports live in the same account and are navigated the same way, but an app is never described as a site and its screens are never called pages.

There are SDKs for the common platforms, and the wire format they speak is versioned and frozen, precisely because an old build cannot be fixed remotely. The App Analytics page covers what is measured and which platforms are supported.

Credits are shared across everything on the account -- sites and apps alike -- so adding an app is not a second subscription. The pricing page has the arithmetic.

The two halves keep their own vocabulary where they differ, because a site has page views and an app has screen views, and they share the session window that makes them comparable.