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 Android, iOS, and React Native SDKs are in active development and land by launch while Pug is in open beta. 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 Android, iOS, and React Native SDKs are in active development and land by launch while Pug is in open beta. 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.