HELPERG (opens in a new tab) Ecosystem

WebmasterID logoWebmasterID
Menu
Privacy-first mobile app analytics

Mobile app analytics for iOS, Android and Flutter

Install a public SDK, pass each user's consent decision and send events. WebmasterID reports events, sessions, installations, retention and conversions for your iOS and Android apps, in the same workspace as your websites, and the reports state what they cannot answer.

Already a customer? Open the Apps reports or register an app under iOS apps or Android apps.

Platforms
iOS 15.0 or later, Android API 24 or later, and Flutter 3.47.0 or later for both.
Reports
Overview, Events, Conversions, Retention (beta) and Attribution.
Privacy
Nothing is sent before your app passes the user's consent decision. No advertising identifiers.
Price
Included in Pro ($499/month) and Agency ($1,199/month).
Platforms

Native SDKs for iOS and Android, and a Flutter plugin

Install from the public package channel each platform already uses. No private repository, no access token, and no credential to add to your build server.

iOS

Swift Package Manager

  • WebmasterID iOS SDK 1.3.0
  • iOS 15.0 or later
  • From a public Swift package on GitHub
Install on iOS

Android

Gradle, Kotlin or Java

  • WebmasterID Android SDK 0.3.0
  • API 24 or later
  • From the public Maven repository at webmasterid.com/sdk/maven
Install on Android

Flutter

pub.dev: webmasterid_flutter

  • Version 0.4.0, for iOS and Android apps
  • Flutter 3.47.0 or later
  • Runs on the native iOS and Android SDKs
Install on Flutter

React Native, Unity and .NET are not supported. The Flutter plugin covers iOS and Android apps, not Flutter web or desktop.

What you can measure

Five reports, built from the events your app sends

Every report counts by the time WebmasterID received an event, not by the device's clock, and the headline metrics carry their definitions on the page.

Overview

Events, sessions, active installations, first-observed installations and identified users, with events per day, the top events, and tracking health: when the last event arrived.

Events

Every event name with its counts and sessions, the top screens and countries, and the 50 most recent events with shortened pseudonymous identifiers.

Conversions

The funnel events your app reports in one table; purchases verified with Apple or Google in another. The two are never added together.

Retention (beta)

Day 1, 7 and 30 cohorts by installation, in your reporting time zone. A day that has not passed yet shows as not yet observable, never as 0%.

Attribution

What is known about where app activity came from, and what is not. The SDKs send no source, campaign or referrer, so install sources show as unknown, never as organic.

The 14 events an app can send

A fixed vocabulary, so every app's reports mean the same thing. Events record the screen they happened on, where there is one. Custom event names and custom properties are not supported, and the app version, OS version and consent state are checked when an event arrives but not stored, so there is no breakdown by them.

  • app_open
  • session_start
  • screen_view
  • cta_tap
  • search_performed
  • filter_applied
  • signup
  • login
  • checkout_started
  • booking_started
  • payment_started
  • booking_completed
  • cancellation
  • refund_requested
Dashboard

Apps sits next to Web in the same dashboard

One sign-in, one workspace, one plan. Filter by app, platform, environment and date range. Production is the default view; development and TestFlight builds stay out of it unless you choose them.

The Apps overview with demo data: filters for app, platform, environment and date range; tracking health with the last event received; and counts of events, sessions, active installations, first-observed installations and identified users, each with its definition.
Demo data. The Apps overview, rendered by the dashboard's own components with the sample apps from its test suite. These are not a customer's numbers.
  • Tracking health firstWhen the last event arrived, by server time, next to what the device's clock reported.
  • Unavailable is not zeroA report that could not be read says so. It is never shown as a zero.
  • Limits statedThe overview lists what the reports can and cannot answer; Attribution and Conversions state their own.
Websites and apps

Your websites and apps in one workspace, reported side by side

Teams that run a website and an app see both in one place, under one plan. The reports stay separate: WebmasterID does not merge a website visitor and an app user into one person.

Shared

  • One account, one workspace and one plan.
  • One dashboard, with Web and Apps sections in the sidebar.
  • The date range carries over when you switch between them.
  • One reporting time zone for both.

Kept separate

  • No combined web-and-app report.
  • No journey from a website visit into an app.
  • No matching of a person across devices: an account key is hashed per app, so the same user counts once in your iOS app and once in your Android app.
Install

From install to the first event

Registering an app collects nothing. Events appear when the SDK is installed, started with the user's consent decision, sending events and delivering them.

Before you start

  • An active Pro, Agency or Business plan on the workspace.
  • The Owner, Admin or Editor role, to register an app.
  • iOS 15.0 or later built with Xcode 26.0 or later; Android API 24 or later with Gradle; or Flutter 3.47.0 or later.
  • A place in your app where the user makes the analytics choice, such as a consent prompt or a setting, whose answer your app passes to the SDK.
  • No GitHub account, access token or private repository.
  1. Step 1

    Choose a plan

    Create an account and choose Pro or Agency at checkout. App analytics is part of both.

  2. Step 2

    Register the app

    Under iOS apps or Android apps in the dashboard. You get a public property ID: safe to embed, not a secret, and not enough to collect anything on its own.

  3. Step 3

    Add the SDK

    From Swift Package Manager, the WebmasterID Maven repository or pub.dev. No private repository, account or access token.

  4. Step 4

    Start it with a consent decision

    Initialize the SDK with the property ID and pass the user's decision. Until there is one, nothing is queued or sent.

  5. Step 5

    Send events

    Screen views, taps and the funnel steps that matter to you. In Flutter, the plugin's lifecycle and navigator observers record app_open and screen_view for you.

  6. Step 6

    Deliver them

    The SDK does it on its own, on iOS and Android: about 5 seconds after an event, when the app moves to the background, and after the next launch for anything left. flush() is only for a boundary your app chooses.

  7. Step 7

    Verify the first event

    Apps → Overview → Tracking health shows the last event received. If nothing arrives, the guide's verification steps and the SDK's diagnostics say why.

The installation guide covers each step for Flutter, Swift and Kotlin or Java, including the first run, verifying the integration and troubleshooting by symptom.

Consent and identity

Consent and identity, in plain language

WebmasterID records what your app sends, under the decision your app passes. Whether consent is needed, and on which legal basis, is for you to decide; the SDK does not make an app compliant by itself.

  • No decision, no data

    Until your app passes the user's decision, the SDK queues nothing and sends nothing.

  • Allowed

    Events carry a session ID, an installation ID and, if your app calls identify(), an account key. Installation IDs and account keys are stored as keyed hashes: pseudonymous, not anonymous.

  • Restricted

    Events carry a session ID only: no installation ID and no account key. This is reduced identification, not anonymity. The session ID, exact times and the country remain.

  • Disabled

    Nothing is sent.

  • No advertising identifiers

    The server refuses IDFA, IDFV, the Android advertising ID and other device identifiers. App Tracking Transparency is not requested, and an ATT answer is not consent to analytics.

  • No IP address stored

    The country is taken from the network edge when an event arrives. No IP address or user agent is written.

Details in the installation guide: consent states, identifiers, and what the SDKs send for App Store privacy details and Google Play Data safety.

Conversions

Reported conversions and verified purchases are different facts

Your app can report a checkout. Only Apple or Google can confirm a purchase. The Conversions report keeps the two in separate tables and never adds them together.

The App conversions report with demo data: a table of app-reported conversion events, and below it a separate table of provider-verified revenue by app and currency, with notes that sandbox purchases never count and RevenueCat is not supported.
Demo data. Sample apps and amounts from the dashboard's test suite, not a customer's.

App-reported conversions

The funnel events your app sends, counted as its own claims:

  • signup
  • login
  • checkout_started
  • booking_started
  • payment_started
  • booking_completed
  • cancellation
  • refund_requested

Store-verified purchases

On iOS, Apple-signed StoreKit 2 transactions, checked against Apple's certificates, and App Store Server Notifications. On Android, Google Play purchase tokens checked with Google, and real-time developer notifications. Each needs a store connection set up on the app's page in the dashboard. Production, revenue-bearing transactions only, gross before refunds, each currency separately. Sandbox and test purchases never count.

Where purchase verification stands

App Store notification delivery is verified in production. The Google Play side is deployed but not yet proven end to end with a test purchase, and no purchase has yet been carried through either store's sandbox and verified. RevenueCat and other purchase frameworks are not supported.

Is it a fit?

What it is for, and what it is not built for

A good fit

  • Teams that already measure a website with WebmasterID and ship an iOS or Android app.
  • Apps whose key moments fit the 14 events: screens, taps, search, filters, sign-up and login, and booking, checkout and payment steps.
  • Teams that want consent-first, pseudonymous app analytics without advertising identifiers.
  • Agencies running websites and apps for several clients (the Agency plan adds workspaces and team members).

Not built for

  • Install attribution: ad-network postbacks, SKAdNetwork, Apple AdServices, the Google Play Install Referrer, deep-link campaigns, cost or ROAS. WebmasterID is not a mobile measurement partner.
  • Custom event names or properties, or a single journey that follows a person from your website into your app or across devices.
  • App Store or Google Play download counts. A first-observed installation is the first event from an installation ID, not a download.
  • Crash reporting, session replay, push notifications or A/B tests.
  • React Native, Unity or .NET apps.
  • App data in the Event Explorer, exports, or the MCP and agent tools: those work with website data.
Pricing

Included in Pro and Agency

The SDK packages are public downloads. Sending events and reading the Apps reports needs an active plan. There is no free plan for new accounts.

Pro

$499 / month

One workspace with up to 5 connected sites, plus app analytics.

Start with Pro

Agency

$1,199 / month

Multiple workspaces and team members, plus app analytics.

Start with Agency

Business

By agreement

Custom limits and onboarding, plus app analytics.

Contact sales

Monthly billing in USD; cancel any time. Compare every plan. Already on a plan? App analytics is already in your workspace: register an iOS app or an Android app.

FAQ

Mobile app analytics, answered

Does registering an app start collecting data?
No. Registration creates the app's public property ID and nothing else. Events appear once the app has the SDK installed, starts it with the user's consent decision, sends events and delivers them.
When do events leave the device?
About 5 seconds after they are recorded, on iOS and Android alike, with no call from your app — and when the app moves to the background (best effort: the system may suspend the app first), and after the next launch for anything still queued. While the app is running, failed requests are retried on their own; a suspended or closed app sends nothing until it runs again. Before iOS SDK 1.3.0 and webmasterid_flutter 0.4.0, iOS sent only when the app called flush() or moved to the background; updating brings automatic delivery.
Do I need a website to use app analytics?
No. After checkout, open iOS apps or Android apps in the dashboard and register the app. App reports do not depend on a website.
Is WebmasterID a replacement for AppsFlyer or Adjust?
No. Those are mobile measurement partners: they attribute installs to ad networks and campaigns. WebmasterID's SDKs send no source, campaign or referrer, and WebmasterID does not connect to ad networks, SKAdNetwork, AdServices or the Install Referrer.
Is the data anonymous?
No. Installation IDs and account keys are stored as keyed hashes, which makes them pseudonymous, not anonymous. Under the restricted consent state, events carry only a session ID — reduced identification, still not anonymity.
Does it use the IDFA or ask for App Tracking Transparency?
No. Advertising and device identifiers are refused by the server, and WebmasterID does not ask for ATT. An ATT answer is not consent to analytics: your app passes its own analytics decision to the SDK.
Can I see web and app activity for the same person?
No. Websites and apps are reported side by side in one workspace, but identifiers are hashed per website and per app, so a visitor and an app user are never matched — nor is one user across an iOS and an Android app.
Which purchases count as revenue?
Only purchases verified with Apple or Google: production, revenue-bearing transactions, gross before refunds, each currency separately. Sandbox and test purchases never count. Checkout or payment events your app reports are shown as its own claims, apart from revenue.
Is RevenueCat supported?
No. Purchase verification works with StoreKit 2 on iOS and Google Play Billing on Android. RevenueCat and other purchase frameworks are not supported.
Do you support React Native or Unity?
No. There are native SDKs for iOS (Swift) and Android (Kotlin or Java), and a Flutter plugin for iOS and Android apps. React Native, Unity and .NET are not supported.
How much does it cost?
App analytics is included in Pro ($499/month) and Agency ($1,199/month), and in Business plans by agreement. The SDK packages are public downloads; sending events and reading the reports needs an active plan. There is no free plan for new accounts.