// the find
talivia-group/talivia
Open-source, self-hosted revenue-first analytics for founders: web analytics, Session Replay, revenue attribution, and customer revenue integrations. datafast alternative
Talivia is a self-hosted analytics platform that bolts revenue attribution onto standard web analytics and session replay, pulling payment events from Stripe, LemonSqueezy, Polar, Dodo, or Yolfi so you can see which visits actually turned into paying customers. It's aimed at indie founders and small SaaS teams who want a Plausible/Umami-style privacy-friendly analytics tool but with revenue tied to the funnel, not just pageviews.
Splits data across Postgres (Prisma, relational/account data) and ClickHouse (event volume) — the same split PostHog uses, and the right call for a product that has to ingest high-cardinality analytics events without choking the app database. The open-core boundary is stated plainly in the README (Google Search Console, Bing, GitHub activity, social mentions are cloud-only) rather than discovered the hard way after self-hosting. Revenue attribution — first/last-touch tied to actual subscription lifecycle, refunds, and disputes — is a real differentiator over plain pageview counters, not just a rebrand of existing session data. The MCP/Agent Kit (`npx @talivia/agent mcp`) that lets Claude Code/Codex install the tracking snippet and verify live events is a genuinely useful distribution mechanism, not just marketing copy.
Ships with hardcoded bootstrap credentials (admin/admin) and only a README reminder to change them — anyone who forgets, or automates deployment without a post-install step, has an open admin panel. Payment webhook URLs are derived from the incoming request's Host/X-Forwarded-Proto headers; behind a misconfigured or permissive reverse proxy this is a spoofable attack surface, and the README's fix is 'forward the headers correctly' rather than anything enforced in code. There's no migration path off Talivia Cloud into the self-hosted edition — the baseline Prisma migration only works against an empty database, so anyone trying the hosted product first and later wanting to self-host starts from zero. The migration history is young (literally migration 0001 plus two follow-ups), so long-term upgrade stability across schema versions is unproven.