Hi!
I’ve encountered strange user behavior, which I suppose might be the problem connected with analytics. We have an event called first_launch that fires off when a user launches the app for the first time. This event should be followed by another event telling that the subscription screen is shown. They go one after another and normally should work even if the user opened and immediately closed the app.
However, I see that 2.5% of users only get the event first_launch along with two standard Start Session events before and after it. Strangely, the first Start Session event has a Session ID equal to -1.
We couldn’t reproduce that situation, so I thought it would be a good idea to ask Amplitude gurus what it can possibly be. :)
I’d appreciate any ideas on that issue.
P/S: Also, what may Session ID equal to -1 mean?
Session ID -1 is not unusual, it’s a default value for an undefined Session ID. There are use cases (like HTTP API or specific Segment configurations) where you have to define your own Session ID or it will always be -1. However, it’s curious to see it in data collected by the SDK. Browsing quickly through our data, I couldn’t find similar examples there.
I assume you have also cases where the first Start Session event for a new user has a Session ID set up?
That being said, my first thought about this behavior is that your app crashes at launch and these users never get to the point where the second event would be sent. Have you analysed these cases to see if there are any common factors, such as a specific phone model, OS version or something like that?
@quentin After exploring this bit further, I think I have an explanation.
We have a similar first_launch event in our application. When I looked at our data in more detail, exactly the same behavior was showing there. To understand these users better, I created a funnel from this first_launch event to Any Event and then created a cohort from those users who failed to convert the funnel. When I looked at the top events for this cohort, most of them were triggering a pretty standard distribution of our most common active events. Furthermore, they had been doing so already before the my first_launch funnel was started. I.e. they had been users before triggering first_launch.
How does that work out?
The thing about our first_launch event (and I assume this applies also to you) is that it’s not actually capturing the first app launch for that user, but for that installation. So if the user re-installs the app or changes their phone and installs the app for the first time on that device, they will trigger first_launch event again.
How this results in what I think is happening here is related to how Amplitude identifies unique users (see https://help.amplitude.com/hc/en-us/articles/115003135607-Tracking-unique-users).
When the user launches the app after the re-installation, a new Amplitude ID is being generated for the user before Amplitude realises that it has actually seen this Device ID before. When Amplitude figures this out, all the further events are assigned to the existing Amplitude ID. Since the event stream view is based on Amplitude ID rather than Device ID or User ID, there is no connection or continuity between the temporary Amplitude ID and the proper Amplitude ID. This creates these “ghost” users that only generate the first_launch event, but nothing else. They are users returning with a new installation, but it takes a bit too long for Amplitude to realise this.
Essentially it seems that the first_launch event is triggered so early in the app initialization process that Amplitude SDK hasn’t quite caught up at that point yet.
I hope that explanation makes sense, this is an unusual situation.
I also want to emphasize that at this point, this is just a theory based on what I see in our data, but it would explain this. It would be nice to get a confirmation or otherwise from Amplitude side.
Furthermore, if this is the case, I’m surprised that the funnel chart from first_launch to any event would work the way it does. It would mean that in these cases Amplitude is failing to connect the dots between the different Amplitude IDs.
HI @quentin ,
@MikkoKarvonen has summed it up excellently. As he said , a session ID of -1 means that it has no session ID and therefore it given the defalt of -1 to denote it is an out of session event.
I would agree that this is probably due to an initialization issue and it could be due to crashing. I know you said that you weren’t able to reproduce it but have you been successful with a reproduction of the issue yet? My thought would also be that the event is triggered to quickly for the SDK to keep up? I would try a wait function just to see if this is the issue. I would also try to compare against successful users and see what was different. It might also have to do with the type of iOS people are running. Perhaps the application is not running well on a particular iOS version? Building a funnel is a smart idea to see the paths.
If none of this helps, let me know and I will investigate again!
@MikkoKarvonen @Denis Holmes
Thank you for your detailed replies! We checked crashes in the first place but it doesn't seem to be the cause of the issue. We’ll try to trigger the event a bit later and see how it goes.
@MikkoKarvonen @Denis Holmes
Thank you for your detailed replies! We checked crashes in the first place but it doesn't seem to be the cause of the issue. We’ll try to trigger the event a bit later and see how it goes.
Hi Quentin,
Do and let me know how it goes. If you are still having issues, you can PM me the details of the issue along with whatever screenshots you have and a detailed account of the problem and we can move from there :)
