Guide

Product analytics for developers

What developers actually want from analytics: a clean SDK, autocapture, a sane identity model, a typed API, and the option to self-host. Here’s how open-source product analytics fits a real codebase.

Start with autocapture, not a tracking sprint

The fastest way to kill an analytics rollout is to require a big instrumentation project before any data appears. Autocapture flips that: after one init(), the Web SDK records page views, clicks, scrolls, form submits, and even rage and dead clicks automatically. You get a usable event stream on day one and add explicit track() calls only for the domain events that matter — signup, purchase, and the like.

One person, not one device

The identity model is where product analytics earns its keep. Before sign-in, events accrue to an anonymous ID. When you call identify(userId), that history merges into a single profile, and traits like plan or email become filters across every report. The mechanics are covered in the product analytics guide; the practical point for developers is that you call identify() in one place — your auth callback — and the rest just works across sessions and devices.

SDKs you’ll actually use

Pug ships three SDKs today, chosen for where tracking really happens:

  • Web (TypeScript) — autocapture, identity, and custom events in the browser.
  • Flutter (Dart) — typed event methods for mobile apps.
  • Node (server-side) — track server events, identify users, and read profiles and insights.

Native mobile and React Native are on the roadmap. You can see initialization for each on the SDKs page.

A typed API, not just a dashboard

Analytics shouldn’t be a silo. Pug’s API is Connect RPC (Protobuf in, Protobuf out), so a private key lets your own services track events, identify users, fetch a profile, or run an insight query directly. That makes analytics data available to backend logic — onboarding flows, internal tools, billing — rather than trapped in a UI. The platform overview shows how ingest, the pipeline, and reads fit together.

Self-host because you’re the one who’ll run it

For developers, self-hosting isn’t just about privacy — it’s about control. Pug runs as a single Go binary with Postgres, ClickHouse, and NATS, so there’s no sprawling stack to babysit, and the code is AGPL-3.0 so you can read exactly how events are processed. Start on the free cloud, then move to your own infrastructure with the self-hosting setup guide when you’re ready.

FAQ

Common questions

What makes product analytics developer-friendly?

A clean SDK with autocapture so you’re not hand-instrumenting everything, a simple identify() model for tying events to people, a typed API for reads and server-side tracking, and the option to self-host so you own the data and the deployment.

Which SDKs does Pug provide?

Three today: Web (TypeScript/JavaScript), Flutter (Dart), and Node (server-side). Native mobile and React Native are on the roadmap. The Node SDK can also read profiles and run insight queries with a private key.

Do I have to instrument every event by hand?

No. The Web SDK autocaptures page views, clicks, scrolls, form submits, and rage/dead clicks after one init(). You add explicit track() calls only for domain events that matter, like signup or purchase.

Can I query analytics from my own backend?

Yes. With a private key, the server-side SDK can track events, identify users, fetch profiles, and run insight queries — so analytics data is available to your own services, not just the dashboard.

Built for developers

Web, Flutter, and Node SDKs, a typed API, and self-hosting under AGPL-3.0. Free during open beta.