Session

When the only thing being counted was people, the record kept the fact that someone showed up and nothing else. A person who opened the product once and closed it immediately and a person who came and went five times while working both registered as one. The two were using the product in entirely different ways, and the dashboard showed the same value for either of them.

The limit showed itself in a Pagedeck weekly meeting. Daily active users (DAU), the count of people who used the product in a day, had gone from 900 to 1,100, while the number of documents edited over the same stretch barely moved. Mia asked whether new people had arrived or the same people were coming more often, and there was no number in the room that could answer.

So a visit unit got stacked on top of the person unit. Group everything from arrival to departure into one block and you can see whether visits went up or down even in a month when the headcount held flat.

Sessions are made by laying activity records out in time order and cutting wherever the gap widens. There is no moment where someone declares they are leaving, so the quiet stretch stands in for the exit.

The cut has four steps.

1. Lay out one user's recorded actions in time order. Opening a screen, editing a document and running a search are all raw material.
2. Start at the timestamp of the first action.
3. If 30 minutes pass after the last action with nothing following it, cut there. That 30 minutes is the inactivity threshold, and most analytics tools ship with it as the default.
4. When an action arrives after that, a new block begins.

Open the product at 9:10 a.m., edit documents until 9:25, go to a meeting, come back at 11:00, and that day holds two blocks. The stretch from 9:25 to 11:00 belongs to neither of them.

Two numbers come out of this. One is how many times someone arrived, the other is how long they stayed once they did. If 1,000 people arrived 3,000 times in a day, each person came three times.

The 30 minutes is a convention, not a fact. Change the threshold to five minutes and the same records yield close to twice as many blocks with average length cut in half. So if you want to say the number went up or down, the threshold has to stay where it was.

Time spent has one blind spot. Nothing records how long someone kept looking at the screen after their last action, so counting stops at that action. A block with only one action therefore comes out at zero length. Someone who opened a document, read it for three minutes and closed the window is recorded as zero seconds. A product with a short average may not have people leaving quickly — it may have a lot of read-only visits.

It separates two things that a headcount runs together: whether people are coming more often, or staying longer each time.

There are four places to read it.

1. Habit. When visits per person climb from 1.2 a day to 2.8, it isn't new people arriving — the product has moved into the working routine of the users already there. It is usually the first number to move when people start opening something without deciding to.
2. Feature judgment. Put it beside feature adoption rate, the share of users who have tried a given feature, and you can tell whether that feature gets used inside work already underway or creates a separate trip. A feature people open from a notification, check, and leave raises visit counts while pulling time spent down.
3. Group definition. It supplies the line for a power user, the kind of user who goes far deeper and more often than average. At Pagedeck, arriving on five or more days a week is one of the conditions.
4. Early warning. Visit frequency often falls before retention, the degree to which existing users keep coming back, does. An account that dropped from four visits a week to one hasn't left yet, but it is a candidate to disappear at the next renewal.

It counts something different from monthly active users (MAU), the count of people who used the product in a month, or stickiness, the share of those who come every day. Those count people; this counts visits. A month can hold the same people and more visits, or the reverse.

"User count is flat but sessions are up 40 percent. The same people are coming in more often."

Separating a rise in frequency from a rise in size.

"Average time on that screen is three minutes, which isn't a good sign — it means people can't find what they came for."

Marking a place where time spent must not be read as an achievement.

"The threshold changed to 15 minutes when we switched tools. Don't compare this against last month as is."

A warning that the reason the number looks higher is the calculation, not the product.

To answer her own question, Mia put visits on the dashboard underneath the user count. Two months later the screen showed 1,100 users next to 1,320 visits. That works out to 1.2 visits per person per day — effectively one arrival, finish the task, leave.

What that number led to was not a new feature but a reason to come back. A morning email collecting the comments left on your documents went out, and by the end of the quarter visits were at 1.9. The user count had barely moved while documents edited went up. Watching only the headcount, the quarter would have been recorded as one where nothing happened.

The most common reading is that longer time spent is better, because staying a while looks like attachment. What it means flips by screen, though. Twenty minutes on a document screen means work is getting done; three minutes on a settings screen means someone can't find what they are after. Set length as a goal without that distinction and you end up with proposals to add steps and buy time.

Reading visit counts as people is the other common one. The two sit side by side on a dashboard as large numbers, and the labels alone don't separate them. But one person can produce five visits in a day. Read 3,000 daily visits as 3,000 users and you overstate the size of the product threefold, and once that figure lands in an investor deck or a hiring plan it is hard to walk back.