How to Separate Test Users from Real Users in Firebase Analytics

Nobody sets out to count their own phone as a user. It happens because Firebase has no idea who is testing: a debug build on your desk, a TestFlight build on a colleague's phone and a paying customer all send the same first_open, session_start and screen_view events.

What test traffic looks like in the data

• New users jump on release days and fall back the next day
• A handful of users with an enormous number of events each
• Activity on an app version that was never published to the store
• Users concentrated in one city — yours — during working hours
• Custom purchase or subscription events with no matching sale in the store (GA4 ignores sandbox purchases for in_app_purchase, but your own events are not filtered)

Active users (month)                    410
Active on 1.3.0-beta (never released)    62
Events per user, top 5 users          2,900
Events per user, everyone else           38

At least 15% of the "users" are testing,
and five devices produce about half of all events.

Where it comes from

Keeping it out from now on

1. 1

   Give development builds their own Firebase app

   Register the debug or staging build — with its own bundle ID or application ID — in a separate Firebase project, so its events never land in the production property.

2. 2

   Turn Analytics off in debug builds

   If you keep a single Firebase app, disable collection in debug builds with setAnalyticsCollectionEnabled(false), or with FIREBASE_ANALYTICS_COLLECTION_ENABLED in Info.plist and firebase_analytics_collection_enabled in AndroidManifest.xml, and enable it only for release.

3. 3

   Add a developer traffic filter in GA4

   Under Admin → Data collection and modification → Data filters, create a developer traffic filter to exclude events from devices in debug mode. Leave it in Testing first, check the "Test data filter name" dimension in an exploration, then make it Active.

4. 4

   Detect Firebase Test Lab on Android

   Test Lab devices set a system setting called firebase.test.lab to "true". Check it at startup and switch Analytics collection off when it is set.

5. 5

   Mark internal testers on release builds

   For people testing the store build, set a user property such as tester = true from a hidden settings switch. It does not remove their data, but it lets you exclude them in explorations and comparisons.

Separating data that is already mixed

Past data cannot be filtered after the fact, but you can read around it. In an exploration, add a segment or comparison that excludes:

• App versions that were never released to the store
• The tester user property, from the day you started setting it
• Device models or locations only your team uses — as a last resort, because real users can match them too

Note the exclusion next to any number you share. A user count that quietly changed definition halfway through a quarter is worse than one that openly includes testing.

What goes wrong if you leave it mixed

• Early retention looks far better than it is, because testers open the app every day
• Funnels complete at impossible rates, because testers go straight to the feature they are checking
• A release-day spike reads as a successful launch
• High event volume from a few test devices hides a real event that stopped firing for customers

How this looks in Appnaly

Appnaly reads the processed data in your GA4 property, so a filter you activate in GA4 applies to what Appnaly shows from then on, and test traffic you did not filter is counted like any other user. Its checks wait for a minimum number of users before commenting, which stops a few test devices from raising an alert on their own — but it cannot tell a tester from a customer. That separation has to happen at the source.