Cookieless, self-hosted product analytics: why we built Linqry
Cookieless, self-hosted product analytics without the GDPR risk or per-event bills: why we built Linqry, how it works and what it trades off.
By FutureGen Systems
Every product we ship eventually raises the same question: where did this user come from, where did they get stuck, and did they ever pay? For years the answer meant choosing between two bad options. Pageview tools were simple and privacy-friendly but stopped at "how many people visited". Full product analytics suites answered the real questions but brought cookies, consent banners and pricing that grows with every event you track. We wanted cookieless, self-hosted product analytics that still did funnels, cohorts and revenue, so we built Linqry.
This post explains the trade-off that pushed us there, how Linqry handles privacy, and where it is and isn't the right fit.
The trade-off: GDPR risk or per-event pricing
Most teams pick an analytics tool long before they think about it properly, and then live with the consequences.
Cookie-based analytics works by giving every browser a persistent identifier. That makes cross-session tracking easy, and it is also exactly what the GDPR and the ePrivacy rules care about. In practice it means a consent banner, a share of visitors who decline (and vanish from your data), and a legal question every time you add a new script.
Hosted product analytics gives you funnels, retention curves and user paths, but the pricing is usually tied to event volume. That creates an odd incentive: the more carefully you instrument your product, the more you pay. Teams end up tracking less than they should, sampling, or deleting events to stay under a tier. Your raw behavioural data also lives in someone else's infrastructure.
Lightweight pageview tools solve the privacy problem, but they were never designed to tell you that 40% of a hypothetical signup flow drops off at the "connect your bank" step, or which campaign produced paying customers rather than just visitors.
We needed the product questions answered without the cookie and without a bill that punishes good instrumentation.
How Linqry stays cookieless by default
Linqry's tracker is under 2 KB and sets no cookies. Instead of a persistent browser ID, visitors are identified with a server-side HMAC that uses a salt which rotates daily. Within a day, Linqry can tell that a run of pageviews belongs to one visit. Once the salt rotates, there is no way to link that visitor to the next day's activity, so long-term cross-session tracking is impossible by design rather than by policy.
No personal data is stored, which is why Linqry is built to be GDPR and ePrivacy compliant without a consent banner. As always, your own legal position depends on what else you run on the page and what you send to it, so check the full setup with whoever owns compliance on your side. The point is that the analytics layer is no longer the thing creating the risk.
The honest trade-off: if you want to follow a single anonymous visitor across weeks, a cookieless design won't do that. We think that is the right default. For most product questions you care about aggregates and about users who have signed up, not about re-identifying anonymous browsers.
What you get beyond pageviews
Linqry was built to replace Google Analytics and Plausible for teams that need more than visit counts, specifically onboarding funnel visibility and revenue attribution in one dashboard. The main views:
- Onboarding funnels: sankey-style funnels showing the drop-off percentage between every step, so you can see exactly where new users leave.
- User flows: the most common paths through your product, entry pages, exit links and where journeys split.
- User lifecycle: new, returning, dormant and reactivated users over time, grouped by stage.
- Retention and cohorts: daily, weekly and monthly retention curves grouped by signup cohort, source or plan.
- Revenue attribution: send payment events with a simple API call and see revenue broken down by channel, page, campaign and country, with no third-party integrations required.
- Real-time dashboard: live visitor count, current pages and top sources, refreshed every few seconds.
- Built-in SEO auditor: crawls your site for title, meta, redirect and broken-link issues and gives each page a score.
Revenue attribution is the one we lean on most. Knowing a blog post drove traffic is mildly interesting. Knowing it drove paying customers changes what you write next.
Self-hosting with Docker
Linqry is MIT-licensed and fully self-hostable with a single Docker command. Under the hood it is a Next.js application on PostgreSQL with TimescaleDB for the time-series data, so there is nothing exotic to operate. It is designed to run comfortably on a small VPS.
Self-hosting gives you three things a hosted tool can't:
- Your data stays on your infrastructure. Behavioural data never leaves a server you control, which simplifies data-processing agreements.
- No per-event pricing. Your cost is the server. Instrument every step of onboarding without worrying about the bill.
- You can read the code. With an MIT licence you can audit exactly what the tracker collects, and change it.
There is also a managed cloud version, with a 30-day free trial and no credit card required, for teams that would rather not run another service. Details are on linqry.com.
What self-hosting asks of you
Running your own analytics is not free of effort. Before you choose it, be honest about:
- Backups. Analytics data feels disposable until someone asks for last year's numbers. Back up the PostgreSQL database like any other production store.
- Upgrades. Pull new releases on a schedule rather than when something breaks.
- Monitoring. If the collector is down, you silently lose data. Put an uptime check on the tracking endpoint.
- Ad-blockers. Some block analytics scripts by name or path regardless of privacy. Serving the tracker from your own domain helps.
If those are already part of how you run servers, self-hosting is a small addition. If they aren't, the managed version is the sensible choice.
When Linqry is the right fit
Linqry suits you if:
- you run a SaaS product or web app and want onboarding funnels and retention, not just traffic;
- you sell to EU customers or simply don't want a consent banner on your marketing site;
- you want to tie revenue back to channels and campaigns without wiring up several tools;
- you'd rather pay for a server than for event volume.
It is probably not the right fit if you need cross-device identity resolution for advertising, or session replay of individual users. Those features depend on exactly the kind of persistent tracking Linqry deliberately avoids.
Getting started
The quickest test is to run it alongside your current tool for a couple of weeks. Add the tracker, send a payment event from your billing webhook, define your onboarding funnel, and compare what each tool tells you. If the cookieless numbers are close enough for your decisions, you can drop the consent banner and the cookie-based script.
Linqry is one of several products we build and run ourselves; the rest are on our projects page. If you want help instrumenting a product, setting up self-hosted analytics, or wiring revenue events into your billing flow, tell us what you're working on.