Sessions

Session Management

A session groups user activity within a time window. Sessions help you understand user engagement patterns.

Session Rules

Rule	Description
Timeout	Session expires after 30 minutes of inactivity
UTM Reset	New UTM parameters start a new session — in the url on the web, in the link handed to `handleOpenURL()` on iOS and tvOS
App Lifecycle	Session resumes when app returns to foreground (mobile)

Automatic Session Tracking

The SDK automatically manages sessions - no manual intervention required.

The SDK automatically manages:

sessionId: Unique identifier for the session
pageNumberInSession: Sequential page count (1, 2, 3…)
UTM parameters: Captured at session start
Traffic source: Categorized once when the session opens and stored with it, so it stays the same on every page of the visit. Recomputing it per page would split a campaign session in two, since from the second page onwards the referrer is your own previous URL.

Sessions are stored in a cookie (alke_s) that expires after 30 minutes of inactivity. Its value is a compact internal format — around 30 bytes for a visit with no campaign — and it is not part of the public API: read session data through the SDK rather than by parsing the cookie, as its layout changes without notice.

// Session data is included automatically in every event
// No manual configuration needed

The SDK automatically:

Creates a new session on first launch
Resumes session when app returns to foreground
Starts a new session after 30 minutes of inactivity
Starts a new session when a link carrying utm_* is handed to handleOpenURL() — even while the current session is still alive, because a campaign arrival is a new visit

// Session timeout is configurable
AlkeAnalytics.setConfig(AlkeConfig(
    propertyId: "...",
    appVersion: "...",
    sessionTimeoutMs: 15 * 60 * 1000  // 15 minutes
))

The SDK automatically:

Creates a new session on first launch
Resumes session when app returns to foreground
Starts a new session after 30 minutes of inactivity

// Session timeout is configurable
AlkeAnalytics.setConfig(
    context = this,
    config = AlkeConfig(
        propertyId = "...",
        appVersion = "...",
        sessionTimeoutMs = 15 * 60 * 1000  // 15 minutes
    )
)

User ID

The user ID is a persistent identifier stored on the device, generated automatically on first SDK initialization.

Stored in alke_u cookie
30-day expiration, renewed on each visit — a reader who comes back at least once a month keeps the same identifier indefinitely
Respects consent (cookie only set if consent granted)

Reader loyalty (`alke_v` cookie)

A third first-party cookie tracks how regularly the reader comes back, which feeds the visitSequence and newsletter dimensions.

Property	Value
Name	`alke_v`
Expiration	30 days, renewed on each visit
Contents	Session count, first and last session timestamps, date of the last newsletter arrival — in the same compact internal format as `alke_s`
Consent	Only written when storage consent is granted, like the other two

Declare it alongside alke_u and alke_s in your cookie policy and CMP. See Content Dimensions for what it powers.

UTM Parameters (Web)

Traffic source attribution is captured from URL parameters:

Parameter	Description
`utm_source`	Traffic source (google, newsletter)
`utm_medium`	Marketing medium (cpc, email)
`utm_campaign`	Campaign name
`utm_term`	Paid keywords
`utm_content`	Ad content variant

https://example.com/page?utm_source=google&utm_medium=cpc&utm_campaign=spring_sale

When a user arrives with UTM parameters:

A new session is started
UTM values are stored for the session duration
All pageviews in the session inherit these values

Consent

UTM parameters require consent for purposes 1, 7, and 9 (store/access, advertising performance, audience understanding).

Traffic Source

Every session is attributed to exactly one traffic source. It is decided when the session opens and carried in the alke_s cookie alongside the session’s UTM parameters, so every pageview and event of that visit reports the same value — and the categorization reads the UTM of the session, not of the URL currently being viewed.

The source is a closed vocabulary of 11 values, so reports stay comparable across properties:

Value	Meaning
`SEO`	Organic search
`SEA`	Paid search
`Social`	Social network
`Email`	Email or newsletter
`Paid Advertising`	Display, video and other paid placements
`Affiliate`	Affiliate partner
`Referral`	Another site linking to yours
`Google Discover`	Google Discover feed
`LLM`	AI assistant or language model
`Other Campaign`	A campaign that matched none of the above
`Direct`	No campaign and no referrer

A utm_medium that is declared but matches none of the categories becomes Other Campaign. It is never stored as free text, and never folded onto Direct: Direct means “no campaign and no referrer”, so an SMS or print campaign folded onto it would be indistinguishable from a visit with no provenance at all.

The value is validated server-side against those eleven. Anything else is reported as Other Campaign — the column is a closed vocabulary, and a value outside it would break the comparison the vocabulary exists for.

How the referrer is read

With no utm_medium on the arrival, the referrer decides. Its host is compared on whole labels, against the registrable domain — google recognizes google.com, google.fr and google.co.uk, and never googleusercontent.com.

For the brands that serve other products from the domain that serves search, only the hosts that are the search engine count as SEO. Google Tag Manager’s preview mode navigates from tagmanager.google.com to the site it is debugging: that visit is a Referral, and so is one from Analytics, Ads, Drive, Docs or Gmail. Social networks and AI assistants carry no such restriction — m.facebook.com, chat.openai.com and web.whatsapp.com are the product itself.

An arrival from a search engine carrying a gclid or an msclkid is reported as SEA, not SEO: a paid click identifier on a results page is a click on an ad. This is the common case of an advertiser who relies on Google Ads auto-tagging and never sets utm_medium=cpc; the same identifier on any other referrer stays Paid Advertising.

On iOS, tvOS, Android and Android TV

The same eleven values, decided from the link you hand to handleOpenURL() and carried by every report of the session that link opens. Nothing to declare and nothing to set: the source is derived, and the SDKs expose no way to write a category of your own.

An application has no referrer, so the rules that read one cannot fire: the categories are decided by the link’s utm_medium, and by the gclid, msclkid and fbclid it may carry on its own. Two consequences worth knowing before reading a report:

Case	What you see
`SEA` and `Google Discover`	Never reported. Both need a referrer — `SEA` is a paid medium arriving from a search engine, and Google Discover is a referrer rule.
A launch with no link	`Direct`, the same value the web gives a visit with no campaign and no referrer. This is what an ordinary app open — from the home screen, from the multitasking switcher — reports.

A campaign that has no category in the vocabulary — a push notification, an in-app deeplink you tag yourself — reports Other Campaign, exactly as an SMS or print campaign does on the web. Tag it as you would any other campaign and read it back through utm_source and utm_campaign, which carry the detail the category does not:

myapp://article/123?utm_source=push&utm_medium=push&utm_campaign=breaking-news