Every analytics tool has a data model, and the model decides which questions you can ever ask. Not which are easy: which are possible. Choosing between a session-based tool and a person-based one is not a feature comparison, it is a choice about the shape of the questions you will be able to answer for as long as you keep the data.
The person, event and property model is deliberately small. Three objects, and almost every question a business asks about customers can be expressed in them. This is what each one is, what the choice buys, and what it costs.
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.Three objects, and what each one is for
The model is small on purpose. Most of the discipline is in deciding where a piece of information belongs.
A.Person: the anchor
A person is one human, tracked across every device and session they ever use. They begin anonymous, identified by a cookie or a generated identifier, and at some point they supply something stable, an email or an account ID, and the two histories merge.
The merge is the important part. Everything that person did before identifying themselves remains attached to them afterwards, so the blog post they read three weeks before signing up is on the same record as the payment. That single behaviour is what makes first-touch attribution possible at all.
A session-based model has no equivalent. It has visits, and a visit has no memory of the one before it.
B.Event: a thing that happened, at a time
An event is a named action with a timestamp, belonging to a person. Signed up. Ran a report. Purchased. Cancelled.
Two rules. Events are immutable, because they are a record of the past and the past does not change. And they are named after what the person did, not where they were when they did it. “Viewed /pricing” is a pageview wearing an event's clothing; the URL will change in the next redesign and the history becomes uninterpretable. “Viewed pricing” with the page as a property survives.
C.Property: context, and where you put it matters
Properties are key-value pairs attached to either an event or a person, and choosing which is the single most consequential modelling decision you will make repeatedly.
An event property describes the moment: which plan was purchased, which device was used, which campaign brought them. It is fixed forever, because it describes something that already happened.
A person property describes current state: current plan, company size, lifecycle stage. It is overwritten as things change, and the old value is gone.
Put a moment on the person and you destroy history the moment it changes. If plan is only a person property, then a customer who upgrades in March makes every purchase they ever made look like it was on the new plan, and your revenue-by-plan report silently rewrites itself.
Where each piece of information belongs
Data model view| Information | Event property | Person property | Why |
|---|---|---|---|
| Plan at time of purchase | Yes | Also, as current plan | The moment and the state are different facts |
| Device used | Yes | No | People are not mobile; sessions are |
| Acquisition source | On first event | Yes, first touch | Must survive to the purchase |
| Company size | No | Yes | Attribute, not a moment |
| Order value | Yes | No | Belongs to the order |
| Lifecycle stage | No | Yes | Current state by definition |
| Experiment variant | Yes | Yes, while enrolled | Both, and for different reports |
II.The model decides which questions are askable
This is not about convenience. Some questions are unanswerable in a session model regardless of effort.
A.What a session model can and cannot reach
A session-based tool answers questions about visits extremely well. How many people came, which pages they saw, where they left, which channel sent them. For a content site measuring reach, that is the right model and a person-based one would be overkill.
It cannot answer questions whose subject is a person over time. Not slowly, not with effort: the join does not exist in the data. Which customers who read the pricing page in March eventually upgraded. What the people who churned in Q2 did differently in their first week. Whether the cohort acquired from a channel in January is still paying.
Each of those requires connecting behaviour separated by weeks to one identity, and a session model has thrown away the connection at the session boundary.
B.The cost of the person model
It is not free and the trade is worth stating plainly.
Identity is required. The model only works if you call identify when somebody gives you a stable identifier. Miss those calls and you have a person-based tool recording anonymous fragments, which is worse than a session tool because it looks like it is working.
It is heavier. Retaining full per-person history costs more than aggregating sessions. That is the price of being able to ask a question you had not thought of when the data was collected.
It is personal data. A record of one human's behaviour over years carries real obligations: retention limits, deletion requests, access control. A tool built around people should make deletion straightforward, and if it does not, that is a reason to look elsewhere. Our privacy-first analytics guide covers the governance side.
III.Designing yours, and the four mistakes that are expensive to undo
Schema errors are cheap to fix in week one and very expensive in month nine, because the history is already wrong.
A.Start from questions, not from pages
Write down the ten questions the business will actually ask. Which channel produces customers who stay. Where does onboarding lose people. Which feature predicts renewal.
Then work backwards to the minimum events and properties needed to answer them. This produces a small schema, and a small schema is the objective. Teams that start from “what could we track” produce four hundred events and answer nothing, because no two of them are named consistently enough to join.
B.The four mistakes
Pageview-shaped events. Tracking “Viewed /checkout/step-2” instead of “Started checkout”. The first breaks at the next redesign and cannot be compared across it.
Moments stored as person properties. Described above, and the most common. It silently rewrites history.
No identify call, or one call at signup only. Identify at every point a stable identifier appears: newsletter form, email click, support conversation, login. Each missed one is an anonymous fragment that never joins the person it belongs to.
Unbounded property values. A property whose value is a free-text search query or a raw URL has effectively infinite cardinality and cannot be grouped by, which means it cannot appear in a report. Bucket it, and keep the raw value only if you have a specific use for it.
C.Or start from a draft
The reason schemas come out badly is that they have to be written before anyone knows which questions will matter, by whoever is implementing tracking, under time pressure. It is the hardest decision in the project and it is scheduled first.
Kissmetrics starts you from a draft instead of a blank page. Point it at your site and it works out what kind of business you run and what is worth capturing for one. Once events are arriving, the schema page lists every event, the properties each one carries, when each last fired and the role it plays, with a picker to change any of it. Correcting a draft is a different task from producing one, and the draft avoids two of the four mistakes above by construction, because it names events after actions and puts moments on events as a matter of course.
The correction still matters. If it decides your newsletter signup is the primary conversion because it looks like one from outside, you want to catch that in an afternoon. See which events deserve to be conversions and the tracking plan template.
Verdict
Person, event, property is three objects and a rule about where things go: if it was true at a moment it belongs to the event, if it is true now it belongs to the person. Almost everything a business asks about customers fits.
The choice of anchor is the choice of which questions exist. A session model answers what happened, cheaply and well. A person model answers who it kept happening to, which is where retention, lifetime value and attribution live. Pick deliberately, because the questions you cannot ask will not announce themselves.
Continue Reading
Person-Level Analytics: Why Individual User Tracking Drives Revenue
A session is a timeout window scoped to one browser, so one buyer on three devices arrives as several unrelated rows. Resolving them into people fixes attribution and lifetime value, and costs coverage, consent, and the risk of merging two strangers into one profile. Here is when that trade is worth making.
Read articleThe Ultimate Tracking Plan Template: Event Specification Guide for Analytics
Every analytics implementation starts with good intentions and ends in chaos without a tracking plan. This guide provides naming conventions, property standards, complete examples, and a template to ensure clean, consistent, trustworthy data from day one.
Read articleCustom Event Tracking: How to Track What Matters Without the GA4 Complexity
GA4's event model is powerful in theory but frustrating in practice. Between the 500-event limit, 25-parameter cap, and GTM dependency, most teams track less than they should. There is a simpler way.
Read article