A consumer health and fitness app
A subscription app with an established mobile audience, checked as part of a wider review before a marketing push. Company name, domain and exact figures have been removed. What’s below is real.
A subscription app with an established mobile audience, checked as part of a wider review before a marketing push. Company name, domain and exact figures have been removed. What’s below is real.
The analytics property had no web data stream connected to it at all. Every session recorded was coming from the app. If the business had a website, or launched one, it would collect zero visitor data on it until a stream was actually added. Web performance, campaign landing pages and marketing results from anything outside the app were simply invisible.
None of the sessions in the audit window carried any information about where the user had come from. Search, social, paid, word of mouth, all of it looked identical: unattributed. That makes it impossible to tell which marketing activity is actually driving installs and engagement, which for a subscription app is close to the most important question there is.
The default two-month retention window was still in place. Once that window passes, the data is gone permanently, no comparing this quarter to last quarter, no seasonal pattern, no long-term growth trend. For an app with subscription revenue, that's exactly the kind of comparison the business would eventually want and no longer be able to run.
The event tracking subscription starts was recording at a fraction of the volume of closely related events happening in the same funnel. That gap doesn't reflect real user behaviour, it's the signature of a tracking break, most likely in one specific part of the purchase flow. Until it's fixed, reported subscription numbers are understated, possibly significantly.
A different in-app action was also recording close to zero, while the equivalent 'completed' version of that same action was firing at normal volume. A near-zero rate on an action users take often enough to matter is unlikely to be real: it's a second, smaller version of the same class of problem as the subscription event above.
Staff and developers using the app themselves weren't being excluded from analytics. Their sessions were counted alongside genuine users, inflating engagement figures by an amount that's hard to quantify without the filter in place to separate them out.
A setting that lets analytics recognise the same person across their phone and tablet was disabled. Without it, one real user on two devices is counted as two separate users, and the demographic data that comes with this feature isn't available either.
Several data-sharing options were active, covering platform support access, sales representative access, and industry benchmarking. None of this is inherently a problem, but it needs to be clearly disclosed in the app's privacy policy, and that disclosure hadn't been confirmed.
✓Core in-app behaviour, from onboarding through to paywall views, was tracking consistently.
✓Traffic was clean: no bot activity, self-referrals or payment-gateway noise distorting the numbers.
✓The attribution model was set to data-driven, ready to fairly distribute credit once source data actually starts arriving.
✓Currency and regional settings were correctly configured for the business.
This came from a normal two-minute audit, no manual digging. Your first audit is free.
Run a free audit →Traffic showing up with no source is one of the most common GA4 symptoms, the unassigned traffic guide covers the causes. More real audits are at Case studies.
It usually comes down to how the install and open events are wired up. If the SDK isn't correctly passing through the referral or campaign data attached to an install (from an app store listing, an ad network, or a deferred deep link), GA4 has nothing to attribute the session to, and it records as unattributed for every session, not just some.
Compare it against a related event in the same flow. If 'exercise completed' fires 90 times and 'exercise skipped' fires once in the same window, a near-zero skip rate isn't realistic user behaviour, it's a strong signal the skip event itself isn't wired up correctly, rather than evidence that nobody skips exercises.
They can, GA4 supports multiple data streams (web and app) under one property specifically for this. The value is a combined view of a user's journey across both. It only works once both streams are actually connected and sending data, which wasn't the case here.