Identity and sessions

An identity in product analytics is the identifier a tool uses to decide that two events came from the same person, and a session is a group of that person's events which a timeout rule has decided to treat as one visit.

Both are conventions, and neither is a fact about anybody. A product cannot observe a person. It observes a device, a browser, an account and a gap between two actions, and every per person and per visit figure it reports is built on rules a team chose about how to turn those four things into one.

The rules land on a product manager because they change the answer and nobody else will notice. An engineer implementing sign in has no reason to think about whether the analytics tool rewrites history at that moment. An analyst reading a retention chart has no way to tell that a third of the population is using a browser that deletes the identifier every seven days. The person who asked for the measure is the only one holding both ends.

The sections below take the two identifiers a product works with and the moment they are joined. They then set out what stitching cannot recover and what browser storage limits do to a returning visitor. Finally they take the session, work through what a timeout choice does to the numbers, and settle the unit each measure is counted per.

Two identifiers and the moment they are joined

A product carries two identifiers for a person, and the whole subject turns on how and when the two are connected.

The anonymous identifier is generated the first time somebody arrives and written to the device. In a browser it lives in a cookie or in local storage. In a mobile application it lives in the application's own storage. It is specific to that device and that browser, so one person with a laptop and a phone has two of them from the start.

The known identifier is the account identifier the product already holds once somebody signs in. It is stable, it travels across devices, and it is the only identifier that can honestly be called a person.

Stitching is the moment the product tells the analytics tool that a particular anonymous identifier and a particular account identifier belong to one person. It happens at sign in and at registration, and it is one call in the code that a team either makes or forgets. Forgetting it is common.

What happens to the earlier anonymous events differs between tools, and a team should find out which behaviour its own tool has before building anything on it. Some tools rewrite the history, so every event the anonymous identifier produced before sign in is reattributed to the known person. Others link the two from that point forward and leave the earlier events where they are. The difference decides whether a funnel running from a marketing page through registration to a first paid action can be measured at all, because under the second behaviour the top of that funnel belongs to a different person from the bottom.

What identity stitching cannot recover

Stitching joins what the product observed and cannot join what it never saw, and four gaps account for almost all of the loss.

1. A device somebody never signs in on. A person reads the marketing site on a work laptop over three weeks, then registers on their phone. The laptop identifier never meets an account and stays a separate person forever.
2. A shared device. A family tablet, a shop floor terminal and a shared login for a small team all put several people behind one identifier.
3. One person with two accounts. A consultant with a client account and their own account is two people to the tool, correctly by its rules and wrongly by any other measure.
4. Storage that was cleared. A new browser, a private window, a wiped phone or a person who clears cookies weekly produces a new anonymous identifier each time.

The loss runs in a consistent direction, which is the useful thing to know about it. The count of people is overstated, because one person appears as several. The count of actions per person is understated, because that person's actions are divided between the copies.

One example puts a size on it. A product records 61,000 distinct identifiers in a month, of which 38,000 are signed in accounts and 23,000 are anonymous identifiers that never joined one. If a quarter of those anonymous identifiers belong to people already counted among the 38,000, the real population is about 55,250 and the reported figure overstates it by roughly ten per cent. A team cannot know the quarter exactly, and it can estimate the share by watching how often an anonymous identifier is later joined to an account that was already active.

What browser storage limits do to a returning visitor

An identifier written by a script in a browser has a shorter life than most teams assume, and the change came from the browser makers rather than from anything a product did.

WebKit announced Intelligent Tracking Prevention 2.1 in February 2019, which capped every persistent cookie created through document.cookie at a seven day expiry. In March 2020 John Wilander announced a further change for WebKit, which blocked cross site cookies by default in Safari 13.1 and deleted all of a website's script writable storage after seven days of Safari use with no interaction on that site. Local storage, IndexedDB and service worker registrations were all covered, which closed the routes that had been used to survive the cookie rule. Seven days is the figure to remember.

The consequence for analytics is direct. An anonymous identifier set by an analytics script in Safari does not reliably survive a fortnight of not visiting. A visitor returning after three weeks arrives as a new person, with no history and no cohort.

That understates retention, and the size of the understatement differs by browser. A product with a large Safari share on mobile and a large Chrome share on desktop is measuring two different things under one chart. A comparison between the mobile segment and the desktop segment then moves for a reason that has nothing to do with the product. Signed in users are unaffected, which is why long range retention is usually reported on the signed in population and stated as such.

The session as a convention

A session groups a person's events into something a team can call one visit, and the grouping is decided by a rule about inactivity.

The convention was settled in the web analytics era. The Web Analytics Association published a set of standard definitions in 2008, which described a visit as ending once somebody had taken no further action for a set period. It named thirty minutes as the usual timeout and recorded that the Interactive Advertising Bureau's audience measurement guidance was moving to require the same thirty minutes. Google Analytics 4 still ships thirty minutes as its default and lets the figure be set anywhere between five minutes and seven hours fifty five minutes.

Thirty minutes is a habit with a long history behind it and no claim to being right for any particular product. A banking app used for ninety seconds twice a day and a video editor used for four hours have nothing in common that a single timeout could capture.

What a timeout choice does to every session measure

Changing the timeout changes every session figure a product reports, while changing nothing at all about what anybody did.

A researcher uses a document product across one morning. She works from 09:00 to 09:20, returns from 10:05 to 10:35, and returns again from 11:20 to 11:45. Her active time is 75 minutes and both gaps are 45 minutes long.

Sessions per person fell from three to one and mean session length rose from 25 minutes to 165, which is a factor of more than six. The researcher did exactly the same work under both settings.

Two further measures move with it. A bounce is usually defined as a session carrying a single event, so a shorter timeout manufactures more single event sessions and raises the bounce rate on a product nobody changed. And any figure expressed per session, such as searches per session or pages per session, falls as the timeout shortens, because the denominator grows.

The practical position is to pick a timeout once, write down the reason, record the date it was chosen and treat any later change as a break in the history. A team comparing its own figure against a published benchmark should also check which timeout the benchmark used, since two products reporting sessions per user are often reporting two different conventions.

The unit a measure is counted per

Every measure is counted per something, and naming the unit removes most of the ambiguity a metrics review runs into. The unit is rarely stated.

The account is the unit most often missed in a product sold to organisations. Five people at one customer each running the same report once is one customer's behaviour, and counting it as five people exaggerates how many organisations the feature reached. A renewal conversation turns on how many accounts used the thing, so a measure reported per person answers a question nobody in that conversation asked.

Identity and sessions are conventions a team chooses, writes down and can state beside any number it reports. The pipeline carrying the events those conventions are applied to fails in ways nobody chose and nobody wrote down, and it fails without an error message. Whether the figures coming out of it can be believed at all is the subject of the next page.