Hey @liukaichi,

thanks for writing into Amplitude Community! Hope I can help with your questions and clarify it a bit :)

1. Correct, Amplitude does not track Start Session and End Session events by default so it would only start a session when some event is fired.  

   That said, if tracking Start Session and End Session events is critical to your analysis, you can easily turn on tracking for these events by adding this line of code before initialising the SDK:

   For Android:

   Amplitude.getInstance().trackSessionEvents(true);

   For iOS:

   pAmplitude instance].trackingSessionEvents = true;

    

2. Yes, we do track the background time Background time would be included in the session length because session length = timestamp of last event - session ID, and the timestamp of the last event would therefore take into account all the background time. So unless the background time is over 5 minutes (which would trigger a new session) it will be included in the session length. 
   There are 2 main pieces to the session logic: one is triggered when the app goes into the background, and the other when the app comes into the foreground.
   
   Piece 1: When the app goes into the background, we record and save the timestamp.
   
   Piece 2: When the app comes back into the foreground, we check the current timestamp and compare it to the recorded timestamp from Piece 1. If more than 5 minutes have passed since the app last went into the background (meaning the user has not been using the app for at least 5 minutes), then we know that we should begin a new session.
   
   So going back to your example - if you don’t leave the app (don’t ‘background’ it) - it will still count as the same session even after 10 minutes.
    
3. When we begin a new session, we first end the previous session by sending the end session event using the recorded (at that time) timestamp, and then we send a start session event using the current timestamp.
   So basically we will only send the end session event when we determine that a new session should be started. For this reason, the total number of end session events will always be less than the total number of start session events. The missing end session events will get sent the next time those users re-open your app. At that time they will also send the next start session event as well.
   
   And the need for the ‘End Session event’ is that we use it to calculate Session length :) 
    
4. As an option - I would say that instrumenting tracking of Start Session and End Session events would be a good fit in this case since it minimises the amount of basic events you would have to track for users that just ‘play around’ and end up not interacting with the core functionality of your product.

Hope this helps! 

Wow, this is great. I really appreciate your detailed response. I find your response very interesting, as it contradicts some of the things explained in the documentation, I would recommend you update that document to better reflect how you described it . For example, the documentation it only detects the timestamp of the events themselves, and not saving timestamps when backgrounded to possibly use at a later time. 

A couple more follow up questions:

1. So if a user only fires one event, stays in the app for 10 minutes, and quits the app without another event and never returns. How long will this user’s session be in Amplitude? Based on your response it seems it would basically count as 0m 0s. On the other hand, if they came back and we had “End Session” configured, it would count as 10 minutes. Does this sound correct?
2. Is there a possible way to get that accurate 10 minute session time without the user returning? Maybe some kind of server event or something?
3. As I understand it, if I do not implement “End Session”, Amplitude will use the backgrounded timestamp to understand when to start a new session, but it will not use it to calculate the previous session’s length. So I could send a single event, use the app for 10 minutes, and then come back the next day. The previous session will still register as 0m 0s, since that is the only event in the session. 

Again, I really appreciate you taking the time to help me understand. Thanks!

Also, here are two diagrams I made based on how I understand it that I plan to share with my team. Hopefully it all checks out. 

Thanks for helping with this problem. I also have the same situation.

There are many benefits to hiring a software development service https://mlsdev.com. Aside from the cost savings, you can also be sure your project will be delivered on time. In addition to delivering quality, a professional team will reduce the time you spend on ensuring that your product is a success. The software development life cycle is an important process that will help you make a great first impression with your customers. A dedicated software development team will ensure that the project is done right and will exceed your expectations.

Hey @Zhenia Semenina any updates here? I would be great to confirm this before we choose to go custom or use Amplitude’s built-in methods. Thanks again!

Hello @Zhenia Semenina 

We have the same misunderstanding, could you please clarify it ? 

@Zhenia Semenina 

Does setUserProperties()  also have an impact on the session length (because internally it also logs an event)

Hi @liukaichi @louis I’m doing some research on amplitude sessions. I’ll update my answer here and update the documents if incorrect within a week.

Hello  @liukaichi,  cc @louis, I have some updated answer for your questions.

For question 1 about session start time:

• The sessionId which is the timestamp of a new session’s start point, will be set and store in amplitude client when:
  • For web, Javascript SDK client initialized.
  • For mobile, app come to foreground.
• This sessionId evaluation doesn’t need an event to fire. It hooked up with app activities(app open, come to foreground etc.) and site opened(page landed and client initialized)

For question 3 about what is the need for the “End Session” event?

• End Session event and session timeout are not conflict. Session timeout is used to determine whether to start a new session. Session length could be much longer than session timeout since we only start new session when the app goes into the background and no events are fired for at least 5 minutes(5 mins is session timeout and configurable)
• Using in-built Start Session and End Session mean the session will last all the way until the next session. Because the last event of previous session is End Session event, timestamp of which is very near following Start Session event. As mentioned in document, Start Session and End Session event are not required for session tracking and not enabled by default. If no Start session and End session sent, session length can still be calculate by timestamp of last event for a sessionId: session length = time_of_last_event - sessionId

For follow up question 1

• session length will be calculated by timestamp of end session event, length = endSessionTimestamp - sessionId, most likely longer than 10 min.

For follow up question 2

• It can be done by sending a “enterBackground” event to our backend server when user close the app. Server side can not determine session length for a client without an explicit event.

For follow up question 3

• Enable “Start/End Session” event or not does not affect sessionId refresh. If “Start/End Session” enabled, the behavior is when new session started, send an end session event with previous sessionId and current timestamp, then send a start session event with new sessionId and current timestamp.

One correction, End Session event timestamp is the timestamp of last event in previous session, not the timestamp of sending End Session event.