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.

Where is the session ID stored?

The session ID is an automatically-created global variable, accessible as session.id. It is stored as a string.

For more on what session-level variables are and now they are used in Airkit, see documentation on Variable Namespaces. For more on automatically-created variables, see Standard Journey Data.

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.

What is the difference between a URL that resumes a Session and URL that begins a Session?

A Starting Link triggers the start of a Session. It can be used any number of times to begin any number of Session.

A Journey Link leads to a web page associated with an existing Session. It is capable of doing so because it contains a unique Session identifier in the URL path.

Upon navigating to a Starting Link and beginning a Session, the change from Starting Link to Journey Link will be reflected in the address bar of the web browser, as an identifier becomes part of the path parameters. (If you want to send someone a link to an Airkit app, be mindful of which URL you are sending. You cannot send someone a Starting Link by copy/pasting the URL from your address bar.)

Journey Links can be sent via reminder texts, prompting users to return to a half-finished Session to finish what has been started without loosing previous progress. For more on how this is done, see Linking to Sessions.

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.