I am using Firebase for just Analytics. I implemented yesterday Firebase successfully. In fact I did not get any runtime error but I noticed in Logcat.
After 2-3 seconds, this message is seen in Logcat.
V/FA: Inactivity, disconnecting from the service
Analytics data is very important for me. As a result, I want to make sure this Analytics data is completely correct. I don't want inaccurate data when it comes to analytics.
As you know, in Firebase Analytics session duration is important. If firebase is disconnected from the service, then session duration probably won't calculated correctly.
Finally, What do you think about this situation?
Should I continue to suspect? If so, how can I solve this problem?
or
Can we say no problem? Session duration and other metrics will be calculated perfectly.
That's just a verbose log message. It doesn't mean that you're losing any data.
If you have concerns about the way any Firebase SDKs are working, please contact Firebase support for help.
V/FA is Firebase info (verbose)
A session expires when there 30 minutes by default that none of the app's activities is the current activity. If the user exits the app for a shorter period than the session timeout and then restarts it, the session continues. If the user exits the app for longer than the session timeout, then the session ends.
doc , check setSessionTimeoutDuration
Related
Like google analytics has setSessionimeout where all the vents are grouped together and at the end events are dispatched.Is there anything similar for Flurry analytics,As flurry hits the flurry server instantly,I want it to bunch together all the events in a session (Suppose of 30 min ) and then disptach them.
It is not possible to force the Flurry SDK to report analytics session data at specified time. A Flurry session is defined by
"If the app pauses or moves to the background for more than 10 seconds, the next time the app runs, Flurry agent will automatically create a new session and end the previous session. Otherwise, Flurry agent will continue the same session. This can be updated via the setSessionContinueSeconds method. If the app is terminated, a new session will be created when the app runs again."
The only way to control the session reporting is through the app lifecycle. But generally I would expect all of the events to be reported in a single batch per session. You can observe this behavior by watching the event log in the Flurry UI as the app is closed and/or reopened.
setSessionContinueSeconds is really only useful for cases where you would want the Flurry session to continue for longer than 10 seconds while the app is in the background. For instance an app that plays music in the background.
We've just started using Firebase Analytics and have exported all the events to BigQuery. While processing the "app_remove" event we noticed an odd thing. Sometimes our servers record activity from the app after the timestamp of the app_remove event (i.e. event_dim.timestamp_micros).
While running, the app periodically contacts our servers and we then record the UTC time of that request. Sometimes the latest activity time is higher than the timestamp of app_remove event. The largest time difference we've noticed is 12h 23m 17s.
Each app instance gets a unique certificate that it uses when authenticating with servers so if an uninstall completes it's impossible to record any new calls for that app instance, even if you reinstall. After reinstall a new certificate is issued and the activity time would be recorded on a different row in the db.
How could this occur? Are the timestamps of app_remove set by the client so it could be caused an incorrect clock on the user's phone? How else could it occur?
The event_dim.timestamp_micros is the UTC time that the event was logged on the client based on the device time, and so it is indeed subject to errant clock times on the device.
I have read the GCM(Google Cloud Messaging) guide. It is written that on failure of registration client to GCM, we should retry the registration process. Google advices about exponential back-off: "the client app should wait twice the previous amount of time before retrying".
Why should the client app wait twice the previous amount of time before retrying?
Let's think this scenario;
My client downloaded the app.
Client didn't open the app until the night.
Client intended to open the app before sleep.
The app was started and the client used the offline features.
Client didn't have internet connection in this time.
So, my app would try to register the client to GCM all night until the client would have internet, exponential back-off time reached some hours or days.
So, isn't it a bad practice? Why does google advice this? I think, developer should set a maximum(limit) time to exponential back-off time, at least.
GCM Guide:
https://developers.google.com/cloud-messaging/registration
As par link you gave, I found below sub link.
ExponentialBackOff
Please read it to understand the process better.
You try certain times(or till reaches max interval between two requests), and it needs to stop there. Then it will be in cycle again when user uses the app or you gets Internet_state_change event.
Example from the link :-
The default retry_interval is .5 seconds, default randomization_factor is 0.5, default multiplier is 1.5 and the default max_interval is 1 minute. For 10 tries the sequence will be (values in seconds) and assuming we go over the max_elapsed_time on the 10th try:
I try to send an event just before disabling the Google analytics in android. But, the event doesn't show up in the real-time GA console.
tracker.send(new HitBuilders.EventBuilder()
.setCategory(category)
.setAction(action)
.setLabel(label)
.build());
//disable GA
GoogleAnalytics.getInstance(this).setAppOptOut(true);
Thanks for any advice.
If you enable Google Analytics logging you can see that when you call setAppOptOut(true) Google Analytics will clear all queued hits since it last sent hits to the Google Analytics servers:
V/GAV4﹕ Thread[GAThread,5,main]: clearHits called
As you noticed yourself dispatchLocalHits() doesn't help since it does nothing with Google Play Services installed. What you need to do is to wait with calling setAppOptOut(true) until after your hits have been dispatched. However as you don't know when the hits are dispatched it's not an easy thing to do.
You can specify what dispatch period your app should have with the ga_dispatchPeriod setting (with the default being 30 minutes). If you wait for longer than the configured dispatch period you should be fairly certain that your event has been sent, however this is not guaranteed since GA may wait with sending the data even longer if you do not have any network connection at the moment.
If you would take this approach you must make sure that the wait works across sessions since Google Play services is a separate service on the device and it will hold on to your hits even if you restart your app. So opting out on next startup of your app will not work either.
However waiting with opting out for more than 30 minutes might not be very nice to your users since that gives a lot of time for data to be gathered and submitted after the user thinks that they have opted out.
A better approach might be to have your own internal Google Analytics wrapper class that all parts of your app calls to report data. Then each reporting method could have a check if Google Analytics is enabled, never call any of the real Google Analytics methods.
This way you can be sure that you final event is sent to Google Analytics while no more events are sent after that even though you don't call setAppOptOut(true).
Do note that this only works if you do not rely on any automatic tracking like automatic reporting of uncaught exceptions or automatic screen measurement.
I need to start and to stop a session at a specific hour.
In official documentation I have found only that I can start a new session :
// Called after a user successfully signs in to your app.
private void onSignIn() {
... // The rest of your onSignIn() code.
myTracker.setStartSession(true); // Where myTracker is an instance of Tracker.
myTracker.sendEvent("app_flow", "sign_in", "", null); // First activity of new session.
}
But I have no methods in API to stop the session or to change the session time out.
I already tried to set ga_sessionTimeout to 1 day but it didn't worked,after ~8 minutes the session was closed even when the activity was still on the screen.I saw it on my Google Analytics dashboard's real-time overview.
Other ideas will be appreciated.
By default, Google Analytics will group hits that are received within
30 minutes of one another into the same session.
My goal was to keep the session alive till some event happen,
therefore I decided to implement Heartbeat mechanism.
That will send event every X minutes to keep the session alive.
It solved my problem.
P.S. : I discovered another thread with same solution.