Hi Product Hunt!
Today I'm launching JAMP! An agentic analytics tool, that is extremely lightweight, cookie-free, and has a generous free tier!
We do Analytics, Error Tracking, Uptime, Performance, and more. Basically an all-in-one monitoring suite for your website, so you can tell exactly what users are doing on your website, where they've come from, and where they are dropping off.
Our biggest differentiator? JAMP is built for Agentic web development. You can connect to our MCP server and pipe all your site's data directly to your AI agent.
Here’s how it works: An API fails to one of your users. JAMP collects the error in real-time and alerts you via Email/Discord/Slack. You then ask your AI agent to retrieve the stack trace and the exact sequence of user actions leading up to the crash, allowing the agent to deliver a precise, immediate fix.
Giving you faster debugging, faster development times, and insights for you to make business decisions
We're giving out free Pro for life if you can give us feedback!
If you have any questions, feel free to comment below
Cheers
Replies
Congrats on the launch!
Lemme ask one thing on "cookie-free", because I went through this exact question this week with the tracker on my own site: cookie-free only does work for you if you say precisely what the script does and does not keep in the browser and on your server. I ran a cookie-free analytics tool behind a consent banner for two weeks, out of caution, and it counted 3 to 6 visitors a day because nobody clicks Accept. Dropped the banner once I could write down in the privacy policy exactly why there was nothing to consent to.
What does JAMP store client-side, and do you hash IPs or keep them?
@siarheihamanovich
Thanks, and honestly that banner experiment is the exact thing I did too, so this is a fun one to answer.
Short version: in the browser, JAMP keeps nothing. No cookies, no localStorage, no fingerprinting. The script is about 1KB and the only thing it "remembers" is the current URL in a variable so single-page apps don't double-count, and that's gone the second the page reloads. Every pageview just sends the site ID, the URL, the referrer, and an optional release tag.
On IPs, we never store them. The IP shows up for a split second in memory to rate-limit and to feed one thing: a salted hash. The visitor "ID" is basically HMAC-SHA256 of (today's date + IP + user agent) with a secret key, and the important part is that the salt is the date, so tomorrow the same person hashes to something completely different. There's no durable identifier to follow anyone around, which is the whole reason there's nothing to consent to.
If you looked at an actual row in our database you'd see: time, site ID, that daily hash, the event, URL, referrer, browser, OS, country, release. No IP anywhere, and not even the raw user agent, we turn it into "Chrome / macOS" on the server and bin the rest. Country is just an edge header, not an IP lookup we keep.
So the privacy-policy line that let me finally kill the banner was basically: no cookies or IDs in the browser, no IP storage, visitors counted with a hash that resets daily. Happy to go deeper on any of it.
@jack_williams38 That's a clean answer, thanks. Rotating the salt by day is the part that does the work, and it is the same reason I could drop my banner.
The price of it is worth saying out loud though, because it is a product decision and not a privacy one. With a salt that resets every day, you cannot tell a returning visitor from a new one after 24 hours. So "unique visitors" for a week is not really unique, it is the sum of seven days, and the same person counts seven times. Retention and cohorts are off the table completely. I am fine with that on my own site, I only look at daily numbers, but for a tool that sells "where users drop off" it is a real limit.
How do you show that in the UI? I would rather see a tool say "sessions, counted daily" than quietly add them up.