The analytics layer of your content stack is quietly becoming an agent interface
If you run social accounts for a living, you already know the dirty secret of the job: the publishing tools are fine, but the measurement layer is where the day goes to die. You can schedule thirty posts across five platforms in an afternoon; you cannot get a straight answer about which of them actually drove signups without opening four dashboards, reconciling three attribution models, and then arguing with a consent banner that half your EU traffic bounced off before it ever loaded. That is the gap Statable Analytics is aiming at, and it is worth your attention less because of what it does for websites and more because of what it signals about where analytics is heading — toward an interface your AI assistant queries directly, and away from the dashboard you log into by hand.
The maker, Yevhen Skrypets, launched it on Product Hunt with a pitch that will sound familiar to anyone who has ever sat through a GA4 course and realized they were not the target user: cookieless, EU-hosted in the Netherlands, no consent banner required for analytics, and — the part I actually care about — an MCP server that lets an AI agent read your numbers and, optionally, configure things. Free forever on .edu and GitHub or GitLab Pages. That is the whole pitch. No revenue figures, no user counts, no funding. Not disclosed, because he didn’t disclose them, and I’m not going to pretend otherwise.
So why am I writing about a web analytics tool on a blog about social media operations? Because the mechanics of how you get insight out of your traffic are about to change the same way scheduling did when Buffer and Later made the API calls someone else’s problem. And because the specific design trade-offs Statable made — cookieless identity, 24-hour rotating hashes, read-versus-write agent permissions — are the exact trade-offs you will be forced to make on your own stack within the next year, whether you adopt this product or not.
What problem it actually solves, and who feels that pain first
Let me be concrete about the operational reality. When I scheduled 30 posts across five platforms last month, the publishing side took maybe two hours. The reporting side took the rest of the week, because attribution across Instagram, TikTok, YouTube, X, and LinkedIn is a mess of native insights that don’t share a vocabulary, plus a website that is supposed to be the place where all that attention actually converts. The website half of that equation is where Statable lives. It is not a social scheduler. It is not a competitor to Buffer or Metricool or Hootsuite. It is the thing that tells you whether the traffic those tools sent you did anything.
The core claim — and I want to attribute this carefully, because it is a claim — is that Statable is cookieless, EU-hosted, and needs no consent banner for analytics. The maker frames this as a direct response to GA4’s bloat: “GA4 kept growing, with more reports and more setup, most of which I never opened.” That is a real complaint, and it is one I have heard from every operator I know who has tried to build a funnel in Google Analytics 4 without a dedicated analyst. The pitch is that you collect as little as possible, skip fingerprinting, and shape the product around European regulation rather than bolting compliance on afterward.
Why this matters more to EU-facing creators than US ones
If your audience is mostly US, the consent-banner problem is abstract. If you have meaningful EU traffic — and if you run a newsletter, a course, or a SaaS with any European reach, you do — the banner is a tax on every session. It suppresses your data, it suppresses your conversion rate, and it makes your funnel look like a cliff that isn’t really there. A cookieless analytics layer that doesn’t trigger the banner is genuinely useful, not just philosophically nice. This is the strongest part of the pitch, in my experience, and it is the part I would test first.
How it differs from the incumbents you already pay for
Here is where I have to be honest about the comparison landscape, because “GA4 alternative” is a crowded shelf. Plausible, Fathom, and Simple Analytics have all been selling privacy-first, cookieless, lightweight analytics for years. If you are shopping purely on “simple dashboard, no cookies, EU-hosted,” Statable is not first to that party and you should compare pricing and feature depth directly. The source doesn’t disclose pricing tiers beyond the free-for-.edu-and-Pages offer, so I can’t tell you whether it undercuts Plausible or Fathom on cost. Go check.
What actually differentiates Statable, based on the launch thread, is the MCP server. MCP — Model Context Protocol — is the interface layer that lets an AI assistant like Claude or an editor like Cursor call tools and read data on your behalf. The maker’s framing: “AI got good enough to take over my routine work, but agents had no way into analytics. That is what the MCP server fixed.” You connect with one OAuth sign-in, and you choose whether the assistant can configure anything or only read. Then you ask, in plain language, what moved last week, or describe a signup funnel in a sentence instead of clicking through a builder.
That is the interesting bet. The incumbents sell you a better dashboard. Statable is betting you won’t want a dashboard at all — you’ll want an answer.
The read-versus-write split is the detail that matters
Buried in the comments is the design decision I would actually evaluate the product on. A commenter, Gal Dayan, asked exactly the right question: if you grant only read access, can the agent still see raw visitor-level data — IPs, hashed IDs, individual sessions — or is it aggregated numbers only? The answer, from the maker’s colleague Anatolii Vasylenko, is that read access is aggregates only. IPs are used on arrival to look up geography and build a visitor hash, then discarded. The hash is salted daily and never exposed. No tool lists individual visitors or sessions.
That is a meaningful architectural choice, and it is the kind of thing most analytics vendors bury in a privacy policy nobody reads before granting OAuth access. Dayan’s follow-up — that this config “is basically the config I’d want to see documented on the site itself, not just in a comment thread” — is the correct critique. If you are piping traffic data through a model you don’t fully control, the permission boundary is the product. Right now that boundary lives in a Product Hunt thread. That is a trust gap, not a dealbreaker, but it is a gap.
The trade-off nobody puts on the landing page
Now the limitation, and it is a real one. Amy Bradley asked whether cookieless still captures enough detail for meaningful conversion analysis. The maker’s answer is refreshingly blunt: for conversions that happen within a visit, yes — goals, custom events with properties, funnels, and the source, UTM or referrer the person came from. Where it is weaker is a journey spread over several days. The visitor ID is a hash that rotates every 24 hours, so someone who reads on Monday and signs up on Thursday counts as two visitors, and the signup gets credited to Thursday’s source.
Read that again, because it is the single most important sentence for a social media operator evaluating this. If your content strategy depends on multi-touch attribution — the TikTok view on Monday, the newsletter open on Wednesday, the purchase on Friday — this tool will not tell you that story. It will tell you Thursday’s source got the credit, which is a lie of omission your CFO will eventually notice. The maker calls it “the trade we made for no cookies and no banner.” Fair. But you need to know which side of that trade your business sits on before you migrate anything.
Where the math breaks for social-first funnels
Social content is the worst-case scenario for short attribution windows. A creator’s funnel is almost never same-visit. Someone sees a Reel, doesn’t click, sees a carousel three days later, clicks to a link-in-bio, subscribes to the newsletter, and converts two weeks after that. A 24-hour rotating hash will chop that journey into four unrelated visitors and credit the last touch. If you are trying to prove that your TikTok content drives revenue, this tool will systematically undercount it — not because it is broken, but because it chose privacy over continuity. That is a legitimate trade. It is just not the trade most growth teams can afford to make without a second source of truth.
My take: Statable is a strong fit for same-session conversion businesses — e-commerce with short consideration cycles, lead-gen landing pages, newsletter signups — and a poor fit for anything with a long, multi-touch, social-driven consideration path. Know which one you are.
What creators and social teams can borrow from this, regardless of whether they switch
The most useful thing about this launch isn’t the product. It’s the pattern. Three things here are worth stealing for your own stack this quarter, even if you never touch Statable.
1. Put your analytics behind an agent, with a permission boundary
The MCP server is the future-facing part. If you are already using Claude or Cursor for content work, the ability to ask “what pages did my TikTok traffic land on last week and where did they drop off” without opening a dashboard is a genuine workflow change. The read-versus-write split is the model to copy: give your agent read access to your data by default, and require an explicit, separate grant for anything that can change configuration or spend money. Most MCP analytics tools, as Dayan noted, “just hand the agent full write access and hope for the best.” Don’t do that with your ad accounts.
2. Keep emails and customer IDs out of your UTM tags
This is a small operational habit with outsized consequences. Vasylenko’s warning is direct: page paths, UTM tags, and custom event properties come back as your site sends them, and while the tool strips query strings from page URLs, it doesn’t strip your UTMs. So if you have ever tagged a link with an email address or a customer ID in a UTM parameter — and I have seen this in real campaigns — you have just piped PII into an AI agent’s context window. Audit your UTM conventions this week. Use campaign IDs, not identifiers.
3. Treat the consent banner as a conversion variable, not a legal checkbox
If a meaningful slice of your traffic is EU, the banner is costing you conversions on every session it appears. A cookieless analytics layer removes that cost for the measurement side. You still need consent for ads and for anything that fingerprints, but you can at least stop losing 10–20% of your data to a banner that exists only because your analytics tool needs cookies. That is a real, measurable win, and it is the part of the privacy-first pitch that pays for itself.
Where my judgment says it falls short
Three things I would want before recommending this to a client.
First, the trust documentation problem. Dayan’s point stands: the daily-salted hash, the stripped query strings, the aggregates-only read access — these belong on the site, not in a comment thread. Until they are documented where a buyer can find them before granting OAuth, the privacy story is a promise, not a spec. I’d wait for that page to exist.
Second, the attribution ceiling. If your business depends on multi-touch, cross-device, multi-day journeys — and most social-driven businesses do — this tool is a partial answer at best. You will need a second source of truth, and reconciling two attribution models is its own job. Don’t migrate your primary analytics to a 24-hour hash and then wonder why your numbers don’t match your ad platform.
Third, the platform coverage question. The source is entirely about websites and subdomains. It says nothing about native social platform analytics — no mention of pulling Instagram Insights, TikTok analytics, or YouTube Studio data into the same view. So the “all your numbers in one place” dream is not what this is. It is the website half of that dream, with an agent on top. That is useful. It is not complete, and the marketing shouldn’t pretend otherwise.
Who is it not for? Anyone whose conversion path runs longer than a day, anyone who needs cross-device identity, and anyone who needs a single dashboard that already ingests native social platform metrics. If that’s you, stay on your current stack and watch this space.
What I’d watch / test next
Here is what I would actually do this week, in order.
Open the Statable Analytics Product Hunt page and read the full comment thread — specifically the exchange between Dayan and Vasylenko about the read-access permission boundary. That thread is more informative than most vendor landing pages. Then, if you have a site with EU traffic and a same-session conversion goal, spin up the free tier and run it in parallel with your existing analytics for two weeks. Compare the same-session conversion counts. If they roughly match, you have a cookieless option worth considering. If they diverge wildly, you have learned something about your attribution model.
Separately, and regardless of whether you adopt this tool: connect one AI assistant to one analytics source via MCP this month, with read-only access, and see whether the workflow actually saves you time. That experiment costs you an afternoon and tells you more about the next two years of analytics than any product launch will. And audit your UTM tags for PII before you pipe anything into an agent. That one is non-negotiable.
