Mobile app analytics is one of the areas where ecommerce teams routinely underestimate the work. The platforms — Mixpanel, Amplitude, Heap, Shopify's own dashboards — look familiar from web analytics. The implementation looks like a copy-paste of the web setup. And then, six months in, the team realizes the dashboards are missing things, the funnels do not match the actual buyer behavior, and the answer to "how is the app channel doing" is harder to give than expected.
This piece is about the three specific ways mobile app analytics diverges from web, and the setup decisions that prevent the most common gotchas.
Difference 1: events are batched, not real-time
Web analytics fires events in real time. The browser sends the event the moment it happens; the dashboard updates within seconds. Mobile apps cannot do this. Battery and network constraints mean events are typically batched on the device and sent up in clusters — when the app goes to background, when the network is good, periodically every few minutes.
The implication: dashboards lag. A push campaign that fires at 10am will show events trickling in over the next 30–60 minutes, not all at once. A funnel built on "events in last hour" will under-count the contribution of pushes sent recently. For real-time decision making — pausing a bad campaign quickly, for example — the lag matters.
The fix: build dashboards that account for the lag. Most analytics tools offer "delayed" views that backfill as data arrives. Use the 24-hour view for daily decisions; reserve real-time views for diagnostics only. Train the team to wait before reacting to a fresh number.
Difference 2: attribution is platform-mediated
Web attribution is direct: the user clicks an ad with a UTM, the URL carries the tracking, the analytics tool sees the source. Mobile is mediated. The user clicks an ad, lands on the App Store, taps install, opens the app — and somewhere in that chain, the attribution has to be reconstructed. The reconstruction depends on platform attribution protocols (SKAdNetwork, Google Play Install Referrer), MMPs (mobile measurement partners like AppsFlyer or Adjust), and post-ATT modeling for the iOS users who did not opt in.
The result: mobile attribution data is messier than web data. Multiple sources can claim the same install. SKAN data arrives delayed and aggregated. The MMP and the channel may report different numbers for the same campaign because each is filling gaps with different modeling assumptions.
The fix: pick one source of truth per channel and stick to it. Most brands use the channel's own reporting (Meta, TikTok, Apple Search Ads) as the operational dashboard, with the MMP as the cross-check. Reconcile periodically. Do not try to reconcile in real time; the upstream lag makes it impossible.
Difference 3: the user model is install-based, not session-based
On web, a user model is loose — sessions, cookies, the occasional logged-in user. A web visitor on Tuesday is mostly a different person from the same web visitor on Friday, from the analytics perspective. On mobile apps, the user model is install-based: one install equals one identifiable user-device combination, persistent across sessions, until they uninstall or switch devices.
This is actually better for analytics — you can track install cohorts, retention over time, and per-user behavior with confidence the web version cannot match. But it also means the dashboards and analyses need to be structured differently. Reporting on "DAU" without contextualizing it against the install base misses the point.
The fix: structure your reporting around install cohorts. Weekly active users as a percentage of the install cohort tells you retention. Average events per install per week tells you engagement. Revenue per install per month tells you LTV trajectory. Same data the web team uses, framed differently.
A single events schema
The other common mistake is letting the events schema drift. Different developers fire similar events with different names ("product_view" vs "viewed_product" vs "product_detail_open"). Different teams add custom properties that conflict. The result is a dashboard graveyard where nothing aligns.
The fix: a single events schema, documented, owned by one person. Every new event addition goes through review. Properties are named consistently. The discipline pays back when the team can actually trust the funnel they are looking at because the events feeding it are well-defined.
“The single highest-leverage move in app analytics is treating the events schema as a serious internal product. Most teams treat it as someone's side project.”— Analytics lead, internal
What to actually track
A reasonable starting events set for a Shopify brand app: install, app_open, product_view, add_to_cart, begin_checkout, purchase, push_received, push_opened, subscription_paused, subscription_resumed, account_created, review_submitted. Plus a small number of brand-specific events that map to your particular funnel — wishlist, gift card purchase, loyalty redemption.
What to skip: every micro-interaction in the UI. Tracking every tap, scroll, and hover sounds appealing for data fidelity but creates a noisy schema that nobody actually queries. Track the events that map to a decision (a funnel step, a retention trigger, a campaign target), not the events that prove the app was used.
Reporting cadence
Daily: install volume, opens, push delivery, attributed revenue. These are operational metrics — they tell you if something broke yesterday. Weekly: cohort retention, funnel conversion, push engagement. These are trend metrics — they tell you whether the channel is healthy. Monthly: LTV by cohort, channel mix, ASO health. These are strategic metrics — they inform planning.
Reviewing all three together once a month, with the right people in the room, is the cadence that holds up. Daily reviews of every metric burn out fast and lead to overreaction. Quarterly reviews are too infrequent to catch issues. Monthly is the right interval for most ecommerce brands running an established app channel.
Done correctly, mobile app analytics gives you better visibility than web because the install graph is persistent. Done incorrectly, it gives you the false confidence of a dashboard that looks complete and is missing the moves that matter. The difference is in setup discipline, not tool choice.
