Comparison
Good tools. None of them score traffic.
These are genuinely good, inexpensive, privacy-first tools and we recommend them regularly. They report what happened. What none of them do is tell you whether the traffic was any good — and on collection architecture we are closer to them than to Google.
First, the fair part
What these tools do well.
- They are genuinely privacy-first. Cookieless by default in most cases, no cross-site identity graph, and a clear position on what they will not do with your data. That is a real commitment, not marketing.
- They are cheap and predictable. Self-hosting costs infrastructure; cloud tiers are inexpensive. Compared with an engagement, this is not a close call on price.
- They are fast and light. Small scripts, simple dashboards, and a deliberate refusal to grow into a platform. That restraint is a design achievement.
- They are yours. Self-hosting gives you full control over infrastructure and data residency, which for some organisations settles the question entirely.
- Several are open source. You can read exactly what is collected. Nothing we offer substitutes for that.
Where we actually diverge
On collection architecture, we are close. These tools already avoid the third-party request problem, either through self-hosting or through custom-domain collection on their cloud tiers. We are not going to claim a meaningful first-party advantage over a well-configured self-hosted install, because there is not one.
The divergence is on the two things after collection.
The first is what the data is ranked against. These tools report traffic and support goals, and their reporting is oriented around visits, sources and pages, with conversions as an additional column. Wardly inverts that: one conversion event is the axis, and every source, campaign and entry point is ordered by measured performance against it. That is a different default, and defaults are what people actually read.
The second is who does the work. These are self-configured products, deliberately so — the whole appeal is that you can install one in an afternoon and own it. Wardly is a deployment. Somebody who does this for a living defines the conversion event with you, wires it, verifies it against live traffic, and builds the reporting around your team. That is most of the cost difference, and it is the whole product.
Visitor-level scoring, and why they don't do it
Most privacy-first tools deliberately avoid building visitor-level profiles. It is a coherent position and it is a large part of why people trust them.
Wardly does score at visitor level: every session gets a behavioural score, and once enough conversions have accumulated, visitors get a likelihood estimate trained on your own history. That is a real difference in what is being built, and it is worth being clear-eyed about rather than presenting it as a pure upgrade.
What it is not is cross-site tracking. Scoring runs against an anonymous browser-level identifier, on your site only, and produces no identity resolvable against anything else. If your objection to visitor-level measurement is philosophical rather than about cross-site exposure, these tools are the better fit and we would rather you used one.
The honest cost comparison
A self-hosted tool costs infrastructure and an afternoon. A cloud tier costs a modest monthly subscription. Wardly is an engagement, and it is materially more expensive than either.
The comparison that makes sense is not tool versus tool. It is a subscription plus the internal time to define, configure and maintain the measurement, against an engagement where that work is the deliverable. For a business where nobody currently owns that work — which is most of them — the second is often the cheaper way to get a correct answer. For a business where somebody does own it and enjoys it, it plainly is not.
Side by side
The comparison, dimension by dimension.
| Dimension | Self-hosted tools | Wardly |
|---|---|---|
| Primary job | Report site traffic accurately and privately, without the weight and complexity of a general-purpose platform. | Rank every visitor and traffic source against one defined commercial conversion event. |
| Who sets it up | You. Installation is deliberately simple, and configuration beyond that is left to you. | We do, as the engagement, including defining the conversion event and building the reporting. |
| Hosting | Self-host it yourself, or pay for the vendor's cloud. Both options are usually offered. | Deployed to run under your own setup as part of the engagement. |
| Conversion measurement | Goals and custom events are supported. Ranking is by traffic; conversions are a column rather than the axis. | One event is the axis. Every channel, campaign and entry point is ordered by measured performance against it. |
| Visitor-level scoring | Generally out of scope by design — these tools intentionally avoid building visitor-level profiles. | Every session is scored behaviourally, and visitors are scored against conversion likelihood on your own data. |
| Cost model | Low and predictable. Self-hosting is free plus your infrastructure; cloud tiers are inexpensive. | A paid engagement, scoped per deployment. Materially more than a subscription, because it includes the work. |
| Ongoing effort from you | Upgrades, infrastructure and configuration are yours, unless you use the vendor cloud. | Configuration and review are ours, as part of the engagement. |
Stay self-hosted if
- What you actually need is accurate, private traffic reporting — and these tools do that well, cheaply.
- You have someone who enjoys owning the configuration and will keep it current.
- Your conversion is simple, low-stakes, or already well understood, so ranking against it is not a live question.
- Budget is the binding constraint. A subscription and an afternoon is a very different commitment from an engagement.
- Data residency or full infrastructure control is the requirement, and self-hosting satisfies it directly.
Questions
Common questions.
Aren't these tools already first-party?
Broadly yes, and it is one of the main reasons to use them. Self-hosted deployments serve collection from infrastructure you control, and the cloud tiers of several of these vendors support custom-domain collection. On the collection question specifically they are close to Wardly, and we would not claim otherwise. The separation is what happens to the data afterwards.
So what is the actual difference?
Two things. These tools report traffic; Wardly ranks against one conversion event and scores visitors against the likelihood of it. And they are self-configured products; Wardly is a deployment where the definition, the wiring and the reporting are done with you. If you take away the second, we would be a more opinionated tool. It is the second that makes it a different category.
Can we not just add goals to Plausible or Matomo and get the same thing?
You can and should define goals — it is a real improvement over raw traffic. What you will not get is every report ordered by performance against that goal by default, or per-visitor likelihood scoring trained on your own history. And you will still be the one deciding what the goal should be, which is the part most teams get wrong.
Is Matomo not much more full-featured than this?
Matomo is a large, mature product with a wide feature surface, including features Wardly does not have. Feature count is not the axis we are competing on. The question is whether someone has configured the thing around a specific commercial outcome, and with a self-hosted install that someone is you.
We already self-host something. Does that make deployment easier?
Usually yes. Teams already running self-hosted analytics tend to have the access, the technical contact and the appetite for infrastructure work, which removes most of the friction from deployment. It also tends to mean the conversion definition conversation is the whole project, which is a good place to start.
See which of your channels brings buyers.
A 30-minute call on your site, your traffic and the one conversion worth scoring against.