Discrepancy between Engagement Time Msec Firebase Dashboard Vs BigQuery Data - firebase

I use BigQuery to get data from Firebase, and I'm having some issues with data accuracy. Figures I get from the data in BigQuery are not matching the ones on Firebase dashboard.
I recently understood that Firebase does not look at all users, instead it considers only active users. So now I have filtered for active users by putting a filter for engagement_time_msec>0. My active users number is matching up with Firebase dashboard now (just 1-2 digits difference occassionally).
But my main problem is with the average engagement time!
Firebase (and GA for Firebase) shows average engagement time metric under engagement overview. When you hover over it, it gives this definition.
"Average Engagement Time per active user for the time period selected"
However, when I get data through BigQuery and calculate this manually, my numbers are off.
I am calculating Active Users as Distinctcount of user_psuedo_ID where engagement time>0, and engagement time is being summed up where event name = user_engagement. (I have converted engagement time msec to mins)
Average engagement time = SUM(Engagement time mins)/Active Users
This should give me an average engagement time per active user, but this figure doesn't match the one in Firebase console. I have tried so many methods, and I fail to understand what Firebase is doing at the back end to come up with these values.
P.s: I have also tried summing up engagement time without a condition on event name and that gives me an even greater average, making the difference between it and Firebase even bigger.
Please help!!

Related

Google Analytics realtime shows mismatched data

which one of the following is correct in the Google Analytics dashboard?
The "Right Now" or the "Metric Total"? how many users I actually have??
It is a bug of Google Analytics real time report.
It has been observed that the inflated number of active users, after a more or less expanded period of time, returns to normal, and then eventually resumes the anomalous count and subsequently re-enters the ranks again.
What probably happens is an accumulation of the number of active users over time without, however, the total being decreased once the user is no longer in that state.
https://www.analyticstraps.com/bug-numero-anomalo-di-utenti-attivi-in-tempo-reale/

Firebase inapp messaging showing only one time even after setting per day one time option as frequency limit

I have created one campaign by showing a inapp messaging popup to user while they do particular event. While scheduling the campaign i have set frequency limit as per day one time as option for frequency limit. But it shows only one time to user, it is not showing on the next day.
I saw Firebase inapp messaging is beta version, but not sure which all functionalities will work or not properly. Any ideas or comments on this?

Discrepancy in Daily user engagement between Firebase Analytics dashboard and BigQuery

I'm trying to develop a query against Firebase Analytics data linked to BigQuery to reproduce the "Daily user engagement" graph from the Firebase Analytics dashboard (to include in a Google Data Studio report).
According to Firebase Help documentation, Daily user engagement is defined as "Average daily engagement per user for the date range, including the fluctuation by percentage from the previous date range." So, my attempt is to sum the engagement_time_msec (the additional engagement time (ms) since the last user_engagement event according to https://support.google.com/firebase/answer/7061705?hl=en) for user_engagement events, divided by the count of users (identified by user_dim.app_info.app_instance_id) per day. The query looks like this:
SELECT ((total_engagement_time_msec / 1000) / users) as average_engagement_time_sec, date FROM
(SELECT
SUM(params.value.int_value) as total_engagement_time_msec,
COUNT(DISTINCT(user_dim.app_info.app_instance_id)) as users,
e.date
FROM `com_artermobilize_alertable_IOS.app_events_*`, UNNEST(event_dim) as e, UNNEST(e.params) as params
WHERE e.name = 'user_engagement'
AND params.key = 'engagement_time_msec'
GROUP BY e.date)
ORDER BY date desc
The results are close to what's displayed in the Firebase console graph of Daily user engagement, but the values from my query are consistently a few seconds higher (BigQuery results shown here on the left, Firebase Console graph values on the right).
To note, we're not setting user_dim.user_id and not using IDFA, so my understanding is the correct/only way to count "users" is the user_dim.app_info.app_instance_id, and I imagine the same would be true for the Firebase console.
Can anyone suggest what might be different between how I'm determining the average engagement time from BigQuery, and how that's being determined in the Firebase console graph?
To note, I've seen a similar question posed here, but I don't believe the suggested answer applies for my query since 1) the discrepancies are present over multiple days, 2) I'm already querying for user_engagement events and 3) the event date being used in the query is stated to be based on the registered timezone of your app (according to this).

Firebase Analytics User time for performing actions

I would like to measure how long (on average) users are performing certain actions in my app. For example, the time it takes for a user to add an item to the cart till the time to purchase the items. Can Firebase analytics track these time differences? If so, how can I get a report out of it or add it to my dashboard.
I know this can be done using traces in Performance monitoring, but I want to know these time differences not to troubleshoot performance issues but rather behavioral issues for my users.

Why are Google Analytics Dashboard statistics changing?

Background:
I have a Google Analytics account using which I am tracking user activity for web and mobile app. After logging into your account and choosing the web property and the corresponding view, you generally see a dashboard with quick stats like Pageviews, Users, Sessions, Pages/Sessions, Avg. Session Duration, Bounce Rate and percentage of new sessions. You can change the time period (from the top right area of the Dashboard) to get the same stats for that period.
Problem:
Last week, I was interested in the three main stats: Page views, Users and Sessions for a particular day - say, day A. The dashboard showed the following stats:
Pageviews - 1,660,137
Users - 496,068
Sessions - 983,549
This report was based on 100% of sessions.
I go back to the dashboard TODAY and check the same stats for the same day A. Here's what I saw:
Pageviews - 1,660,137
Users - 511,071
Sessions - 1,005,517
This report is also based on 100% of sessions.
Nothing was changed in the tracking code for the web and mobile app. Could someone explain why I have this difference in the stats? Is this normal?
They need some time to update the system, otherwise their system would overwhelm
When you first create a profile it can take up to 48 -72 hours for it to start showing data.
After that time data will appear instantly in the Real-time reports.
Standard reports take longer to finish processing. You need to remember the amount of data that is being processed. Some of the data may appear in the standard reports after a few hours. The numbers have not completed processing for at least 24 hours, so anything you look at then will not be accurate.
When checking Google Analytics never look at todays or yesterdays numbers in the standards reports, if you want accurate information. Things get even more confusing when you consider time zones. When exactly is it yesterday? I have noticed numbers changing as far back as 48 hours. But Google Says in there documentation 24 hours. I am looking for the link in the documentation will post it when I find it.
Found it: Data Limits
Data processing latency
Processing latency is 24-48 hours. Standard accounts that send more
than 200,000 sessions per day to Google Analytics will result in the
reports being refreshed only once a day. This can delay updates to
reports and metrics for up to two days. To restore intra-day
processing, reduce the number of sessions you send to < 200,000 per
day. For Premium accounts, this limit is extended to 2 billion hits
per month.
So try doing the same thing again today but check your last day being Monday. When you check again next week the numbers should be correct.

Resources