Simple Analytics
For analysts
Why Simple Analytics can collect sessions without consent
Before you stop reading: when we say that Simple Analytics collects sessions, we do not mean sessions in the traditional analytics sense.
Observed
Pageviews and events
The underlying records describe what happened.
Calculated
Session starts
Pageview context determines unique or non-unique.
Never created
Visitor identity
No cookie, fingerprint, persistent ID or user profile.
We don't hash an IP address and User-Agent into a visitor identifier. We don't store a persistent session ID in a cookie or local storage. And we don't use sessions to recognize a person across separate visits or reconstruct their browsing history.
There is no tiny anonymous detective following you around.
Instead, Simple Analytics looks at each pageview independently and determines whether that pageview starts a new visit or continues an existing one. We get a useful session count without first creating an identity for the visitor.
For analysts, this distinction is important. It means you can have a stable session metric across your complete traffic, instead of having session counts depend on whether someone accepted a cookie banner.
Let's look at how that works.
A session without a visitor ID
The basic Simple Analytics data model is pageviews and events.
For every pageview, we determine whether it is unique or non-unique. A unique pageview starts what we call a session.
The most important signal for this is the referrer. Our documentation on unique visits describes the exact logic.
Imagine someone finds your website through Google:
new session starts
The referrer is external, so /pricing is a unique pageview and starts a new session.
They then click your features page:
same session continues
The referrer belongs to the same website, so this is a non-unique pageview and remains in the same session.
This produces slightly different session semantics from Google Analytics.
Leave a website, then come back later
Leave the tab open for five hours, then navigate internally
Refresh the page
Simple Analytics can detect reloads and browser history navigation as non-unique pageviews as well.
There is no arbitrary 30-minute timer that suddenly decides your coffee break constitutes a new human being.
More importantly, none of this requires us to answer the question:
Not our question
Who is this visitor?
That would require recognizing the same person.
Our question
Does this pageview look like the start of a visit?
This only requires the context of the pageview.
Those are fundamentally different problems.
What we actually collect
A useful analytics tool obviously needs to collect something. A dashboard containing one very privacy-friendly zero would not be especially helpful.
For normal pageviews, Simple Analytics can collect things such as:
These values are documented in our data collection documentation, and individual metrics can be disabled.
The important property is that these values are attached to a pageview or event. We do not combine them to create a fingerprint that represents a visitor.
Useful — what happened
Observed event context
{
"path": "/pricing",
"referrer": "google.com",
"utm_campaign": "enterprise-q3",
"browser": "Firefox",
"country": "NL"
}A very different thing — who
A visitor profile
{
"visitor_id": "abc123",
"first_seen": "2026-06-20",
"previous_visits": 7,
"pages_this_session": [...]
}For example, knowing that the first happened is useful. Creating the second would be a very different thing. Simple Analytics deliberately doesn't build the second dataset.
Our documentation also explicitly states that we drop IP addresses rather than storing or hashing them. You can inspect the complete list on our data collection page.
Why this matters when consent enters the picture
This difference becomes particularly useful in Europe.
Traditional analytics usually starts with an identifier. Once you have an identifier, you can connect pageviews into sessions, sessions into users, and users into conversion journeys.
Consent then creates an awkward problem.
100 visitors, 40% decline consent
If 40% of visitors do not consent, you don't merely lose 40% of your pageviews. You also lose the identifiers that make concepts such as users, sessions, journeys and attribution work.
Google Consent Mode is Google's solution to that problem.
Simple Analytics avoids creating the problem in the first place.
How Simple Analytics differs from Google Consent Mode
With Advanced Google Consent Mode, Google tags can still send cookieless pings when analytics_storage is denied. According to Google's Consent Mode documentation, these requests can contain information such as a timestamp, User-Agent, referrer, consent state and a random number generated on each page load.
But without Analytics consent, those events are no longer associated with Google's normal persistent user identifier.
Google describes the consequence very clearly in its behavioral modeling documentation:
“Analytics applies machine learning to estimate the behavior of those users”
Google uses behavior from similar consenting users to estimate what happened among visitors without identifiers.
That's clever. It is also a very different data model.
Google effectively has
Observed plus estimated users and sessions
consented traffic → observed users & sessions
plus
non-consented traffic → cookieless events → behavioral model → estimated users & sessions
Simple Analytics has
An observed session count
pageview → observed pageview context → unique or non-unique → session count
We don't try to estimate how many invisible people probably generated the events.
We intentionally avoid needing the people.
Why analysts should care about modeled sessions
Behavioral modeling solves a real problem for Google Analytics, but it creates another one for technical analysts: part of the report is now an inference rather than a direct aggregation of the underlying events.
Google itself says that if Analytics receives ten pageviews without identifiers, it cannot determine whether those pageviews came from one user or ten users. Its model estimates the missing behavior from consenting traffic.
That makes apparently simple questions harder:
Debugging question
Why did sessions fall 12%?
- ?Was traffic actually down?
- ?Did consent rates change?
- ?Did the CMP implementation change?
- ?Did modeled traffic become available?
- ?Did Google's model change?
- ?Are we looking at observed or blended reporting?
- ?Can we reproduce this number from our warehouse?
Google also acknowledges that behavioral modeling can cause differences between standard reports and explorations in its documentation on data differences between reports and explorations.
For an analyst, "the model knows" is not always the most satisfying debugging strategy.
Simple Analytics takes the opposite trade-off. We sacrifice some user-level detail so the aggregate metrics can remain based on events we actually observed.
That makes Simple Analytics particularly useful as a baseline alongside GA4 or Adobe Analytics.
Your consent-based platform can answer detailed questions about the users who consented. Simple Analytics gives you a stable number for the complete traffic population.
This is how we increasingly see enterprises use Simple Analytics: not necessarily replacing their existing analytics stack, but complementing it with a consent-independent baseline. Our enterprise analytics page describes this setup.
For quarterly traffic trends, that baseline can be significantly easier to trust. Your Q3 session count doesn't suddenly move because Q3 happened to have a better cookie-banner acceptance rate.
But what does ePrivacy actually say?
This is where it gets interesting.
The relevant EU legislation is Article 5(3) of Directive 2002/58/EC, commonly called the ePrivacy Directive. The core rule says that
“the storing of information, or the gaining of access to information already stored, in the terminal equipment”
Article 5(3) then provides two exceptions. Consent is not required where the storage or access is solely necessary to transmit a communication, or where it is strictly necessary to provide a service explicitly requested by the user.
This is important because the Directive does not say:
It doesn't say any of those. The law is technology-neutral. The question is what information is stored on or accessed from the visitor's terminal equipment and whether an exemption applies. Our legal and compliance overview reaches the same framework.
“Cookieless” is not a legal argument
This is where privacy analytics sometimes gets a little too enthusiastic.
Not using cookies is good. It doesn't automatically mean Article 5(3) disappears.
The EDPB's Guidelines 2/2023 interpret the provision broadly. They explicitly discuss HTTP headers, User-Agent information, IP addresses, URL tracking and other mechanisms that don't involve traditional cookies.
The EDPB also makes an important distinction:
“the applicability of this article does not systematically mean that consent needs to be collected.”
In other words: the technical-scope guidelines deliberately do not decide whether one of Article 5(3)'s exemptions applies.
That distinction gets lost surprisingly often.
Our legal analysis therefore doesn't depend on saying "no cookies, therefore no ePrivacy." It looks at what Simple Analytics actually does with each piece of information.
And there is still legal uncertainty. The EDPB's interpretation is broad, its guidelines are not legislation, and our legal report explicitly avoids pretending every question has already been answered by a court.
We would rather explain that uncertainty than solve it with a larger font size on the word "cookieless."
Why Plausible and Fathom can offer more traditional sessions
This comparison makes the architectural difference clearer.
Plausible explains in its data policy that it calculates a daily identifier as:
Daily identifier
hash(
daily_salt
+ website_domain
+ ip_address
+ user_agent
)The salt rotates every 24 hours — but within that day, the identifier exists so repeated requests can be recognized as the same visitor.
The salt rotates every 24 hours, so Plausible deliberately prevents the identifier from persisting across days. That's significantly more privacy-friendly than a traditional persistent tracking cookie. But within that period, the identifier exists specifically so repeated requests can be recognized as belonging to the same visitor.
Fathom uses a similar concept. Its data documentation describes a user signature based on values including IP address, User-Agent and hostname.
From an analytics perspective, that's useful:
But read that alongside the EDPB guidance.
The EDPB specifically discusses IP-based navigation tracking and states that Article 5(3) can apply where IP addresses originating from terminal equipment are used to track navigation. It separately identifies User-Agent and HTTP headers as mechanisms that can trigger Article 5(3), particularly for fingerprinting or tracking identifiers.
Hashing the values afterwards doesn't change the operation that happened before the hash:
Our reading is therefore that this kind of construction is materially harder to fit within Article 5(3)'s transmission exemption. The IP address isn't being used solely to transmit an HTTP request anymore. It is also an input into an analytics identifier.
That does not mean we're declaring Plausible or Fathom illegal. The EDPB guidelines are not a court ruling, and Article 5(3) exemptions still need to be assessed.
It does mean we made a different engineering choice.
Simple Analytics does not try to make a more privacy-friendly visitor identifier. We avoid making the visitor identifier.
What do we lose?
Quite a bit, if your job is to follow a person around.
Suppose someone does this:
Monday
Google Ads → /product
Wednesday
Direct visit → /pricing
Friday
Direct → /checkout → purchase
Without an identifier connecting those visits, Simple Analytics cannot truthfully tell you: this Friday purchase belongs to Monday's Google Ads click.
That requires tracking across visits.
There is no clever referrer trick that changes this. If you need exact cross-session campaign attribution, you need something that links the Monday visitor to the Friday visitor.
Simple Analytics deliberately does not do that.
This is why running Simple Analytics alongside a consent-based analytics platform can make sense. Use the tracking platform where you genuinely need attribution and user journeys, and where you have the appropriate consent. Use Simple Analytics for the traffic baseline that doesn't disappear when consent does.
Funnels without pretending we know the person
Funnels follow the same philosophy.
A traditional funnel might ask: of these exact 10,000 visitors who viewed /product, how many of those same people later purchased? That requires connecting events to people.
A Simple Analytics funnel can instead ask:
Then calculate the aggregate relationship between those steps.
We know 10,000 product views happened. We know 800 checkout visits happened. We know 320 purchases happened.
We do not invent a relationship claiming that those exact 320 people originated from the first bucket.
You could call them aggregate funnels. Internally, "funky funnels" is admittedly harder to forget.
This gives analysts a useful measure of how a conversion flow performs without constructing a user journey behind it.
The limitation is also clear. If your question is which campaign generated this exact purchase three days later? — Simple Analytics cannot answer it without introducing tracking.
That's a feature boundary, not a missing SQL query.
What can I add to the data layer?
The same principle applies to custom events and metadata.
Send information about what happened, not who did it.
Good — describes the event
Business context
sa_event("checkout", {
product_id: "pro-annual",
plan: "enterprise",
price: 499,
currency: "EUR",
checkout_step: 3,
experiment_variant: "pricing-b"
})Avoid — a backdoor identity layer
Persistent identifiers
{
user_id: "847238",
email: "person@example.com",
session_id: "abc123",
account_owner_id: "..."
}The good properties describe the event, product or business context.
Once you intentionally add an identifier that lets you reconnect the same person later, you've changed the privacy model. Calling the field totally_not_a_user_id unfortunately does not help.
Simple Analytics events are designed to count actions and attach useful metadata to them, rather than require a user profile. See the events documentation.
What this gives an enterprise analytics team
For many larger organizations, the useful setup isn't Simple Analytics or GA4/Adobe.
It's both.
Your consent-based stack keeps doing
Things that require tracking
- detailed conversion attribution
- persistent user journeys
- retention
- cohorts
- user-level funnels
- multi-session campaign attribution
Simple Analytics provides another layer
Consent-independent, across all traffic
- total pageviews
- consent-independent session trends
- events, referrers, UTMs, pages, countries
- aggregate conversion trends
- raw data for your warehouse
This gives analysts a stable denominator.
Adobeconsented only
6.4M
Simple Analyticsall traffic
8.1M
If Adobe says you had 6.4 million sessions this quarter and Simple Analytics says 8.1 million, that gap is itself useful information.
More importantly, Simple Analytics can give you a number whose collection methodology doesn't change depending on how many visitors clicked "Accept all."
That makes year-over-year and quarter-over-quarter analysis less dependent on CMP design, consent rates and changes to your tracking setup.
It is also why we don't position Simple Analytics as a magical replacement for every analytics use case. Tracking gives you capabilities that non-tracking analytics intentionally cannot provide.
The interesting question is not
How can we track users more anonymously?
A different kind of identifier is still an identifier.
It's
Which analytics questions actually require us to track a user at all?
Start with the analytical question, then choose the minimum necessary data model.
For sessions, traffic trends, content performance, referrers, campaigns, pageviews, events and many aggregate conversion questions, our answer is: fewer than you might think.
And that's how Simple Analytics can give analysts a real session metric without first giving every visitor an identity.
