I'm using Google Analytics in an Android Application. I have registered few events using EventBuilder. For me it took almost a day to show that events in Google Analytics web portal. But in iOS it shows the event builder hits within 10 to 15 minutes of time. How its happening? Am I missing anything?
EDIT I'm not talking about RealTime tracker. In that we can see the traffics and locations. I'm talking about Events.
Dispatch settings
There are different default settings for Android and iOS. It sends event in batch mode once time in 30 minutes (or different time frame).
Check out documentation
https://developers.google.com/analytics/devguides/collection/android/v4/dispatch
https://developers.google.com/analytics/devguides/collection/ios/v3/dispatch?hl=cs
Website usage
Time required for data processing depends on amount of hits sended to UA account. Full data-processing usually tooks between 4 hours to 1 day. So you don't miss anything.
Some data are accessible faster, like events, default dimensions, etc., but custom dimensions and dimension breakdowns tooks longer time.
Thanks for your help. I was doing a silly mistake while viewing report. By default Analytics will be show data till yesterday. By changing the date to today at Right top corner in portal displayed today's events. Minimum time it took to display the data is 15 to 30 minutes. May be it might vary depends on the number of hits.
Related
We started to implement manual_screen_view for Android in June 2021. Faced problem about double screen_view events. It was fixed and released around the 12th of July. The last release before the problem appeared was on the 16th of August.
Everything was fine until the 26th of August. Since then our engagement times started to rise significantly and way out of proportion. As an example, we've highlighted a screen called "Logo intro". This is Splash screen and takes around 5 seconds before moving on to the next screen. Why is the average engagement time 1m 33s and then varies from 6mins to 40 sec.? There are way more examples, but this is a nice illustration.
graphic
table
We spoke with Firebase support and sent them screenshots from DebugView. Everything is perfectly fine with events and params. "Logo Intro" event is sent, then "Watch" event with previous "Logo Intro" and engagement_time_msec is around 6 second.
log intro event
watch event
watch event previous screen
watch event engagement_time_msec
We try to contact with Google Analytics support but haven't get any answer yet.
It is very important to understand this metric "Average engagement time". I have start to understand that metric when I was looking for how it is counted. In GA4 interface the note in question mark is very sad. This is from docs:
Average engagement time is the sum of user engagement durations divided by the number of active users. This metric shows the average engagement time per user. Google Analytics also shows the average engagement time per session, which is the sum of user engagement durations divided by the number of sessions. (https://support.google.com/analytics/answer/11109416)
In other words, the metric doesn't say what is average time spent in the mobile app for one session. It says how long on the average the users stays in your mobile app in the time period. E.g it says this "Between 1.9.2021 and 31.12.2021 users spend with your app 6 min on average. They dedicated 6mins of their life on average with your mobile app between the time period"
Rather than looking at implementation, which seems okay to me, ask some questions:
Have you released any new cool feature, that your users were looking forward to?
What about your average session duration, did it change overtime? If so, how and explore why.
In mixpanel is it possible to track then total number of hours my application used per day. I am having Shift in and Shift out option in my application but what i need is to track the Consolidated
time of my application usage per day.
In theory yes, but it very much depends on the events you have.
If for example you have a beginSession and an endSession event tracked every time the users opens and closes the app, respectively, you can simply find all of a user's events of these kind and compute the "live time" between them.
Mixpanel have a new(ish) application in their we console for running map-reduce style JQL queries on your data set, you could script something like this. Or if you prefer, you can plug into their export API and pull all your events for a users, and run the calculations. If you have lots of events you could even try to heuristically determine "active time" based on idle time between events?
However, I believe you are more likely asking if this is something that Mixpanel tracks for you and will give you for free, I do not believe this is the case.
If you have a rundown of your tracking structure, I may be able to provide more specific advise?
Google Analytics (using iOS SDK version 3.14 and it's built in sessions tracking) is reporting a significant percentage of app sessions as 1 second.
Maybe users are launching an app to view a page and (effectively) then instantly leaving the app, but that seems unlikely (that it should continue as the top use case. You think such users would stop using or uninstall.)
Initially I suspected this was related to "background fetch" but when I look at a prior incarnation of the application (that did not have background fetch enabled or used) I still see these (seemingly) bogus sessions also. That application (pre iOS9) had no universal links.
The (obvious) reason I don't want to see these sessions (especially if from automated action not user action) is it removes all value of "user behavior"; i.e. loyalty, recency and skews "average session length". These are the main reasons I want to use GA, i.e. to see if folks are using it more/valuing it more.
My questions:
What might these sessions be caused by? Are they bogus?
If bogus, how can I stop them?
Can I ensure new "background fetch" code doesn't somehow trigger them?
Some things I've considered / looked into:
I am seeing a similarly large set of "short sessions" on an Android application (this application's peer) and again with extremely high numbers. I've been wondering if this was a result of a web searches & site links, with those site links automatically loading the app, and the a (very) quick user "move on". (Universal linking is something the new iOS application is working towards, but doesn't see much of yet.) Given it is not that on iOS I am starting to doubt that it is that on Android.
There is a "optOut" option on GA. That feels like a sledgehammer solution to this walnut problem. It is also a persistent setting, which feels risky to use for a transient situation. I could attempt to toggle it at applicationDidEnterBackground / applicationDidBecomeActive (and will if it is deemed the solution) but worry it could have negative side-effects.
One can have multiple trackers. I am planning to attempt one for human foreground activity and one for background operations (which might allow time /event tracking when in background, w/o impacting human user tracking numbers. That said, I don't know / believe this is the cause of the bogus sessions. )
One can manage sessions manually and also customize the sessions interval timeout, but I don't see why this application should need any custom behavior. It is a normal application.
The application isn't reporting crash totals to match these numbers; it is a generally well liked 4/5 star app w/ few crashes.
Google Analytics measures duration as the time between interactions.
This means that in order to be able to measure duration, Google Analytics needs a minimum of two interactions to measure between. But they still need to collect data on one-interaction Sessions, and from the reporting perspective, every session starts the same - with an interaction. It's just that some don't go any further. To account for this, Google Analytics keeps a running total of Session duration.
When a user first interacts, that total is set to 0.
31 seconds later, they interact again. That total is updated to 31 seconds.
10 seconds later, they interact a third time. Total is now 41 seconds.
35 seconds later, they quit. This is not measurable, and hence not an interaction. Google Analytics waits faithfully for 30 minutes, before deciding that they aren't coming back.
Your total Session Duration is recorded as 41 seconds, as that was the last point at which you checked in. There's no way of knowing that you stuck around an extra 35 seconds.
This isn't an issue if you looked at 4 or 5 pages, but if you had only looked at 1 page, we would have been left with a Session Duration of 0. This is what happens with every 'Bounce'; every Session with only one interaction is measured '0' seconds long.
Throw into that a handful of people who interacted 8 or 9 seconds later, and you have an average of 1 second for the '0 - 10' category.
Turns out the problem was inside the Google Analytics SDK. A new version has been posted:
[Google Analytics SDK issue with short sessions][1]
So I'm writing a fitness application for android. I'm using the Google fit API to count the steps.
I'm using the Recording API to count the steps when the app is in the background. Once the app is in the foreground I'm fetching the steps count with the History API to show it on the screen.
What happens is that the count is not correct. There is a delay until you get the correct and updated count.
To be more specific no data is being lost. I guess that the Recording API is updating with a specific time interval.
I'm also using the Sensors API to show the real count on my Activity when it is running. So what happens is that for example you see 300 steps in your screen (real time data). Close the app, open it again and then for the next minute you see 250 steps for example. And only after some time the History API catches the correct data and shows 300 again.
Has anyone found a way through this issue?
Thank you and sorry for the long text!
Your are right. Recording API takes some time for update. There is two way that came to my mind.
always get steps by History API. I mean when activity is running just increase the checking rate of History API. Advantage of this is though it is taking some time, user always the same count.
another way is bit more complex. store your Sensors Step count with time & apply some logic whether or not you need to add & show this to user.
Sorry for the long text.
I was wondering about dispatch while implementing the new v2 of Google Analytics for my Android app.
If the default period is 30 minutes, and the data needs to be reported in like 24 hours or the data will not be processed, how do apps fare when they are only used like 2 times a week and for a duration of like 5 minutes?
From what I have read I can't seem to find that the app will be staying in the background waiting till the time is up and start submitting? Any insights? Otherwise I'll have to switch to manual dispatch.
I had the same question (though with the v1 GA, I think the issue is the same).
I chose to make the dispatch explicit. I try and use the same scale timeout to trigger the dispatch in the background (every 30 minutes), but I do a dispatch on certain events (like start and suspend, and when the app user hits certain internal milestones). Note that I just went with this for the same reasons you're thinking. I didn't find anything more definitive or do any tests that verified the behavior ...
An additional reason to do this to have a bit more control over the thread that is issuing the dispatch call (instead of just triggering as a side-effect of whichever thread is pushing some new stats into GA).
I don't think there is a 24h timeout on data stored locally that hasn't been pushed. In fact, I thought the problem was that data would get timestamped with its push time, not its actually recording time. But I'm not confident about this either way ...