--- title: Why are my app analytics numbers so different across platforms? description: Conflicting app analytics numbers across platforms explained. Discover why sessions, events and attribution figures differ and how to audit your setup. image: https://weareaffective.com/hubfs/learning-centre-images/why-are-my-app-analytics-numbers-so-different-across-platforms.webp --- [Skip to content](https://weareaffective.com/learning-centre/why-are-my-app-analytics-numbers-so-different-across-platforms#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Why are my app analytics numbers so different across platforms? Table of Contents You open your dashboard and see one number for sessions. You check your mobile measurement partner and see a different one. You cross-reference your ad platform and find a third. All three are supposedly measuring the same app, the same users, the same period. The gap between them can feel like a fault in the tools, but it is usually a fault in how the tools were set up, or in what each one was actually built to count. > The numbers look like they're measuring the same thing, but each platform is asking a slightly different question. This kind of discrepancy shows up on almost [every app product we look at closely](https://weareaffective.com/app-audit). The numbers rarely match exactly, and in some cases the differences are stark enough to change a decision entirely. According to [INCRMNTAL](https://www.incrmntal.com/resources/ios-vs-android-performance), when comparing attributed Cost per Install across 11 app developers on iOS and Android, the average difference between platforms was 393%. That is not a rounding error. That is a measurement architecture problem. Understanding why analytics figures diverge is less about chasing perfect alignment and more about knowing what each platform is actually measuring, and whether those measurements are serving the decisions you need to make. The answer is almost always that they are not quite doing what you think they are. ## The most common reasons the numbers don't match Most discrepancies come down to three things: different definitions, different data collection methods, and different rules about what counts as a valid data point. Platforms do not use a shared standard. Each one was built by a different team with a different purpose, so they make different choices at a low level that compound into large differences at the reporting level. The first source of drift is timing. One platform records an event when it happens on the device. Another records it when the data reaches the server. If a user is on a poor connection, those two moments can sit minutes apart or, in some cases, the server-side record never arrives at all. The device said it happened. The server says it did not. The second is scope. Ad platforms are built to attribute installs and conversions back to spend. Analytics platforms are built to understand behaviour once a user is inside the product. These two systems care about different events, so they count different things, and comparing their totals is a bit like comparing the guest list at the door to the number of people who ordered food inside. The third is privacy. Consent changes what data is available, and different platforms handle missing consent differently. Some exclude the user entirely. Some model the gap with estimates. The same user, in the same session, gets counted differently depending on which platform is doing the counting. ## How session definitions vary between platforms A session sounds like a simple concept: a user opens the app, does things, leaves. But the moment you try to define the edges precisely, platforms disagree. What counts as leaving? What if the user switches apps for 30 seconds and comes back? What if the phone locks? Each platform has its own answer, and those answers are not published prominently. #### The timeout gap Google Analytics for Firebase defines a session as ending after 30 minutes of inactivity. Mixpanel's default is the same. But some platforms use 15 minutes, and some let you configure it, which means if the team changed the setting at some point and did not document it, you could be comparing 15-minute sessions against 30-minute ones without knowing it. A user who puts the phone down for 20 minutes and picks it up again is one session in one platform and two in another. #### Background and foreground states On mobile, the app does not fully close when a user switches away. It moves to the background. Some analytics SDKs treat a return from background as a continuation of the existing session. Others treat it as a new session start. This alone can inflate one platform's session count by 20 to 40 per cent over another's, on the same users, in the same period, with no one having made a mistake. The practical consequence is that session volume is not a reliable cross-platform metric. If you are comparing sessions between two tools, you first need to read both platforms' documentation on how they define session boundaries, and then [decide whether the definitions are close enough](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) for comparison to mean anything. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Event tracking: what gets counted and what gets missed Event tracking looks straightforward until you get into the mechanics. An event fires when code runs, and code runs on a device that may be offline, may have a flaky connection, or may kill the app before the event reaches a server. The infrastructure for capturing events reliably is more complex than engineers typically realise at the start. One of the patterns we look at closely is what happens at moments of hesitation: when a user enters a screen, backs out, and re-enters. That repeated movement is a [behavioural signal worth tracking](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl), and it requires granular event instrumentation rather than simple page-view counts. Standard analytics setups often miss it entirely, because they log the screen view but not the exit-and-return sequence. > Standard setups log that someone arrived on a screen, but not that they arrived three times. The same is true of scroll behaviour. Knowing that a user scrolled down a terms and conditions screen is useful. Knowing that they scrolled up and down repeatedly, several times, in under two minutes, tells you something quite different about their state of mind. That second data point requires more deliberate event design, and most out-of-the-box setups do not capture it. Audit your events list against the decisions you actually make. If you cannot point to a product or design decision each event informs, it is either untriggered instrumentation or data you are collecting without using it. When we worked on a mobile product in the health and wellness genetics sector, one of the issues we identified was that the existing analytics setup captured broad funnel stages but missed the [fine-grained interactions that would have explained](https://weareaffective.com/learning-centre/what-a-behavioural-retrospective-looks-like-three-months-after-launch) where and why users were hesitating between receiving their results and engaging with the recommendations. The numbers looked fine at a funnel level. The detail that would have explained the drop-off simply was not being recorded. ## Attribution models and why they disagree on credit Attribution is the process of deciding which marketing touchpoint gets credit for an install or a purchase. The challenge is that a user rarely touches only one thing before converting. They see an ad, search organically, click a social post, and then install. Different platforms assign credit to different points in that sequence, using different rules, and they do not tell each other what they decided. #### Last-click versus algorithmic models Last-click attribution gives all the credit to the final touchpoint before conversion. An ad platform running last-click will claim every install where its ad was the last thing a user saw. If two ad platforms were both running ads and a user saw both before installing, both platforms may claim the same install as theirs. Your installs count doubles on paper. Your actual installs did not. #### Privacy constraints compound the problem On iOS, Apple's App Tracking Transparency framework means a significant portion of users cannot be tracked individually at all. [Cometly](https://www.cometly.com/post/conversion-tracking-for-app-installs) puts global ATT opt-in rates at around 25 to 30 per cent, with variation by category and region. For the users who do not opt in, Apple's SKAdNetwork provides aggregate conversion data rather than individual-level tracking, with a reporting delay of 24 to 72 hours and only 64 possible conversion values to represent all post-install behaviour. That is a significant compression of information, and different platforms model the resulting gaps in different ways, producing different numbers from the same underlying reality. Never reconcile attribution figures by trying to make two platforms agree on the same number. Reconcile them by understanding what each platform is claiming credit for, and whether that claim is methodologically sound for the decision you are making. ## Sampling, filtering, and data thresholds Some platforms do not process every event. When traffic volumes are high enough, they sample: they process a percentage of events and extrapolate the totals. If one platform is sampling at 80 per cent and another is processing 100 per cent of events, you will see different numbers even if the underlying events fired identically. Google Analytics 4, in its free tier, applies sampling in some report types. The sampled nature of the result is often indicated in the interface, but it is easy to miss if you are pulling numbers quickly. The result looks like a precise figure because it is expressed as a whole number, but it is an estimate. Comparing an estimate from one platform against a full count from another is not a fair comparison. Filtering introduces a separate layer of divergence. Analytics platforms allow IP filtering, bot filtering, and test traffic exclusions. If those filters are configured differently across platforms, or if one platform has a filter the other does not, the same traffic generates different totals. We have seen setups where internal team traffic was excluded from one platform and not from another, inflating one set of numbers in a way that made the product look more active than it was. Document every filter applied in every platform in one place. If you cannot list them from memory, you cannot know whether cross-platform comparisons are valid. ## When measurement decisions made at launch become permanent problems Analytics setups get configured early, often under time pressure, and then rarely revisited. The decisions made in the first week of a product's life tend to stay in place for years. If those decisions were made without a clear measurement plan, the accumulated debt compounds. On the social football platform we worked on, the decision to launch iOS-only had consequences that rippled through the analytics picture as well as the business model. Because the target audience skewed younger and disproportionately towards Android, the iOS-only launch meant day-one adoption was significantly lower than it would have been with both platforms live. The analytics data that came back from that launch reflected an audience that was not fully representative of the product's intended users, which made it harder to draw reliable conclusions about how those users were actually behaving. Measurement decisions made at launch also include [what you decide not to track](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one). A product team that sets up only page views and session counts at launch is making a choice, even if it does not feel like one. Eighteen months later, when you want to understand whether users who engage with a specific feature retain at a higher rate, the data is not there. You cannot go back and recapture it. The decision to under-instrument at launch is a decision you live with. The instinct is often to avoid complexity early and add more tracking later. The reality is that adding tracking later means backfilling nothing, and the questions you most want to answer are usually the ones that require longitudinal data you never collected. ## How to audit your setup and establish a single source of truth Establishing a single source of truth does not mean making all platforms agree. It means deciding, deliberately, which platform you trust for which type of question, and why. Different tools answer different questions well. The goal is clarity about what each one is for. #### Start with a measurement plan A measurement plan lists every question the product team needs to answer, maps each question to the events and metrics that would answer it, and specifies which platform holds that data. Without this, analytics setups grow by accretion: someone adds a tool, someone adds events, and three years later no one knows what is being measured, by what, or whether it still matches the original intent. 1. List the ten decisions you make most often about the product. 2. For each decision, name the metric you use to inform it. 3. Trace that metric back to the events that produce it. 4. Check whether those events are actually firing correctly. 5. Verify that the platform calculating the metric defines its terms the same way you do. On a practical level, cross-platform discrepancies of up to around 10 to 15 per cent are normal and expected given the differences in session definitions, sampling, and attribution models. Discrepancies larger than that usually point to a specific configuration problem: a filter applied in one place and not another, an SDK that was not updated after a platform policy change, or events that fire on the client but fail to reach the server at a meaningful rate. The question we come back to with every analytics audit is whether the numbers are fit for the decisions being made from them. A figure does not need to be perfect to be useful. It needs to be understood well enough that you know what it is telling you and what it is not. ## Conclusion Analytics discrepancies across platforms are a sign that different systems are measuring different things, often with different methods, under different constraints. The gap becomes a problem when teams treat a number from one platform as ground truth and make decisions accordingly, without knowing what that number is actually counting. The deeper issue is that analytics data, even when it is working correctly, tends to tell you what happened rather than why. Session counts, install figures, attribution reports: these are all downstream outputs of user behaviour, and they are several layers removed from the emotional and psychological state driving that behaviour. A user who backs out of a screen three times before completing a purchase shows up in the funnel data as a conversion. The hesitation is invisible unless you built the instrumentation to see it. Getting the infrastructure right matters, and so does knowing what the infrastructure cannot tell you. Numbers are easier to collect than meaning, and the most common analytics problem is over-confidence in what any single platform is actually revealing. If your analytics setup is producing numbers you cannot fully explain, or if you are making product decisions from data you are not sure you trust, [let's talk about your measurement setup](https://weareaffective.com/get-started). ## Frequently Asked Questions Why do my session counts differ between analytics platforms? Different platforms define sessions using different timeout rules. One platform might end a session after 15 minutes of inactivity whilst another waits 30 minutes, meaning a single user visit can be counted as one session in one tool and two in another. Why does my ad platform show different install numbers to my mobile measurement partner? Ad platforms are built to attribute installs back to advertising spend, whilst analytics platforms are built to track behaviour inside the product. Because they are asking different questions and collecting different data, their totals will rarely align. Can privacy and consent settings affect my analytics figures? Yes, significantly. When a user does not consent to tracking, different platforms handle the missing data in different ways. Some exclude that user entirely, whilst others model the gap with estimates, so the same user can be counted differently depending on which tool is doing the reporting. Is a large discrepancy between platforms a sign that something is broken? Not necessarily broken, but it is a sign of a measurement architecture problem. Discrepancies are common across app products and often come down to how platforms were set up, not a fault in the tools themselves. How does timing affect the numbers across different platforms? Some platforms record an event the moment it happens on the device, whilst others record it only when the data reaches the server. On a poor connection, those two moments can be minutes apart, and in some cases the server never receives the data at all. Should I be trying to make all my analytics platforms show the same numbers? Chasing perfect alignment across platforms is rarely the right goal. It is more useful to understand what each platform is actually measuring and whether that measurement is serving the specific decisions you need to make. What are the most common causes of analytics discrepancies? The three main causes are different event definitions, different data collection methods, and different rules about what counts as a valid data point. These differences exist because each platform was built by a different team for a different purpose. Could a configuration change in my analytics tool cause a discrepancy I am not aware of? Yes, and this is a common issue. If someone on the team changed a setting such as the session timeout threshold and did not document it, you could be comparing data collected under different rules without realising it. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.