How close should mobile web vs mobile app reporting in ga4 numbers be before I worry?

It depends on attribution scope, identity settings, and the systems being compared. The right question is not “Do they match perfectly?” but “Is the remaining gap explained, expected, and acceptable for the decision being made?”

What should I validate first when mobile web vs mobile app reporting in ga4 numbers disagree?

Start with date range, attribution model, conversion/key-event definition, reporting identity, and cross-domain or consent effects. Those five variables explain most “mystery” mismatches.

When is a discrepancy a tracking bug instead of a reporting difference?

It becomes a tracking problem when the gap is unexplained after scope alignment, or when one source is clearly missing sessions, events, revenue, or campaign context that should be present.

Mobile Web vs Mobile App Reporting in GA4 (2026)

Why does my mobile data look so different across web and app?

Mobile web and mobile app generate fundamentally different GA4 data even from the same user. Sessions count differently (web 30-min inactivity vs app 30-min with backgrounding rules), default events differ (mobile web uses page_view, app uses screen_view), conversion rates typically differ 2-3x (apps higher because users self-selected for engagement), identifiers differ (web cookies vs IDFV/Advertising ID), and attribution mechanics differ (gclid vs gbraid for iOS apps where ATT is denied).

The dashboard pattern for stakeholders who care about "all mobile" needs explicit filtering and normalisation. Don't compare "mobile web sessions" to "app sessions" directly — they're different units measuring different behaviours.

The fundamental differences

Dimension	Mobile Web	Mobile App
Default page event	page_view	screen_view
Session timeout	30 min inactivity	30 min with backgrounding
Identifier	_ga cookie	App Instance ID + IDFV/AAID (with consent)
Attribution	gclid (gbraid for iOS)	gbraid (iOS) / gclid (Android)
Automatic events	Enhanced Measurement set	Firebase automatic events set
Conversion rate	Lower	Typically 2-3x higher
Cross-device	Limited (cookie-based)	App Instance ID (per-device)
Push notifications	Browser push	Native push via FCM/APNs
Offline events	Not possible	Buffered, sent on reconnect

These aren't bugs — they're architectural differences between web browsers and native apps. Understanding them prevents bad comparisons.

Filtering reports by platform

In GA4 reports, the Platform dimension distinguishes:

web — desktop and mobile browsers
iOS — iOS app (native)
Android — Android app (native)

For mobile-specific analysis:

Mobile web only: filter Platform = web AND Device Category = mobile
Mobile app combined: filter Platform IN (iOS, Android)
All mobile: filter (Platform = web AND Device Category = mobile) OR (Platform IN (iOS, Android))

The Stream ID dimension provides finer granularity if you want to distinguish your iOS app from your Android app, or your main website from a separate mobile-optimised site.

The conversion rate gap

A common stakeholder question: "Why are app conversion rates 3x higher than mobile web?"

The honest answer: users who download apps have self-selected for higher engagement. They've already decided your brand is worth the friction of installing an app. Mobile web visitors include first-time discovery, casual research, and competitive comparison.

Specific factors driving the gap:

Repeat visitors are more common in apps (app icon on home screen vs typing URL)
Logged-in state is more common in apps (password manager + biometric auth)
Push notifications drive return visits
Loyalty program members disproportionately use apps
Mobile web includes ad clicks (lower-intent traffic)

The implication: don't try to "fix" mobile web to match app conversion rate. They measure different user populations. Compare to industry mobile web benchmarks instead.

Deep links and cross-platform journeys

Want to see which hidden implementation gaps are affecting your GA4 data quality?

Start free audit

A mobile user's journey often spans web and app:

Sees ad, taps, lands on mobile web
Browses, decides to download app
Opens app, completes purchase

Without deep linking, this looks like:

Mobile web session that bounces (zero conversion)
App session that converts (no source attribution)

With deep linking (Firebase Dynamic Links — note: deprecated in 2025, replaced with custom solutions; or Branch.io, AppsFlyer):

Mobile web session → app open with attribution preserved
Conversion attributed to original ad click

The implementation:

User taps ad → ad sends to deep link URL (e.g., app.example.com/product/123)
If app installed, deep link opens app to that product
If not installed, opens mobile web (and offers app install)
After install, deferred deep link opens app to the original product page
Attribution flows through

Setup: 4-8 hours engineering time per platform. Worth it for any property doing significant mobile ad spend.

The "all mobile" dashboard

For stakeholders who want unified mobile reporting:

Build in Looker Studio (or BigQuery + visualisation)

The pattern:

Pull GA4 mobile web data (Platform=web AND Device Category=mobile)
Pull GA4 app data (Platform IN (iOS, Android))
Union them with a normalised "platform_type" dimension
Aggregate metrics that are comparable (users, sessions, key events, revenue)
Avoid metrics that aren't comparable (bounce rate has no app equivalent, screen_view ≠ page_view counts)

Comparable metrics

These work for combined reporting:

Active users
New users
Key events / conversions
Revenue
Engagement time per user
Session count (with caveat about counting differences)

Don't combine these

Pageviews vs screen_views (different units)
Bounce rate (apps don't have a traditional bounce concept)
Pages per session vs screens per session
Average session duration vs average screen time