But realtime traffic users are still appearing and latest release shows that users are adopting the new version, so clearly it's still reporting correctly? But all of the data dropped to 0 overnight. Any ideas?
Related
Non-technical here, just learning Google Analytics and recently dwelling with app analytics for a client, where their developers didn't seem very skilled in Firebase and can't help me understand this issue - can you help?
I'm trying to understand how many raw downloads in Play Console and App Store Connect are actually users that launch the app, by looking at the first_open event. However, I'm aware that iOS users get a pop-up asking if they allow tracking (or maybe another pop-up similar?).
---> Question: If they do not allow tracking on this pop-up, would our Firebase still get data about these users launching the app? What about other events that were set-up with Firebase, such as initiating a booking?
PS: Also, now that you're here: App Store Connect is displaying 23 Total downloads (counting re-installs) for a given month in Country A, but Firebase is displaying 49 first_open events for the same country in the exact same month! How's this even possible, if a first_open only fires at least once per install, or doesn't even fire if the user never opens?
I was wondering if first_open event still includes app updates. I have read that it has been counting previously but should be changed soon. However, I could not be sure that if it is changed and not counting app updates anymore.
From documentation, first_open:
the first time a user launches an app after installing or
re-installing it.
This event is not triggered when a user downloads the app onto a
device, but instead when he or she first uses it. To see raw download
numbers, look in Google Play Developer Console or in iTunesConnect.
The last important distinction is that when existing users migrate to the new version of your app which includes Firebase, they will log a first_open event. And so, even though they are not new users, they log a first_open.
In other words, it gets triggered on an update, only if the previous version did not previously have Firebase.
Does anyone know why are users with older app version which doesn't have new experiment in config counted as part of experiment? This is scenario:
I have app version 1 with experiment A with activation event for new users new_install
Then I create app version 2 and new experiment B with same activation event for new users new_install . I start experiment on firebase console.
Now I am waiting for app to be approved by apple appstore or starting rollout on android. Even before any user gets app version 2 I already see many users showing in experiment B on firebase console.
I would expect that users with app version 1 will be not part of experiment because remote config doesn't have default value for experiment B in app version 1 but it seems that because users are still installing app version 1 and new_install event is fired, they are counted as part of experiment B event when it's not in app version 1.
Is it feature? Bug? I am supposed to create custom activation event for every experiment?
That's actually easy to prevent - and good practice for A/B testing in general - just target users with at least given app version. Usually it will be version since you have remote config properly set up.
I would not rely on Firebase including or excluding users if they don't have remote config parameter. Today it might work differently than how it's going to work in a month. If there is no guarantee, just make sure you are targeting users who are properly set up.
I have added performance monitoring to iOS project.
The automatic traces as well as custom traces appear in the dashboard. Also the aggregated network calls are visible in network tab.
But I am not able to see details of trace samples. If I click 'see sessions' a message saying to update the Firebase Sdk is displayed.
I am using Firebase SDK 5.13.0, which is the latest stable SDK.
Note that Performance Monitoring data usually displays within 12 hours of testing your app.
Unfortunately, based on their getting started docs, they mentioned that the data takes up to 12 hours to be displayed. So, we will just have to wait for it to appear.
On firebases documentation it says:
Even with persistence enabled, transactions are not persisted across
app restarts. So you cannot rely on transactions done offline being
committed to your Firebase Realtime Database. To provide the best user
experience, your app should show that a transaction has not been saved
into your Firebase Realtime Database yet, or make sure your app
remembers them manually and executes them again after an app restart.
https://firebase.google.com/docs/database/ios/offline-capabilities
Yet I went into my App with an iphone 6 simulator, while offline, changed some data, then switched to iphone 7 simulator to make sure 6 simulator stopped, and then went back to the 6 simulator with my internet connection now turned on, and the change I had previously made while offline synced no problem.
What problem does this documentation point to that I need to take into account. I can't afford to make something where users are frustrated with changes they thought saved getting lost, but to my eyes there is no issue?
I think the key word there is "Transactions" which are a very specific kind of write operation. (See description here).
If you're just doing a regular ol' write to the database and not sticking it inside a transaction block, your write should be saved, even across an app restart.