“Every day, thousands of marketing teams log into their analytics dashboards, look at graphs showing sessions, page views, and conversion rates, and believe they understand their customers. They do not.”
They understand traffic. They understand averages. But they have no idea who their customers actually are, what journey brought them to purchase, or which marketing dollars turned into real revenue.
This is the fundamental blind spot of session-based analytics. It treats every visit as an isolated event, strips away individual identity, and forces you to make decisions based on aggregated statistics that mask the true patterns in your data. When a customer visits your site three times from three different devices before converting, session-based analytics sees three separate anonymous visitors. Only one of them converted. Your conversion rate looks lower than it actually is. Your attribution model gives credit to the wrong channel. Your entire understanding of the customer journey is built on a fiction.
Person-level analytics is the proposed fix. Instead of counting sessions and aggregating behaviours, it resolves activity back to individuals across touchpoints and devices, and asks a different class of question: which specific people are likely to buy, what path did the highest-value customers take, which campaigns produced customers who stayed.
That is the promise. This article treats it as a claim to be tested rather than a conclusion. Three questions settle it. What does a session structurally fail to record? What does resolving people cost, in engineering and in certainty? And where does the resolved data actually change a decision you would otherwise get wrong?
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
I.What a session cannot record
The gap is not a reporting preference. It is written into how a session is defined and where the identifier lives.
A.One person arrives as many rows
A session is a window, not a person. Almost every implementation closes it after 30 minutes of inactivity, and most also close it at midnight in the property timezone or when a new campaign parameter appears in the URL. The identifier that holds the window together is a first-party cookie or a local storage value, scoped to one browser on one device. Three devices means three identifiers with nothing linking them.
The identifier is not even stable within one device. Safari’s Intelligent Tracking Prevention caps script-set first-party cookies at seven days, so a three-week consideration cycle on one Mac can produce two or three distinct anonymous IDs on its own. Clearing storage, a second browser profile, and private windows do the same thing. The fragmentation is not an edge case; it is the normal state of the raw data.
Resolution works by aliasing. Every event carries the current anonymous ID. When the person does something that reveals who they are, the SDK submits an alias pairing that anonymous ID with a known key, usually an email or an internal user ID. The store keeps a mapping of aliases to one canonical person, and reassigns the events the anonymous ID already owned. That reassignment is the whole trick: history appears retroactively because ownership is rewritten in the event store, not reconstructed by a join at query time.
One buyer, as the raw data holds them
People report view| Identifier | Device | First source | Events | Revenue |
|---|---|---|---|---|
| a1f3…9c | iOS Safari | Paid social | 14 | $0 |
| 7b02…4e | macOS Chrome | Organic search | 22 | $0 |
| c48d…11 | macOS Chrome, new cookie | Direct | 6 | $0 |
| e9a7…d2 | iPadOS Safari | 9 | $248 | |
| Resolved person | 4 IDs merged | Paid social | 51 | $248 |
B.What that costs in attribution and lifetime value
Two numbers absorb most of the damage. The first is conversion rate. Per-session conversion rate equals the per-person rate divided by the average number of visits a converter makes. So the headline metric moves whenever consideration gets longer or shorter, even if nothing about the product or the persuasion changed. Unique visitor counts drift the other way, inflated by the device and cookie count rather than by audience growth.
The second is attribution, and here the error has a direction. The events that reveal identity cluster at the end of a journey: login, checkout, an email click into a personalised link. That is also where last-touch credit lands. Direct, branded search, and email therefore accumulate credit that reflects where the identifier appeared rather than where the demand was created. The bias is systematic, not noise, so averaging more data does not remove it. Multi-touch models applied to session data inherit it, because they redistribute credit across the touchpoints they can see, and the pre-identity ones are still missing. Our multi-touch attribution guide works through the model choices in detail.
Lifetime value fails differently. It needs a key that stays stable across months of purchases. Without one you can still recover the revenue after the fact by joining orders to email addresses in a warehouse, and plenty of teams do. What that join cannot recover is the behaviour before the first purchase, which is the part that explains the difference. You end up able to rank sources by revenue but not to say why one produces better customers, which is the question that would actually change the budget. The LTV calculation walkthrough covers the arithmetic once the key exists.
90-day revenue per acquired person, by first source
Revenue report viewII.What person-level costs
Identity is an estimate. The honest version of the pitch says so, and reports the estimate's coverage next to every number built on it.
A.Resolution is partial, and the rest of it is probabilistic
Deterministic matching is the reliable half. Login, checkout, newsletter capture, support chat, and account linking in an app each hand you an explicit key, and each is a place to fire an identify call. Instrumenting more of them raises coverage, which is the share of events attached to a person key. Coverage is the first number to build, and the one to report permanently.
Probabilistic matching is the other half: IP ranges, user agent and device characteristics, behavioural similarity. It extends reach and it introduces false merges, and the two error types are not symmetric. An under-merge leaves you exactly where session analytics already was, which is a known loss. An over-merge invents a person who did things two people did. Funnels then show step orders no single user performed, cohorts inherit retention from a stranger, and revenue lands on the wrong profile. None of it raises an alarm, because a merged profile looks richer than a real one.
Where identity actually comes from
Funnels report viewB.Consent and regulation bound what you can join
A resolved profile is personal data under GDPR and its equivalents, which is a design constraint rather than a blocker. You need a lawful basis, a purpose you stay inside, and the ability to export and erase on request. A canonical person key makes the last part easier than the session model does: a deletion request against a keyed profile is one operation, whereas finding every anonymous ID a person ever held is guesswork.
Consent is where the real ceiling sits. In jurisdictions that require opt-in before analytics storage, a refusal means no durable identifier and often no event at all. Consent rates vary by region, by device, and by traffic source, so the resolved population is a biased subsample of the whole, tilted toward logged-in and returning users. That does not invalidate person-level rates, but it does change how to read them: they are rates within the resolved set, and they are comparable over time only while coverage is stable. A jump in a person-level conversion rate is a coverage change until proven otherwise.
Probabilistic device matching also runs against the direction of travel. Fingerprinting is precisely the technique browser vendors and regulators have been restricting, through tracking prevention, third-party cookie deprecation, and the storage limits already mentioned. First-party deterministic identity, tied to something the person knowingly gave you on your own property, is the part that survives. Our privacy-first analytics guide covers the consent plumbing.
III.Where it pays, and where it does not
The value is concentrated in decisions whose horizon is longer than one visit. Outside those, sessions are not a compromise, they are the right unit.
A.The decisions that genuinely change
Budget allocation is the clearest one. Ranking sources by cost per acquisition uses a number available on day one; ranking them by revenue per acquired person and by retention at 90 days uses a number that does not exist until the window closes. Those two rankings frequently disagree, and the disagreement usually appears in month two or three, after the attribution window most paid dashboards run on has already closed. A Cohorts view built on acquisition source is where that shows up.
Retention by acquisition source
Cohorts report view| Cohort | M1 | M2 | M3 | M6 |
|---|---|---|---|---|
| Organic searchn=1,240 | 62% | 48% | 41% | 34% |
| Emailn=880 | 59% | 44% | 36% | 29% |
| Paid searchn=2,100 | 57% | 33% | 21% | 12% |
| Paid socialn=3,400 | 54% | 26% | 14% | 6% |
Retention work is the second. A churn signal is a decline in one person’s frequency against their own baseline, which has no session equivalent: a bounce rate cannot tell you that a weekly user became a monthly one. Populations hold the group that matches the declining pattern, and Campaign Performance tells you whether the intervention aimed at that group actually moved it, rather than whether the email was opened.
Product diagnosis is the third, and it is the cleanest illustration of the difference. A funnel that drops at an integration step tells you the rate. It does not distinguish between a user who saw the step and left, and a user who returned three times, tried, and gave up. Those two have opposite fixes: the first is a motivation or targeting problem, the second is a defect you can design out. The distinguishing measure is repeat attempts per person, which is a count over one person’s history and does not exist in session data at all. The Path report gives the order they arrived in. KISSmetrics ships these as standard reports rather than as a modelling exercise.
B.When session data is honestly enough
If the decision closes inside one visit, session data answers it, more cheaply and with no consent dependency. Landing page copy, page weight, form field count, the order of checkout steps, and most A/B tests whose metric is same-visit conversion are all correctly measured in aggregate. Resolving identity adds pipeline and shrinks the sample to the consented, identified subset, and buys nothing for a question that a visit already contains. Person-level analytics is not a better version of session analytics; it is an answer to a different question, and it is overhead when you are not asking that question.
This is the fair way to place GA4. It is event-based, and with User-ID configured it will report a logged-in user across devices. What it does not do is retroactively re-own the anonymous events a person generated before they identified themselves, so the part of the journey that happened before the account exists stays detached. Large explorations are subject to thresholding and sampling, and there is no individual timeline to open. Those are consistent design choices for a tool whose centre of gravity is traffic and ad measurement, and inside that scope it is capable and free. Our feature-level comparison covers the specifics.
So the test is not which tool is better. It is whether your decision depends on what one person did before they were a person to you. Single-visit purchases, no account, no repeat buying, a short cycle, or traffic too thin to fill a cohort: in all of those, the answer is no, and sessions are sufficient. Long consideration cycles, subscriptions, and repeat purchase: the answer is yes, and the session model is not conservative there, it is wrong.
Verdict
Person-level analytics is worth its cost under two conditions, both of which you can test before buying anything. First, the interval between first touch and the revenue you care about is longer than one visit. Second, somewhere inside that interval the person hands you an identifier. If both hold, session analytics is not merely coarse. It is wrong in a known direction, over-crediting whichever channel happens to sit nearest the identifying event, and no amount of extra traffic corrects a bias that is built into the measurement. If either fails, resolution buys you a harder pipeline, a consent dependency, and a smaller sample, in exchange for a precision no decision on your roadmap needs.
Where it does apply, one discipline decides whether it is trustworthy: publish resolution coverage beside every person-level number, and keep merges auditable. A person-level conversion rate at 30% coverage is a fact about 30% of your traffic. Presenting it as a fact about all of it is a worse error than the session model it replaced, because it comes with more confidence attached. Instrument the identify calls, measure the coverage first, and read everything else through it.
Continue Reading
Beyond Google Analytics: Why E-commerce Brands Need User-Level Tracking
Google Analytics tells you what happened on your site. But for e-commerce brands that need to understand individual customer journeys, reduce cart abandonment, and attribute revenue to the right channels, you need something more.
Read articleMulti-Touch Attribution: How to Give Credit Where It Is Due
Customer journeys involve multiple touchpoints across channels and devices. Multi-touch attribution distributes credit across the entire journey so you can invest in what actually works.
Read article