Session

GA4 opens a session with a session_start event and keeps it open while events keep arriving. After thirty minutes with nothing happening, the session ends; the next event starts a new one. That is the whole rule, and every complication below comes from it.

The thirty minutes is a default rather than a fact. It is configurable from five minutes up to just under eight hours, and changing it changes the session count for identical visitor behaviour. Raising it merges visits that were separate; lowering it splits visits that were one.

This is worth checking before comparing two properties or reconciling with a client own dashboard, because the setting is invisible in every report it affects. A property configured with a two-hour timeout will show fewer sessions and a higher average duration than an identical property on the default, and nothing about the traffic differs.

Midnight is the other boundary. A session crossing into a new day is split in the reporting, which is a small effect on most sites and a noticeable one on anything used heavily in the evening.

Universal Analytics started a new session whenever the campaign source changed mid-visit. Somebody who arrived from organic search, left, and came back through an ad twenty minutes later produced two sessions, one credited to each source.

GA4 does not do this. The same behaviour produces one session, and the second touch does not split it. That is a meaningful part of why session counts dropped for many properties at the migration, independently of anything else that changed.

The reasoning is defensible: a person who did one thing should probably count as one visit. The consequence for attribution reporting is that last-click credit within a session behaves differently, and a channel that used to pick up sessions from mid-visit re-entry no longer does.

For agency work the practical point is narrow. If a paid channel appears to have lost sessions across the migration while its clicks and conversions held, this is usually the reason, and it is a reporting change rather than a performance one.

A session belongs to a client identifier, normally a cookie set in the browser. Everything that resets or hides that identifier splits one persons visit into several, and each fragment arrives looking like a new visitor.

The causes have multiplied. Safari Intelligent Tracking Prevention caps the lifetime of client-side cookies, so a returning visitor after the cap looks new. Clearing cookies does the same thing immediately. Moving from phone to laptop produces two identities unless a user ID is set. Declining consent can prevent the identifier existing at all.

The direction of the error is consistent and worth stating plainly to clients: session counts overstate distinct visits, and user counts overstate distinct people, and both errors get worse as privacy protections tighten. A site whose audience skews to Safari and mobile is more affected than one that does not.

A user ID, set when somebody logs in, is the only reliable repair, and it only works for the logged-in portion of an audience. For most marketing sites that is nobody, which means the fragmentation is a permanent property of the data rather than a bug to fix.

This conversation happens on most engagements and it is almost never a tracking fault. Two tools measuring the same site will disagree on traffic because they define a visit differently, and naming the difference ends the conversation in a minute.

The things to check, in order: the session timeout in each tool, whether either restarts sessions on a campaign change, whether one counts server-side and the other client-side, and whether they are filtering internal traffic differently. Any one of those produces a double-digit percentage gap on its own.

Consent is the other half. A platform that fires before the banner and one that fires after are measuring two different populations, and in Europe the difference is not small. Search Console against GA4 is the clearest example: one counts the click on Google side, the other counts a session that survived the banner.

What not to do is try to reconcile them to a single figure. That is a project with no end state. Pick the tool decisions are made on, say so once, and report the other as a cross-check when its movement is informative.