"You own your data" appears on the homepage of nearly every analytics product, including ones where it is not true in any sense that would matter to you.
Four questions separate the claim from the reality. They are worth asking of any tool, including this one.
One: where do the bytes physically live?
Not "where is it processed" or "which region is it in" — whose account is billed for the disk.
In your infrastructure account means the database is in your cloud console, under your billing, subject to your access controls. If the vendor disappears tomorrow, the data is still there and still yours.
In the vendor's infrastructure means you have an export feature. That is a promise, not possession, and it is only as good as the company's continued existence and cooperation.
Both are legitimate products. Only the first is ownership.
Two: can you query it directly?
The revealing question, because it separates real access from a supported export path.
If your analytics data is in a database you can connect to and run SQL against, you can answer questions the product's authors never thought of. Join it to your orders table. Compute something the dashboard does not offer. Feed it into a warehouse.
If your only route is a CSV button, you have what the vendor decided to give you, in the shape they chose. That shape will eventually be wrong for a question you want answered, and there will be nothing to do about it.
Three: what happens if you stop paying?
Data in your account: nothing happens. It is your database. You stop getting updates and support; the data and the dashboard keep working.
Data with a vendor: you have an export window and then it is gone. Some vendors are generous about this. Generosity is a policy, and policies change with ownership.
Worth asking about one-time-licence products too, including this one — the honest answer for a self-hosted tool should be that the deployment keeps running because it never phoned home in the first place, and cannot be switched off remotely by anyone. If a self-hosted product can be disabled from outside, it is not self-hosted in the way that matters.
Four: does anyone else see your visitors' traffic?
The one people forget, and the one that matters most for the people you are measuring.
With hosted analytics, your visitors' browsers make requests to a third party's servers. That third party sees IP addresses, user agents and page URLs for every person who visits you. Whatever their policy says, the data crossed their network.
With genuinely self-hosted analytics on your own domain, your visitors talk only to you. There is no third party in the path, so there is no third-party policy to read, no sub-processor to list, and nothing to disclose in a privacy notice beyond what you do yourself.
This is the difference that shows up in a data protection assessment, and it is why the answer to "who are your sub-processors" being "nobody" is worth something concrete.
What ownership does not give you
Being honest in the other direction, because overclaiming here is how the phrase became meaningless.
It does not make you compliant. You are the controller either way. Self-hosting removes a processor from the chain; it does not remove your obligations. Whether you need a consent banner depends on what the tool stores on the device, not on who runs the server.
It does not make the data better. A self-hosted tool measuring from a browser script has exactly the same blind spots as a hosted one measuring from a browser script — blocked visitors and crawlers — because that limitation comes from where the measurement happens, not from who owns the disk.
It does not remove operational responsibility. Something has to be upgraded, and something will break at some point. With a hosted product that is somebody's job. With a self-hosted one it is yours, and that is a real cost that should be counted honestly against the licence you did not buy.
The one thing self-hosting uniquely enables
Beyond ownership, there is exactly one capability that comes from running the software yourself rather than buying it as a service: your analytics can sit in your site's request path.
A hosted vendor cannot do that, and not because of their roadmap — for them to count your HTML requests, your visitors' traffic would have to route through their infrastructure, making them a dependency of your site being reachable rather than just of your reporting. Nobody sensible offers that and nobody sensible accepts it.
Being in your own request path is what makes blocked pageviews and AI crawlers visible. It is the only item on this page that is a capability rather than a matter of principle, and it is the one worth choosing an architecture for.
Common questions
Does self-hosted analytics make me GDPR compliant?
No. You are the data controller either way, and self-hosting removes a processor from the chain rather than removing your obligations. What it does change is that there is no third party receiving your visitors' IP addresses and page URLs, which simplifies your sub-processor disclosures and your data protection assessment considerably. Whether you need a consent banner depends on what is stored on the device, not on who runs the server.
What is the real difference between self-hosted and hosted analytics?
Three things: the database is in your infrastructure account rather than a vendor's, your visitors' browsers never contact a third party, and your analytics can run in your own request path. The first two are about ownership and privacy. The third is the only one that is a capability — it is what makes ad-blocked pageviews and AI crawler activity visible at all.
What happens to a self-hosted install if the vendor shuts down?
For a properly built one, nothing. The software runs in your own account and never contacts the vendor after installation, so there is no licence check to fail and no service to go offline. You lose future updates and support. If a self-hosted product can be disabled remotely by its vendor, it is not self-hosted in the sense that matters, and that is worth checking before buying one.