Sessions

Sessions describe a means of conceptualizing how Airkit keeps track of where users are within the flow of an application, as well as what they've done, entered, or requested in the process.

Whenever someone uses an Airkit app, they're working within an individual Session, a term in Airkit used interchangeably with "Journey". By automatically distinguishing each Session as a separate entity, Airkit makes it possible to gather information regarding how a user is engaging with an application, even if nothing else is known about the user themselves.

Defining a Session

An Airkit Session starts when a user first begins to go through the flow of an app. This can happen in many different ways, but regardless of how a Session starts, it spans all of the user's interactions with that app, across all relevant channels, as long as the app has some way of recognizing the Session. This is done by associating a Session with unique identifiers. By default, Airkit provides the first identifier automatically: as soon as a Session begins, it is assigned a unique ID (the "session ID") as an identifier. This allows every Session to be immediately considered as its own separate entity, even if nothing else is known about the person embarking on it.

If an app is sufficiently simple, automatically-assigned identifiers might be the only pieces of data associated with Sessions in that app. Similarly, a user might exit an app before providing any information that might serve as unique identifier. In both cases, it is still valuable to keep track the Session via its default identifier, for the purposes of data analytics if nothing else. You might want, for instance, to compare the number of Sessions started with the number of Sessions completed.

A single Session can span multiple channels by collecting relevant information and storing it in the form of identifiers. The exact nature of this relevant information varies, though emails and phone numbers are among the most common. If a Session begins with a user making an appointment via a web app, and then continues through the user getting a confirmation text, this is made possible only because the user's phone number was in some way tied to their Session. It wouldn't work otherwise – a phone number is required to receive a confirmation text, and if you send one, you want to ensure it's precisely confirming the appointment that was made online.

Identifying a Session by information known by the user also allows the user to pick up their Session where they left off should they leave in the middle. This is technically possible even when a Session is identified only by automatically-assigned IDs. For example, in the case of web apps, an initial identifier is stored in the URL path. (For security reasons, this identifier is not the same as the session ID.) If a user records the URL path associated with the Session they started – which is, critically, distinct from the Starting Link they went to in order to start their Session in the first place – they can resume their Session where they left off. However, if the user did not take note of the identifier in the URL path before exiting the web app, as is more likely the case, they will have no way of finding it out, and will therefore not be able to access that initial Session upon their return. They will be forced to start a new Session and repeat any aspects of it that they have already gone through.

Starting a Session

A Session starts whenever a user begins engaging with or being engaged by an Airkit app; this is when they are automatically assigned a unique ID as an identifier. You can start a Session upon a potential user clicking a link, sending a text message, or calling a phone number. A Session might also start when an API is triggered. Deciding how uses might begin a Session is done in the Triggers Builder.

A single app might allow users to begin their Sessions through it via multiple channels. While each individual Session can only begin once, different users accessing the app might begin their interactions with it – and thus their Sessions – in different ways. An app might, for example, allow users to begin their Sessions via either sending a text or making a phone call. 

For a more detailed discussion on how to start Sessions from multiple channels, check out Texting Journey Links.

Ending a Session

Sessions don't last forever. By default, a Session ends after thirty days, although this default can be changed in Settings, modified dynamically with the Extend Session Expiration Time Action, or overridden by the End Session Action. The existence of this default is largely a matter of efficiency. Consider, for instance, cases where a user accidentally exits an app before reaching the end or providing any information that might serve as unique identifier. If the only way to end a Session was by explicitly ending it once the user had successfully completed what they set out to do, this Session would remain active but untouchable, in limbo, forever. With this default expiration, it only stays in this limbo for thirty days.

Once a Session is over, a user cannot return to it; if they access the app again, they will begin a Session anew.